“Headless commerce” is the ubiquitous, abstract description of the modern commerce suite. Technical folks talk about it as if it’s the new gold standard, and you’re probably wondering if you’re expected to change your entire commerce stack. There’s one not-so-small problem, though: “Headless” means something different depending on who you ask — and where you sit in the vendor-user (provider-merchant) relationship. Let’s analyze that. In the end, I suspect you’ll find you were never really going to lose your head.
Retailers And Their Heads
The “head” for our purposes is the consumer-facing experience layer . . . it’s the front end of the website, or the voice-activated device in the living room, or a wearable connected device. In the context of digital commerce, it is most commonly the retail website itself. Therefore, just about every retailer has one. Why, then, is the term “headless” so popular when discussing decoupled commerce technology? Because it was coined by a vendor — one that is, of course, “headless.”
Architecture that is based on interconnected microservices has its benefits, particularly for digitally mature merchants that can manage the increased complexity. Primarily, decoupling the front and back ends allows merchants to select specialized providers for each need. This ability is not only laudable but will become table stakes for many more components of a commerce suite in the future.
So if you need a “head” and vendors are selling you a solution without one, what do you do? Think of it as a head — stay with me — that can be reattached! This experience layer is the bit that “headless” vendors may omit from their solution, which means you need a separate solution, or solutions, for those components. Who provides a “head”? You can choose an interchangeable head from a content management system, an experience management platform, or even a standalone specialty front-end provider (call it a DIY suite).
Making Heads Or Tails Of It
Need help making sense of the many messages on this topic? Some vendors take liberties with the term, so here’s my guide for you. When commerce providers say “we’re headless,” they might mean one of the following (see figure below):
- “We’re a legacy monolithic platform with extensive functionality, and we have spun off pieces of our offering into separately implementable microservices.”
- “We are a commerce platform, and we have separated our front end (or CMS or experience layer) from our back end (commerce engine or business management tools) so you can implement either or both.”
- “We’re a commerce tech provider that has containerized our offering into microservices.”
- “We are a commerce tech provider that built API-first architecture. There was never a full platform approach but rather a collection of services that may be enabled in any combination and order. Maybe there is no front-end experience layer included with our solution at all.”
To further simplify, when a vendor claims to be headless, it may mean that it doesn’t provide content or front-end management at all . . . or it might just mean this functionality is separated or optional. Read more in our report about this architecture.
Four Interpretations Of “Headless Architecture”
Considering replatforming your commerce solution or just want to learn more about what headless means for you? Set up an inquiry with me here. Check out my report, “Redefining The Three Commerce Technology Models For Today’s Business Requirements,” and watch for more of my upcoming research around the shifting commerce technology landscape.
(Written with Brandon Shaik, research associate)