Composable Commerce & Headless Commerce

How do you manage to constantly further develop an online store and still keep it running solidly? The headless commerce approach provides an answer to this question. And how is it possible to unite specialized suppliers of shop functions in one application? Taking a look at composable commerce will be worthwhile.

Christopher Warnow

Consultant & Developer at FIS

What is the difference between composable e-commerce and headless commerce?

The main feature of the headless commerce approach is the separation of the visible part of an e-commerce shop and the technology in the background. Composable commerce divides the e-commerce platform into separate exchangeable modules.

SAP CX with FIS

SAP Customer Experience: Focus on the customer

Cloud-based application for marketing, sales, service and e-commerce

To the product

What is headless commerce?

Headless commerce describes an e-commerce architecture with the online shop display (storefront) being separated from the technical platform for business logic (back end). This separation enables greater flexibility, scalability and an improved performance of the entire e-commerce system.

Challenges making the use of headless commerce necessary

For the first time, the term “headless commerce” was used by Dirk Hoerig, founder of “commercetools”, in 2013. Before this concept was introduced, business logic, database and shop display had been delivered in a monolithic suite. This led to multiple challenges:

Even small changes to the front end, e.g. to the graphic or the layout, required a restart and a deployment of the entire store, which entailed elaborate quality assurance and reconciliation processes.
Performance problems at back-end level, e.g. in price calculation, could have a direct negative impact on the shop display and impair the customer experience.

How does headless commerce work?

To circumvent these problems, an architecture was introduced that uses independent technologies for shop display (storefront) and business logic (back end). The communication between these two system areas takes place via Web services or APIs (Application Programming Interfaces), which entails several advantages:

Changes to the design or to specific layouts can be made irrespectively of the back end in headless commerce.
Performance and scalability of the back-end processes do not impair the speed and the display of the e-commerce shop.
Enterprises can quickly respond to market requirements by making adjustments directly in the storefront without having to carry out comprehensive back-end deployments.

Example: price layout adjustment during the Christmas season

A vivid example of the use of headless commerce is the seasonal adjustment of an online store. If a trader wishes to change the layout of the price displays during the Christmas season, this can be implemented directly in the e-commerce storefront without developers being involved for the business logic. This leads to a substantial saving of time by using headless commerce and an improved responsiveness to market trends.

What does composable commerce mean?

Composable commerce is a further development of the headless commerce approach, which is not only restricted to the decoupling of front end and back end but also organizes the back-end business logics in modular components. Individual functionalities, such as price calculation or order processing, are treated as independent packages and loosely coupled to each other via API interfaces. Therefore, enterprises can flexibly respond to new e-commerce requirements and exchange or extend specific functions according to their needs.

How are composable commerce and headless commerce related to each other?

If you follow this logic, the storefront is only a module and could be exchanged. The back end would remain unchanged in the scenarios. As a consequence, headless commerce works as a concrete specification of the composable commerce approach.

How long has composable commerce been available?

For the first time, the term “composable commerce”, was mentioned in a study by Gartner entitled “Composable Commerce Must Be Adopted for the Future of Applications” in 2020. Here, the concept of business capabilities is defined as a central component enabling enterprises to achieve their individual business objectives.

Example: replacement of a price service

A practical example is the replacement of the price calculation service. Instead of carrying out the price calculation in the back end, it is read from an ERP system. Development and testings can take place in a separate area, while the e-commerce storefront continues to run solidly. After implementing the new price service, it can be displayed faster and even customer-specifically in the storefront without having to adjust the entire system.

How can a company respond faster to market changes by using composable commerce?

An example of this is a company that operates online stores in several countries with each country having individual business processes or logistics partners. In a classic monolithic e-commerce architecture, the entire shop software of all countries would have to be tested before each release to ensure that the shops in all countries continue to work smoothly. This leads to high reconciliation efforts and slows down the release cycles.

By using composable commerce, it is possible to update specific back-end services only for individual countries or business areas without affecting the rest of the system. If, for instance, logistics provider B is replaced by C in country A, the back end will assume communication with the new provider without impairing the shops in other countries. In this way, the entire shop remains stable and continuously available.

What are the benefits of composable commerce?

Faster implementation of new requirements: Individual components can be specifically activated or replaced without affecting the entire system.
Increased system stability: Updates and changes only affect the services concerned with the overall system remaining stable.
Reduced error rate and side effects: As components can be tested and implemented independently of each other, fewer unexpected errors will occur.
Easy integration of specialized providers: Enterprises can specifically integrate the best providers for certain functions into their e-commerce platform.
Cost efficiency: Only the components that are actually required will be licensed, which avoids unnecessary costs.

Challenges of composable commerce

High initial development costs: The development of an individual storefront might be expensive. Therefore, enterprises should select providers offering storefront and back-end components that have already been synchronized with each other.
Orchestration of the individual components: The back end must be able to efficiently manage the different services. In some cases, an additional process layer is required to coordinate the services.
Technical interface competence: Developers have to ensure that the storefront can smoothly interact with new back-end components.
Overview of license costs: As multiple specialized components are used, fixed costs might add up.

