Intro
You have just received the Client Functional Requirements:
Build an international platform with multiple websites for multiple countries while expecting a maximum combination of business features, system settings, and external system integrations per country. The SAP Commerce license is already acquired. What do you do next? The decision starts with a good understanding of the business logic for country-specific data:
- Are the business logic and project data (like the product, stock, or price data) common for all countries and the focus is on the localization of the content?
- Does the business logic vary depending on the country?
- Is there more than one brand or channel involved?
- How is the UX/UI handled for different storefronts, per country/brand/channel?
Keep in mind the 3 main Cs – Content, Customer, Country – of an e-commerce internationalization platform and how can they impact your solution:
Content is the key to an internationalized multi-site context. Creating the proper content can be achieved through an adequate CMS (Content Management System). Choosing a proper CMS is the key to creating good content, to offer editors a strong tool which eventually results in lower costs compared to other market Competitors’ tools. You need to discover what Customer segmentation looks like, understand their behavior and level of engagement starting from their Culture and through Customer Service and Communication. Different Channels and Currencies arise for different Countries. Good knowledge of KPIs help to put into context the Conversion rates.
Challenges
When dealing with complex requirements, the best way to go forward is to have a well-defined plan. In the next sections, we will see 3 different approaches offered by SAP Commerce to solve our requirement. Before that, I propose to have an overview of the challenges we might face:
- How to manage the Product Catalog(s) and Content Catalog(s)?
- What to re-use between countries/brands/channels?
- What is different between countries/brands/channels?
- What is the long-term plan/strategy?
Overall approaches
SAP Commerce offers three general approaches for multi-country setup: multi-site, multi-tenant and multi-instance. In the next sections, you can find a detailed overview of each of them, along with pros and cons.
Multi-site setup
In this setup, one single SAP Commerce instance could deliver the websites for 2 or more countries or a brand-country-channel combination. The same SAP Commerce instance would have:
- Multiple product catalogs (derived from one common/master catalog)
- Multiple sites (each with its own catalog)
- Multiple warehouses and stores
- The same codebase and set of extensions, which leads to:
- Same integrations
- Same functional flows
- Integrations and flows enabled per country/channel/brand through so-called feature toggles.
Pros:
- Low development cost and speed to market for a new storefront.
- Easy code to maintain
- Country representatives have the flexibility to independently manage their catalogs
Cons:
- Requires a common development partner to distribute the knowledge sharing
- Potential Extension overload, to ensure limited regression tests.
Multi-tenant setup
In this setup, one single multi-tenant SAP Commerce instance could deliver the websites for 2 or more countries or brand-country-channel combinations, by ensuring that each website has its own tenant. The same SAP commerce instance would have:
- Multiple tenants, each with its own: catalogs, sites, set of enabled extensions
- Isolation of data between tenants
- Option of using separate databases
- Option of setting individual time zones and locale settings
- Same codebase, with the option to have dedicated extensions per tenant.
Pros:
- Low development cost & speed to market for a new storefront
- Reusable code/extensions
Cons:
- Scalability limits
- Outage or deployment of new functionality/tenant affects all regions.
- Additional configuration to avoid a clash of resources (definitions, localizations) for Backoffice Platform
- It isn’t possible to use different versions of SAP Commerce per tenant
Multi-Instance setup
In this setup, there are different SAP Commerce instances, running different codebases, each targeting a certain country or brand-country-channel combination. The different SAP Commerce instances may run:
- The same codebase (with different configurations)
- Different codebases with potentially reusable shared extensions (if needed)
- Different application lifecycle
Pros:
- Flexibility and speed: you do not have to manage common code base, process variations, regression
- Independent performance tuning
- Assume Centralized Common Development Team and Code Base/Reusable extensions
Cons:
- Requires a common development partner.
- If not: Potential high development cost and speed to market for a new storefront and limited re-use opportunities: requires a very strong governance
- Recurring costs, maintenance/support
A success story
“Wait. You have 400+ websites running in one single SAP Commerce instance and an automated Rollout Process?”
I get this question very often as a reply to: “What is your project about?”. And I am always more than happy to share an overview. From a functional point of view, the websites are logically separated into areas like Marketing Campaign, Outlet, and Customer Account. But the separation is not in a hard way – which means one page contains items exclusively from one area. Instead, every page can consist of several components, with every component belonging to another area. From a product/catalog perspective, the following key facts were considered when designing the architecture:
- There is one master catalog (with one catalog version) in the system which contains all products.
- For every website, multiple product catalogs contain the category trees and the product assignment to the category.
- There is a global content catalog from which the common content is distributed to country-specific catalogs.
- Every website has its content catalog that country editors can customize accordingly.
- Due to a lot of AJAX calls and CMS components with content from different areas, it is possible that parallel requests need a different product catalog enabled. For example, on the same page, a banner with products from the Shop area is displayed, whereas the footer contains category links referencing the Customer Service area. This challenge was solved through the implementation of a custom context. Such a custom context holds all the information needed by the website to display the components about the same Page, but for completely different areas: user group, store, brand, country, currency, language, and so on (based on the project’s concrete needs).
- The challenge of different functionality per country/brand was handled through the use of so-called feature toggles – only when enabled, the feature implementation is triggered.
Going back to the three General Approaches from SAP Commerce, you might have noticed that the solution chosen here is the Multi-Site setup. Based on the complex requirements, it was the best fit.
Conclusion
SAP Commerce offers three General Approaches for implementing an international platform with multiple websites for multiple countries. Choosing the best fitting solution is always challenging, but having a well-defined plan and a detailed overview of the approaches will guide you into selecting the proper one.