We designed an architecture that combines maximal flexibility with minimal duplication of data and assets.
The 3 main ingredients of the architecture are:
The ERP Layer
The in-house built ERP consists of 4 separate instances. Each instance has different prices and business rules that apply to one of the 4 main business areas: Liquor / Perfume / Food / Retail. The ERP feeds the system with Product data, Prices, Promotions and Customer data.
The Experience Layer
An architecture that is capable of supporting multiple Bloomreach sites.
This allows different business to create their own unique experience OR to cooperate on the same if their business is very similar.
A completely component-based frontend functionality.
From the start we added each component to a library that can be reused across the organization, in all Bloomreach channels. When necessary, we add configurable options to the components to support specific needs of different BU’s, minimizing the number of different component versions.
Decoupling of visual design and functionality.
Since each BU has its own look and feel we start the design-process for each BU with a brand-intake. In fact, for several BU’s we created a completely new branding: Anker Amsterdam Spirits, B&S HTG, Hellwege, Square Dranken. Each BU-specific branding is applied to the generic components, resulting in a unique look and feel for each of the BU’s.
The Commerce Layer
Consisting first on a headless, service-based, E-commerce foundation based on the Commercetools’ ‘PaaS’ solution that serves up to date, customer-, product-, price- and stock data coming from the ERP and is in charge of transactions.
In addition, a custom ‘B&S Commerce layer’ that combines the data from Commercetools and business rules from the ERP -instances. This layer makes sure that all data that is served to the frontend is specific for the BU that requests it. The commerce layer is based on the following principles:
- Reusability: Bases on a generic data model that can be extended to provide specific business unit context.
- Statelessness: Commerce Layer is not connected to any database.
- Loose Coupling: All services are exposed using an API
- Extensibility: All modules should be extendable to apply specific BU functionalities. (e.g. Cart validation rules that are different against BUs). To achieve this, the Commerce Layer is Business Unit aware.