Composable Commerce

E-Commerce

Another new term. Composable Commerce. Supposed to be the ultimate when it comes to a future-proof approach to technology decisions, according to Gartner. It’s a shame, however, when headless commerce and microservices are already raising question marks, and now yet another new term is being hyped in e-commerce. How is anyone supposed to have a say in that, please? You feel the same way? Then let’s shed some light on the jungle of terms. Here we go!

Headless Commerce was on everyone’s lips in 2013. This was triggered by a report from Forrester Research. In it, the market research firm suggested separating front- and back-ends of e-commerce stores to more flexibly route store data to different output channels for a better user experience. This push led to the gradual replacement of monolithic systems with cloud-based headless technology. Today, the headless architecture includes frontend, backend and APIs. Within the subsystems, different microservices can be deployed, i.e., consisting of a number of small, independent, and specialized services that communicate with each other via defined interfaces and protocols. These services can use different technologies and databases and can be scaled and updated separately.

If, on the other hand, you build your e-commerce solution purely from microservices that communicate via APIs, this is known as a microservice-based application. But now suddenly everyone is talking about the time of microservices being over. Goodbye microservices is heard all too often. Is it perhaps because leading analysts have found that over 50% of microservice-oriented e-commerce projects fail. The reasons can be different, but first and foremost the associated complexity, because many different microservices have to be operated here. This increases the effort required for operations enormously, because once you have lost track of where which service is running, chaos is inevitable. Composable Commerce has become the buzzword of the e-commerce hour. Shall allow for speed and customizability. Two skills that are essential in e-commerce. But what is the meaning of the term, please? Let me back up for a second.

How did Headless Commerce come about?

Today, there is a wide range of end devices (cell phone, tablet, computer, smartwatch or all web-enabled end devices). Therefore, store operators must ensure that their online store can be used via any end device flawlessly and optimized for the respective device (e.g. gesture control to operate the mobile phone without touching it). Means: Adaptation of the online store to any end device. This can best be realized by detaching the data management from the subsequent display. Headless Commerce was born out of this thought. One has literally created an application without a head, i.e. without a user interface, so that one can flexibly design different front ends for each end device.

The great advantage lies not only in the problem-free recording of the end devices and the display variants required with it. Rather, it is about keeping pace with the future, because requirements and technology are known to change incessantly. With Headless Commerce, store operators are therefore able to adapt and further optimize existing front-ends at any time to improve the user experience. The backend remains unaffected by this. Conversely, the backend can also be further developed independently of the frontend. With Headless Commerce, e-commerce companies can respond quickly to changes in the market or in customer behavior because content creators and developers can work in parallel. The catch? Headless Commerce is complex because multiple systems need to be managed. In addition, Headless is shortened by the head of the preview and therefore has no preview function. Thus, previews of changes are not visible.

Wouldn’t an All-in-One Solution be better after all?

I admit it. Managing multiple systems like Headless Commerce can be daunting. One is then more inclined to consider an All-in-One solution. After all, here you have one software for everything. Front- and back-end are united, so that previews are possible. However, it should be remembered that web development and technologies such as endpoints are very fast-moving. So, with an all-in-one solution, you may have an up-to-date backend, but be tied to an outdated frontend. This can have a negative impact on user interaction, as you may not be able to use modern web applications to your advantage. Not to mention that with an All-in-One solution, you are always tied to the given customizability of the monolith. Okay, so what about Microservices now?

A characteristic of Microservices is their decoupling in terms of development and scalability. Thus, each Microservice can be developed, customized or replaced autonomously (for example, replacing Google Translator with DeepL Translator). Failure is also decoupled, allowing one Microservice to continue running when another fails.

The big advantage is that you really get the Best-of-Breed technology for specific use cases, i.e. the best possible solution thanks to fine selection. In detail, Microservices bring the following advantages:

• Scalability: Microservices can be scaled individually as needed without impacting the overall application. This allows for better load matching and resource availability.
• Flexibility: Microservices allow different technologies, programming languages and databases to be used for each service, depending on what is most appropriate. This encourages innovation and experimentation.
• Speed: Microservices enable faster application development, deployment, and updates because each team can work independently on its own service. This leads to shorter development cycles and greater agility.
• Isolation: Microservices reduce coupling between services and increase cohesion within a service. This improves the maintainability, testability and fault tolerance of the application. If one service fails, this does not affect the other services as long as the interfaces are maintained.

Of course, Microservices also have drawbacks. This can be the hashing in the minutiae and an increased effort in the operation. Challenges include:

