Interest in composable and headless architecture for e-commerce solutions has grown enormously in recent years. Composable offers many benefits but also comes with costs that are often not talked about. In this article I want to give a balanced view of the pros and cons of the different paths available when you shape your systems landscape.
In recent years interest has grown enormously in composable/headless architecture for e-commerce solutions. Composable offers many benefits but also comes with a cost that is often not talked about. In this article I want to give a balanced view of the pros and cons of the different paths available when it comes to shaping your systems landscape.
Previously it was known as headless, and that term is still used relatively often, but it is a rather misleading name. Trying to explain added value through a word that takes something away, the head, is hard. It is not obvious what the value is of removing the head. You have to have quite a lot of knowledge and experience to understand why it is interesting.
Composable, on the other hand, gives a better picture of where the value lies: being able to compose together different systems and even individual functionality to work together. Which is a fairly clear contrast to previous-generation systems where everything sits together and it is hard to break out parts of functionality and use other systems for them.
Having a composable commerce architecture means that the systems in your systems landscape are built to be able to work together. Not just that they can work together, but that it is a big part of the system's value proposition. A composable commerce system should not just be easy to integrate with, they should have thought about ways you may want to do things before you have done them. Such a system should also be open with its data. Changes in the system should be exposed so that other systems can listen for it and in that way build a common flow across several systems.
But composable commerce is not just requirements on the systems you choose, it is also requirements on how you implement it. The point of composable is nimbleness and being able to swap out parts as needed. Whoever puts the parts together has to know how it should be done, otherwise you quickly end up with a masked monolith.
Over the past twenty years the trend has been that as an e-commerce operator you switch platforms roughly every five years. Sometimes even every three years. That platform switch often leads to a big multi-million project, and because you previously chose a system where everything sits together you have no choice but to swap everything, even the parts that actually worked fairly well. You chose a system that sounded good five years ago, but over time you hit the ceiling and realise you need to switch again. You invite tenders and listen to different platforms' and vendors' sales pitches and pick an option that once again sounds good. Then you set the alarm clock for five years from now, when it is time again.
In its way it is good with a recurring spring clean, but the biggest problem here is that you are also forced to tear out the parts you think work well. And instead of just getting teething problems in the new parts, you get teething problems in the whole solution. The value of composable commerce lies in instead picking out systems with clear, composable properties and yourself, or together with a partner, putting them together into a working whole. If you do this right, you radically reduce the risk of having to do a big multi-million project again where everything is to be swapped. Instead you can swap and change the constituent parts over time. That increases both your nimbleness and flexibility and makes it easier to keep up with increasing and changing demands from your customers.
Using LEGO as an analogy is worn out but here it works very well. Composable commerce is like buying a bag of LEGO bricks without getting a description of how it should be put together. It opens fantastic possibilities if you have the patience, the creativity and the knowledge of how to put the bricks together in the right way.
Here it is incredibly important to pick a partner you can trust. The word partner is important, rather than vendor. Because the point is that you should live with and refine this solution over many years, you should find someone you can have a collaboration and partnership with over the whole journey, not just someone who comes in and does an initial project for you.
If you have ambitions of doing it yourself with your own development capacity, it is important that your team has the right experience or that you hire in that experience. It is tempting to think that it is easy to put LEGO bricks together, they are shaped to be put together after all. Surely anyone can do that? The hard part does not lie in putting two of the bricks together, the hard part lies in making the whole right. It is easy to set your sights on the Sydney Opera House but instead end up with the municipality building in Svalöv.
Step one is to understand why you need composable commerce. If your reason is that it seems to be the new black, and everyone else seems to want it, then it is not time for you yet. You first have to experience and understand the problems composable commerce solves before it is time. If you do not suffer from the problems composable commerce solves, the risk is that it becomes a net loss for you, because composable commerce, as I said, comes with its own challenges.
Step two is to really identify what your USPs are. What is it that makes you a better e-commerce operator than your competitors? The more of your USPs that need strong technical support, the greater the probability that composable commerce is right for you. This is because the probability of finding one single system that can solve all your USPs is fairly small. You will need to put together several systems.
Step three is to get a deeper understanding of what composable commerce means for you. What possibilities it can open up for you and your business specifically, but also what risks it involves and how those can and should be avoided.
As usual, there are no silver bullets, there are only different trade-offs. With composable commerce it is a trade-off between getting a long-term and flexible solution against having to invest more up front in the solution. Both in terms of money, but perhaps above all in terms of learning what it is you are getting and how things fit together.
The alternative is to turn to a platform that is much more standardised and finished. The trade-off there is of course that much less is required of you as an e-commerce operator to get going, at the cost of your flexibility decreasing. A mistake I see many e-commerce operators make is to pick this path without really understanding it. It feels so safe and good to pick, but then you get frustrated at hitting the ceiling, and in pure frustration you procure a new platform with more flexibility, but you do it far too early. It is a natural step to go from a standardised platform to a composable commerce architecture, but it is a little too tempting to do it too fast. You look at what other, larger e-commerce operators have done and think you might as well pick the path they picked, but you do it when you are half the size they were when they made the choice. And they perhaps made the choice for reasons that are not relevant to you.
It is easy to see it as obvious that the technology and systems should be adapted to the business and not the other way around. But the key to success is to do both. When you hit the ceiling for what your system can handle, adapt the business temporarily instead to get around that limitation. Here creativity is required, because at the same time you do not want to slap plasters and tape on everything that hurts. The point is to find ways to turn disadvantages into advantages.
That buys you time to make the right decision when it comes to your system choices. And perhaps you find paths that mean you do not even need to switch systems. Very often big platform decisions are made on very loose grounds, and you have not sufficiently analysed whether it is really needed and where the bottlenecks actually lie. Because you are so wounded by the challenges you have in daily life, you blindly trust that the new platform will handle everything and a bit more, in pure TV-shop euphoria.
Standardised platforms and composable commerce are in many ways each other's opposites. When you are choosing a system, it is very tempting to look at the middle options. The ones who say they have the best of both worlds. The reality is often that instead you end up with the worst of both worlds, with higher project and development costs than expected but still not enough flexibility.
E-commerce is a many-billion industry that just keeps growing, but it is surprisingly few people who really know what they are talking about. There are many who want to sell things to you, but the probability is that they do not know more than you do, they have just learned to say the right things. Ask lots of questions, because the probability is that everyone else is wondering the same thing but no one dares ask. And do not accept vague, evasive answers. You know you have found the right person when they are grateful for the questions and answer enthusiastically to share their experience.
Related articles
AI makes it possible to produce code faster than ever, but more code does not automatically mean more value. What AI really does is amplify the skill and judgement already present in the person or team using it. That makes the ability to understand the problem, spot risks and know what not to build more important than ever.
Technical debt is more than a technical concept, it is a business-critical reality that affects everything from time-to-market to customer experience. In e-commerce, where every millisecond and every click counts, the choices you make in your technical platform can have far-reaching consequences. When quick fixes are prioritised over long-term durability, an invisible but growing debt is built up. It affects not only development speed and stability, but at worst can slow the company's ability to innovate and compete. To face the future the right way, technical debt has to be understood, quantified and managed as the strategic investment it actually is.
For many years 'no code' and 'low code' have been pitched as the answer to the integration problem. The promise has been simple: no developers, no code, just draw a few arrows between systems and everything is solved. Read on to see why 'much code' is a better option.
