How A Headless CMS Could Help Your Team To Be Awesome

OK, so the headless CMS is nothing new. There are many headless CMS providers to choose from. Some examples of providers are Contentful, Prismic, and Kentico Kontent. For the most part, they provide very similar features and price plans. Let's take a look at what the headless CMS is and why you should consider it for your team.

First of all, let's be clear on what we're talking about and what makes a headless CMS.

A traditional CMS combines content and presentation in a single solution. There are benefits to this single solution, but it means that choosing a CMS platform can tie you into the provided technology stack. That's great news if you can guarantee that nothing will ever change and you'll always use the same stack. The trouble is, no-one can say that for sure and no-one has a crystal ball to see what will happen in 3, 5, or 10 years.

A good example of a traditional CMS is Kentico Xperience. Kentico Xperience utilises ASP.NET and Microsoft SQL Server. So choosing Kentico Xperience commits us to that technology stack for the lifetime of the project. If you have any new features, extra channels, or change requests then they will happen in that stack. You will need to make sure that you maintain an active skill set in that stack within in the team to cater to that. For most agencies, this is not going to be a problem. For other types of company, this might be more difficult. These companies may rely on smaller in-house teams or external contractors for support.

Also, a traditional CMS will also focus on the web as the primary - if not only - delivery channel. This was clear with Kentico Xperience's prior portal engine for example. The portal engine allowed you to develop a web application within the browser. This functionality still exists to some degree using the recommended MVC approach. You'll find similar scenarios with some other traditional CMS platforms.

A headless CMS takes a different approach. It combines the content admin component and a method to get information in and out using an API. The focus is on the content and the workflows that support it. The final presentation is completely separate from this content. How you display the content is not the concern of the CMS, only the content itself is.

With this separation of concerns, the headless CMS is becomes stack agnostic. With Kentico Kontent for example, I have two ways which I approach projects:

The JAMStack approach that complements the front-end team more. For me, they are sites that have less frequent content updates. Development is swift and hosting costs can also be lower, as there are fewer resource demands. I should state that Gatsby is an example. I could have said Gridsome, Nuxt, or Next for example.

ASP.NET Core would favour a back-end focused team. These projects have more frequent content changes and need a managed cache life-cycle.

That's not an exhaustive list, the key is that you're not tied to a stack by the platform. You decide how you want to work with it and what technologies you want use. Just take a look at Kentico Kontent's developer page and you can see a selection of example code including React, Angular, Vue.JS, .NET, PHP, Swift, Angular and Java (all of which have a dedicated SDK).

Then, there is the whole idea of pushing your content to many channels. You may have a website, other web-based end-points, or a Google Assistant. We are now starting to talk about 'omnichannel'.

Omnichannel is a key phrase that you hear in the headless CMS arena. It is a content strategy that embraces many delivery channels to reach target audiences. What we mean by this that we shouldn't narrow our focus on developing content for the web. Part of the point here is that your customer can use the content anywhere rather than only on a web site. For a lot of traditional web agencies, the key market is the web. We hear about virtual assistants, AI automation, smart TVs, and of course the IoT fridge. All these are different delivery channels for content. When the content has been well structured you can retrieve the pieces that are relevant to a channel through the API.

An important distinction is that 'omnichannel' and 'multichannel' are not the same things. Multichannel approaches treat each channel as a separate opportunity. Often they are not not connected together and the information in the mobile app is different to the information on the website. Users may need to create different accounts for each platform. Omnichannel aims to provide a single, unified experience. Different views of the same content across all channels. A user account across all channels makes the experience for the users seamless. To get this working well, you need to carefully consider how to model your content. It is no long just about pages, but about content and metadata. You can read more about content modelling in Michael Kinkaid's series of posts called Content Modelling in Kentico Kontent.

When I first looked at headless CMSs, my view was that they were for smaller projects. Those projects that didn't need much functionality. Yes - I knew all about omnichannel, but I wanted to get my teeth stuck in. This was a very simplistic view and not reflective of the tools I was using. A headless CMS can play a key role in an enterprise-grade solution as a centralised content hub. The infrastructure behind the supports this, and once you understand the content modelling a little more, this view becomes more apparent.

While there isn't a hard rule to decide which projects should use a headless CMS. There are a few things that can guide you. What you should consider is:

The answers to these will help to guild you. If you're working on a project that is part of a bigger strategy you will want the flexibility that a headless CMS offers. The sources of data you're using may lend themselves well to linking with a headless CMS. You can decide this with experience. But to be able to decide, you need to be comfortable as a team with what you can deliver.

Along with the technical benefits that a headless CMS, there are several ways that leaning a headless CMS like Kontent can benefit your team.

This first is both a benefit to the team and your business. Your team will be able to field questions about headless CMSs. If the business wants to know if this is a benefit yo them, you'll be able to answer in an informed way. Besides, if the team know their way around then they are also well placed to put together a proof of concept. This will not only help to answer the question but also put your team in a position to take advantage.

Technology is always changing, and developers pride themselves on keeping up. If they're stuck for maintaining older frameworks, they'll become frustrated. In the worst cases, they will leave to find another position that can offer them new challenges. Introducing new technology can help to improve morale and give your team more drive. New technology also provides a training opportunity too. Training can help build enthusiasm in the team, whether instructor-led or self-paced.

Bringing in new technology also promotes thinking out of the box. Your team over time will learn each other's strengths and weaknesses. If the technology stays the same for too long, things start to stagnate and innovation can stall. New tools create new opportunities to build skill sets and to develop new approaches. This does not mean that you need to jump on every new framework that appears, that can cause issues in itself. A small or periodic change can spice things up and get your team thinking in a different way.

My preference in a headless CMS is Kentico Kontent. As a Kentico MVP, that might seem an obvious choice, but I've also tried several other platforms over the years and have found that Kontent provides a good level of flexibility, functionality and innovation.

Kentico is targeting enterprise clients, there is no secret there. It is the focus of a lot of their recent marketing. For Kentico Kontent it makes things a little sticky. The features and the infrastructure support the kind of performance you need at an enterprise level, but to get projects that use a headless CMS, you need to prove that you can do it. Then you might run into the familiar catch-22 situation of not having enough experience to gain experience in the first place.

You can run a Kentico Kontent site for free using the Starter plan and store a reasonable amount of content and assets. As you need more features, content, or bigger team structures then you can upgrade your subscription to the next level. This is the same for other providers too like Contentful and Prismic, though each clearly has their own pricing structure.

As projects get bigger and need bigger teams and more content items, they become more expensive. With Kentico Kontent there is a sizeable jump from free to $1000 a month in the publicised prices list. Smaller businesses are not going to pay that price tag, so the aim is to target bigger business that can see the value of using a headless CMS as a part of a much bigger digital landscape within their business.

So, how can a headless CMS help your team to be awesome? For me, it boils down to two things.

By being aware of how to make us of a headless CMS, your team can be ready. Ready to take advantage of the benefits that headless can offer and ready to think in different ways. With headless and the separation of content and channels, we simplify content.

The stack-agnostics nature of headless allows your team can use their current skills. But it also allows them to start branching out and exploring new stacks. My background is .NET development, but more recently I've been exploring JAMStack. I have done this by using existing content and rebuilding existing applications.

Remember that - for a lot of developers - learning promotes motivation. That learning needs to be relevant and needs to offer a perceived benefit to the developer. It also needs to be relevant to the business, but if you've read this far then we can assume that headless CMS is already!