Composable commerce in 2024 - trend or standard? Monogo E-commerce News 67
A brief introduction to Composable commerce
Ecommerce relies heavily on technology that allows shoppers to access offers and shopping carts 24 hours a day. The explosion in popularity of online shopping has led to a search for new technological solutions to provide flexibility and speed. Speed of both implementation and shop operation.
Before concepts such as headless commerce or composable commerce appeared in the industry for good, we were working on an old and familiar monolith. That is, the ecommerce system was a coherent whole. In other words, one supplier provided all the modules, from the product catalogue, CRM, CMS, integration with payment gateways to the front end.
Over time, interesting solutions started to appear, e.g. CMS, which were well ahead of those provided with ecommerce engines. Having a monolith, it was not easy to add other systems that surpassed the capabilities of those we already had in the shops. For this reason, among others, the composable commerce architecture was invented. It assumes a strong separation of each main function, or group of functions, from the others, as well as from the presentation layer.
What to bear in mind with composable commerce?
The sirens' song about composable commerce does not always include lines about what you need to know, or what you will face when you go towards this architecture. And that's important, because the investment is significant.
- Surely flexibility is so important in your business?
- Do you have enough technical resources to build/integrate composable commerce?
- Are you ready/ready to work with multiple suppliers and are they mature enough to work together?
- Is investigating performance issues or bugs across multiple tiers/vendors a powerful challenge for your organisation?
- Are you ready/ready for a significant upfront investment (given time and budget)?
Initial cost of composable commerce
The budget to be prepared at the outset is significantly higher than monolithic solutions or Modular Monolithic Architecture. This is due to the fact that each module must be purchased (its licence), then integrated after the API with other parts of the system, and the frontend. This means a longer time-to-market and a larger budget.
Here it is worth mentioning that it often happens that solutions have APIs that are incompatible with each other. This will bring a lot of work and headaches for the technical teams. Despite the fact that GraphQL is becoming more and more popular, we still have to deal with missing or incomplete implementations. And now the question is whether to do part of it this way and part of it that way, or to wait, or to opt for incompatibility and use REST/SOAP?
Maintaining composable commerce
Assuming you go through with building an ecommerce ecosystem in a composable commerce architecture, then you need to consider maintenance costs (run cost or Total Cost of Ownership). Depending on the platform you choose, these costs are hard to predict, but we can discuss the ongoing commitment.
This commitment will come from the fact that each module separately is being updated and practically all the time there will be something to improve or change. All because vendors will be changing their APIs, releasing new versions, and old versions will have an end-of-support date. And this is all without counting the implementation of your new business functions.
On the other hand, you update the monolith according to the manufacturer's updates. Usually once every 3 months or even less frequently.
What about the advantages of composable commerce?
It's not that composable commerce is all costs and problems. On the contrary, there are plenty of advantages too. Let's consider a few points:
- If all services and APIs are running fast (and they usually are) then the performance and CWV (Core Web Vitals) of your shop will certainly outperform the monolith. In our experience, this is indeed the case.
- Mobile first: definitely composable commerce outperforms the monolith in being mobile user friendly. And this is because there is an API everywhere. If you're going to have a mobile app then the data is going to come natively because it's going to come over the API. You don't have to worry about lack of coverage. After all, your frontend already runs 100% on the API. And in addition, modern frontend solutions provide quite a few options for mobile users. From pages that look great on phones to PWAs.
- Ease of module replacement. Because everything is integrated with each other, replacing a CMS, e.g. on builder.io , can be much easier because the integration is not so deep.
For whom is composable commerce?
The choice between the available architectures, Modular Monolith or headless commerce, comes down to the specifics of your business and your development directions. In other words, your business priorities and long-term goals.
Composable commerce is a great choice for:
- Corporations with larger resources or internal technical departments with experience in this architecture.
- Businesses that prioritise flexibility and the potential to customise the ecosystem to suit their own needs or requirements.
- Businesses that are comfortable and brave enough to adapt new technologies.
- Businesses that accept a higher initial cost in exchange for long-term benefits.
On the other hand, they are not for businesses that:
- Want a solution quickly (fast time to market).
- Do not have a significant budget for an initial solution.
- Do not have suppliers or in-house resources experienced in modern front-end technologies and complex integrations.