Recently I have been hearing the term “Composable Commerce” more frequently, and I like it. It expands beyond “Headless Commerce”, separation of the frontend stack from the backend, into selecting best of breed technologies to build your commerce stack.
The first reference I have come across is from Gartner (Composable Commerce Must Be Adopted for the Future of Applications).
Digital commerce platforms are experiencing ongoing modularization in a cloud-native, multiexperience world. Application leaders responsible for digital commerce should prepare for a “composable” approach using packaged business capabilities to move toward future-proof digital commerce experiences.
The Practical Commerce definition (from their pros and cons article) captures it more succinctly.
The term “composable commerce” refers to joining multiple components to meet a merchant’s specific needs.
Composable commerce is the modern approach by which eCommerce teams are empowered to select and assemble various “best of breed” commerce solutions and compose them to satisfy their exact business requirements.
It goes on to some specific technology mentions.
I am a little uneasy about these specific callouts however. I think there are good ideas in these technologies, but I am not sure dogmatic adoption of these technologies are appropriate for ecommerce. Specifically:
- Microservices to me is an internal architectural pattern. Cloud SaaS services could be microservice based internally or monoliths – it (generally!) makes no difference to how customers interface with them via APIs etc. So I agree with leveraging cloud services and APIs, but an ecommerce team does not *have* to adopt microservices.
Four51 describes the difference between microservices and Packaged Business Capabilities (PBCs) with some nice diagrams (although I cannot say the “PBC” rolls off the tongue as a cool, sexy name). See also the Amplience site for similar information, with a blog post giving an example list of PBCs.
- I am not sure how well the static site generation side of JAMstack works with ecommerce sites and product filters, user preferences, cart, scheduled sales, etc. As soon as the site has a significant portion of pages generated from content from an API call, is it still JAMstack? I do agree that serving static files can be more secure, but I am not sure an ecommerce site can be completely pre-rendered and kept up to date (with all internal links up to date) when product updates can occur in real time. Hey, prove me wrong!
Are the major all-in-one platforms going away? No. All-in-one solutions are the fastest way for a business to get live for the first time. Plus most (if not all) all-in-one solutions provide APIs and extension points to make integration possible. Most existing platforms can play a part in a composable commerce solution.
Does composable commerce mean less effort? No. It takes more effort to integrate different technologies. Composable commerce is not about cost savings, it is about creating the best solution for a specific business need. It can result in greater business agility or ability to innovate. You have more control over your strategy. But this comes at a price – you need a development team (or partner).
I will end up with this blog post title from Divante.
In terms of buzz words I think this is spot on, but not because composable commerce is a radical new idea (agencies have been integrating technologies like forever!) It is more that the number of businesses for which it now makes sense as a business priority has reached the critical mass such that it is worth giving a name to.
Please note: Mentions of above companies or products is not an endorsement of these specific products. A quick Google search brings up many other companies and products that also have content related to composable commerce.