5 questions to ask Headless eCommerce vendors

This is a short guide for business developers and senior-position managers looking for a B2B ecommerce platform for their company. In this way, any vendor you meet on the market will describe their platformin the best possible colors, but the decision to make and the price of the wrong choice are yours.  

Moreover, the platform you choose from a technological point of view will further determine its successful adaptation to your company’s business strategies, say, if you want to  set up a b2b online marketplace. No doubt, you know the importance of this factor, but we must remind you of it. 

Surely, you have heard more than once about such characteristics of ecommerce architectures as monolith and headless: 

• Monoliths are heavy, feature-rich and slow, commercial platforms with front end templating logic geared towards classic browser ecommerce sites. Components have tightly interconnected code and are difficult to change when developers need to deliver new customer experience features in a reasonable amount of time or scale in performance.
• Headless ecommerce platform has the front end as a stand-alone piece of software, which communicates with a back end through API. Both parts operate separately from each other, and can even be placed on separate servers, creating a minimum version of a multi-server architecture. The bridges between both parts work via API clients.

Here in the post below, we will not repeat the many advantages of headless architecture. Although, in all fairness, we must say that these advantages do not manifest themselves in the absolute number of situations. There are cases, mainly in the startup environment, where it is easier to launch an online store on a monolithic solution. The revolutionary benefits of headless ecommerce architecture are not secrets. 

So, how a person with a business background could determine the true nature of the platform architecture: is it headless or monolith. In other words, separate the wheat from the chaff? For example, you are just looking for headless platforms to bring to the board of directors for consideration. Don’t be fooled by packaging and consider these 5 questions to determine the “true” nature of the B2B ecommerce platform architecture.  

Certainly, the easiest way that comes to mind is to ask a vendor. There is one problem here - the vendor's answer may be a marketing-like text including words of praise about the platform,  using indecipherable collocations like asp net ecommerce, but with no direct answer to your question about the architecture type of the platform.  

For this case, we have prepared four more questions on how to get enough information about the possible architecture of the platform.

We intentionally put the removal of redundant features first in this question. Let us explain why. First, one tries to get paid for functions that are not used, which contradicts your desire to conduct business economically. Second, redundant functions mean extra code in the system, which requires additional server's CPU and memory for which you must pay otherwise the system will work too slowly.

If you get an evasive answer like “you cannot remove anything, just use the functions you need” this most probably means the platform is based on a monolithic architecture. In terms of adding features, this is often possible even in monoliths, albeit from a limited list of add-on applications.

With headless architecture, adding or removing functionality is possible by choosing any best-in-breed application available on the market, i.e., without limitation, but such applications must support API communication, of course.

The third question is related to the second one and allows you to indirectly estimate the size of the application ecosystem provided by the vendor.

Monoliths are characterized by a small number of add-on applications, since the requirements for their compatibility are very high. The use of third-party applications is possible only with companies that maintain partnership agreements with the vendor of the monolithic platform. The unpleasant side of this is that such agreements can be terminated at any time, and you will be faced with the fact that new versions of the platform will not be compatible with the applications you have previously integrated into the overall ecommerce solution. 

In the case of the headless platform, the ecosystem could potentially include all ecommerce applications in the market that have developer APIs designed to be used for touchpoint runtime.

Updates issued for a monolithic commerce platform are relatively rare, usually coming no more than once a quarter. Sometimes such updates are an ultimatum "accept or stop using it further" in the sense that monolithic platforms cannot support their users on outdated versions. The new features are only available in the latest release, and all software must be updated to access just one feature that the business would like to add to support its business processes. 

Particularly serious problems arise when the platform installed by the client has undergone some kind of customization. In that case, it is absolutely impossible to foresee how the vendor’s update of such a monolithic platform will affect the stability of its operation. Sometimes an update requires additional in-house testing routines and/or staff training across the entire platform, leading to a lengthy implementation.  

In contrast, the possibility of high-rate updates and scalability gives a head start for headless architecture in ecommerce. Because front end technology can be updated more often, headless utilizes a Lego-like style of system architecture and allows fast implementation of new business ideas to drive profitable business.

The size of the RAM required for a minimum launch of the platform shows the amount of software code and the level of its optimization. At the same time, remember that this minimum is when the platform contains no real product data. Ask the vendor about the memory size and recommended CPU power when the platform moves to scaling from the test environment to production.  

If you get 16/32+ gigabytes of RAM recommended as an answer, then the platform is most likely monolithic. At the same time, modern headless platforms can usually be installed on a server with just one gigabyte of RAM (memory). Thus, the question of the number of hardware resources is another way of determining the type of platform architecture.  

It also matters how much the hardware costs to run the platform on-premises or on a hosted service. To run monolith on-premises, you'll need to spend more capital expenditure (CapEx) on hardware.  

For hosting the platform in a data center, monolith will incur higher operational costs according to the Pay-as-you-go payment model [hour-based payment for server resources you currently use]. So, mind the price for a 1GB RAM cloud server is about ten times cheaper than for a 16GB RAM one. The savings on renting a cloud server can be significant if you calculate this for years.

We have listed five questions that can be asked to vendors of ecommerce platforms in an attempt to find out the principle of building the architecture of these solutions. If you dig a little deeper into the essence of these questions, you will discover the differentiation focus that lies in the use of APIs. 

A monolithic ecommerce platform, including its SaaS implementation has API typically tied with touchpoint (storefront) only. However, some APIs are usually offered in monolith, but mostly for integration purposes. For headless API, it is designed to be used for touchpoint runtime. 

The “API first” principle for monoliths works in the way that APIs are available as wrappers over some internal APIs and some limited APIs for integration. For headless, a full “API first” approach via REST and/or GraphQL protocols brings flexibility, scalability and the possibility for easy and incremental platform updates.

Make sure to learn from other materials:

• Headless Ecommerce Explanation and Platforms Overview
• The Ultimate Guide of Headless Approach in Commerce