We’ve been seeing lots of buzz lately about headless content management systems (CMSes)—which separate creation and management of content (the back-end, foundational tasks) from its delivery to a web page, or an app, or an internet-connected device (the front-end “head”). In other words, they allow you to edit, store, and manage content but leave the design and delivery of that content to a separate application. So your content, rather than being presented to the end user on a web page, is made available to a developer via an API (application programming interface). The developer creates an application with the content delivered to it from the “headless” CMS.
There are several things driving the buzz about “headless.” The Internet of Things, for one, in which lots of connected devices just request pieces of content from a CMS. Also the fact that brands want and need mobile applications that leverage their web content and reach an exponentially growing mobile consumer base.
Sitecore as the original headless CMS
When I first started hearing the buzz about headless CMSes, I didn’t think anything of it. After all, Sitecore originated as a headless CMS. The first two versions of Sitecore were designed with a content management layer separate from the abstract layer, where the abstract layer requested content via an API. Later versions introduced a layout engine as a middle layer that tied content management to the API with layout definitions (e.g., templates that define how the layout is assembled). But that layout engine, which is where site visitors interact, has always been completely abstract of the content. And as we’ve evolved our web services API to use the latest technologies (like O-data), our platform has and always will separate content from the design of that content. This is what we mean when we say the Sitecore Web Experience Manager “decouples content from its presentation” and lets you write once and distribute anywhere.
Sitecore has never marketed itself as “headless,” because, as we have always separated content from presentation, we thought of “headless” as a commodity. No big deal. It wasn’t until recently, when some in the industry incorrectly concluded that our content, layout, and presentation layers were coupled, that we felt the need to clarify our headless approach—which has been in existence well before “headless” was even a term. I’m beginning to realize how unique we are in that aspect. I recently spent some time exploring our competitor's approach to content management, and can see that it’s easy to equate our architectural approach to our competitors, which are most certainly not headless.
Let me explain. Sitecore stores content as small objects, and our layout engine places those objects, or modules, in a web presentation format. Similarly, a mobile app developer can use our API to call those content objects and reuse them in a mobile app. So when a marketer changes your brand’s web content in Sitecore, those changes automatically propagate across any channel on which you’ve called or reused those content objects. With our Experience Editor, you can edit and preview content components (or modules) on a page. You can do the same in AEM and other products. Many CMSes make it appear as though you’re editing content components on the page, but the similarity ends there.
Look under the hood
Many competing CMSes are architected to store their content with the page, e.g., one page might include many different components, but they are stored according to the page upon which they appear. For instance, AEM copies components (using something called Multi-Site Manager) from web pages to mobile pages sharing the same blueprint, and synchronizes them to maintain consistency. The system is not natively reusing the components, because it can’t—they are stored in the page. These are very unforgiving systems under the hood. To the user who’s editing the components, Sitecore and its competitors may behave in very similar ways, but they are architected to store content very differently. Sitecore is and always has been headless.
Which is better—headless or coupled?
So, what do you, as a business or digital marketing leader, need to consider when wading through the buzz about headless? Think about these three points:
Headless is not new; it’s just a “new” buzzword. We have always believed in decoupling presentation from content, but a fully headless CMS introduces significant risk in that it increases the complexity of your solution for both your developers and your marketers. Sure, headless CMSes certainly free developers to choose whatever front-end user interface technology they’d prefer, and that might give you an app with a great user interface. But the down side is that your app’s customer experience will also be decoupled. You won’t be able to personalize that experience, or respond in real time with relevant content, or test and optimize and manage forms and market in context of user interactions. Is a standout user interface worth it if it’s that isolated?
There is no good or bad here—there needs to be a balance. Not every site needs to be built within the constraints of a CMS. But not every site needs to be built headless. That’s why we believe in the hybrid solution and support both approaches—a contextual site generated with the Sitecore layout engine or a headless CMS and app based on the Sitecore REST API (JSON).
What are your thoughts? Are you enamored of headless CMSes? Or do you prefer the coupled approach, or have you chosen a balanced strategy between the two? I’d love to hear your thoughts.
Lars Fløe Nielsen is CDO at Sitecore. Follow him on Twitter @ln_sitecore.