Dirty secrets of headless commerce: What some vendors intentionally don’t say

The dirty secrets of headless commerce solutions: What some vendors are (intentionally) not telling you can cost you, big time.

Headless commerce—or, simply, “headless”—is the darling of the B2C world right now. According to Google Trends, search requests for headless commerce have grown exponentially since early 2020. From an e-commerce standpoint, it’s easy to see why.

Consumers have been housebound, tethered to their social media feeds during the pandemic. Direct-to-consumer brands can take advantage of media like Instagram, TikTok, or Facebook and take their wares straight to their intended audience. Headless commerce solutions are a no-brainer.

Headless architectures provide great flexibility. Because of the decoupling of the frontend and the backend (and the availability of APIs), it’s much easier for organizations who want to deploy commerce on new channels to do it with a platform that supports headless.

Headless commerce solutions also provide greater agility as the frontend and backend are deployed separately. Since agility has become a tremendous business differentiator, interest in headless is surging.

Headless commerce solutions: Cutting through the hype

But what exactly is headless commerce? As is often the case in the worlds of tech and marketing, there’s a tendency to latch onto the latest shiny buzzword — think back to big data or artificial intelligence/machine learning a couple of years ago — and inject it into as many conversations as possible.

When people can’t really define what a thing is, however, the waters around that thing tend to get pretty murky. That’s exactly what’s happening with headless commerce.

We can’t be too hard on marketers; they’re not the only ones muddying the waters. Plenty of vendors are adding to the mix, intentionally or otherwise, by conflating headless, cloud, APIs, and microservices. They have their agendas, so it’s to their advantage to blur the lines between these things. And to be clear, none of them is the same.

Simply put, headless commerce means:

1. The frontend/storefront/glass is decoupled from the commerce engine (i.e., the backend).
2. Since it’s decoupled, it consumes backend capabilities like pricing and promotions via API calls.
3. Therefore, by definition, for a commerce platform to be able to support headless deployments, it needs API coverage of the commerce backend functionality.

Let’s jump in and take a closer look at exactly what headless is (and what it isn’t), where it came from, and who it’s for.

Headless commerce isn’t anything new

While the term itself might have only started to gather steam in the last couple of years, the concept of headless isn’t remotely new. As mentioned above, it’s an API-first approach where the front end/presentation layer/glass is decoupled from the core (using the APIs).

For example, at SAP (and formerly Hybris), we’ve been enabling commerce capabilities via our Restful API layer (Omni-Commerce connect) for over a decade. About half of the 3500+ customers that run SAP Commerce (on-premises and in the cloud) do so in a headless fashion with a third- party CMS or bespoke decoupled storefront.

The point is, don’t be fooled by the buzz; headless hasn’t just emerged onto the scene.

Pure headless commerce solutions aren’t for everyone

Headless, as with everything else, isn’t for everybody. It’s complex, for starters. Developers must have depth and breadth of skill across multiple codebases.

But that’s not all. They require IT maturity and development capacity, as a bespoke presentation layer/storefront has to be built entirely from scratch using front-end frameworks and libraries (such as Angular/React/Vue) or through a partner solution at the bare minimum. These custom frontends are generally not vendor supported.

Moreover, bespoke frontends typically limit the ability of business practitioners to design and update the frontend without the help of IT. If that’s an important consideration for your business, then headless-only commerce solutions might not be a good fit for you.

The good news: Vendors offer “headless and head-on” capabilities with 100% API coverage and a decoupled storefront without the need to build it from the ground up. This approach accelerates frontend development and the overall project delivery timeline.

Headless doesn’t equal microservices

As we mentioned at the beginning, some vendors are intentionally muddying the waters by conflating headless with microservices. Let’s set the record straight.

No, Microservices are NOT equivalent to APIs. And no (I am about to use my “outside” voice here), A MICROSERVICE-BASED ARCHITECTURE ISN’T A PREREQUISITE TO HEADLESS (APIs, on the other hand, are).

According to Martin Fowler, “the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”

You read that right – microservices expose their capabilities via APIs and, as such, are complementary, not interchangeable concepts. Compare a microservice-based architecture to a monolithic architecture where the entire application consists of “one piece” of code. In the real world, few applications are either fully microservices based or fully monolithic; they typically fall somewhere in the middle.

While microservices can do lots of things, they are also costly (lots of overhead) and are by no means a silver bullet for agility. Without going into the pros and cons of each architectural pattern, it’s worth noting that the main advantage of a microservice-based architecture is the speed and agility at which large development organizations can build software. The overhead is small compared to the time to develop code in a monolithic architecture.

So, it’s quite valuable for a commerce platform vendor like Amazon that typically has hundreds of developers working on it. However, this sort of architecture wouldn’t work well for everybody. It’s a particularly poor fit for organizations that don’t have the IT chops and corresponding commerce development resources to benefit from it.

It’s better to consider what Gartner calls the composable business architecture. This model of interchangeable building blocks enables a business to rearrange as needed, depending on factors such as a shift in customer values or sudden change in supply chain or materials. These building blocks or modules could be micro, but also macro services.

According to Gartner, this architecture provides: speed through discovery, greater agility through modularity, better leadership through orchestration, and resilience through autonomy. This couldn’t have been more important than during the pandemic, when organizations had to completely rethink and pivot their business models in a matter of days or risk going bankrupt.

Now, if you’re wondering why some vendors are conflating headless with microservices, the answer is as old as the enterprise software market itself. By emphasizing a new shiny capability, it allows emerging vendors to divert focus from capabilities where they fall short like platform and feature robustness.

And while a modern architecture is definitely an important consideration when selecting a commerce platform, it can’t be at the expense of functional richness or the ability to empower business users.

Headless is here to stay

As the number of touchpoints continue to grow, headless commerce isn’t going anywhere. When selecting a platform, consider all the functional and non-functional requirements applicable to your business, not just today, but also tomorrow.

Selecting a platform that might do the job today but won’t support your growth down the line (e.g., international localization) is short-sighted and will only result in kicking the proverbial can down the road.

Finally, the fact that some vendors want you to look at the bright, shiny object doesn’t mean the other requirements suddenly don’t matter. Product information management, web content management, order management, B2B capabilities, B2C capabilities, and personalization are essential.

Don’t fall in the trap of conflating robust functionally with legacy architecture, despite what some vendors say.