With headless content management systems gaining more and more traction in the marketplace, old-school systems are now attempting to rebrand themselves as capable of being decoupled. The powerhouse open-source platforms such as WordPress and Drupal are now providing extensions and plugins that allow them to be decoupled from the front-end experience.
Rather than being designed to natively serve as a decoupled system, these platforms are only accomplishing this by being extended with third-party software options.
But why bother with using those platforms to decouple your architecture? It doesn’t really cure anything, but rather confuses things even more.
Why decouple your CMS?
The real reason to decouple is to free yourself, to liberate your company from the negatives related to these platforms. Decoupling a platform that already features an integrated front-end really just means you are hacking the platform to remove half of what it does. And you’re still stuck with the administrative capabilities of the system that may not match your workflow.
Take the WordPress platform as an example. Why decouple this framework, which is still built on the philosophy of posts and pages? How does that translate into a long-term framework to power the distribution of your content to multiple, complex outlets?
Remember, one of the core reasons to decouple isn’t only for front-end flexibility in terms of both functionality and technology, but also to make a decision to run on a particular platform for a long period of time, thus providing stability to your company and website.
Why decoupling doesn’t make sense on a WordPress or Drupal site.
In the case of extending an off-the-shelf platform, you will still be making an investment in a product with an unknown and unpredictable upgrade cycle. You’ll still be liable for any security updates and upgrades necessary over time. And your content will be organized according to the platform, but not according to your requirements and business logic. Does that sound compelling as a solution for your company?
So why are people doing it? For the same reason they are picking these platforms for simpler projects: it is all they know! A WordPress expert won’t embrace a true headless CMS for a project, even if it calls for it, when they can stick with the system they already know with some modifications. But with the advent of hosted CMS solutions and custom CMS solutions, there is no reason to ever consider decoupling monolithic CMS systems, especially for new website projects.
There is one exception to the rule.
If you already have a site and simply need to add a distribution channel. In the case of an existing WordPress or Drupal site, it may be easier for you to simply integrate the API plugins or extensions rather than build your own or start from scratch.
But even in this case, if your company is going to be engaged in advanced content sharing and needing an API, you should consider your long-term plans regarding content distribution. Once you build third-party applications you will be tied to the API provided by the plugin, which if changed means that now you’ll have to amend your applications to be compatible.
Headless CMS architecture only makes sense if you can have tight control over the base CMS framework. If you can’t dictate workflows or establish your own content taxonomy and storage strategy, it may not even be worth doing. If you are going to take a large, bloated piece of software and remove functionality to accomplish a headless architecture, then you owe it to yourself and your company to take a detailed look at the alternatives available to you.
The goal with each headless project we commit to is the creation of a platform that can last, at a minimum, five years. Hacking existing software to perform similarly will reduce, if not eliminate the possibility of a long shelf-life while introducing an entirely different host of problems. As your CTO to hire, we can’t recommend building an ecosystem for your company with so many unknowns in the not-so-distant future.
