Your association has a lot of content, and it has to go into an increasing number of places. Does it make sense that all that content is being managed through a number of different interfaces?

For example, your mobile app might require a different interface than your blog posts, and your social media content—despite borrowing from each of those items—requires a third interface.

All of this gets very confusing, and it’s led to a lot of rethinking of content management over the years. For example, one thing that has gained buzz among programmers is something called a flat-file content management system (CMS), which eschewed the need for a database entirely. This kind of CMS usually appeared in the form of a static site generator, which removed much of the complexity in favor of an interface that removed the back end entirely—once you’re done with an article, you put a file into a folder and boom, you’re done.

That exact solution, most commonly used with the Jekyll platform favored by the code-sharing website GitHub, hasn’t really gone mainstream—the average user wouldn’t know where to start with Jekyll or similar tools, like Hugo or Metalsmith. But while static site generators probably haven’t won over a lot of associations (let me know if your org uses one), this approach has proved inspirational to something that associations might find particularly useful: the “headless” CMS.

Losing Your Head

What’s a headless CMS? Simply, it’s an interface that manages the content but is not tied to a single website. What does that mean? I’ll explain it in the terms of this particular site, which runs on WordPress, a content management system with a “head”: The front-end interface, which is what you’re currently using, is tied to a back-end system that defines how the site is organized and managed, how posts are published, who has access, and all that.

A headless CMS is a cloud-based back-end system that isn’t attached to a front end. It can be used to manage multiple types of content, including things that would go onto a WordPress site, a Drupal site, an app, or any other platform with an application programming interface (API). In fact, you don’t need to have an existing CMS—it can work without one, but if you have existing infrastructure, you can make it compatible.

The ability to manage multiple kinds of content from a single interface, as well as the ability to put a friendly face on the complicated process of content management (particularly with relatively new formats like apps), are the places where folks in the enterprise see the big benefit.

“While the concept is far from new, the interest reflects a growing recognition that managing content for multiple channels is hard to do well while also managing those disparate channels,” Dominion Consulting Director Laurence Hart recently wrote for CMS Wire.

It also helps that, since these offerings fall under the Software as a Service (SaaS) classification, they tend to be very polished. You could see your employees using something like Contentful or Prismic without going nuts.

(Also of note is the similar “decoupled” CMS concept, which also separates the content management from the front end, but relies on a layer of onsite management that a headless CMS format does not.)

Why Would Someone Want This?

This may sound a bit weird, or abstract, but the best way to think about it is this: We are no longer in a world where our content lives in just one place. It needs to live in six places. And the process of building content with six different processes and six different content management systems can get awful frustrating.

Additionally, the standard interface that comes with a platform like WordPress or Drupal may not be a good fit for every use case. For some sites, WordPress is a better fit; for others, a static site generator like Jekyll is the best option because a full CMS is overkill.

CMS Wire contributor Petr Palas, the head of Kentico Software (a firm that makes a headless CMS), says that this is where a headless CMS often works best.

“The headless approach, however, breaks down that barrier. It decouples the content and the presentation,” he wrote back in January. “Now the content can be stored in a centralized cloud-based repository and provided as a service to any application on any platform through an API.”

And there are times you want a platform that works specifically well for a certain use case. There are workflow advantages that may show themselves in a purpose-built approach of this nature. (An example of this is Camayak, a headless CMS and alternative WordPress interface built specifically for newsrooms that’s become particularly popular with college papers.)

There are performance considerations as well: When a database on a CMS gets large or very complicated, it can affect site performance. Separating back-end functionality from the front end makes it possible to optimize performance for each.

Of course, that’s the carrot. The stick is the same one that comes with every SaaS cloud app provider: You’re paying another vendor to handle this separation for you—another group of hands to rely on in case something goes wrong.

But, on the other hand, it could prove a boon to associations that have one of two problems: First, those that produce a lot of content; second, those that have content that has to show up in a lot of places.

We’re in a complicated universe, and we’re deploying messages in ways far beyond what we were even five years ago.

Shouldn’t your content management strategy reflect this reality?

The idea isn't as weird as this image. Promise. (iStock/Thinkstock)