I was reading an interesting article from Digital Commerce 360, “Heard at NRF: Contradictory conversation from ecommerce tech vendors”. One of the topics that came up was inconsistent definitions of what headless ecommerce is. I thought I would share my thoughts on the topic and article in general.

Inconsistency and Change

The first remark that leapt out at me was “even these very savvy business leaders are frustrated by the constant onslaught of contradictory and changing mandates”. This rings so true to me. I must admit it is also why I find ecommerce so fascinating! It is a field of constant innovation and change. There is a stable common base (product catalogs, inventory management, shipping, payments, …) but there is also a lot of innovation as new ideas are explored. 

Personally I don’t see this changing any time soon, if ever. Merchants are always looking for an edge to increase profits – that is core to their existence! This is why I think flexibility and openness of platforms is important, particularly for larger businesses. Your business can benefit from being ready to take advantage of future changes without a major overhaul of the whole platform.

On the other hand, having to piece together too many diverse systems can be expensive. This is why complete (pre-integrated) solutions are attractive. You get breadth of functionality without the cost of integration. This is a benefit of platforms supporting extension models. You get a core with an ecosystem of extensions that reduce the integration costs.

This leads into the comment “these tech vendors are in a tough spot right now, as the API-first trend nudges retailer expectations toward openness and flexibility, rather than locked-in, preconnected solutions”. I agree completely with this. Platforms that support more of a pre-connected solution can significantly reduce deployment costs for merchants … if the end result meets their needs. Platforms, however, also needs to be open so merchants can integrate with other systems. I see this problem as only getting worse for vendors, it will not go away. But I will also say I have not seen any vendors shying away from the problem. The ones I have talked to understand this as a business reality and are tackling the problem head on.

Headless Commerce

So what is headless commerce? Definitions offered up in the article include:

• “Commerce platform without a UI” – yes! But the article goes on to ask if it is the storefront or backoffice UI that is separated. My personal answer: the storefront. Yes, backoffice functionality should also have APIs to allow integration with external systems, but to me headless commerce is about enabling new creative consumer experiences, by not being locked to only the storefront experience provided by the vendor.
• “Decoupled or atomized bits of the full solution that may be deployed independently.” I (personally) don’t consider this a definition of headless. It is a fine architectural decision, but headless and independent deployment are orthogonal topics. You can have a headless solution with a monolithic backend. SaaS providers for example typically hide the exact service breakdown behind public APIs from it’s customers, allowing the provider to change internal architecture as needed without merchants being impacted.
• “API-first set of microservices”. This is not the definition of headless. It again is a fine architectural design pattern, but orthogonal to headless.
• “Categorized chunks of services…” going on to say some vendors had really implemented “macroservices”. Again, to me, not relevant to the discussion of headless.

So to summarize, headless commerce is about the separation of consumer experiences from the backend. It allows new, tailored, consumer experiences to be built while having a single product information management, inventory management, shipping, discounting, pricing, returns, etc backend. Consumers should see a business as a single business with multiple customer touch points. Prices and inventory should be the same no matter what the consumer touchpoint is (in store, online, over the phone, or via a pop-up kiosk). This is the point of headless – multiple consumer experiences, but one business.

Microservices

I have written before on the topic of microservices. They have their strengths and weaknesses. But hopefully my definition above makes it clear it does not matter how back office functionality is implemented or deployed. It can be important when selecting a platform, but it is orthogonal to the term “headless”. Microservices can be thought of as taking the concept of separation for headless and pushing it to an extreme – everything should be disconnected and so more easily replaced, not just consumer experiences.

This approach offers a lot of flexibility. It becomes much easier to replace more parts of a system without disrupting the whole. The larger the business, the more useful microservice architectures are likely to be.

But microservice architectures come with increased operational costs. There are more moving parts. You need better deployment practices as there are more parts to deploy, in particular deployment orders due to potentially complex versioning dependencies. You need more advanced monitoring systems. Testing can be harder. The list goes on. I have built systems where I would not consider any architecture other than microservice based. But I think it is wrong to say monolithic architectures are always bad. You can still have good separation of functionality internally within the code base through good object-oriented programming practices. The main difference is in deployment. A monolith you deploy fewer independent services. This greatly simplifies deployment and monitoring, which can reduce operational costs.

Put simply, understand the pros and cons of any technology and use it when appropriate. I do not believe microservices are always better than monoliths.

Conclusion

I found it an interesting article. Terminology can always get muddled when marketing gets involved. If a term becomes an industry buzzword (potentially blown out of proportion), marketing departments kick into gear. Changing the product architecture itself can take time, so it is much easier to “stretch” the definition of terms so an existing product can get that checkbox of conforming to a new buzzword. This is not a criticism by the way – often the platform does solve the same requirement and that is what really matters. It is solutions to problems that matters more, not the technology used to do it.

From a technical perspective, I see “headless commerce” and “microservice architectures” as two separate concepts. The connection is microservice architectures are more naturally disposed towards supporting headless commerce as they have clearly defined API surfaces, mandated by the architecture. But headless commerce can certainly be implemented using a monolithic backend, if sufficient APIs are exposed.