by Hoang Nguyen
So let’s tackle this head-on.
Once upon a time, when things were much simpler, Sir Tim Berners-Lee invented the brilliant world wide web, and then this handy thing called HTML. Believe it or not, 2019 marks the 30-year anniversary since this happened.
When you ask your web browser for a website, the browser actually loads a HTML-thingy which contains both the content of the page and the instructions for your browser on how to render it. Back then, an article existed as an HTML file somewhere in the web servers’ directory at any given time. If you want a trip to the past today, visit this website: www.007museum.com. This ode to late-‘90s design is still very much active in 2019. It literally belongs in a museum.
In the years that followed, the amount of content on the web, i.e. text, images and funny cat video clips grew exponentially, and with it came the need for a better way to manage them. Managing thousands of HTML and other media files is not fun, and I can’t even imagine how many grey hairs a developer would get if they were asked to simply update the navigation.
The humble CMS (Content Management System) was a godsend. It gave you a handy backend - allowing content editors to easily log in and upload blog posts, pages, articles, images, and videos to their heart’s content. There was no longer the need to manage HTML files one by one. The developers build the page templates (or themes) and the CMS mashes the content and the templates together on the fly to generate the HTML for you.
The CMS scene exploded from that point. It went from simple blogging systems such as Wordpress (which is still today’s most popular CMS) to enterprise-level platforms such as Adobe Experience Manager (AEM), Sitecore and Episerver. All of these give you the ability to author highly personalised content and integrate with CRM and ERP, as well as collect valuable analytics data that provide insights into your customer journeys.
But it’s not without its problems. For example, new zero-day security vulnerabilities within Wordpress are now found every other day. And in terms of IT, not being able to schedule new features that you need to get out for that campaign in time for deployment is also an issue.
As well, most of today’s CMS’s typically combine your content with the presentation format of that content. Any CMS editor is probably familiar with What-You-See-Is-What-You-Get (WYSIWYG) format - the title of an article is not just simply the title; it’s rendered in Bold, with font-size 40pt, in navy blue, located 40 pixels above the actual article copy. WYSIWYG authoring is one of the big successes of the web CMS products, but as the number and variety of touchpoints expand, this direct link is lost, which makes it hard to use that article elsewhere.
In an ideal world today, we would have the simplicity of the 1990s, the authoring flexibility of the 2000s, and the power of integrations and personalisation of the 2010s.
This is why “Headless” architecture was born. The term “headless” means chopping off the head (the presentation) off the body (the CMS – the content repository).
In that sense, the content in a Headless CMS is pure content. An article is simply a structure that has a title, body, and images, minus any clutter of markup, metadata, analytics tagging, and so on. This allows a business to construct a single journey with a single message to their customers at all stages via multiple channels.
But you might be thinking: ‘multi-channel publishing is nothing new, and most traditional CMS’s have allowed for this. With a responsive front-end template, wouldn’t your content be already available on desktop, tablet, and mobile?’
The answer is that the responsive front-end is still in a web environment. For example, your smart speaker will not be able to open a URL and read the HTML natively. Your front-end is probably not able to be rendered under the tiny screen of your users’ smartwatches. The channel needs the ability to query the content via API, and “render” them natively.
Today, purely headless CMS such as Contentful exist; and all enterprise CMS such as AEM, Sitecore and Episerver have retrospectively introduced headless capability into their offering to become a hybrid CMS. With the neck-breaking pace of technology advancement, all of those systems give you a content-as-a-service API layer, which will future-proof your platform from emerging channels.
While the headless concept is thriving in the CMS scene, it also finds its home in the eCommerce world. No longer will the users be limited to shopping on web-only. Headless eCommerce systems such as Magento and Shopify still allow the shop administrators to use their backend for what they are really good at: product management, integrations with payment gateways and fulfilment/accounting systems in the backend. As well, they provide APIs that allow brands to create highly personalised shoppable moments across multiple channels.
The best thing about using a headless CMS is the positive lift in the technology culture it brings to your team. As your tech stack becomes infinitely more scalable, manageable and dynamic, your developers love how modern and liberating it is over maintaining legacy monolithic codebases. Your IT team loves how easy the microservice stacks are to deploy, along with the limited attacking surfaces due to the decoupled backend. And your marketers and content writers regain their focus on the substance of their content, and less about how things should look in a given context.
Headless does sound like a no-brainer then, doesn’t it?