Parsing the Headless CMS Market: Agile Experience Platforms, Headless Apps and Traditional WEM
A CMS is not a CMS is not a CMS. Confused? Probably no more confused than trying to understand the difference between types of headless content management systems.
Be confused no more! Our goal in this blog is to give you a look into the types of headless options out there, so you can make the best decision possible when it comes time to select your headless CMS.
Let's start with an overall definition of headless.
"A Headless CMS is a back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device. The term ‘headless’ comes from the concept of chopping the ‘head’ (the front end, i.e., the website) off the ‘body’ (the back end, i.e., the content repository). “ - Wikipedia
Now that we understand what “headless” means, let’s look at several types of CMS solutions and how headless fits into their model.
Traditional WEM and Decoupled CMS
Traditional web experience management systems generally provide both the front-end delivery tier and the back-end content management model. In most instances, these tiers are tightly integrated and you often are required to place your CMS backend on the same web server as your website (which is not a good thing because you are exposing your CMS to potential hacking).
Recently, some traditional WEM vendors have added headless capabilities in their platform, but the functionality is rarely true headless and comes with a lot of overhead from the delivery tier.
Other CMS applications use a decoupled architecture. Decoupled separates content management from content delivery and presentation. This decoupled architecture is a key requirement for headless, but they are not the same thing. It’s similar in that in both cases the delivery tier is separate from the management tier. But with a decoupled solution, content that is managed in the CMS is pushed to the delivery tier. This push model could be a resource file replicated to a publishing target, or it could be pushed to the target using an API; in either case, it is the CMS that pushes the content out when it’s created or updated.
When you are looking at a CMS that refers to itself as a web experience management solution, ask the vendor how they deliver content to websites and applications outside the CMS environment. If they say they also offer headless capabilities ask them to show you the architecture and what’s involved, along with an example of how it works. It’s more than likely that you’ll discover it’s not headless at all.
There are a few content management systems that provide a pure “headless” offering. With these content management systems, there is no delivery tier at all. All they provide is the back-end content management and an API that will deliver content when calling applications request it.
Pure headless solutions cropped up a few years ago when website development shifted to highly customized solutions that leveraged modern frameworks such as Angular JS and Redact and developers wanted a simple way to create and manage content outside the website or application. In some cases, headless CMS are lightweight CMS solutions offering a fraction of the management functionality traditional solutions provide.
When you are looking at a pure headless CMS solution, it’s assumed you will always create custom websites or applications. Ask the CMS vendor what content management capabilities it offers and make sure that aligns with your expectations.
Keep in mind that a headless CMS requires a lot more work from your development team and it provides no capabilities for marketers or non-technical users to manage the front-end experience.
Agile Experience Platforms
A few CMS vendors are providing that we’ll call the “best of both worlds” option. These vendors provide several approaches for content management and delivery, including tightly coupled, decoupled and headless. We call these agile experience platforms.
Most organizations need a CMS that can provide multiple types of content delivery. They may have a marketing website, microsites or landing pages that marketing needs to control and update regularly without developer assistance. They also have mobile applications and website applications that are built on different technology frameworks or are highly customized, but they want a way to manage content consistently across them all.
Providing customers with a consistent experience across channels is critical. If the content you provide in one channel doesn’t match the content provided in another channel, or worse is completely contradictory, your customers won’t know what is correct, and they won’t trust you. A CMS that can deliver the same content in different ways to multiple channels ensures that consistent experience.
If your digital experience strategy includes multiple ways to deliver the content your customers need to make decisions, outline them all and how you see the content delivered. Then talk to CMS vendors and give them the scenarios you identified. Ask them how their solution delivers content for each scenario.
An agile experience platform supports both marketers and non-technical users as well as developers building custom solutions. They give you the flexibility to choose how you want to create and manage content and where you will publish it.
Which CMS is Right for You?
You could purchase multiple content management systems to provide all the different capabilities you need. Along with the cost associated with purchasing multiple solutions, you’ll also have to deal with training users on multiple solutions and trying to figure out a way to ensure content that you use across CMS solutions is synchronized. There’s a lot more work and cost in this scenario than there needs to be.
However, if you are only dealing with highly customized websites, or with a marketing website, then a traditional WEM or a headless CMS could work fine.
In all likelihood though, the best choice will inevitably be to go with an agile solution; one that allows you the flexibility to deliver content where you want, when you want.
One important take away is that it’s critical to spend the time necessary to understand your requirements for a CMS. Outline the usage scenarios, even at a high level. Document who will use the CMS to manage the content and if they also need to have control over how that content looks on the publishing channel. Understand what content you need to share across the different delivery channel and who is responsible for it. What is their level of technical proficiency? Do you have internal developers dedicated to working with non-technical users?
When you know what you need, start talking to CMS vendors to see how they can best meet your needs.
View original content: Here