Composable Commerce

Composable Commerce. After the covid rush, this is the new buzzword in ecommerce. The thing that will save us all, that will make our shops unbeatable, our conversion rates flying and it will give us more freedom then we could ever dream of.

But does it really? The answer is YES, it really is the best thing that has happened to commerce tech in years - but only if it is done the right way.

Unfortunately, in the last months I have seen so many agencies and tech companies claiming to do Composable Commerce, while actually they are just using the word to gain momentum and sell you the same old legacy stack you’ve been dealing with forever. They are gaining fame by using the word Composable Commerce, while at the same time bringing disadvantage to merchants, and harming the reputation of real composable commerce.

Let me explain:

• Building a frontend and connecting a commerce engine and some services with some API’s is NOT Composable Commerce. It is headless commerce. 

• Using a commerce engine with a headless frontend and then connecting a cms to that engine is also NOT Composable Commerce. It’s still headless with an API connected cms. 

• Using a commerce engine and adding a bunch of services via plugins is NOT composable commerce. It is a traditional monolith with plugins.

• Using a commerce engine and connecting a ‘middleware’ to only talk to your backend WMS or ERP is a more enterprise approach but still with a monolith. 

• The last one: even with everything combined it is still not real Composable Commerce. 

So, what is Composable Commerce?

Composable commerce is the principle of building a platform with several ‘components’ that are used as services.

We have a service for stock (for example our ERP), one for payment (Mollie), a cms (Contentful), an engine for promotions (talon.one) and maybe a custom service for your unique pricing strategy. All these services need to communicate with each other, and eventually with the first service your customer connects with: the frontend(s).

But how do we do that? How do we make all these services talk to each other? Not by connecting them to one service (monolith+plugins) or by connecting to the frontend via direct API’s (headless) .

No, in Composable Commerce we need something that is able to make everything talk to each other, while you still have control. To update, manage, maintain, modify and orchestrate all the data going in and out. We need something that makes sure all these different services work well together, in real time, ánd makes sure we are not depending on one of them. 

And that is the main ingredient of Composable Commerce. The layer so many projects are missing: real composable commerce needs an actual COMPOSER. Like a DJ needs its mixing table, and like a musician needs the director to lead the orchestra. We need something in charge of all these different elements to compose an actual melody.

Only then can we guarantee all the benefits of Composable Commerce: freedom to really choose your best of breed services, freedom to add your own microservices, unlimited scalability, acceleration of new feature adoption, highly personalized digital experiences, and many many more.

So, if someone ever talks to you again about Composable Commerce, it’s really easy to find out if you are getting the real thing: give them a piece of paper and let them draw the architecture they are planning to build for you. If there is not a composer in the middle connecting all the services (including the frontend), watch out. They are trying to fake it till they make it.

Want to know how your plans come to live in a real composable environment? Our architects are ready to dive deep and take you to the drawing board so we can set out the blueprint for your composable commerce strategy.