| November 18, 2019

How are Chris Martin and Gwyneth Paltrow related to Headless Commerce?

A few years back, Chris Martin and Gwyneth Paltrow famously went through a conscious uncoupling – an exercise that cut official and formal connections but kept the two parties close.

It may be time to consider whether your ecommerce application needs to do the same. Unlike Chris and Gwyneth, the path in ecommerce is much more common and increasingly well-trod…and we also use a slightly different naming convention – we call it “decoupling”.

The decoupling we’re going to discuss is the separation of your business and presentation logic so you can adapt faster and more easily to keep pace with changing consumer demands and technology.

To the seasoned ecommerce professional this may sound like Headless Commerce, and yes, it is. But let’s consider the “why” in more detail.

Who cares and moreover, why they should care? 

If you run an Ecommerce project or are involved in one, like me you are no doubt aware that change requests typically adhere to the Pareto rule, that being the 80/20 principle. I have found that when it comes to change requests 80% of the changes are often user experience or presentation layer and the remaining 20% are often back-end or integration related.

If you have an issue it can be difficult enough just to make changes to your presentation layer. But when you layer in the need to do full application regression testing you quickly incur unnecessarily large costs for the scope of the underlying problem. This is one of the key issues conscious decoupling seeks to solve.

Okay lets consciously-decouple. How can we do it? 

Let’s consider the tightly coupled world. Here is a visual example of a tightly coupled ecommerce application and storefront:

Because the UX components are part of the larger commerce platform, as you make user experience changes (those small green changes in the diagram), you still have to test the entire system, leading to those exorbitant costs we mentioned above.

Now, if you decouple your digital storefront / presentation layer / user experience, like this:

you can make changes where you need to without having to test all of your applications. The result is that you can significantly accelerate your time to market for innovations, updates and changes and you can do it in the technology of your choice.

Here is the short list of some of the benefits:

Changes now require less testing due to the reduced scope of concerns.
Changes are easier and faster to implement, as you can build you store in whatever technology is current. Getting skills and resources in a current or popular technology is easier too.
Consumer technology changes fast – today’s shiny new thing could be replaced before you even implement it if you’re unable to pivot and adapt quickly.

The industry calls this decoupling: headless commerce. We have found that not all headless commerce patterns are comparable so it’s important to make sure you ask some basic questions as you set out on your decoupling journey:

Security – Can you run your storefront securely on a separate physical and logical environment?
Scale – How do you scale it? Is it performant? Who can manage it, you or the vendor?
Risk – As time passes how will the vendor support the API Contract? You need to ensure you don’t become tightly coupled again, all be it inadvertently, and risk breaking your storefrontas you upgrade your vendor code.

Not persuaded?

If you don’t agree let’s make this easier with a simple analogy: Let’s say we go and open a traditional bricks and mortar shop such as a bakery, where you run the front of house and I will run the ovens. In a traditional approach, when you need to merchandise the baked goods (a new price, new packaging or bundling cupcakes, scones and pies for example), you would have to check with me and the ovens on those changes. This would slow down your ability to take advantage of a market opportunity like say a busload of tourists. By decoupling these two areas, you would be able to make vital changes as and when you need to. This scenario also lays bare the ridiculousness that lies at the heart of a traditional approach – why would updating or modifying one area rely so heavily on updating the entirety?