Mann am Smartphone
B2C  | 23 Jan 2023

Composable commerce: manifestations of a trend

What needs to be considered in modern e-commerce architectures

Porträt von Friedrich Teucher
Friedrich Teuchner

One thing is clear: requirements for modern e-commerce systems and architectures are diverse and there is no one-fits-all solution that is equally suitable for every objective.
Both the choice of system and the revision of the current e-commerce solution are decisive success factors for companies. The interaction of e-commerce solutions with other systems such as an ERP, CRM, CMS, CDP or CPQ is important here. Solutions for data and process integration must also be taken into account.

“Composable” is the key word for a modern and flexible architecture. But what exactly does it mean? What forms of the “composable” idea are now available?

Isn't everything somehow composable?

E-commerce systems must be increasingly flexible. Providers like to emphasize that the solutions they offer are “composable” and position this as an evolution of suite e-commerce systems such as the SAP Commerce Cloud.

“Composable” as a buzzword appeals to both business analysts and IT architects. The former see this as fulfilling the desire for flexibility in terms of content in the sense of a diverse feature set that can be switched on or off. The latter understand modularity up to a microservice architecture and separation of backend and frontend. Or more generally: the consistent implementation of the MACH principles (microservice, API-first, cloud-native, headless).

With the integration into existing and specialized systems mentioned at the beginning, modern e-commerce landscapes are a composition of solutions - in other words, they are composable anyway.

In any case, it is worth taking a closer look:
  • What level of “composable” commerce is promised by the provider?

  • What requirements does an organization have in terms of modularity?

In the following, we take a look at different perspectives on “composable”.

Horizontal and vertical modularization

Suite e-commerce systems such as SAP Commerce Cloud deliberately break up what at first glance appears to be a monolithic architecture, for example through horizontal separation:

  • Separation of frontend and backend using omni-channel commerce APIs

  • defined integration layer (Integration Extension Pack)

  • various cockpits, dashboards, back office, Smart Edit as CMS

  • Platform: cache, l18N, rules, business processes, background processes


and vertical modularization:

  • Accelerators as industry-specific feature bundles, among others

  • Modules of the e-commerce functions

  • Custom extensions

  • Custom microservices as side-by-side extensibility (SAP Kyma)

Grafik mit bunten KästchenComposable Commerce Building Blocks

Microservice architecture

The additional decomposition of typical e-commerce functionalities such as “shopping cart”, “checkout”, “registration”, “pricing”, “product details” or “back office” within the e-commerce system into individual cloud-native microservices is another manifestation of the “composable” concept. A consistent microservice architecture can be particularly advantageous when distributed development teams are working on dedicated topics at the same time and the decomposition results in a reduction in overall complexity. A microservice architecture for core e-commerce functions is therefore often only worthwhile from a certain project size and should always be weighed up against software solutions. Customer-specific e-commerce processes, data structures and dependencies generally deviate less from the standard and can therefore be delivered efficiently as a customizable bundle.

In general, the division into units or modules increases the maintainability of a system. Microservices implement the modules differently, but not automatically better. The optimal concrete architecture uses the strengths of both approaches and uses, for example, product configuration and pricing logic or personalization (intelligent selling services), which are provided by dedicated cloud services. In contrast, the core store functions can be implemented using coordinated modules from a suite solution without having to resolve the resulting dependencies, e.g. between customer and product data in the shopping cart. If extensions are to be consistently implemented as a microservice, this is possible for SAP Commerce Cloud with the help of Kyma Runtime on the SAP Business Technology Platform, for example, and positioned by SAP as side-by-side extensibility.

Headless Commerce

A continuing trend is that web stores no longer exist as stand-alone applications, but that e-commerce functionalities for customers are seamlessly integrated into websites (content & commerce) or customer portal applications. This requires e-commerce systems to be “composable” in the sense that the backend is integrated headless and can ensure the necessary interaction alongside the business logic. The SAP Commerce Cloud, for example, offers extensive Omnichannel Commerce Connect APIs for this purpose. Further decomposition into “composable commerce” microservices is possible, but not absolutely necessary in order to successfully integrate the e-commerce system into the customer portal. The front-end stack communicates via clearly defined and versioned interfaces that are provided by a microservice architecture or a suite.

Grafik mit bunten Kästchen die eine Architektur aufzeigen

Exemplary “composable” architecture for a customer portal

This move towards headless commerce raises the question: Which components of the system should be composable in themselves? With many e-commerce platforms, the free combinability of modules primarily relates to the backend functionality, especially if no separate frontend application is offered. This means that features and modules can be flexibly selected or deselected, but mapping this in the frontend is the responsibility of frontend development.

SAP Commerce, for example, is currently taking a different approach by offering a “composable storefront” that is tailored to the available store functionalities and has its own mechanism for compiling these in the frontend. This is particularly interesting if the e-commerce functionality is not integrated into a portal or another custom frontend, but is operated as an independent web store.

Conclusion

In any case, it is worth taking a closer look and carrying out an in-depth analysis:

  • Is your organization ready for a consistent MACH architecture?

  • Are your use cases already covered by a suite e-commerce solution?

  • Is the mapping as a headless architecture sufficient for your requirements in terms of scalability and integration capability?

  • Do you want to place the transformation to a MACH architecture at the center of your considerations?

  • What approach can you use to maximize the customer benefit of your customer experience platform and achieve this goal as quickly as possible?


Different e-commerce solutions offer different levels of composability. They are all customizable. It is important to find the right balance between optimally coordinated suite modules and specialized additional components to meet your requirements.

Porträt von Friedrich Teucher

Friedrich Teuchner

Friedrich Teucher advises our clients as a Manager SAP Solutions and SAP Consultant in the field of Customer Experience, particularly regarding integration architecture and interfaces. He has over 10 years of experience in sales processes and their end-to-end mapping using SAP ERP, CRM, CPQ, and E-Commerce.

See all articles