Gone are the days when online shops were built with one massive program. Now, one can select a distinct provider for every software segment, thus creating a unique e-commerce world. Or can they? A new trend is on everyone's lips: MACH! In German that means "Do it!" … But what exactly are we supposed to "do"? And what does it have to do with Composable Commerce?
In our post, we delve into what MACH entails, its potential benefits in e-commerce, but also the drawbacks it currently carries.
Composable Commerce
Until now, a typical "online shop" project involved collaborating with a service provider to develop an extensive application (the online shop) covering all crucial aspects: product catalog, search, ordering and payment process, and order and customer data management.
A disadvantage of these monolithic solutions is the dependency on a single manufacturer, whose updates affect the entire application.
Composable Commerce aims to modularize this monolithic structure and make the individual parts interchangeable.
Technically, it's about separating the components of an eCommerce system (such as shopping cart, payment processes, product data management, and search) from each other and connecting them via APIs so that each section can be expanded, replaced, or optimized independently, without affecting the rest of the system.
The apparent advantage for the retailer is to be able to search for a specialized provider for each aspect and ultimately compile their own solution without depending on a single provider.
The Foundation: MACH Architectures
MACH architecture (Microservices, API-first, Cloud-native, Headless) is the foundation for Composable Commerce.
The concept is quite simple: each part of the system ("Microservice") operates independently and communicates exclusively via defined interfaces ("APIs") with the other components. These components are designed for deployment on distributed systems and leverage their advantages like scalability, reliability, and cost-efficiency ("Cloud-native").
The separation of frontend (the user interface that the customer sees) and backend (like data management and business logic) allows independent further development of each component ("Headless").
The MACH architecture primarily aims at investment, a secured future, and maximum flexibility.
MACH Alliance
However, one challenge of this approach is the collaboration of various manufacturers and service providers. To coordinate this collaboration internationally, an alliance has been formed, providing educational work and certifying service providers. This is intended to make it easier for companies to commission providers who understand and can implement the MACH standards.
Composable Commerce Projects
Many service providers suggest that with Composable Commerce, all components are ready and just need to be "put together". However, implementing such a platform requires both internal and external expertise in terms of both the industry and the technology. Therefore, the application itself must be programmed — and here lies the actual work: the program code, which connects all these microservices via their APIs, must be precisely planned and developed.
This is where the "composable" aspect comes fully into play, as we can decide which components from which provider we want to connect. Search? Algolia! — Product catalog? Magento! — Shopping cart and payment process? Commerce Tools! ... and the list of possibilities and decisions to be made does not end here.
Even after this decision, the possibility remains open to exchange the components in a few years if a more suitable solution is found.
Dependency Hell - Fool's Gold!
Even if all of this sounds like shining gold, closer examination reveals: it's just fool's gold. Because the interchangeability of components often praised in advertising is not currently available.
Many providers already include their own components and advertise a closed system. Yes, it is composable; but no: I cannot easily combine any manufacturers at will.
A crucial technical prerequisite for this interoperability is, as often: standardization. And precisely this is currently not available. There is no DIN "product catalog" defining data formats for the exchange between components. It's not even standardized which API commands (so-called endpoints) must be communicated.
Thus, at the moment, each manufacturer has their own API with their own formats.
And at this point, the great advantage of composable commerce is currently lost. One is trapped in provider dependencies and cannot simply replace components without ordering development work for the integration again.
The Costs of Composable Commerce
It's often said that costs with modern architectures should be lower in the long term than with classic monoliths. This effect comes into play nowadays – if at all – only in rare exceptional cases.
In many cases, MACH architecture means a significantly higher demand on companies and people. Additionally, integrating new functions often means working on several of these components. Usually, different teams then have to be coordinated.
So, when the entire system has a bug, the search begins in distributed systems. Is it the application itself? Or one of the components? If yes, which one? Is it the sole cause of the problem, or do several issues in different components need to come together to trigger the error? The error search is thus much more difficult in these distributed systems.
All these challenges also raise the required budget of the project. A cost-saving only occurs in doubt when everything works smoothly — a rare state.
Thus, the difficult question remains of how to realize your project with a view to the future and what budget you want to put into it.
Quo Vadis?
As long as the major players of the MACH Alliance do not all sit at a table and decide that the welfare of the retailers should be placed above their own financial interests, one has to live with the sour taste of microservice-based monoliths. Only with established and certified interfaces and data formats can the full potential of Composable Commerce be exploited in the future.
An Opportunity - but with Consideration
Even today, existing monoliths are equipped with additional components, bringing new capabilities to existing systems. Algolia is an excellent example of how an external provider can replace and drastically improve the shop's search. Such solutions work reliably and cost-effectively.
However, the integrations are always tailored to the respective system, sometimes even to the individual use case. But they beautifully show that the idea of "Composable Commerce" is heading in the right direction.
So it remains exciting, and ultimately time will tell whether the MACH Alliance will establish common standards that find cross-industry support. At the moment, companies need to take the time to understand the possibilities, impacts, and costs to make an informed decision. Every hype should be critically questioned, and always remember that technology should always be a tool for the company; not the other way around.
Rico Neitzel is Co-Founder of run_as_root GmbH in Germany. We specialize in software quality automation and high quality software development. We primarily focus on ecommerce.
Top comments (3)
A couple of clarifications:
SOA (Service Oriented Architecture) was designs to have interchangeable components. That was never realistic and was probably why it lost popularity. Composable Architecture takes this reality into account, SaaS services want to innovate and therefore must make new API contracts to support that innovation.
I can understand the confusion as you mentioned Magento which claims to be composable, but is really just a headless monolith. You also mentioned commercetools who is also headless, though built on microservices. Check out composer from Elastic path, it gives you the functionality for a composable experience.
Second, MACH is a marketing term and the MACH alliance is a membership system where you have to pay into the fund to participate. I love the idea of "providing educational work and certifying service providers", but in reality there are many products, companies, and open-source solutions that will never be certified simply because they don't want to (or can't afford to) pay the fees.
Love your article, thank you :). It's kinda sad, that the marketing vibe is so aggressive and the forecast for projects is often not realistic. It feels similar to the Microservice bubble a few year ago. Or crypto...
I did not expect to see such kind of alliance 😁