Everyone is talking about “headless" these days. It’s like heads have gone out of fashion. If you’re in some way responsible for the architecture of a large scale commerce site, you might be left wondering what all the fuss is about. Are the people who trumpet the benefits of headless approaches to eCommerce even clear exactly what they mean, let alone able to articulate and evaluate the benefits they’re looking for?
The basic idea is simple. It’s a move away from the idea that our commerce site should be driven by a monolithic “eCommerce System” that both understands how to handle commerce and also knows how to render the website.
Instead, we expose the functionality of our commerce engine via a well-defined API (for example serving JSON data over a RESTful HTTP API). Our "display layer” is a separate application which makes use of this API. This could be a custom-built web application or it could be an “experience management” platform that can deliver to multiple channels and offers a degree of flexibility that allows the business greater control over the experiences we present to our customers.
It’s not hard to construct a justification for this approach on abstract technical grounds. It reduces coupling between “business logic” and “display”. It allows us to talk about our system architecture as conforming to patterns such as “layered architecture”. It follows the “Unix philosophy” that argues that "Every application should do one thing and do it well.” But how does all this translate into tangible benefits for your business? How would you justify this in your next presentation to the Board, some of whom don’t necessarily care about the technical principles?
The first step is to understand what might be driving this change from a market point of view. The Future Shopper Report 2019, from Wunderman Thompson Commerce, found that when customers search for specific products, 56 per cent of the time they do so on Amazon. Many retailers are finding that sales through Amazon are rivalling or even outstripping revenues from their owned sites. Considered as a channel, Amazon generates significant profit for many retailers. However, compared to “owned" sites it performs very badly in terms of generating brand equity. This seems to be driving what some people are calling “the convergence of commerce and content”. Owned sites aren’t just about providing the opportunity to purchase, they are places where you can tell your stories.
At the same time, your customers’ expectations are growing. They’re interacting with you through multiple touchpoints on multiple devices. They expect their journey to be seamless. They expect your identity and messaging to be consistent and your story to make sense. And when they decide to buy, they expect to do that whenever and wherever makes sense to them. Once upon a time, it was enough to build a site that offered your product catalogue and a shopping basket. along with a few pages of static inspirational content. Then you just needed to redirect all interactions on other channels to your site and watch the money roll in. Now, you need to manage your content consistently across all of your touchpoints and to be ready to offer transactional capabilities at whatever moment makes sense to your customers.
Taken together, the need to deliver richer narratives and seamlessly interweave content with commerce functionality throughout the user journey tends to drive us towards a more flexible architecture. Instead of trying to glue together two monolithic applications, one delivering a shopfront and the other serving up brochureware, the headless approach allows us to deliver commerce functionality as a service which can be injected into any user journey that our experience platform is able to deliver.
This brings additional benefits as well. We are effectively taking an “API first” approach to the retail services that our company is able to offer, and when we do this we are exposing a presentation-agnostic API to our retail capabilities. This opens up a whole range of new possibilities. It certainly becomes easier to implement new owned channels (a mobile app, for example, driven by the same API), but also we’re quite likely to find new channels or clients for our API that we weren’t even thinking about when we designed it (surfacing actionable recommendations on a site owned by one of our partners, for example).
And what of the content itself? Who creates it and what system do they work in? There are two distinctly different approaches we could take here. In the first approach (let’s call this simply “headless commerce”) we run the eCommerce functionality as a set of headless services which we integrate into a site built with a content management system (or perhaps “experience management system”, if we want to give it a fancy title). Site authors use the CMS to construct the site just as they would with any other site and the CMS delivers the site to our customers. In this scenario the eCommerce functionality is “headless” but the CMS is the “head”.
The alternative (let’s call it “headless commerce with headless CMS”) we take things a little further and introduce another separation of concerns. We make use of a “headless CMS” that provides authoring capabilities for display agnostic content and exposes it via an API (JSON over HTTP is a common choice). In this case, the “head” is a separate application, which could be a traditional web application or perhaps a client-side “Single Page Application” (SPA). Why would we want to do this? The short answer is a single (possibly made-up) word: “omnichannel”. We want to deliver consistent messaging across all of our channels whilst avoiding the inefficiency of duplicated effort. A route to achieving this is to divorce content from display and to create all content via a single system.
A big challenge that “headless CMS” systems face is maintaining a good “authoring experience”. When we divorce content from display, we may find that we have taken away from authors some of the visual context they need in order to be sure that what they produce works well. For some types of content, it may be perfectly fine to work via a form-based interface that looks nothing like the way the content will ultimately be rendered, but for some authoring tasks, you can't beat the full “what-you-see-is-what-you-get”, drag and drop interface of a modern “experience management” system.
The two approaches to content management I've outlined are in fact not necessarily mutually exclusive. We might like the channel independence that we get from authoring content in a “headless CMS” but also want the level of flexibility and control over the way that pages get rendered that comes from using a more traditional CMS. So we might want to consider an architecture that includes both: a headless CMS that produces channel-independent editorial content feeding into a web CMS that allows the business fine-grained control over how that content is displayed.
Authorability and agility
This last point touches upon a key benefit of headless commerce approaches that we haven't yet emphasised enough. For want of a better word I'll call this “authorability”. When we implement our commerce functionality as a pure service, and use an experience management system to build the site that delivers it, we have created a platform that gives the authors full control over the whole experience. We're no longer in a position where changes to the “commerce” parts of our site can only be done by developers. So now we have not only created a customer experience that represents a seamless blending of content and commerce, we've also given our business the ability to make changes to the experience, across the whole site, as frequently as they need to. This agility, this ability to change rapidly in response to the market and to what we learn about our customers, can give your company a competitive edge.
Architecting the future
So where does this lead us, technically? As IT professionals, architects and engineers should we embrace the “headless” trend? I believe the answer is “yes”, but we need to be sure that we are able to articulate its benefits in terms of business goals as well as technical principles. Ultimately I think the desire to detach the display layer from services in a “headless” architecture is part of a wider trend towards decoupling the individual elements of the systems that we design. Where previously an eCommerce system might have been a single, monolithic system, it's now common for multiple independent systems to deliver capabilities such as Product Information Management, Search, Order Management, Inventory, Pricing and so on. Decoupling the architectures of large systems into an ecosystem of atomic and independent services has been a common theme in the recent history of enterprise architecture, from “service oriented architecture”, through “microservices" to “serverless”. The driving force for this has ultimately been agility.
For retailers who hope to compete and succeed, it's essential to have a platform that is open to extension and innovation. It is hard to predict the impact of newly emerging technologies, like Voice, Virtual Reality or Machine Learning. We can be sure, however, that a monolithic platform that is slow to integrate new technologies presents a serious risk to the business that owns it.
As architects and IT decision-makers, we need to remember that it's not enough to focus on the system we are about to deliver right now. We need to design platforms which can evolve over time to meet the challenges of the future.
David Friar, Senior Solutions Architect, Cognifide