from Cuno Sieber at
How companies are preparing for the future with Composable Commerce
If your software architecture seems too complex and not scalable enough, and can barely keep up with business requirements, it's time for a change.
But what are sensible and sustainable solutions? What is behind the common buzzwords? How do you put the individual building blocks together into a functioning overall architecture?
In the first part of our blog series, we would like to explain some basics.
When researching modern technologies and software, one quickly comes across the terms "headless", "microservices", "cloud", "SaaS" or "Composable Commerce". These are characteristics and components of system architectures that have been able to establish themselves on the market in recent years. They are a reaction to the formerly very widespread monolithic applications.
It is understandable that "all-in-one solutions" have been so popular: Users can manage different data within one tool, do not have to get used to different input user interfaces and often the results of one process step are directly visible in another. The consistent code base makes life easier for developers. Especially the initial set-up of such systems is quite simple.
But therein lies the great weakness. A massive block of software that has to meet all requirements quickly becomes complex and inflexible due to the many dependencies. This makes it difficult to react quickly to new needs or to incorporate new technologies. It is often not possible to scale only certain parts of the application without affecting other areas. At the same time, the entire system comes under pressure when a single part reaches its limits, such as during peak loads in online shops on Black Friday.
A modular architecture consisting of individual components can counteract this. The prerequisites for this are a scalable infrastructure, (headless) services, APIs and well thought-out architectures, which I would now like to explain in more detail. Then we come to the application in the commerce area, the so-called composable commerce.
Headless
"Headless" refers to a software architecture in which the frontend (the head = what the user can see) is decoupled from the backend (the part of the software that contains the actual application logic).
An example: An eCommerce platform holds data on products, availability, prices and customers in backend systems. However, as an output channel there are two different applications that access the same database: a webshop application that runs in the browser and a native mobile application. Both are developed separately from the headless eCommerce platform and can look completely different. Though, they share the processes behind them.
The advantage is that the backend application can be used in different use cases and the developed logic can thus be reused. What the use cases actually look like is irrelevant and can be completely different, which is why we often hear the term "multi-experience" in this context.
Microservices
A microservice architecture is a software architecture based on the concept of individual, independent services (so-called "microservices"), each of which fulfills a specific function. Each microservice is developed as an independent application and communicates with other microservices via an API (interface).
The idea behind a microservice architecture is to reduce the complexity of a large application by breaking it down into smaller, specialised services. Each microservice is self-contained and can be developed in any programming language or technology. The important thing is that it can communicate via an interface. Teams can thus work independently of each other, which can increase the speed of development and the quality of the application.
The microservice architecture is more flexible and scalable than monolithic applications. As an application grows, new microservices can be added to provide additional functionality. Each microservice can be scaled independently of the next to handle the particular load it is processing.
Composable Commerce - Shop according to the modular principle
Due to these developments, it is only logical that something is happening in eCommerce. Shop systems in particular have to map different business logics. They bundle complex information and usually interact with other peripheral systems. Understandably, "headless & co." are also making their way into this world. In eCommerce, the term "Composable Commerce" has become established.
Composable Commerce describes a modular architecture based on (micro)services that gives companies the possibility to combine different functions to create a customised eCommerce solution. The services are bundled based on their business capabilities. This is why we also speak of "Packed Business Capabilities", or PBCs for short.
Examples of PBCs in the eCommerce environment are:
- Commerce
- Content und Assets (CMS / DAM)
- Customer Identity and Access Management (CIAM)
- Analytics
- Payment Provider
- Product Recommendations / Personalisation
- Search
An example of such a Composable Commerce landscape could look like this:
MACH Architecture principle
So how do the different elements come together? The illustration above already contains a proven architectural approach that connects the elements described: MACH. In this combination, the technologies can unfold their potential and therefore form the ideal basis for Composable Commerce.
M (Microservices): Individual applications or services to provide business functionality that can be developed, deployed and maintained independently.
A (API): The entire functionality is accessible via API (interface). Services communicate with each other via the APIs provided.
C (Cloud): Typically, the solutions are no longer self-hosted but operated as a SaaS model in the cloud. This means that maintenance, scaling and automatic updates are outsourced.
H (Headless): Frontend is built decoupled from the backend and is thus channel-independent and not tied to specific technologies.
If you want to learn more about this approach, you can find it at the MACH Alliance (https://machalliance.org), which has developed and certified the approach.
Conclusion 1 - The modular principle makes sense
The advantages of the composable commerce approach with a MACH architecture are obvious: the best applications available on the market (best-of-breed) can be combined for individual business requirements. All components can be networked with each other via APIs and thus put together to form a powerful overall system. It does not matter whether the tools come from one or more manufacturers or have been developed in-house.
With Composable Commerce, it is possible to react immediately to short-term needs such as peak loads (temporary increase in performance of individual microservices). Future changes in market requirements can also be met very quickly and in a targeted manner (integration of new components, further development/expansion of existing PBCs).
Conclusion 2 - A change in thinking is needed
Why does it still take time and also some courage to use these developments for oneself and to establish them in one's own company?
In order to set up a Composable Commerce, more than just functioning individual parts are needed. An important success factor is the overall architecture, and therein lies the first challenge. The subject of architecture has changed a lot compared to that of monolithic systems and therefore those responsible people often lack experience in this area. However, the design of a highly modular system is very complex and needs some thought.
Once you have mastered this challenge and worked out ideas and concepts, the next challenge is just around the corner: the associated business processes probably no longer fit into the new world and also need to be adapted. Which can be associated with tensions with the departments concerned that should not be underestimated: the product managers, the sales people, the service staff, ... they all want to have a say, to get the best out of their area, and yet they don't want to be subject to an IT system. This is where change management is needed to create an understanding among the people concerned of exactly what these changed framework conditions mean. Together, we can then discuss which advantages and facilitations arise from this and which changes in the usual cooperation and processes are necessary.
When the change manager has done his job there, he may already move on to his next clients: those who operate the systems will resist the project. CMS without WYSIWYG experience, CRM without an integrated newsletter tool, five different non-branded systems to publish a news item...! That can be trouble. If you're lucky, you'll find a helpful developer who provides users with technical helpers that make it easier to use. But then the CTO comes along and complains that he is running out of capable developers. How is he supposed to find an experienced commerce developer AND a data science specialist in these times of a shortage of skilled workers? That will be exciting...
The good news is: these challenges are manageable.
There are many ways to provide technical support for the individual steps. Above all, however, it is important to take people along in this process, to take their needs seriously and to support them.
In the end, composable commerce is not only based on the best technological foundation, but is also actively used and further developed by all important participants. This is the real basis for a future-proof e-commerce solution.
Upcoming articles on the topic
Based on our experiences, Michael Schlegel-Iten will go into more detail about the advantages but also the challenges of Composable Commerce from a business perspective.
There will also be an article for all techies in which we will show the suitable technologies and our learnings with a practical example.
How do you like our blog? Write to us: hello@diselva.com
At diselva, we have the experience and competence to support you in an eCommerce or other project. We accompany you on the way to a modern and sustainable software architecture, from the conception to the technical implementation to the introduction of the new system and offer assistance in the coordination of all stakeholders involved.