• Complexity: Microservices increase the complexity of the application because they require more components, interfaces and dependencies. This requires more coordination, integration and monitoring between teams and services. In addition, challenges such as network latency, security, transaction management, and data consistency must be considered.
• Management: Microservices require more effort to manage infrastructure, configuration, and service delivery. This requires the use of tools and platforms such as containers, orchestration systems, and service meshes, which can add additional costs and learning curves

In summary

With an All-in-One solution, i.e. a monolith, I get a complete system including modules. This means that during operation, all building blocks are rolled out together, as they are interconnected and interdependent. Frontend and backend are also united. The opposite of All-in-One solutions are applications based on Microservices. Here I have a system that is composed of individual, independent software modules. I have many different Lego bricks, so to speak, which I assemble individually into an overall construct. Headless Commerce is also the equivalent of an All-in-One solution, but it does not yet represent a true microservices landscape with a backend, APIs, and an external frontend. This is because a true microservices architecture enables complete decoupling of the platform and the service-oriented architecture, whereas with Headless the frontend and backend are divided into individual subsystems, which in turn can contain Microservices.

Champions League: Composable Commerce

Now let’s move on to Composable Commerce. According to Gartner, it’s the future of digital commerce. But if you now think that Composable Commerce is just the tailor-made composition of the best Microservices in e-commerce, you are mistaken. Composable Commerce is about much more, because technology is only a means to an end here. The difference between microservice architecture and Composable Commerce is that microservice architecture is a technical foundation for Composable Commerce, but it is not sufficient to realize Composable Commerce. The entrepreneurial challenge comes first at Composable Commerce. Therefore, the motto is “Outcome First”. This in turn requires a completely new way of thinking. Away from tech focus, toward results orientation. Because only those who are aware of their goals and requirements can make the right technology decision to achieve the desired results (sales, customer loyalty, speed, etc.).

For Gartner, true composability therefore consists of these three components: Composable Thinking, Composable Business Architecture and Composable Technology. As can be clearly seen from the order, thinking comes first. Ergo: Put your challenge first, assign all other decisions to the outcome goal and remain continuously adaptable. But beware of false customizability by combining hyped technologies. What works for one doesn’t necessarily work for you. Think before you compose! This way, you avoid procuring glorified applications and services that may be inappropriate for your use case and add no value.

And yes, technologically, Composable Commerce has all the advantages of Headless Commerce: flexibility, speed, and adaptability. But… Even if the frontend allows all the freedoms, there can be a whole software in the backend of Headless Commerce (e.g. ERP or PIM). We speak of true Composable Commerce or Composable Technology when really all services can be connected and assembled arbitrarily into a user-defined application. Ensuring compatibility between services plays an important role in this context. Therefore, connectors, interfaces and APIs are even more important in Composable Commerce than in Headless Commerce.

One last thing. PBCs. This is an abbreviation for Packages Business Capabilities. In fact, Composable Commerce is an architectural approach to digital commerce where applications are built using PBCs. PBCs are software components that represent a clearly defined business capability and can be functionally recognized as such by a business user. This means the bundling of Microservices. Why? You continue to get good services with PBCs that are just combined because they work well together. For example, a PBC could be a shopping cart and the checkout. PBC gives you full flexibility and saves you the extra effort of picking out needed Microservices one by one.

Note: Microservice architecture is one way to implement PBCs, but not the only one. Other aspects of Composable Commerce include API-first, cloud-native and headless.

• API-first means that the interfaces between the PBCs are defined first, before the implementation takes place. This enables better integration and interoperability between components.
• Cloud-native means that PBCs are developed for use on distributed systems and take advantage of their scalability, reliability and cost efficiency.
• Headless means that by separating the frontend (the user interface that the customer sees) from the backend (such as data management and business logic), independent development of each component is enabled.

In summary, Composable Commerce is a concept based on the MACH architecture (Microservices, API-first, Cloud-native, Headless), but goes beyond it by focusing on business requirements and enabling modular and flexible e-commerce technology from this objective.

So now some advertising on our own behalf: In the report “What Data and Analytics Leaders Need to Know About Composable PIM” published by Gartner in February 2023, apollon is listed as a provider of Composable PIM. Yes, we can also do Composable PIM, but… We don’t blindly implement Microservices because it’s hot right now. We act with caution and implement new technologies only when they actually make sense for our customers.

We would be finished. Was I able to bring light into the darkness? Just write to me: marketing@apollon.de