Headless, coupled, progressively decoupled… What do they mean and which strategy to adopt for the future?

At a time when solutions are mature and the technical strategy is more important than the choice of tool, companies need to decide which approach to adopt: headless, coupled, decoupled, progressively decoupled... It can seem like a labyrinth. This overview focusses on, but is certainly not limited to CMS.

A few definitions of approaches

Coupled or monolithic approach

This is a traditional approach: the CMS is responsible for both management and display of data, which means that it is difficult or impossible to use data through any other system.

 

 

 

Headless or decoupled approach

This approach involves separating data management (back end) and data display (front end), considering that it will be easier for the front end to evolve over the years and, above all, that distribution channels are, or will become varied over time. This approach makes it easier to manage data at a single location and then distribute it for the web, mobile, IoT, marketing tools, etc., via an API. There is often confusion between a headless CMS and a decoupled CMS. A headless CMS does not provide an interface to display content (apart from the back office interface), but makes it possible to share data with various systems via an API. These systems then take care of how data is presented.

 

 

 

A decoupled CMS can both display content on an interface itself and share data with other platforms, via its API and two separate applications. A decoupled solution is a headless solution and more besides. In addition to being headless, it consumes its own services in order to manage the display and, therefore, integrates front-end tools.

 

 

 

Progressively decoupled or hybrid approach

This is a hybrid approach insofar as it enables the management and display of data in the traditional manner, while certain data comes from outside and is processed by an application dedicated to its display. Take the example of a CMS that is connected to an e-Commerce solution in order to get the best of the features offered by each and, therefore, provide an optimal user experience. The CMS can display content pages, product lists and product detail pages in a coupled manner, while also providing a fully decoupled path to purchase through a dedicated application, which is integrated in the website via a JavaScript framework, such as VueJS or React, for example. End users never see the e-Commerce solution directly, but only the CMS, which is able to offer them the best experience, while leaving the e-Commerce solution in charge of what it does best (such as basket and order management) in a headless manner.

"API-first", did you say? In recent years, a certain number of solutions have been moving towards an approach known as "API-first", i.e. one that favours the distribution of data via an API with its own data display feature. This is the case with content management systems such as Drupal (which can be used both as a headless or decoupled CMS, depending on whether or not you also want to use it to display content; it is not strictly speaking API-first, but has been moving steadily in this direction of late), for example, and headless solutions by nature, such as Contentful. Beware of false promises in this area: many publishers are trying to ride the wave by providing an API on their solution (which is often proprietary), but are in no way "API-first" in terms of their approach or content management. So, how to make the right choice for your technical strategy in order to meet the needs of your digital strategy? The first part of the answer: what really matters is the data, the content; not the way in which it is displayed.  

Content is king

Whatever the area, from UX to SEO, accessibility, social media, marketing and IT, everybody agrees that content is king. It is often a company's most valuable asset. It is important to be aware of this and provide content with the conditions and technical environment it deserves, so that it can be used in as many channels as possible, both now and in the future. Today, content has become a crucial part of digital strategy and is consumed on a very wide variety of media, ranging from blogs to portals, websites, connected watches, mobile apps, interactive terminals, social networks and smart devices. Not to mention the needs generated by marketing automation.

Take the example of New York's Metropolitan Transportation Authority (MTA), which is the public transport system with the most users in the United States, with 11 million passengers every day. It has used Drupal for its website for a number of years, to display information about its routes, journeys and timetables. In 2017, the authority installed panels indicating train arrivals in stations.

 

 

The 2500 panels placed throughout New York are complex systems that are able to manage data received and display it themselves, and continue to operate even when the Internet connection goes down. They are also able to contact Drupal in order to periodically download the display interface, which can evolve over time. This project managed by the MTA is a typical example of a decoupled approach, insofar as the authority displays data in the traditional way via its website, while sending the information to other technical solutions that operate through their own processes and interface. It is likely that the MTA's mobile app also uses this data, and that they are shared with Google, or in an "open-data" context. It is clear that data is essential for the MTA and that its display is enabled by technical solutions that ultimately serve its digital strategy and user journey.

The "data-first" approach enables you to free yourself of the interface and think about data in its own right, rather than as a function of its display. It is this strategy of completely separating content and display that enables the MTA to be so flexible and communicate on a wide range of media.  

