Composable commerce is a modular way to build digital commerce solutions. Rather than buying an all-in-one (aka monolithic) platform or building a completely custom application, developers can choose and connect highly specialized components that better fit the clients’ needs. Through this approach, brands can improve their customer experience and increase sales.
A key promise of composable commerce is that it will eliminate vendor lock-in and remove the need for replatforming. Businesses running on monolithic systems can improve their platform’s capabilities incrementally instead of having to replatform to another monolithic solution, which is a costly, time-consuming, and risky process. Furthermore, they can swap out different components as their requirements (or budget) change, future-proofing their stack.
It is mandatory for every component to be API-first when building a composable stack. However, choosing API-first components alone may not be enough to avoid vendor lock-in. Given the same set of components, there's a good chance that they'll be integrated in two different ways by two different developers. Thus, there's no unique way to swap out a component and replace it with another one, which poses a real risk to building your own monolith.
To achieve true composability, we would need a protocol that defines how the different components interact—content, commerce, search, personalization, payments, etc. In addition to being API-first, each component should also adhere to that protocol, so that it could be easily swapped out with an alternative one implementing the same protocol.
The first time I thought of building a "commerce layer", it was with the aim of creating such a protocol. Over the years, ecommerce had become so important that the OSI protocol needed to add an additional layer on top of the seven layers defining how different machines exchange information over the Internet. I know, it was that ambitious. Then the project changed direction and became a company and a product. Yet the name and the idea of defining a highly unopinionated model remained.
In spite of this, it is impossible for a single entity to define a new protocol. In order to eliminate vendor lock-in, multiple stakeholders and experts must collaborate to develop a common set of guidelines and processes that don't favor any vendor or technology. Today, that group of experts might be the members of the MACH Alliance, the organization that promotes the composable approach and helps companies adapt to ecommerce development's new era. We, at Commerce Layer, are proud to be part of this group of vendors and could contribute to the definition of such a composable protocol, resuming our name's roots.
As stated in our collective manifesto, part of the MACH Alliance mission is to “publish technical documentation, such as architectural blueprints and other technical content, demonstrating how to integrate MACH technologies.” Currently, the MACH Alliance is doing a superb job of certifying that the individual members adhere to the MACH principles, which are that they should be microservices-based, API-first, cloud-native SaaS, and headless. As a next step, I believe we should define a MACH protocol and enhance the admission criteria to adhere to it.
A MACH protocol would not only prevent vendor lock-in, but would also simplify stack composition. Today, integration between components is very much dependent on the skill level of developers building those integrations and architectures. The most progressive digital agencies and brands are leading the way. By establishing a MACH protocol, the adoption barrier could be lowered, composable commerce could be made accessible to everyone, and even no-code composition services could be made possible.