Opening Up Content Management
Helping your business decide between monolith, decoupled, and headless content management
Content management has been disrupted. After a long period of stability, digital content management has been going through a significant transformation in recent years. Let’s take a look at how things are changing and help you decide on the right approach for your organization. We’ll consider the lens of engineering, marketing, and IT, and what it takes to build, manage, and operate these tools.
First, some quick context. Led by the rise of dynamic, JavaScript-driven interfaces, content management has been compelled to provide content in a way where the front-end presentation layer is separated from the back-end content modelling, authoring interface, and storage. With this approach, content acts as one service of many in a larger microservices-based application architecture. Our CMS needs to provide Content as a Service. (That’s right, another aaS: CaaS!)
Given that paradigm, a new school of headless content management tools has arisen, such as Contentful, Strapi, and Netlify CMS. All provide the content modelling and administrative features we expect of a CMS, and then expose the content exclusively via an API, completely agnostic as to the presentation front-end. At the same time, traditional experience platforms such as Adobe, Sitecore, Drupal, and WordPress have figured out decoupled approaches where they expose content via API, in addition to their standard monolithic approaches where the CMS controls the presentation of that content as well as the back-end.
Where does that leave us? To generalize, we have three major content management approaches to consider:
- Monolith: A traditional CMS that owns the back-end and the presentation layer
- Decoupled: A traditional CMS that owns the back-end, but is configured to expose content via an API so that a separate presentation layer may be used
- Headless: A CMS that owns the back-end and is designed explicitly to expose content via an API for a separate presentation layer
Note that both the decoupled or headless approaches allow the CMS to work in a Content as a Service capacity.
Let’s take a look at these approaches in the context of some top-level considerations for your organization, listed in rough order of priority for a typical decision process. Of course, if you’re feeling impatient you can just skip to the summary at the end.
User Experience
As a reminder, we should always start with User Experience. Whether individual customers, constituents, other businesses, or internal staff, we should always be animated and driven by what our users really need. What are their goals, what makes them successful, what are their barriers? We should also consider where our content reaches them and what those interactions look like. Will it always be on the web? On a native app? In a store kiosk? To wit…
Consumers
By consumer we don’t mean people, but the applications that will consume our content. These days a content management system may need to provide content for much more than an individual website, and these requirements will fork our decision-making process very early. If you have a single website consumer and you want the CMS to control page composition and layout on that website as well as the content, you’ll want a monolith. If you have additional consumers, the traditional CMS that’s providing the monolith could also be used in a decoupled capacity for that purpose. If your content will be presented on multiple websites, native apps, kiosks or digital signage, or Internet of Things devices, you’ll need Content as a Service via a decoupled or headless approach.
It’s worth noting that detailed content modelling is at the heart of our project and is table stakes in our decision-making process. As Karen McGrane helped us crystallize many years ago, structured content is a necessity not only for multiple content consumers — ensuring the right chunks of content are sent to the right consumers — but also for responsive design and best practices around accessibility and SEO. All of these approaches to content management offer sophisticated abilities to create content types, fields, taxonomies, and content relationships that are the foundation for everything else we’re building.
Author Experience
Next let’s swing over to our authors, the ones from our marketing or communications team tasked with actually creating and managing the content. Giving them self-service tools to accomplish their goals without reliance on IT and with as little friction as possible will be crucial to project success and ongoing management of the system we build. What are your authors’ goals? What will make them successful, what are the barriers to that success? How central is content management to their responsibilities, and what are their expectations for related effort and time commitment?
Authors are already managing marketing data in multiple tools every day — a monolith may be compelling to provide centralized content management as part of a larger marketing technology stack. Adobe is the quintessential example of a monolith here, in terms of Adobe Experience Manager’s default monolithic configuration, and also tight integration with an entire stack of powerful Adobe martech tools. Here authors can do more with fewer tools and interfaces.
If our authors feel more empowered using multiple best-in-class tools to manage content for discrete purposes, then a headless approach might make sense. Decoupled can work, too, and Drupal provides an interesting middle ground. Like Adobe, Acquia provides a full martech stack with Drupal as its CMS, but as an open source tool Drupal is excellent at integration with other software, and now prides itself on being API-first, that is, it treats decoupled as a first-class citizen. With headless or decoupled approaches authors will have more tools to manage, but the organization can take its pick of the best tool to fit each purpose.
And based on where you landed regarding consumers above, you’ll want to consider the marketing perspective on integrated front-end features such as in-context editing — the ability to view content in a website and click it directly from the presentation layer to edit it. These features will either drive decision-making — toward a monolith if they are a priority — or require expectation-setting and training when using Content as a Service.
Integrations
The marketing technology landscape is massive and growing, as demonstrated by the infamous supergraphic. (Content warning: hide your children, this graphic is shocking!) The application(s) for which you’re writing content will need to integrate with other apps, it’s just a question of which ones and to what extent. While this should ideally be considered after the experience of your people, the truth is that existing use and commitments to other related tools may dictate your approach to content management. Common considerations include identity management and access control for your users, a customer data platform or data warehouse, audience segmentation, experience personalization, and customer relationship management tools.
The reality is you’ll never have a 100% comprehensive plan across the entire martech landscape, but at a high level you’ll want to consider whether you need to focus on a central, tightly-coupled stack that owns and controls many of these core tools, or you instead prefer the more modular and swappable “content mesh” approach that stitches together best-in-class tools. The former would push you toward a monolith for content management, while the latter would favor headless or possibly decoupled.
Business Logic
Our application’s business logic encompasses the ways we govern and process our content before it’s exposed to the presentation layer. A simple example is a collection of Article and Blog Post content where, before it’s ready for display on the front-end, we need to gather the most popular related content for each of our Articles.
Traditional CMSs have an advantage here, whether as monoliths or decoupled, providing ways to write business logic as an integrated part of the application via a rich set of APIs and extensible plugin systems. With headless you might write the business logic into the front-end initially, but past some threshold of complexity you’ll likely need to write some middleware as part of your “mesh” approach to hold the business logic for your applications.
Developer Experience
Of course, engineers are an important group to consider as well. Oftentimes the experience and interests of the engineering team — and this team may include in-house developers as well as contractors, consultants, and other partners — will determine which content management tools are used. How big is the team, and how much of their responsibility is it to build and operate the marketing technology stack and content management system?
If the team is tied to a particular technology stack on the back-end, a monolith or decoupled CMS that they install and manage using that technology will be compelling. If they’re tied to a particular front-end framework, or they need to separate concerns between back-end and front-end teams including workflow around development, quality engineering, and deployments, they may require a decoupled or headless approach. And if they don’t want to manage the back-end at all beyond content modelling and configuration, a SaaS-based headless approach would allow them to do so.
Infrastructure
Similar to the engineering team, our IT and operations team will have opinions on our approach to content management. How much of their responsibility is it to maintain this software stack, and what stack are they willing and able to maintain? Do they have compliance considerations regarding code and data management?
If IT doesn’t want to be in the business of maintaining the CMS software stack at all, they may opt for a headless approach using a SaaS tool, or a decoupled or monolith approach using managed services with a cloud-hosting partner. Otherwise they’ll want to run with their favorite stack on-premises or in the cloud. If they have stringent data security considerations, they may turn to a compliant hosting or SaaS partner, or need to stay on-premises.
Recap and Summary
This is an exciting time for content management! There are new architectural approaches challenging the way we think about the field, and a slew of new, forward-looking tools available. Meanwhile, traditional CMSs have taken great strides in marrying their years of battle-tested platform growth with the modern web.
Here’s a summary of factors that might push you toward the different content management approaches we’ve discussed:
Monolith
- Marketers will deliver their content to users in a single website consumer
- Marketers prefer a tightly coupled marketing toolset with a unified administrative interface
- Engineers prefer that business logic lives in the CMS
- Engineering teams are full-stack or are able to harmonize workflow across back-end and front-end
- IT prefers to maintain the CMS software stack, or use a managed services partner
Decoupled
- Marketers will deliver their content to users in one or more consumers — at least one of which is a website
- Marketers prefer a centralized marketing toolset along with separate, integrated marketing tools
- Engineers are comfortable with business logic living in the CMS, middleware, and/or the front-end of individual consumers
- Engineering teams prefer a separation of concerns between front-end and back-end
- IT prefers to use a managed services partner, or maintain the CMS software stack
Headless
- Marketers will deliver their content to users in multiple and varied consumers
- Marketers prefer the content mesh with multiple, separate, best-in-class marketing tools
- Engineers prefer that business logic is simple and lives in the front-end, or lives in separate middleware
- Engineering teams prefer a separation of concerns between front-end and back-end
- IT prefers to maintain the CMS software stack, or use a SaaS partner
This decision-making process can be complex. Hopefully this article helps get you started.
