Headless Commerce / What Does It Actually Mean?

Before you choose the “universal” solution, stop for a moment and think about how you would like to see your sales systems in 3-5 years? What can change during this time and how often, or rather how fast, will you have to make modifications to keep up with the competition? Looking at the best – Amazon updates its applications on average every 11.7 seconds, and Netflix does it even several thousand times a day – I am convinced that the trendy phrase “Change or die” has its justification.

For many years it was thought that to create a successful path to efficient sales architecture and meet customer expectations, it is best to create dedicated all-in-one IT systems. Very often, good ERP systems fell victim to this procedure, as they were extended with new modules – e.g. product information management or contractor management. At that time, this direction seemed right – after all, one comprehensive master system guaranteed the coherence of consumer experience in all channels.

The “even more” chain

Very often, however, such a path also led to the so-called “even more” chain … Even more servicing costs, even more complicated data structure, even more expensive development, even more risk of failure during modification and even more dependence on one system provider. The effect? More and more business has been adapting its goals and activities to its tools … And it should be the other way round, should it not?

A client’s path

All you need is an example of a client’s path (Figure 1) to understand how important it is not only to ensure the coherence of experience at each stage of making a purchasing decision but also to personalise the user experience in relation to the specificity of a given communication channel:

What is headless e-commerce all about?

Headless e-commerce is a concept that completely reverses the status quo. Instead of creating one complex solution that seems to meet our expectations, but is burdened by the previously introduced modifications and a higher maintenance cost, we can use a range of independent applications specialised in their fields that work together in a single integrating architecture based on API Driven Platform (so-called Data Bus). Thanks to this, we are able to achieve much better results.

What can we achieve by headless commerce?

• UX personalization – thanks to the use of strictly dedicated tools for the specificity of a given communication channel and enabling their independent development.
• Flexibility, thanks to the construction of scalable architecture, easier to modify without thinking how small changes can affect the other elements.
• Security – thanks to lower maintenance costs and lower risk of critical failure resulting from the unavailability of a given resource – e.g. temporary lack of access to ERP resources will not disable the online store.
• Standardization of processes – thanks to the construction of one data structure in circulation, we reduce the cost of replacing/adding new components to the existing architecture.

Erstwhile – one head to rule them all

Let’s combine both concepts into one popular scenario. Well, the company has an e-commerce B2B platform and is thinking about implementing a B2C platform. The B2B platform is already years old, and its users have not been so keen on many UI/UX issues. In other words, it was to serve as a simple alternative to quickly order products selected by the contractor in advance.

What model should be used instead?

However, as many of us have learned in practice, in the case of B2C Clients, such a model of operation will not work. In addition, there is obviously the aspect of B2B consumerisation, so this area should also be developed. It is also worth considering the automation of processes that only a few years ago were possible to implement only manually.

How does it look?

The discussed architecture is presented in the actual-hypothetical situation in a manner consistent with Fig. 2. All data regarding products, customers and orders are stored on an e-commerce platform with a built-in CMS panel and one frontend application.

What is the first natural solution?

We exchange the e-commerce platform for a more modern and comprehensive solution – e.g. with a multistore option for B2B and B2C within one application. We create complicated data importers for the initial supply of the new platform’s base and new methods of integration with the systems, developed according to the business vision, by interfering with the source code. And done.

Problems with process implementation

The problem is that the process of implementing the new platform took from a few to even several dozen months, during which market standards moved ahead. It turns out that what in our opinion was meant to intimidate the competition, in practice has barely allowed us to catch up. And because, unfortunately, the true e-Nostradamus has not yet revealed himself in the world, we have not been able to fully predict the technological changes that will have come in the meantime. As a result, the costs of modifying and maintaining the solution are growing. The outcome? In 3-5 years, we are again at the starting point … In fact, you can act more nimbly.

Currently – a few heads are better than one…

Based on the same example, let us assume that we are creating a modular architecture consisting of a completely separate frontend and backend layer. They are connected by one, extensive web service that stores and synchronises bi-directional data between all systems. Within the backend, we break the previous juggernaut into smaller applications – for example:

