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 perspective, I will explain the architectural approach here using a specific example.
The customer's current shop system is an all-in-one solution and has been in use for several years. It has only recently been updated to the latest version and the UI has also been refreshed. However, it is not designed for multi-brand or multi-country. This means that if the customer wanted to establish a new brand in a new market, a copy would have to be made and placed next to it as a second system. The copy&paste approach would certainly be the simplest option in terms of implementation, but from a maintenance perspective and in terms of the potential synergy effect, it would definitely be the wrong approach. Also in terms of further expandability with an additional brand and/or market.
The new solution is based on a modern and modular tech stack and is designed for multi-brand and multi-country from the outset. Following the successful rollout in the new sales region, it will also replace the old solution in the existing market. The new architecture allows as much as possible to be covered by shared modules and specific solutions to be used where necessary or where differentiation is really important.
Our technical setup is as follows:
The frontend has a modular structure 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 required. Today, such requirements can be implemented very well with frameworks such as next.js in the React environment or nuxt.js in the Vue environment.
Because differentiation can or should occur in this area in particular and very independent modules can therefore be created, it is important to think in advance about where things are going in the same direction, e.g. in order to establish a shared component library.
The entire front end runs against an API gateway, in our case Apigee from Google. There are several reasons for this:
The commerce engine, in our case commercetools, takes care of the delivery of the saleable units, the so-called SKUs (Stock Keeping Units), to the front-end solution. The preparation of all product data such as images or product descriptions including technical features etc. is preferably carried out in the upstream systems such as Product Information Management (PIM) and Digital Asset Management (DAM). This is a very crucial and labour-intensive point, but one that is often underestimated. The sales price and stock levels are also stored in commercetools and serve as the first point of contact. Depending on the use case, 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 if a response is not received within a reasonable period of time.
The eCommerce solution offers a search functionality including facets, which can be used for a classic search. If the requirements increase, possibly with regard to product recommendation, additional 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 one, if not the most important part of the solution. I.e. from the provision of the shopping basket with the corresponding calculation including the functionalities required to enrich the information needed during the checkout process so that an order results from a shopping basket.
To manage the CMS part, contentful was chosen. This is the biggest change for customers who are used to a traditional CMS. Not only in terms of operation, but also in terms of mindset. Today's representatives of headless CMS systems have recognised the demands of users, particularly in terms of operation, and now offer users convenient editor solutions such as those offered by contentful with its Contentful Studio.
Thanks to the simple option of storing structured data, we use contentful not only to store classic content for the website or shop, but also to manage settings and configurations for the entire system.
Another use case is, for example, the store data with images, opening hours, etc., which can be organised centrally and made available to different users such as the store locator on the shop page or the independent website of the shop. A small note here, a proximity search for the shop search can be realised directly on the API of contentful, for example.
The integration layer is BizTalk from Microsoft, which in our example has been used by the customer for some time and provides us with data from ERP, PIM, etc. In our case in particular, middleware makes sense, as changes from the systems mentioned only need to be processed once and can then be sent independently to the different consumers or shop systems. In addition, the data comes from different ERP systems and can be merged and standardised at this point. This means that each recipient does not have to deal with the same issue using their own logic. Another point is error handling, which is channelled at this point.
And if you also think that things should be different from what is possible with your system today...get in touch with us, we will be happy to help you lay the foundations for a sustainable and future-proof solution.
Contact us