or how an MVP can be used to lay the architectural foundation for the future overall solution.
After Cuno has given an overview of what composable commerce is and Michael has also discussed the advantages and challenges of this concept from a business point of view , I will explain the architectural approach using a concrete example.
Why a change is pending
The customer’s current shop system is an all-in-one solution and has been in use for several years. It was only recently updated to the latest version and the UI also got a refresh. However, it is not designed for multi-brand or multi-country. This means that for the customer’s intention to establish a new brand in a new market, you would have to take a copy and place it next to it as a second system. The copy&paste approach would certainly be the simplest variant to implement, but from a maintenance point of view or from the potential of the synergy effect, it is definitely the wrong approach. Also with regard to the further expandability with an additional brand and/or market.
Where do you want to go?
The new solution is based on a modern and modular tech stack and is designed for multi-brand and multi-country from the outset. After the successful rollout in the new sales area, it will also replace the old solution in the existing market. The new architecture allows as much as possible to be covered by shared building blocks and specific solutions are used where necessary or where differentiation really matters.
What does that look like?
Our technical setup is as follows:
- The Google Cloud Platform is used as a hyperscaler. It not only delivers the frontend, but also our customer-specific microservices (custom services) are operated on it. In addition, other services or products such as the Google Identity Platform or Apigee etc. are in use.
- commercetools slips into the role of the headless commerce engine.
- Contentful is responsible for the representation of the headless CMS.
- The entire backend integration is implemented via Microsoft BizTalk .
- Of course, there are many other systems in play, but they will not be explained further here.
What the customer sees
The frontend is modular in the Atomic Design System and is completely detached from the backend. It is important that both approaches of Client Side Rendering (CSR) and Server Side Rendering (SSR) are supported as needed. Such requirements can be implemented very well today with frameworks such as next.js in the React or nuxt.js in the Vue environment.
Because differentiation can or should happen in this area and therefore very independent building blocks can be created, it is important to think in advance about where things are going in the same direction, e.g. to establish a shared component library.
The glue that holds everything together
The entire frontend runs against an API gateway, in our case Apigee from Google. There are several reasons for this:
- The customer gets a centralized system for orchestration and controlling or reporting. This is a topic that should not be underestimated , especially in today’s MACH architectures.
- We can solve authentication and authorization very homogeneously in interaction with the Google Identity Platform .
- Especially in the environment of legacy systems, Apigee offers the possibility to transform an XML response into a JSON format and thus make it conveniently available to the frontend. In addition, even a system that is not designed for high access numbers can be easily equipped with appropriate caching.
Would you like anything else?
The Commerce Engine, in our case commercetools, takes care of the delivery of the sellable units, the so-called SKUs (Stock Keeping Unit), compared to the frontend solution. The preparation of all product data such as images or product descriptions including technical features, etc. is preferably done in upstream systems such as Product Information Management (PIM) and Digital Asset Management (DAM). A very crucial and labor-intensive point, but one that is often underestimated. The sales price and stock are also kept in commercetools and serve as a first point of contact. Depending on the application, however, there are still expansion stages in this area, for example, to obtain the stock directly from the leading system and to use the stock held in the Commerce Engine as a fallback, unless a response comes within a reasonable period of time.
The eCommerce solution offers a search function including facets out of the box, which can be used for a classic search. If the demands in terms of product recommendation increase, other services such as the Google Retail API or products such as algolia and constructor.io can be used in this architectural approach without completely bending the solution as is the case with classic monolithic systems.
Last but not least, the transactional process is also one, if not the most important part of the solution. I.e. from the provision of the shopping cart with the corresponding calculation including the functionalities required for the enrichment of the required information during the checkout process so that an order results from a shopping cart.
Content of any kind
To manage the CMS part, the choice fell on contentful. This is the biggest change for customers who are used to a classic CMS. Not only in the operation, but also in the mindset. Especially when it comes to operation, today’s representatives of headless CMS systems have recognized the demands of the users and now offer users comfortable editor solutions such as contentful offers with their Contenful Studio .
Due to the simple possibility of storing structured data, we use contentful not only for the storage of classic content for the website or shop, but also settings and configurations for the entire system can be managed in it.
Another use case is, for example, store data with images, opening hours, etc., which can be organized centrally and made available to different recipients such as the store locator on the shop page or the independent website of the store. A small note here, a radius search for the store search can be implemented directly on the API of contentful , for example.
The Data Highway
The integration layer is BizTalk from Microsoft, which in our example has been in use at the customer for some time and provides us with the data from ERP, PIM , etc. Especially in our case, middleware makes sense, as changes from the aforementioned systems only have to be processed once and can then be played out independently to the different consumers or shop systems. In addition, the data comes from different ERP systems and can be merged and standardized at this point. Thus, not every recipient has to deal with the same topic with their own logic. Another point is error handling, which is channeled at this point.
Result
- The concept of composable commerce allows for an iterative and thus lean approach and is based entirely on the approach: Think big, start small, scale fast.
- The correct structure and design of the API and integration layer is crucial in order to complete the iterative replacement process with as little effort or adjustments as possible.
- Even though the architecture is very flexible and course corrections can be made easier than with a monolithic approach, you should have given some thought to the target architecture right from the start and clearly declare the direction. So that corresponding decisions that have to be made along the way lead to a better result. However, the overall solution definitely does not have to be specified in every detail and for every eventuality, because as is so often the case, the saying comes true: Firstly, things turn out differently, and secondly, than you think.
And if you now also think that things should turn out differently than what is possible today with your system… contact us, we will be happy to help you lay the foundation for a sustainable and future-proof solution.