“What is headless architecture?”; “How does it help us?”; “How can it be implemented?” are questions customers ask us on a regular basis. To better understand this type of approach, let me tell you about the 5 advantages of this type of architecture.
To start with, headless architecture is the logical next step for digital platforms:
- In the early days of the web, sites were built from scratch. They were integrated into the rest of the IS in an ad hoc manner, without any real plan. The sites’ content, presentation and business were mixed, which was a real challenge in terms of administration and maintenance.
- From the turn of the millennium, site construction was industrialised, based on off-the-shelf solutions (portal, CMS, e-commerce). This was the golden age of service-oriented architecture (SOA), with an initial organised approach to sharing business components in the form of reusable APIs. The fundamental principles were established: separation between content in a web application and functions behind an API.
- Headless architecture is the 3rd of these waves. With the arrival of the smartphone, content, business functions and data had to be shared between different touchpoints. Naturally, the trail blazed by SOA architecture was seen through to its logical conclusion: exposing everything in API form and keeping only the frontend applications, which are certainly the simplest but those best suited to the channel.
1. Headless architecture makes omnichannel easier
With its “API-centric” approach, a headless architecture goes hand in hand with an omnichannel architecture. All the functions exposed in API form (customer account, product catalogue, cart, order management, etc.) can be easily reused on all channels.
2. Agile architecture
By separating the front end (UX) from the back end (business), they can be upgraded independently, and above all at the right rates. Of course, the front end is upgraded much more quickly than the back. By separating them, the user experience can be upgraded much more quickly and brand time-to-market requirements met.
3. The ability to innovate
From a UX point of view, by separating front from back, it becomes possible to look beyond the limits of OTS solutions and create a USP-level experience.
From a functional point of view, headless architecture is part of a widespread trend of separating major “all-in-one” monolithic applications into applications focused on a specific business field. When an OTS solution is used, the quantity of built-in customisations can be limited and maintainability boosted. When a specialised need arises, innovative solutions that would have been complicated to integrate earlier can be identified.
4. Organisational separation
Back when websites were built on monolithic OTS platforms, even the most minor development needed developers with specific skills, which were even harder to find if the product was specialised. By separating front from back, specialised technology-specific teams can be assembled. For example, a UX-focused front-end team of web developers, which are far easier to recruit, and a smaller back-end team of harder-to-come-by specialists.
5. A preference for the creation of “core model” platforms
The fifth advantage concerns so-called ”core model” platforms. Many customers deploy e-commerce sites worldwide or for multiple brands. By separating front from back, it’s much easier to create a “core model” system based on a common API. The deployed brands or countries then have a lot of leeway to focus on the front and create a USP-level experience.
The way forward?
Headless architecture has become the most common structure for creating omnichannel, agile and innovative digital platforms.
The principal digital solution publishers have taken this into account by reorienting their products for use in headless mode. Newcomers have also emerged, offering an “API first” approach to CMS and e-commerce from day 1.
But implementing them in an existing system, which requires refactoring of existing applications, is quite a major operation, similar to open-heart surgery. Every implementation plan is unique, based on the existing IS, and takes a lot of architectural and planning work to build and deploy with the lowest possible impact.
Company architect SQLI