How companies are preparing for the future with composable commerce
If your software architecture seems sluggish, too complex, not scalable enough, and can hardly 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 to form 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, you will very quickly come across the terms “headless”, “microservices”, “cloud”, “SaaS” or “composable commerce”. These are properties and components of system architectures that have been able to establish themselves on the market in recent years. They are a reaction to the monolithic applications that used to be very common.
The “all-in-one solutions” were not so popular for nothing: 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 unified code base makes life easier for developers. Especially the initial setup of such systems is relatively simple.
But therein lies the big weak point. A massive block of software that is supposed to meet all requirements quickly becomes complex and inflexible due to the many dependencies. This makes it difficult to respond quickly to new needs or incorporate new technologies. It’s often not possible to scale only certain parts of the application without impacting 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 sector, 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 keeps the data on products, availability, prices and customers in backend systems. However, 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. However, they share the processes behind it.
The advantage is that the backend application can be used in different use cases and the developed logic is thus reusable. What the use cases look like in concrete terms does not matter and can be completely different, which is why you 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 (called “microservices”), each of which performs a specific function. Each microservice is developed as a standalone 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, specialized services. Each microservice is self-contained and can be developed in any programming language or technology. It is important that he can communicate via an interface. This allows teams to 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 scale independently of the next to handle the particular load it handles.
Composable Commerce – Shop according to the modular principle
Against the background of these developments, it is only logical that something is happening in eCommerce as well. Shop systems in particular have to map different business logics. They bundle complex information and usually interact with other peripheral systems. No wonder, “Headless & Co.” are also finding their way into this world. In eCommerce, the term “composable commerce” is now becoming established.
Composable commerce describes a modular architecture based on (micro)services that gives companies the opportunity to combine different functions to create a customized eCommerce solution. The services are bundled based on their business capabilities. This is why they are also referred to as “Packed Business Capabilities”, or PBCs for short.
Examples of PBCs in the eCommerce environment are:
- Commerce
- Content and Assets (CMS / DAM)
- Customer Identity and Access Management (CIAM)
- Analytics
- Payment Provider
- Product Recommendations / Personalization
- Search
So you integrate those services that you need and that best meet your own requirements.
An example of such a composable commerce landscape could look like this:
MAKE a shop out of it for me
So how do the different elements come together? The figure above already contains a proven architectural approach that combines 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 for providing business functionality that can be developed, deployed and maintained independently.
A (API): All 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 effort, scaling and automatic updates are outsourced.
H (Headless): Frontend is built decoupled from the backend and is therefore channel-independent and not bound to special technologies.
If you want to learn more about this approach, you can find it at the MACH Alliance (https://machalliance.org), which 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. Be it tools from one or more manufacturers or, in individual cases, in-house developments, all components can be networked with each other via APIs and thus put together to form a powerful overall system.
With such an overall system, short-term needs such as peak loads can be reacted to immediately (temporary performance increase of individual microservices). In this way, future changing 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 rethink is needed
Why does it still take time and a little courage to use these developments for yourself and establish them in your own company?
To get composable commerce off the ground, you need more than just functioning individual parts. An important success factor is the overall architecture, and therein lies the first challenge. The topic of architecture has changed a lot compared to that of monolithic systems and therefore those responsible often lack experience in this area. However, the design of a highly modular system is very complex and requires a lot of consideration.
Once you have overcome this hurdle 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 have to be adapted. This can be associated with tensions with the departments concerned that should not be underestimated: the product managers, the sales people, the service staff, … everyone wants to have a say, get the best out of their area and not submit to any IT system. This is where change management is needed to create an understanding among the people affected of what exactly these changed framework conditions mean. Together, you can then discuss the advantages and simplifications that arise from this and what changes are necessary in the usual cooperation and processes.
When the change manager has done his work there, he can already move on to his next clients: those who operate the systems will certainly have gone to the barricades by now. CMS without a WYSIWYG experience, CRM without an integrated newsletter tool, five different non-branded systems to publish a news?! That can cause trouble. If you’re lucky, you’ll find a nice developer who provides users with technical helpers that make it easier to use. But then the CTO is already on the mat 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 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.
This is the only way to ensure that composable commerce is not only based on the best technological foundation, but is also actively used and further developed by all important stakeholders. This is the real foundation for a future-proof eCommerce solution.
Upcoming articles on the topic
Michael Schlegel-Iten will use our experience to go into more detail about the advantages but also challenges of composable commerce from a business perspective.
There is also an article for all techies, in which we 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 expertise to support you in an eCommerce or other project in a targeted manner. We accompany the path to a modern and future-proof 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.