Decoupled is Not the Same as Headless

Recently, one of our marketing folks sent me a link to a video she thought was worth watching because of the way an abstruse topic was explained, more than for the content itself. A presenter at DrupalCon had incorporated some pop culture references into his session to make more engaging. While I agreed he had succeeded, in the end I was more focused on the incorrect usage of a word that we commonly use to describe the architecture of our Digital Experience Management platform.

Decoupled. A term that has been hijacked. I’m not sure why but it has certainly been confusing the market.

Decoupled systems are web content management systems (CMS) that won't dictate (or interfere with) your delivery environment. It’s an architectural approach that has been around for many years - decades even.  Companies like SDL Tridion, Interwoven and RedDot were allowing companies to build web experiences and deploy them to any (or many) technology platforms of choice decades ago.

This has been, and continues to be, a vital concern for large, long-established organizations like those in the financial services sector, who have a wide variety of platforms they have to support because they don't have the luxury of resources or time that permits them to just throw them in the trash and rebuild.

That is not how some current vendors are using the term, and I think they're doing a disservice to the market in the process.

When these organizations use the term “decoupled”, they are using it as a synonym for the more colloquial "headless."  The point being that a "headless" CMS provides its content as just data, which means developers and digital agencies are then free to choose whatever fancy new technology they want to use in building the user experience.  This sounds great to them, and they love the freedom.

However, large enterprises are not so thrilled with this mischaracterization, nor should they be when it has these implications.  The only thing I know for sure happens when you make something headless is that it becomes brain dead.  Perhaps that's a bit extreme but I think the analogy is more appropriate than you might at first think.

The problem with headless systems is that all of that freedom you give to the development community and agency world inevitably requires you to sacrifice controls that are really important.  How do you ensure brand consistency across multiple projects when each one is a different stack and a different codebase?  How do you oversee your regulatory program and make sure that the presentation layer meets legal requirements?  How do make sure that your pages are structured properly, and include the necessary metadata, to optimize your SEO program?

Headless approaches may be good for small, one-off, departmental projects but they are the wrong choice for large, distributed, regulated organizations, at least in my opinion.

That's why Crownpeak continues to support and promote the original idea behind decoupled systems.  Organizations large and small should be free to choose the technology of their delivery platform, but that should not mean they have to throw out everything else that is good about full-featured CMS platforms.  Being able to manage the presentation layer, as much as the content it delivers, is even more important today than it was 20 years ago.  Just ask any compliance officer.

Just because an idea is older doesn't mean it's now obsolete.  The model-view-controller pattern which forms the cornerstone of modern architectural thinking emerged in the 1970's.  Wheels and fire are also still quite popular, I hear.

Crownpeak is the modern incarnation of those great foundational ideas in CMS architecture, and continues to provide enterprise architects with the freedom to choose the right delivery technology for the job.  If you want to produce structured JSON or XML content from Crownpeak, or any other template-based CMS, go right ahead.  However, it's reassuring to know that you don't have to give up all the other great features in the process.