• PIM – Product Information Management – the central repository of product data, responsible for the management of product information.
• B2C – e-commerce platform, containing the logic of B2C sales.
• B2B – e-commerce platform, containing the logic of B2B sales.
• CMS – content layout management on both platforms.
• ERP – a system responsible for inventory management and prices as well as order management.
• CRM – a system responsible for managing contractor data and their segmentation and discount promotions per client/group.

Standarization of the data

According to this assumption, each of the above mentioned systems is superior to its field and synchronizes data bidirectionally with other systems to ensure their consistency. To ensure faster data exchange, we assume their standardization within the data bus responsible for receiving, processing and sending information to the indicated source/medium (Figure 3).

What can CMS do?

In this case, each of the fronts of the platform can be a separate part of the ecosystem, managed from the level of one CMS. In other words, CMS can download data from other systems and process them into appropriate layout formats for individual media (e.g. website, online store, etc.). Let us add that, if necessary, each of the fronts can be a separate application, consisting of several layered, separately managed elements, to gain awareness of how low-level integrations can be.

API-first approach concept

Everything is based on the API-first approach concept, which is boldly used by two industry leaders – Amazon and Netflix mentioned at the beginning of the text. Thanks to this, the owner is not dependent on one supplier, and each of the company’s departments can adapt the tools to their needs or exchange them (if necessary) at a much lower cost and in a shorter time. This approach provides employees – specialists in their fields – with access to the best tools, without suppressing the creative potential by mediocre technological potential.

Omnichannel Experience 3.0.

Initially, the API Driven Platform concept was created primarily for the online channel, where the need for immediate response to market changes, customer behavior, and competition is much higher than in the traditional market. However, nothing stands in the way of using it in the case of the development of the whole Omnichannel architecture and intersecting applications responsible for the loyalty program, info-kiosks, etc. All in accordance with the Big Data concept, and at the same time with greater opportunities to adapt the content to the way and channel of communication with the client. Therefore, using the rhetoric that has recently been trendy in marketing – we are dealing with Omnichannel Experience 3.0.

OpenSource is the best solution for Headless Omnichannel

Regardless of whether we are dealing with the architecture based on the supremacy of one system or the exchange of data between multiple domain systems, the cost of maintaining dedicated solutions is usually much higher than the case of ready solutions supported by the manufacturer. The latter, however, have a disadvantage – usually no readily available solution meets all business expectations, and the development itself – because of a sole source of support – can be very troublesome.

Maintaining the full scalability of the system

Open-source solutions come with the help of open software code, which can be freely modified according to the requirements of a given organization. By doing this wisely, without major interference in the source code, you can maintain the full scalability of the system and continue to enjoy the benefits of updating the manufacturer without much workload. This approach makes it possible to significantly reduce the cost of maintaining the application while its development continues.

Optimization of costs

What’s more, solutions like Magento or Pimcore have a large ecosystem of partners, which provides users with access to many ready-made modules by expanding the functional layer. In other words, it also creates an opportunity to optimize the costs of development.

Is it worth losing your head right now?

Each investment must be adapted to the scale of business. It makes no sense to create an advanced architecture that consists of many domain applications if we do not see the prospects for a quick return on investment.

Connections between the systems

Fortunately, we can do it gradually – for example, in the beginning, it can be a simple architecture consisting of an e-commerce platform, a PIM system, and an ERP system. Of course, in this case, ERP will be the primary system. Nevertheless, assuming that the connection between the systems would take place via the Data bus, nothing prevents us from transferring the burden of managing selected areas of commerce to subsequent applications plugged into the architecture over time. At the same time, of course, not turning our organization upside down, and simply adding more extensions to it.

Minimum valuable product

Practice has often shown that the key to success is building a scaled architecture with the minimum functional scope appropriate for the scale of a given business (so-called MVP – minimum viable product) and its agile development in terms of current customer needs. However, that is a story for another time.