'Decoupled' is a definitive trend in the content management landscape. People and organizations are increasingly consuming Content as a Service (CaaS) and there is a growing number of new solutions baptized as headless CMS. A new Forrester report, The Rise of the Headless CMS, features eZ as an innovator in this area. Because the topic is evolving -- and maybe confusing to non-experts -- we have built this 101 to help you understand what headless and decoupled CMSes are, if they are a fit for your digital business goals and how eZ supports Content as a Service with our own platform.

Because this post is quite in-depth, we'll start with a table of contents. Those of you with working knowledge of certain aspects of this topic may want to skip ahead.

• What is Content as a Service?
• What is a Headless CMS?
• What is a Decoupled CMS?
• The repository, the cornerstone of good content management
• Selecting the right approach
• When headless doesn't make sense
• How eZ supports Content as a Service
• Summary and take-aways

What is Content as a Service?

Content as a Service (or CaaS) is not a clear, universally defined term. It has grown organically over the last 5 to 10 years. As an evolving concept, it can be explained this way:

It refers to a use case where content (ie. any content living on the Web and more globally on the Internet) is created and authored independently from the place it will be used, and can be consumed by a range of different applications, be it websites, mobile apps, kiosks and connected devices (aka the Internet of Things), which over time could mean everything from your Smart TV or Apple Watch to your fridge or your car dashboard. The concept of Content as a Service is intrinsically decoupled, drawing a clear line between the people creating the content, the people delivering the content, and of course the people consuming it.

This implies that content is available via a web service through an API over the Internet. In its purest form, we can consider Content as a Service to not only contain the access to the content but also all things referring to its provisioning, such as:

• Does the user have the right to get the content?
• Has the user paid for the content?

This can include more than just requesting content but also delivering it through an API. In addition, there may be e-commerce and transactional processes to get the content.

What is a Headless CMS?

Headless sounds catchy but what does it really mean? Is the front-end supposed to be the head and the back-end the rest of the body? It's definitely very visual.

To be specific, headless CMS is a content management system (CMS) that's focus is not on the delivery of content through pages, but solely on the back-end work: providing content creators the tools to get their workflows up to a point where content is ready to be consumed in a Content as a Service use case. It's basically a regular CMS amputated of its Web delivery layer: no templating system, no HTML delivery and no management of the site structure and style. A headless CMS focuses naturally on supporting users with the following tasks:

• Modelling content
• Creating and authoring content
• Facilitating the workflow and the collaboration around content (including translations)
• Organizing content in the repository (semantic, collections, taxonomies)

And deliberately Content as a Service does not touch how content will be delivered or presented on the front-end to end users.

Examples of headless CMSes

Pure new headless CMSes such as Prismic and Contentful have been emerging. But players working in the traditional CMS space have also started to focus on a headless approach. eZ Platform, the core of eZ Enterprise, consists mainly of a repository and a user interface to manage the repository, and because the platform is decoupled yet integrated, it can be used out-of-the-box as a headless CMS. As a key benefit, our content platform can be enhanced with powerful tools for editors as well as support and maintenance provided with a commercial subscription to eZ Enterprise. ECMarchitect.com gave a good brief on the emerging headless CMS market.

What is a Decoupled CMS?

This is the third big keyword after Content as a Service and headless CMS. And here as well, the term decoupled isn't fully defined. Decoupled can really be understood on two levels:

First, it refers to decoupling the process of creating content from delivering it. In this context, decoupling relates closely to content strategy and implies you structure your organization and systems around different functions. The role of creating content is not the same as the role of delivering it, even if it is sometime hard to imagine. You can accomplish this with a headless CMS or a traditional CMS but only one that can offer a true separation between content and presentation.

The second way to look at the concept of decoupled takes us deeper into the software architecture. In this sense, decoupled refers to separating the different components of a software solution from a software perspective. This follows concepts in the microservices software architecture approach, which are very popular now in the software world. Taken to the extreme, it would imply your content management solution ends up being an assembly of a large number of very dedicated components which have been built or selected individually. It's fair to say this approach can quickly put you into another role, the one of software maker, building a product on top of many components. Congrats, you're now in the software business!

A level of decoupling that meets both the content process view and the software architecture view is probably best explained by segmenting at not too low of a level, considering the following three components: authoring, storage and delivery.

However, there could be even more decoupling on a more granular level , as I mentioned in a previous blog post.

Regardless of how you understand decoupled CMS, the term can be misleading. What is "THE decoupled CMS"? Is it the back end side? The front end side? Both? There's no clear definition about this at all.

We recommend speaking more about "decoupled content management solutions" instead of a "system." (assuming everybody gets the difference between a "solution" and a "system"). To be specific, a solution is possibly made from the assembly of different systems, systems from the market or built bespoke.

Now, is a decoupled solution to be provided by one single provider, or many different ones? There are pros and cons for both but the important thing in almost any case is to ensure there is a real decoupling between the core functions, as follows:

• Making sure you can access content and deliver it on any application/technology
• Making sure you can eventually plug in the tool you want for content feeding
• Making sure the repository can be accessed directly from APIs in read as much as in write mode

eZ's architecture enables all three of these key functions.

The repository, the cornerstone of good content management

Ultimately, the cornerstone of good content management, in a decoupled or a coupled system, is the content repository you use.

There is no point to use a headless CMS if it is only able to deliver blobs of information unfitted to your different channels and if it does not come with the power of a semantically rich content organization.

There is also no point to decouple if the presentation and styles that will apply to your content are stored within the content.

To manage your content efficiently and effectively, your repository needs to provide the ability to:

