From Content Chaos to Structured Content, with a Decoupled CMS

Create once, publish everywhere: the dream of every (content) marketer.

Create once for the corporate website, rewrite to fit the design of the webshop, shorten, and rephrase to fit the social media imagery, rewrite again to fit the newsletter template. Review and start from scratch for every market, because “we don’t speak like that here”. The reality of almost every marketer.

What’s causing this gap between intention and action? What’s broken and where?

In marketing, as in life: your heart may be in the right place, but you also need some brain to turn dreams into reality.

60 years ago, when the 4Ps of the Marketing Mix were defined, it was much easier to figure out what type of promotional message (content) to deliver in each place (channel). The user journey was easier to predict since the number of touchpoints was limited.

In today’s digital marketing landscape, your main role as a marketer should be to empathize with your audience, understand what they need and what they care about, and then create a message that resonates with their needs while highlighting your brand value.

For everything else involved in the marketing mix, you should be able to rely on your digital marketing infrastructure: CMS, CRM, ERP, MDM / PIM, marketing automation & analytics tools, and so on.

CMS architectures: Monolithic, Headless, and Decoupled

Coupled CMS architecture

If your company is using WordPress, Joomla, Squarespace, or Drupal to manage marketing content, it’s very likely that you’re working with a “coupled”, “traditional” or “monolith” CMS.

Why this name?

Because these CMSs, just like the beautiful monolith in the picture above, are stiff, require a lot of workarounds and nobody knows how they appeared there anyway. Just ask your marketing manager who chose the CMS and when …

Seriously though, a traditional CMS couples the content database, the editorial interface, and the publishing engine into the backend, which is tightly linked to the frontend. So all integrations, layouts, components, and plugins are stored and rely on the same resources as the styling.

While for marketers it may seem easier to work with a system like WP, for developers it’s definitely not the best architecture. Because the BE and FE are so interlinked, development is restricted and deployment cycles can get messy.

Moreover, there’s no way to isolate specific parts of the application or website, and the technology stack is so restrictive that it’s not worth the effort of developing new functionalities. Just add another plugin and you’re good to go.

A coupled CMS can be a solution for a small company, but if you’re growing and looking to scale up, you should definitely start thinking about decoupling your content management system.

Headless CMS architecture

A “headless” CMS solves some of the problems that come with traditional content management systems but still has some limitations.

The frontend or “head” is decoupled from the backend or “body”, so they each serve different purposes. The FE is concerned with how the information is presented to the user, and the BE is concerned with the data/content and the logic.

Because the BE and FE don’t really care about each other, the backend acts as a content repository. The content is stored there and served to the frontend through an API, but only if it’s requested. All good you may say, except that by chopping off the head, you’re turning your CMS into a content-only database.

This agnostic architecture can’t determine how the content should be presented to the end-user and when. It’s a reactive, not a proactive model. The content can be delivered anywhere through APIs, but each channel requires new frontend templates.

How do you scale this up? And how do you make your content more future-proof, when you can’t anticipate what devices you’ll target in the future?

Decoupled CMS architecture with structured content

A “decoupled” CMS also separates the backend and frontend, but in a different way.

The BE takes care of content creation and storage, while the agnostic FE delivers the content to a variety of designs, for different devices and channels. This is done through APIs as well, and the changes made to the presentation and formatting (FE) or to the behavior (BE) layer do not affect the actual content.

So just like a headless CMS, a decoupled one has a database where content and assets are stored, a content management backend for authors to create content, APIs that connect the BE and FE, and then a default content publishing frontend.

Since authors are offered templates and components for launching websites and pages quickly, the time-to-market is reduced. Yet, this isn’t the biggest advantage of a decoupled architecture built upon structured content.

The most beautiful part of this CMS architecture is the ability to assemble content on-demand, per channel, user, or device, in a dynamic manner and based on data and behavior patterns.

Let’s explain a bit more. In a decoupled CMS with structured content, the CMS is headless, but its core is not organized around content pages. The foundation is the content model, which is a framework that defines all the types of content and how they relate to each other.

This model is built by breaking down the different types of content into smaller components, and it can go as granular as needed. For example, a title can be a component, and the call to action can be another component. Since the focus is on the content, the design doesn’t matter at this point.

That means that we’re taking a content-driven approach, instead of a design-driven approach. Instead of starting by creating beautiful templates and populating them with lorem ipsum, we first look at the message that we want to share with our audience.

We model that, define the relationships between content components, and only then we move to page templates. These templates are populated dynamically based on the logic defined in the content model, and using a taxonomy model.

Time for a practical example.

Structured content at work

Let’s say you own a library and on your website, you want to offer users the possibility to preview the content of each book, chapter by chapter. The content model is developed for the full library, but we’ll focus on the book object now.

What information does the user need to receive about a book?

The title, the cover image, the author, the summary, the table of contents, the intro pages of every chapter. Also things like price, publishing date, delivery time, user reviews, similar books, and so on.

So your book object will consist of these components, and depending on the context of the user — device, channel, behavior — more or fewer of the components will be assembled into frontend templates and delivered.

In the mobile view of the website, you may want to skip the chapter previews or to limit them to the chapter intros. In the mobile view of the social media snippet, you may want to only share the image, title, author, price, and delivery date.

Then, in a campaign page promoting the launch of a new book, you may want to also include an event component, so you will need to add to your book object another field for the event name.

And the possibilities don’t end here. By taking this approach and structuring content based on a model, you free content from form and design. By no longer locking it in page templates, you not only avoid duplicate work, but you can actually deliver personalized content to your users, based on their context.

I’ve mentioned also the taxonomy model before. Sticking to this example, your metadata model can include fields like the author name, but also the niche, the topic of the book, the length, the reading time if also available in e-book format, or the listening time in audiobooks.

By implementing a taxonomy model and tagging all pieces of content — objects, components, and templates — with the proper tags, you make it easy to discover, retrieve, and reuse.

So the awesome thing about structured content in a decoupled CMS architecture is that it eliminates the copy-paste work, it creates one master content object for every piece of the model, it makes content easy to find and reuse, and it enables in-context content assembling and omnichannel publishing.

If you need help in migrating from a coupled to a decoupled CMS, get in touch with our team. We'll audit your content, interview the stakeholders to understand your requirements, and recommend a CMS and content model that fit your needs.