Composable Commerce breaks down into three main requirements, front-end, APIs, and integrations. The front-end will consist of any UI or customer touchpoint, the most common being a website, but could also include mobile applications, POS systems, AR/VR, and more.
The integrations help to combine the multiple APIs, but also to move data between them.
Finally, they APIs themselves. These are typically SaaS services and are typically what is meant when people talk about the building blocks of composable. These could include:
Product Information Management (PIM)
Products live at the center of digital commerce, without a product there is nothing to sell. A robust PIM is a foundational component and an excellent starting point. PIM enables businesses to store, manage, and maintain consistent product data. This includes attributes, descriptions, images, and technical specifications. By centralizing this core product information, a PIM helps ensure accuracy across touchpoints rather than duplicating data manually across multiple systems.
Traditional PIMs focus on the creation of products and may not be designed for serving that data to websites or mobile applications. In some projects it may be beneficial to keep the traditional PIM and add a digital PIM for enriching the data and propagating that data through scalable APIs.
It’s important for the PIM to be flexible, allowing for many prices, catalogs, languages, and variations. Limitations in the PIM will cascade down through the rest of the implementation.
Product Discovery / Search
Once the product data is defined, the next step is to enable customers to quickly find the products they need. This starts with a robust search engine which should go beyond a basic keyword search and include advanced filtering, personalized recommendations, boost/bury functionality, and configurable facets. Depending on the products, the search may also need to handle large catalogs with many variations.
The product search service also needs to be API-First and scalable, it will be responsible for powering product listing pages (PLP) and product search pages, which are both at the top of a traditional commerce funnel and get a significant amount of traffic.
Order Management System (OMS)
The OMS takes control after an order is placed. While the customer rarely interacts with the OMS, it is responsible for processing, tracking, and managing all the orders. The OMS can also participate in inventory management, payment processing, shipping, and returns. Having an extensible OMS is important to define all of the data that needs to be tracked as well as supporting custom life cycles or workflows. Having an OMS that can be properly integrated with APIs helps ensure an efficient and transparent fulfillment process, which creates higher customer satisfaction and lower support volumes.
Customer Relationship Management (CRM)
CRM tools create a unified view of each customer, storing interactions, preferences, purchase history, and enable more targeted marketing and personalized experiences. Many CRM tools also provide identity management allowing for streamlined authentication through social login. It is possible to split the customer profile and authentication into multiple services depending on the overall requirements. Since the CRM aggregates all of the customer data from other systems, choosing a solution with strong APIs is a must.
Content Management System (CMS)
It is possible to make a basic ecommerce system without a CMS, but the majority of companies have heavy content requirements and need to empower business users to make content changes. As a result almost all composable commerce implementations include a headless CMS. The CMS facilitates the creation, management, and publishing of digital content across all customer touchpoints. A major difference between traditional CMS solutions and headless CMS options is how they treat this data. The traditional system took a webpage view of content, often mixing content and markup, resulting in data that would need to be modified or adjusted when used in a mobile application or other channel. A headless CMS removes any artifacts related to the channel, so rather than creating a page with markup, a schema is defined to store the clean content which can then be formatted as necessary.
There can often be confusion between a headless CMS and a PIM. While it is possible to build a schema and represent products in a CMS, this brings issues and limitations to the project. It will also require rebuilding all business logic that the PIM provides. Instead, core product data should always be stored in the PIM. There are some circumstances where product content is split between a PIM and CMS, in these situations base product data lives in the PIM while extended details may be best suited for a more visual editor found in a CMS. It’s important to talk with an experienced architect to help decide where data should be allocated.
Payment and Fraud Detection
Payment gateways are a clear requirement for any digital commerce experience, not just composable solutions. By choosing composable API-first options for all components, more data can be leveraged when handling fraud detection. Especially data from the OMS and CRM to identify repeat offenders or unexpected behavior.
Summary
While this covers the core systems required in basically all composable commerce systems, the final solution is designed around a business’ specific needs and could include other specialized systems. These may include marketing automation, tax management, translation service, data warehouses, among others. These systems can be added or removed as requirements and objectives change. As a result, the need for extensive RFPs covering each possible requirement, current or future, is no longer necessary. Instead, the solution can evolve and grow over time, so functionality missed on initial launch can be quickly incorporated.
https://www.youtube.com/@thecomposableconnection
https://www.thecomposableconnection.com/
Top comments (0)