• Store any content type to fit your information architecture as well as the ability to modify the content model you are creating
• Semantically create relations, or collections, to allow different ways of navigating and discovering content that can be meaningful
• Read and write your content in different ways and different formats such as XML and Json, just to name a few
• Enable flexible workflows for different processes such as reviews, approvals and sunsetting of content.
• Facilitate localization and translation of content, with a customizable translation workflow that is easy to implement

Selecting the right approach

When it comes to content management, there's no "one size fits all," and organizations have many different needs. That is what makes content management so different from other domains such as marketing automation or CRM, where there often are configurations but much lower levels of customization are needed.

In general, we can say that going headless or decoupled is an excellent approach for all use cases which are clearly Content as a Service by nature. For example, news and media organizations would greatly benefit from a headless CMS in order to make their content available to other platforms via API.

It's also a very good approach for all companies who have the need for building very specific front-ends, eventually blending in the front-end content and other services. In this case, the traditional CMS template system might be too limiting. The decoupled way will make it possible for developers to simply integrate content via APIs over the Web (ie. Json or XML content over RESTful communication) and literally build any kind of front end they want.

If your digital product is mostly based on mobile apps for instance, or if it is about displaying content on very specific devices such as digital displays in airports or museums, the decoupled approach might also be a good choice, enabling you to use the different displays at their best, with the technology they provide (even if it ends up being HTML-based).

When headless doesn't make sense.

While a headless CMS approach can be a very strong fit for certain cases, there are many projects where the decoupled approach adds little value and may very well generate additional costs and challenges.

For instance, if you are launching a simple corporate website with very few pages, you have very little to gain to go decoupled. You'll achieve your business objectives as well if not better using a traditional web content management (WCM) approach and site maintenance will be simplified, as building custom front end generates extra maintenance work and costs.

Another example would be an information portal, extremely heavy on content and heavily structured, but with relatively simple requirements when it comes to presentation. Think informational-rich internal or external sites for large organizations such as what you often find in governmental websites, biopharmaceuticals, medical or even heavily structured product catalogs. A traditional CMS can provide great value and there is not necessarily added value in decoupling.

The modern CMS: extensible and decoupled

Most enterprises today, especially those with many brands, international audiences and multiple digital properties, should look to consolidating their digital environments on a flexible, scalable and decoupled technology platform.

With a modern CMS based on a decoupled architecture, organizations have the freedom to go headless or traditional -- or a combination of the two depending on the project. More importantly, these systems adapt to the organization's business needs so they don't get stuck with limited technology that hinders their plans to innovate.

How eZ supports Content as a Service

At eZ, we've always ensured our software was highly versatile. For over 15 years, eZ's CMS has been based on a strong decoupling that lets developers chose different models when it comes to content delivery. This flexibility makes our technology an exceptional fit in a cross-platform, cross-channel scenario.

Our new open source core eZ Platform it provides a modular toolkit that covers every area of content management from the repository and its REST API to the editorial interface and the web delivery framework on the other end. Organizations can use and extend eZ Platform to build a full suite of digital solutions relying on one or all of these components - from brand sites and news portals to native apps and the Internet of Things.

Many of our clients and partners use eZ partly or entirely as a headless CMS to build very specific front ends based on Angular.js or React. This is a great architecture that our engineers and solution architects love since it really makes the best of our APIs.

On the other hand, as I mentioned earlier, while the decoupled approach opens up a wide range of possibilities and value, It doesn't mean all organizations or all projects should go this way. A traditional content management approach can make a lot of sense. At eZ we've implemented a decoupled approach to traditional content management, where organizations can manage as many sites as they want in a single system, share content across properties, manage translations and localize information seamlessly.

eZ's versatility is perhaps where we provide the most value and differentiate the most from other players in the CMS landscape. Our technology keeps the door open for further projects, catalyzes innovation and future proofs your content, as Bård Farstad, co-founder at eZ, often says.

Summary and take-aways

The Content Management discipline is evolving, driven by the need to create digital experiences that are increasingly cross-platform and richer and more personalized than ever before. Users are engaging with brands across many platforms and channels, and APIs are becoming a necessity. This explains the rise of headless approaches to content management.

New technological approaches can blur your view on what's best for your organization. It's important to ask the right questions and do your research.

Here are some things to consider before selecting a headless CMS:

• Evaluate the business value of a decoupled approach. What is the rationale for your organization?
• Analyze the costs of maintaining custom front-end(s) vs implementing a traditional web content management solution. How do they compare?
• Do a SWOT cost benefit analysis, comparing capabilities of a headless CMS to a traditional web content management system.
• Think beyond your current web project and assess your full set of digital properties. Would it benefit your organization to consolidate your properties into a single technology stack? What technology set-up will support and sustain your digital business for the long run?

Ultimately, it's difficult to foresee the future so if you're unsure of committing to a headless system now, your best bet is to invest in a flexible, decoupled yet integrated platform that enables both headless and traditional approaches.

Beyond this, don't forget the importance of a clear information architecture and a CMS that enables you to customize your content model. As with topics such as personalization, invest in information architecture and content strategy before jumping into technicalities. Technology choices should come after content strategy and information architecture quite naturally.

If you're more interested in Content as a Service, here is some further reading:

• Forrester - The Rise Of The Headless Content Management (for pay)
• eZ - Decoupled yet Integrated
• Pros and cons of Microservices architectures
• Even if now a bit dated, interesting thoughts from Deane Barker
• Choosing a content management system (Mark Rodseth, Hugenic)

Discover which skills and technology are required to successfully implement Headless CMS in the Enterprise

Headless CMS in the Enterprise

This eBook covers the considerations you should take into account to have the right skills and technology in place as well as what to pay attention to when it comes to the cost of ownership to ensure successful digital transformation in your organization.

Download eBook now