What is Composable eCommerce if You Ask NASA

What is composable ecommerce? Over the past few years, we have seen fundamental changes in the architecture of ecommerce systems. More and more terms and approaches are emerging, and this causes a bit of confusion among business decision-makers and their development teams.  Only recently they have gotten to know and understand one new and hot term and a new one is popping up. 

The four main terms discussed today are monolithic systems, microservices, headless and composable ecommerce. As you know, nothing helps to understand the essence of abstract things better than an allegory from the world of natural science. So, let's imagine that we asked the NASA office to explain the terminology of ecommerce system architectures in terms of celestial bodies.

Until recently, most enterprise B2B ecommerce software solutions were supported by monolithic architectures. These were and are all-in-one systems with a tightly coupled front end and back end. This means the high functional dependency of one software module on another, while is not clear how changing the code in one module affects the operation of the entire system. It is necessary to test the complete platform again and again. And an important detail — monolithic systems were initially designed for a desktop browser as a front end visualization, but in the last decade many more front ends (mostly mobile ones) appeared. Therefore, the amount of testing work for monolithic systems is growing at an unprecedented pace. 

The best analogy for a monolithic system is our planet Earth. All its ecosystems are so interconnected and interdependent that changes made by mankind to one of the ecosystems lead to destruction on a planetary scale. An example of this is the climate change caused by CO2 emissions. 

Let's get back to ecommerce. Everything started to get complicated and development problems multiplied when smartphones and tablets began to appear “en masse” around 2010-2011. Since then, it was required to develop and support at least 3 versions of the online B2B marketplace's interface: for a desktop browser, for a smartphone browser and for a mobile application. In the case of developing an ecommerce busines to regional or foreign expansion, more front end versions were required, plus catalog and price management according to the client’s IP address, currency and other factors. 

Three or more UI front end versions with the same back end — that looks like a lot of hassle, doesn’t it? So, either a new approach to platform architecture is required, or businesses will not keep up with the demands of the customer experience: 

• Different front ends, difficult geographic scaling due to a closely related catalog and other services front end / back end problems; tough to make changes to the platform. 
• The platform vendor made the desired changes for an unacceptably long time, and sometimes it is almost impossible to rewrite the mobile interface. 
• Customers could only work with the mobile application if they had installed the latest version. 
• The monolith instances were deployed on several servers to distribute the IT-load, each of which served its own group of client databases. When one of the servers fails, all users of the corresponding group lost access. 
• All customer expertise was kept by the vendor of the monolith solution, not by the retailer. 
• Since the retailer could not make changes at the request of customers directly, and the functionality was insufficient compared to competitors, there was a risk of customer leak to competitors. 

Summarized: as doing ecommerce business becomes more complex; monolith platforms can often be slow and difficult to scale. The subsequent appearance on the market of various types of mobile devices has led to an increase in the number of new front ends and user interface (UI) appearance, making the monolith code increasingly complex.  

Understanding the shortcomings of monolithic corporate ecommerce systems has gone in the direction of detaching a number of services to work independently from the back end side and providing some small and bounded functionality. This next type of system architecture became known as the microservice ecommerce platform. 

The main reason for using microservices is because retailer’s business units want to implement a new user experience quickly and improve the platform when necessary, i.e. adapting to respond to changing business requirements and staying ahead of the competition. For example, in ecommerce, we operate with the concepts of digital catalog, shopping cart, marketing, ordering, payments, etc. These are all bounded contexts and therefore candidates for microservices. 

When talking about the approach of structuring the front end and back end in a microservice architecture, it will be necessary to separate the code bases of the front end and back end, leaving the application UI as one whole. With this architecture, front end and back end are distributed and interact over the network (HTTP). However, the entire UI can be maintained, making it easy to keep it up to date. 

Think of the microservice architecture as an analogy of many orbital satellites, each fulfilling its own duty for planet Earth. Some space stations evaluate cosmic radiation, others study the solar system, third stations conduct biological experiments, and so on. The number of each type of space station can easily be scaled according to demand. For example, to obtain better telecommunication coverage, the Iridium operator could launch an additional number of satellites into the orbit.

Within the ecommerce microservice architecture, there are many microservices and a core module. The core could be a very small and lightweight for better system flexibility. Microservices communicate with each other and core via an API. Among microservices running bounded service functionality, there are microservices for system duty — for example, to discover an appropriate microservice in the system through a request from a functional microservice.

