Composable Commerce in use

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 perspective, I will explain the architectural approach here using a specific 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 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.

Where should the journey take us?

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.

What does that look like?

Our technical setup is as follows:

• The Google Cloud Platform is used as the hyperscaler. It not only delivers the front end, but also runs our customised microservices (custom services). Other services and products such as the Google Identity Platform or Apigee etc. are also used.
• Commercetools takes on the role of the headless commerce engine.
• Representation for the headless CMS is provided by contentful.
• The entire backend integration is realised via Microsoft BizTalk.
• Of course, there are many other systems involved, but these are not explained further here.

What the customer sees

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 glue that holds everything together

The entire front end runs against an API gateway, in our case Apigee from Google. There are several reasons for this:

• The customer receives a centralised system for orchestration, controlling and reporting. This is an issue that should not be underestimated, especially with today's MACH architectures.
• We can provide a very homogeneous solution for authentication and authorisation in conjunction with the Google Identity Platform.
• Apigee offers the option of transforming an XML response into a JSON format, for example, and thus making it conveniently available to the front end, especially in the environment of legacy systems. In addition, a system that is not designed for high access numbers, for example, 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 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.

Content of any kind

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 data highway

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.

Conclusion

• The concept of composable commerce allows an iterative and therefore lean approach and is based entirely on the principle: think big, start small, scale fast.
• The correct structure and design of the API and integration layer is crucial to ensure that the iterative replacement process is completed with as little effort and adjustment as possible.
• Even if the architecture is very flexible and course corrections can be made more easily than with a monolithic approach, you should have already given some thought to the target architecture at the beginning and clearly declare the direction. This ensures that the decisions that need 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 proves true: firstly, things turn out differently and secondly, things turn out differently than you think.

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.