Even though the headless architecture concept might sound unfamiliar and new, it has been around for a while now. As an increasing number of companies are adapting headless architecture when building their commerce platforms, the maturity and stability of headless architecture have improved and will continue to improve. This is the first article of the headless architecture series, in which we will take you on a journey to create a better understanding of the headless architecture concept and why it is worth to be on the radar for your digital commerce platform.

<<< Start >>>

<<< End >>>

What is headless architecture?

In simple language, headless architecture means wrapping up all the business logic and functionalities in a set of APIs, which are powered by the specialized backends and make them available so that any front-end channel can hook into these APIs and provide the customer experience desired for that channel.

It offers you the opportunity to use ‘best of breed’ platforms specialized in their functions (for example, Commerce, CMS, Search, Payment, Customers, PIM, Media management). Headless architecture also gives you the flexibility to choose the way you want to build your front-end for your sales channels, as opposed to only using the front-end technology provided by your commerce or CMS platform.

Furthermore, it enables a quick introduction of new customer touchpoints/front-end channels, as all of them can be powered by the same set of APIs ensuring consistency of data and functionalities. For example, how the add-to-cart event is processed is defined only in one place—in the API—rather than copying the processing logic to all the new front-ends.

<<< Start >>>

<<< End >>>

The term ‘headless architecture’ was coined some time back and has been used ever since to refer to this concept. As the headless architecture keeps on evolving, new definitions emerge. For example, some have referred to headless commerce as ‘composable commerce’, which means you can decide in what ways you build your commerce applications by selecting your own building blocks from different parties rather than from one platform vendor.

While looking at the term headless, it would suggest that the architecture is without a head, but it represents a ‘flexible head’. The flexible head gives you more flexibility and opportunities to evolve the customer experience.

There are many ways to achieve a headless architecture, which we'll discuss in the following posts in the series. For this article, let’s first establish why it's getting increasingly more common for digital commerce applications.

Why it might be a good choice for you?

Keeping up with the latest trends and technology is not an easy task for many companies. It’s not enough to be up to speed about new possibilities that are relevant to your company but deciding which ones are valuable to your organization and being able to adapt them quickly will plan a key role in ensuring your competitive edge.

<<< Start >>>

"To stay ahead of the competition, agility and adaptibility are a must."


<<< End >>>

These capabilities should also exist for your digital commerce platform. The agility depends on how flexible your digital application is. You can ask yourself:

  • How easy is it to introduce a new customer touchpoint?
  • How easy is it to change the components of your digital application?
  • How easy is it to deploy smaller chunks of changes; does it need deployment of the whole application?
  • Do you need to do regression tests for the whole application/ functionality when you touch a small part of the application?

Apart from agility, there are more questions around the flexibility and the adaptability of digital applications. For example:

  • When there's extra load on your website, can the components be scaled up individually or does the whole application needs scaling up?
  • Is it possible to change the technology your front-end is using when necessary? For example, if you want to move to the latest front-end frameworks like ReactJS, VueJS, et cetera.
  • Is it possible to change parts of your digital application easily? For example, change the search engine only.

<<< Start >>>

<<< End >>>

When you use a headless (or 'flexible head' or 'composable commerce') architecture, you answer the questions asked earlier with a positive response.  

This means, if done right, a headless architecture will support:

  • Front-end built with preferred technology, enabling flexibility and scalability to meet changing customer expectations for (digital) experiences.
  • Flexibility in choosing separate ‘best of breed’ back-end functionalities and platforms.
  • Scaling and deployment of individual parts of the application, limiting regression.

Most importantly, this enables a pay-what-you-use concept. For example, the license cost of current enterprise e-commerce platforms includes the cost of all functionalities provided by the platform, no matter if you use it or not. As a good example, most of the existing enterprise commerce platforms come with an in-built CMS, and businesses are paying for it as there is no option to exclude it. However, most of the time, companies end up integrating a specialized CMS platform to provide a better customer experience. This can drastically increase your total cost of ownership.

<<< Start >>>

<<< End >>>

Do you really need it?

The headless architecture promises better readiness for any future additions or changes to your digital platform. This doesn’t mean that you necessarily have to do it.

As the components of the application in a headless architecture are separately managed, it means you need to manage more. A few concerns may, for instance, be:

  • Having the right technical people available who can drive the architecture in a true headless pattern. In absence of the right people, a headless architecture can also turn into a monolith after time containing many functions in one component/ building block. This means the interdependency of individual components (microservices) to be managed properly.
  • Management of the deployment, monitoring, and logging infrastructure for different components (microservices).
  • The total cost of ownership can increase based on the number of individual platforms used. This cost can be higher than a traditional platform in some cases.
  • Monolith commerce systems that provide all functions in one can still be a good choice when rolling out for a new business. The time to market is shorter and there are many quick wins you can achieve in a short amount of time. 

<<< Start >>>

"Don't just build it because you can. With greater flexibility comes greater responsibility."

<<< End >>>

Is your organization ready to take on the new normal in digital commerce?

On one hand, a headless architecture gives you more flexibility in building customer experiences and ensures easy adaptations and transitions for future changes. On the other hand, it requires a group of experienced technical professionals to build and manage it. This can put a large strain on your company’s resources.

A comprehensive architecture assessment and future roadmap analysis are required to know if a headless architecture is a right fit for your digital commerce platform. It also requires a continuous commitment from the company’s management, as building, maintaining, and developing the headless architecture is a continuous journey.

Currently, many organizations have already taken this approach and are reaping the benefits of this flexible architecture. Seeing more and more brands adopting the pattern, it would be fair to say that it is becoming the new normal in the field of digital commerce.

Do you have more questions? Feel free to reach out to us to share views or get more insights.

Jasvent Singh

Digital Business Integration Manager - Accenture Interactive, the Netherlands

Subscription Center
Subscribe to Accenture Insights Subscribe to Accenture Insights