Composable commerce is a development approach that combines or "composes" best-of-breed commerce components into a custom application. There is no other approach that offers such flexibility. Too much freedom, however, can also be disorienting. Without guidance, selecting the right components and designing the right architecture can be challenging. On the other hand, being too opinionated about the tech stack can be equally dangerous, as it compromises the natural flexibility of composable architecture.
Some might argue that the ideal composable commerce stack doesn't exist, as what's optimal for one brand is not always suitable for another. Though this may be true to some extent, I also believe that many brands have similar architectural requirements. It's the frontend experience, content model, and internal workflows that make each brand unique. With that in mind, I'll dare to outline what I believe is the ideal stack for composable commerce. This is based on my experience working with enterprise-grade brands across various industries.
A best-in-class architecture
The picture below shows a best-in-class architecture containing the key commerce components, each managing and delivering a specific domain of the commerce experience.
At the bottom of the architecture, we find a PIM (1). The PIM gathers basic product information from the ERP and other sources and manages the master catalog(s). The PIM also facilitates the consolidation and aggregation of product information that generally isn't very structured, especially when it comes from different sources.
There are two parts to a product catalog. First, there is the product data. Second, we have product classification. Product details pages (PDPs) are populated with product data. Product classification refers to categorizing products by merchandising categories, gender, use cases, or other taxonomies. Product listing pages (PLPs) use this information as a data source.
Using a headless CMS (2), content editors can enrich product data with editorial content that enhances the story telling. A CMS is also where content editors manage navigation and other non-catalog content, such as homepages, landing pages, blog posts, etc. Content is delivered to the frontend via a content delivery API. Generally, this content data does not change too often. Thus, it can be cached aggressively, improving site speed and scalability.
All product listing data is indexed into a headless search engine (3), which delivers all PLPs. Those PLPs can be the result of a full-text search, faceted filtering, or manually merchandising categories. The search indexes can contain only the data needed to show a product preview, such as the the main image URL, the title, and the categorization path. Clicking a product preview in the list will take the user to the PDP with the full product data. Search engines can also provide product recommendations to PDPs based on filtering criteria (i.e. within the same category) or AI-based recommendations.
The dynamic nature of product listing data limits the level of caching achievable. In spite of this, search engines are an excellent tool for delivering real-time data with high performance due to the fact that data is indexed. In fact, the search engine and content delivery APIs become the delivery side of a two-stack CMS, with the PIM serving as the "offline" management system.
It is important to note that the indexing process may include some logic to enhance the index data. For example, it can retrieve price and stock information from the commerce engine to filter or sort PLPs by price and availability. In some cases, unavailable products are hidden from the search results. My recommendation is to keep unavailable products online and enable alternate CTAs on the PDP.
Last but not least, the ECOMM platform (4) makes the entire experience shoppable by providing prices, promotions, stock availability, carts and checkouts. Stock data and price lists are imported from an ERP and delivered to the frontend with business rules that can differ by market, channel, or customer segment.
For an omnichannel retailer, the ECOMM should provide advanced OMS features, such as an integrated view of inventory, available shipping methods, order splits, and order orchestration. As soon as the order and customer have been processed, they are sent back to the ERP, WMS, and CRM for accounting, fulfillment, and marketing automation.
That's it. It is a sophisticated, yet clean architecture that scales without being overly complex. In terms of filling in the boxes, there are many options available. Depending on your budget and needs, you might consider choosing different vendors or even building some components yourself. Composable stacks are great because you can evolve them as your needs change. Just remember that the early decisions you make about your architecture will have the biggest impact in the long run.