When building microservice architecture, the DevOps team would be responsible for the product throughout its entire lifecycle, including development, maintenance, and decommissioning. This forms a “product mindset” and means strong ties between a technical product and its business capabilities. A direct relationship is created: how the application helps its users to expand their customer experience.

When talking about headless ecommerce, front ends (aka heads) are fully decoupled from the back end (aka body) and they communicate only through API. For headless, it doesn't matter if the system is a monolith or a microservice one. The difference lies in the effectiveness, because with a microservice architecture, headless brings better flexibility to implement business logics compared to headless working with monolith (by API).

From the space allegories point of view, the front ends could be far-space satellites and the Earth is the back end. If these far-space satellites communicate directly to the Houston control center, this will be a “headless + monolith” architecture. If far-space satellites only communicate to space stations in near-earth orbit and these stations receive and transmit data strictly according to their bounded functional service, this will be a “headless + microservices” architecture.

Summarized: Microservices enforce the bounds of services, keeping the code healthy, clear, isolated, and encapsulated in separate connected modules. If a module (i.e. microservice) becomes buggy, then this non-optimal program code only remains there and does not spread to other parts of the IT system. This brings more flexibility in the development and implementation of the front ends; the headless approach could be combined with microservices.

However, the microservices approach is more innovative than a monolith, but not the best ever. The understanding of how to translate a task from business decision makers into an IT solution deepens as developers go further. Therefore, the microservice code has to be constantly rewritten (refactored which leads to the descaling of microservices more and more to a smaller functionality, and the system becomes too granular. This could affect reliability and requires more testing time, more involvement of technical support for quick bug fixing.

The composable ecommerce platform, according to its definition, provides flexible and modular free-to-choice business scenarios that a retailer would like to make available to customers. The API collects the data from the ecommerce back end, transforms it in a proper network protocol, then delivers data to a broad array of digital touchpoint front ends and vice versa. Various third-party solutions can be easily connected to the business logic (ERP, CRM, PIM, AI, etc.). 

The technological core of a composable ecommerce system establishes the architecture to stay extensible and scalable, available for orchestration, discovery and synchronization of system modules. The GraphQL protocol can be used for integration with sales touchpoints. By using this modern technology, it is possible to integrate online shopping websites, mobile apps, chatbots or any other touchpoint within same business logic as omnichannel sales. 

What would it look like if we take analogies from the world of the planets and stars? In the natural world, planets do not consist of large pieces, although it may have been after the Big Bang of the Universe until the gravity turned the planets into multilayered monoliths. If we want to make a man-made cosmic construction from the set of modules, the International Space Station (ISS) could be a good example. It consists of modules built by multinational space agencies: NASA (United States), Roscosmos (Russia), JAXA (Japan), ESA (Europe), and CSA (Canada). 

Continued with the ISS space station allegory, each big module has some smaller components of bounded functionality (power supply, a network switch, sensors, computation engine, etc.) that can be considered as microservices. Headless can be explained as the ISS space station (as body) has formalized communication protocols to other satellites in orbit (as heads) to receive data from their sensors. Thus, we have a full set of terminology there — the ISS space station is a composable product built from modules of many vendors; each module has many components as microservices, and there are communications protocols to exchange data with other satellites, which realizes headless.    

What is important for retailers, in composable ecommerce platforms the third-party applications such as a digital catalog can be used instead of the same-functionality module designed by the platform vendor, this provides the greatest level of flexibility for the ecommerce platform. Also, various third-party solutions can easily be connected to the business logic (ERP, CRM, PIM, AI, etc.).

Composable ecommerce adds a new level of flexibility to the platform architecture. By assembling the back end and middleware from a vendor's kit with legacy systems and best-breed third party applications from the market, a retailer can create a flexible system that is fine-tuned to the business requirements of the online commerce niche where the company operates. 

Composable ecommerce can be functionally well combined with headless and microservices as it is a business concept rather than a technical one. Within the composable ecommerce platform, large API-based modules can have an additional de-scaling to microservice architecture that makes it easy to develop, support and update. It also has extensibility points to modify its business logic while it is still possible to get and deploy updates from the vendor without the risk of changes loss. 

Today, there is no more advanced ecommerce system than the one that uses a composable back end and middleware approach, microservices for flexible implementation of functional business services and a headless architecture for communication with touchpoints via API. This is exactly how the Virto Commerce platform works.