How to choose the right approach?

I will attempt to be solution-oriented here and avoid falling back on the stock phrase used by IT teams: "it's complicated". In reality, let's just say that it all depends on context.

Coupled or monolithic approach

This approach offers the best time-to-market and lowest cost as it requires no data strategy. This solution will be perfectly suitable for your CMS project if the web is your only communication channel. Beware, however: the choice of a purely coupled solution could hold you back in the future, prevent you from diversifying your communication channels and require a long and costly migration process. In particular, I am thinking about publishers that do not base their offering on an open-source solution, providing a solution that has not been designed for content and multichannel communication in general, with no data strategy. It is, however, possible to use open-source solutions such as Drupal with a coupled approach. This will enable you to decouple when the time comes, as long as your data management strategy in the solution has been designed with this in mind from the outset.

Headless or decoupled approach

This approach, which involves separating the front end (interface) and back end (CMS), presents several advantages:

• Separating the front end allows it to be more flexible, enabling more advanced experiences;
• Development work will very often be facilitated between the front-end and back-end teams, as long as data contracts are clearly defined and respected;
• It will be possible to use data in a transparent manner for various channels;
• It will be possible to change interfaces regularly without touching the back end.

  However, it also presents a certain number of inconveniences:

• The interface can generally not be managed from the back office;
• Very often, it is not possible, or very difficult, to preview content before publication;
• The "visual" integration of content is not possible since it is by nature not linked to an interface.
• Numerous native features of the CMS and community modules will not be usable as they are, which will affect the cost and time-to-market.
• Generally, it is necessary to provide a SSR (Server Side Rendering) solution for SEO – a need that does not exist for a business application for example.

Many projects can benefit from adopting this approach, even though it will require the deployment of several technical solutions in order to be effective. The risk is choosing the headless approach just for the sake of it. This is particularly true in the case of a purely CMS project, as this will sometimes generate certain constraints, even though these can be managed without too much difficulty if the right technical approach is used. Elsewhere, the headless approach will facilitate the work of front-end and back-end teams, which will be able to work with almost total independence, as long as the data contract is approved by both sides. It should be considered for large scale projects, as it will enable greater flexibility and upgradeability on the front end. The decoupled approach will make it possible to get more out of the native features of the CMS and its community modules.  

Progressively decoupled or hybrid approach

This approach is not really an alternative to a coupled, decoupled or headless approach; rather, it is a solution for fairly specific technical and functional needs. As with the coupled approach, it is important to avoid choosing a CMS that cannot be decoupled in the future, and to establish an effective multichannel strategy for data. It is also important to pay attention to the management and separation of coupled and decoupled pages, so as not to interrupt the user journey and, therefore, the customer experience.

This is the approach we chose for an international project based on Drupal. It involved multiple websites with deployment on more than 70 markets, and a high level of dependency with existing information systems for e-Commerce management. As the project also involved the development of mobile apps with content managed from the CMS, the choice of Drupal enabled us to very easily implement all of the necessary APIs. We handled the CMS part in a traditional manner, which enabled us to benefit from all of the features provided by the solution, while the decoupled approach was used for the path to purchase and mobile apps.

In conclusion

From my point of view, data is a crucial asset and the approach depends greatly on your specific environment. At SQLI, we have invested a great deal of time in R&D and training in order to be able to provide headless solutions for our clients, as we believe that it is important to begin building for the future now. Clearly, it all depends on the context of the brand.

For a CMS project, it will probably be necessary to plan for at least one SSR solution for the solution to be really effective. While, more often than not, decoupling will be better suited to business applications, it can also be suited to content management systems and can facilitate the work of developers on a large-scale project. The decoupled approach offers more flexibility, while the coupled approach is clearly the simplest, as long as it is designed with an eye to the future, or it will rapidly show its limits.

This can be done by choosing a technical solution such as Drupal, for example, which will make it possible to decouple further down the road, and by respecting data. This means handling it in a totally separate way from its display, which will be able to evolve or diversify over the years, and therefore taking into account the various things you may want to do with it in the future. In any event, while "turnkey" proprietary solutions may sometimes seem attractive, it is best to go for open-source and upgradeability: think about the future!