Conclusion

Composable commerce and headless commerce provide innovative technological approaches for the architecture of complex online stores. Due to the decoupling of front end and back end, headless commerce enables more flexibility and scalability. Composable commerce goes even farther than this and allows a modular, API-controlled system design.

Although these concepts are highly effective, they are no panacea for every online store. The implementation requires technical competence, cost control and orchestration of the e-commerce components. Particularly for enterprises with complex requirements, they provide a future-proof alternative to monolithic systems. The appropriate use decides on success, and not every shop architecture automatically benefits from it.

FAQ – frequently asked questions

API means Application Programming Interface. In the context of composable and headless commerce, REST Web services are meant. The term REST was formed by Roy Fielding in his dissertation in the year 2000.

Technical boosts made APIs mature for the composable commerce approach

APIs and their use have matured along economic and technological developments. Technological boosts were enabled by ever-accelerating Internet connections during the decade of the 2000s. Due to the requirements of the software-as-a-service approach as of approximately 2015, the thought of computer users concerning the application of a software on their own computers disappeared. With the latest trend of cloud computing based on this approach, which started in the 2020s, APIs are the sophisticated lubricants of these architectures.

APIs enabled new business models resulting in composable commerce and headless commerce

In addition to the technological dimension, APIs enabled new business models and formed the last 20 years to such an extent that this now culminates in a composable commerce or even composable business approach. The first proof that it is possible to earn money with APIs was produced by Amazon, Salesforce and eBay at the turn of the millennium. For the first time, their APIs enabled them to sell products not only on a website but anywhere on the Internet.

During the decade of the 2000s, social content was included into the value chain by enabling a secondary exploitation of Flickr images or Facebook profile data. Shortly afterwards, Amazon announced S3 Storage Service in 2006, which enabled the invention of system architectures based on API. In 2007, iPhones and, in 2008, Android Phones were introduced, which enabled APIs to transform trouser pockets into points of sale by using Google Maps and location-based apps like Foursquare.

In the end, this drive led to the ultimate business idea of API-as-a-product (AaaP). This means that an API is the central monetization source of a company. One of the first successful business models of this kind was developed by Twilio in 2008. The API enabled telephone calls or the sending of text messages between cell phones. This development was followed by search services in websites by Algolia or online payments by Stripe.

Composable commerce roundup

Now, let’s go back to composable commerce. The business model of API-as-a-product was able to professionalize itself for 10 years so that composable commerce was announced in 2020. It is the intellectual framework for a business world where these companies work together to enable an overall experience.

Composable commerce is part of a line of tradition – from software-as-a-service, cloud computing to API Economy. Shopify, for instance, was a shop system that did not have to be installed by customers but was already available online.

In addition to shop-as-a-service, further specializations, such as search-as-a-service or fulfillment-as-a-service, developed during the last years.

Composable commerce meets API economy

Currently, respectively since 2021, cloud software revenues have been the great driving forces for companies like Salescloud and SAP. This technological wave already pushes the next one, i.e. that of API economy. According to Fortune Business Insights, annual growth rates of 25% are expected until 2032. API economy describes a business mode where the technical infrastructure is formed by means of API-based services.

The headless commerce and the SAP composable approach move in the spectrum between best-of-breed approach on the one hand and the all-in-one approach on the other. Until approximately 2015, different small programs were installed in IT system landscapes and each of them did a perfect job. However, they were unable to communicate among each other, so data silos occurred.

In the e-commerce context, this means that you call a company after placing a purchase order and the employees there cannot view the purchase order history as the customer numbers from the shop and the retailing system differ.

Composable commerce moves between all-in-one and best-of-breed

At the other end of the spectrum, however, the monolith can be found. This is an oversized suite that only uses a small part of the features but whose entire license has to be paid.

A compromise is the “platform thought” with a company providing different solutions which, however, are able to communicate with each other by default. For e-commerce customers, this means that they can already view the status of service tickets in their account areas. In spite of these conveniences, however, the vendor lock on the debit side is disturbing and you do not feel good with only one vendor.

This is where the composable approach comes into play. The platform opens up to the market and individual features can be replaced by specialist suppliers, which is almost like using a best-of-breed-approach, only with data.

Programming patterns for headless commerce

Composable commerce is not new. It only has a new look, which is due to Java patterns enabling developers to switch specific business logics on and off at programming level. The “father” of this approach is object-oriented programming. Its “uncle” is the MVC pattern, a programming approach decoupling the software display (view) from its business logic (controller) and the individual pieces of data (model). The purpose of this approach is to avoid an erroneous spaghetti code.

The composable approach is the new offshoot here that has to go its own ways. If the individual components are mixed, this might quickly result in a spaghetti architecture as well. If this problem is solved by a middleware or a business process engine is currently still open.

Table of content