On the road to composable – Going Headless

The starting point, and a bit of terminology

How long does your content publication process take? Multiple days? Is a design change, that was supposed to be as simple as changing a button colour on your site, taking multiple sprints to finish? Are you waiting forever for your price change to appear in the search results? Then you’re most likely suffering from a poorly decoupled frontend. “A what?”, you might ask, “Is that contagious?” Not really, but let’s first get our terminologies straight: What is meant by frontend, backend, and the most mysterious of words; “decoupling”?

The frontend takes care of the custom user experience; the ever-changing brand messages, colour palettes and user flows. This part is what changes the most often in your eCommerce platform, so you can stay relevant to your customers and can offer them unique content and experiences. Here you want to try out new ideas quickly, test them for success in front of customers and discover how you can serve them best. And here you are the most hindered by connections to the backend.

The backend of your eCommerce engine takes care of the product catalogue, price- and promotion management, order management, etc. Think of it as the databases in which information is stored, and from where it is retrieved and changed when you need it.

Where the problem arises is when the frontend and backend are woven together too closely, or in software terms: tightly coupled. Think about a bowl of your favourite spaghetti, which used to be a set of separate ingredients, but are now one thing: a bowl of spaghetti. Try isolating an ingredient now. Pretty hard, isn’t it? So decoupling means separating the frontend from the backend in a meaningful way. But why would you like to do this?

Why headless?

A good way to look at your technology is through the lens of pace-layered architecture. In the picture below, you can see the level at which systems need change. Your backend (database, product model, pricing model, etc) does not need to change so often, but your frontend experiences need to. They reside in different layers of the architecture. The frontend is therefore a system of innovation, while your backend a system of differentiation. Below a third layer exists still, your systems of record. Think about your ERP system, your PIM system, where you store your data for master data management.

In other words, the pace of change for distinct layers is different. Therefore, you want them to be independent of each other, so you have as little dependencies as possible for the changes you want to make. You don’t want a stable system with a low change rate to slow down your high change rate systems, or your high change rate systems to introduce instability in your stable systems! The aim of separation (decoupling) is therefore speed. When the amount of complexities and dependencies goes down, the time to market of new features goes up. That time can then be used to provide value quicker to your customers, bring new features to live quicker than your competitors, or even fix defects quicker, before they start preventing customers from clicking on that “order now” button…

It’s reassuring how common this problem is, scaling out of a monolith. Most successful retailers did well before eCommerce was a channel to think about. As we read in the last article, by the time they started on the eCommerce journey, they acquired a monolithic eCommerce engine, since it solved their problems with one system, relatively easily and quickly. Or they built a custom engine themselves, but were overtaken by their own success. Either way, the pace in which changes were needed to the customer experience was becoming too high, and the monolith was not able to scale with the demand. This happened with Adidas and Nike, who grew out of their Demandware (Salesforce) platform. It even happened to Amazon, despite having built their own eCommerce engine Cadabra all in-house. So, what was their first step of scaling out of their monolith?  They liberated the system that was in the most pain; the frontend.

But you might wonder, how does your eCommerce system become headless? Surely, without some frontend your customers cannot experience your shop anymore? (As in “how did the headless chicken cross the road? In a KFC bucket...”).

Indeed, the way to do this is by separating the frontend visuals from the backend logic. The frontend should just be worried about display, not about functional rules or data. It should get its data from the backend, by requesting it, by API. The separated frontend is generally custom built, using technologies such as React, Next.JS or OutSystems (our preferred choice at Product League). And this frontend is only allowed to request data, not store something itself!

The value

Is your monolithic eCommerce engine bursting at the seams? And is the word “technical debt” heard in most conversations about your roadmap? Time to consider scaling at the point where you experience the most pain: the user experience.

Going headless is not as difficult as it sounds and has many advantages. By allowing the frontend portion of your platform (the part that is most subject to change) to be independent, you start to unlock the potential of your teams: you will see faster release cycles, time to market of new features will improve, and page speed will be up. All of this will directly benefit your customers and your revenue, allowing for a quick return on investments made.  What this will not do yet, is to take care of the complicated backend, with its layers of business rules, databases and (product-) content.

 For operating your business at a true scale, with the best performance and with great flexibility to react to customer demand, going headless will still not be enough but it is the right first step.  During your move to headless, or even before, you will experiment with the first microservices. A dedicated onsite search engine for example, or a modern content management system that is headless by design. Truly, now you are heading towards composable, a landscape that is no longer limited by the question “what still fits?” within the monolithic platforms, but instead is being determined by the question “what is the right fit for me?”.   

But we'll leave that nut to be cracked in the third article of our series; On the road to composable: Composable freedom. We hope you enjoyed this article, and have helped ease some of your worries over the prospect of cutting off the head of your eCommerce platform. See you next time!