Demandware Master Architecture – Is it Right for Your eCommerce Business?
By Robert Ward, Technical Lead
Whether your company is diverse enough to feature multiple brands, or you have taken the leap into internationalization with multiple locales, the odds are pretty good that your Demandware eCommerce solution could require more than one site.
Since multiple Demandware sites can reside on the same realm, sharing a variety of global content and data elements, there is an opportunity to share code as well. The benefits of sharing code among sites are numerous– increased consistency and reliability, decreased time and cost to implement, and simplified maintenance and support.
When it comes to sharing code, one of the ideal ways to make it happen is with a Master Architecture.
What is a Master Architecture?
At its basic level, a Master Architecture just means that there is a core part of the codebase that applies to all (or maybe just most) of your sites. Then, site-specific styles and functionality are layered on top of that.
The core part of the codebase will contain all of the shared features common to the multiple sites. In Demandware terms, this is typically the “storefront” cartridge, which provides the backbone for everything from the homepage, to the product/search pages, to checkout.
The site-specific parts of the codebase will contain the features that apply to one (or a few) of the sites, but not others. This can be anything from the visual look and feel, to unique business logic customizations, to third-party integrations that will not be replicated elsewhere.
Should My Site Use a Master Architecture?
This is where things get tricky. An experienced Demandware architect will be able to make this determination, but there are a few key questions that will help steer you towards an answer:
- How similar are the interfaces on these sites going to be?
While this may seem fairly obvious, the general structure of the pages is a major determinant for the effectiveness of any Master Architecture strategy. For example, if you would like the product detail pages to be similar between the sites, varying more in colors and fonts than in visual hierarchy, then these sites may be a solid candidate for consolidation into a Master Architecture. However, if you would prefer to have a completely different user experience between the sites, to the point where each site needs separate wireframes to be created, applying a Master Architecture strategy may be more trouble than it is worth.
- How unique are the products being sold in different brands/locales?
Even the most well-intentioned Master Architecture can start to break down if one of the sites strays too far from the core feature set. Some common examples of unique product features are:
- Recurring subscription products
- Single page checkout
- Additional steps in checkout to upsell accessories or warranties
- Emphasis on digital or in-store delivery of goods
- Real-time inventory or shipping rules
If the nature of the products is similar among the sites (even if the products themselves are completely different), then a Master Architecture strategy could help prevent you from “re-inventing the wheel,” so to speak.
- How many of the third-party integrations will be shared?
For a Master Architecture to come together smoothly, it is typically preferred to have as many of the third-party integrations in common as possible.
For example, say you want to use the same tax calculation service or payment processor among your sites. In this case, the integration only needs to be implemented once, and then included in all of the sites.
However, if one of the brands/locales functions as a completely separate business entity, with its own established vendor relationships or order management system, it may be wise to develop that site accordingly, making it unique from the others.
- Is your leadership willing to support a shared codebase?
One of the biggest risks with a Master Architecture strategy is when the different business units may have competing goals and expectations. If leadership is not on the same page with timelines, or if each business unit functions as an autonomous silo, co-development and prioritizing releases can be difficult.
Since core components are shared, any change to them typically necessitates regression testing for each of the sites that includes them. As a result, the types of Master Architecture sites that are the most successful are those that have centralized leadership (i.e. a cross-business IT director) capable of performing the necessary coordination.
- Is there a centralized support team in place?
Once the sites launch, the development team (whether outside or internal) will need to understand the shared codebase and not introduce core code that will break functionality on other sites. This requires a fair amount of discipline, and is typically best done by one or more experienced front-end developers who can preserve the shared architecture without implementing one-off “hacks” every time a unique situation comes up.
The more clearly the support team understands the big picture, the easier it will be to continue to reap benefits from the Master Architecture strategy.
Conclusion
When applied correctly, the Master Architecture strategy can drastically simplify the eCommerce implementation process on the Demandware platform. By asking yourself the right questions early on in the process, you can assist an architect in determining if this strategy can benefit you.
Robert Ward is a Technical Lead on the LYONSCG Implementation team, and has been building Demandware sites since 2011. Robert is a certified Demandware Developer, and he is an avid fan of all things basketball-related.
