Headless CMS is all the rage. Analysts predict significant market growth in the headless technology space in 2020. So no wonder, everybody jumps on the headless train. Even the clunkiest and dustiest CMS now claims to offer a headless or hybrid solution. FOMO is real.

Gartner Research, in their latest Magic Quadrant for Web Content Management, calls out as one of three market trends: “Hybrid is the new headless: Although “headless content management” has become something of a buzzword, global organizations are increasingly seeking systems that are not only purely headless but that can also provide head-on and head-optional capabilities from the same platform.”

I beg to differ. “Hybrid”, very often, is a charade put on by traditional vendors to camouflage their shortcomings as a modern content management system. Having been a part of this industry for more than twenty years, I cannot shake off this “here we go again feeling.” (Remembering a decade ago when everybody thought they could leverage the rise of SaaS by launching some cloud offering.)

A modern CMS is more than just a headless CMS; it combines the strengths of API-first, microservices architecture, cloud-first, and subscription model.

Here are seven ways to help you differentiate a headless CMS from an impostor and ensure you buy into a modern content management system that is ready for the future of digital experiences:

1. A Modern CMS Offers More than a Content REST API

Most content management systems, both native headless CMS or traditional monolithic CMS, include some form of REST API, allowing you to get content out of a repository in a flavour of Content as a Service (CaaS).

Much like one swallow doesn’t make a summer, that single API doesn’t make a modern CMS. Look for APIs to cover all aspects of the CMS, including the content, management, and delivery functionality.

If a CMS does not feature several dedicated APIs that give your developers programmatic access across content and management, big red flag.

2. A Modern CMS Supports any Front End

You should find a number of Software Development Kits (SDKs) catering to the different front-end frameworks and Front-end as a Service provider — like AngularJS, React, GraphQL, and Gatsby. Expect SDKs for native mobile apps like iOS and Android as well as traditional application programming languages like JAVA and .NET.

If a CMS vendor doesn’t have multiple front end and mobile app SDKs, big red flag.

3. A Modern CMS Is API-first, Not API-added

Another critical question to ask is if the APIs were there first, or were they patched onto a traditional model advocating pages, components, and templates. An API-first CMS is a synonym for headless precisely because the APIs were there first. It is an essential distinguishing factor because it allows you to draw conclusions about how exhaustive these APIs are and how well they perform.

If a CMS comes from a closed, monolithic background, big red flag.

4. A Modern CMS Is a Cloud-First CMS

The label “headless CMS” is a bad one for many reasons. Not just because it implies that a crucial bit is missing to it, but also because it reduces the segment to the API-first architecture principle. I am trying to advocate topless CMS for a while, but it just doesn’t want to stick.

What makes a headless CMS a modern CMS is that it is also a cloud-first CMS and follows a Software as a Service (SaaS) business model. This differentiation is not semantics: Traditional, monolithic vendors may tell you that “headless” is synonymous with “decoupled.” It is not. “Decoupled” has been around since the 1990s, decoupled can sit in your server room in the basement. Chances are you don’t have one anymore, but we did in the 90s.

If a vendor insists that headless is nothing more than decoupled, big red flag.

Alternatively, ask where your front-end is hosted. If your front-end has to run with the vendor, another red flag.

5. A Modern CMS Is a SaaS CMS

Most traditional vendors run cloud offerings; some are even usage-based priced like SaaS software. Often, these are not run in a SaaS technology model, however, but managed services in disguise. Why would you care? Because that means you still have to cope with versions and upgrades. Ultimately, you cannot benefit from the rapid development pace that a modern SaaS CMS would bring to the table.

Your safest bet to see if the vendor is camouflaging a traditional CMS as a SaaS CMS is to ask how much upgrade effort to expect with new versions.

If a CMS has a notion of upgrading between versions, big red flag.

6. A Modern CMS Is Channel Agnostic

Any CMS can serve multiple channels. The devil is in the details. Traditional CMS typically have the concept of publications or channels. That means you need to create a separate set of content variations per channel.

A headless CMS serves these channels from one, single content source — the variations happen on the fly. That tremendously reduces the overhead for your business teams in serving these channels and one of the main business drivers for the rise of headless CMS.

If a vendor tells you that you need to put resources on dedicated channel experiences, big red flag.

An example of this is the notion of a “dedicated mobile experience” to serve mobile web and apps. Vendors advocating the use of frameworks like Cordova are most likely camouflaging the lack of native mobile app SDKs.

Why is that so important? Frameworks like Cordova get you about 80% to a native app experience. It’s a “meh” experience — and by definition a disappointment to your audience. Differentiation happens in the last 20% of the experience delivery.

If anybody tries to talk you into 80% mobile app experience being good enough, big red flag.

7. A Modern CMS Is Agile. As in Fast.

The hardest imposter move to spot, because every CMS claims that they can deliver implementations in record-breaking time. Because every vendor has some case study of a massive brand name deploying something in under six weeks.

How do you uncloak this move? You have to try for yourself. Here is my advice: Run a proof of concept. Before you commit to a partnership with a vendor for something as crucial as your new digital experience architecture, make sure you take that CMS for a spin.

Ask for a test account with the vendor and team up with your developers or a system implementer you trust. Invest in this if you have to — it pays off in the long run. Spend a week and try out concrete use cases that matter to you.

There is absolutely no reason why you should believe the sales pitch and demo alone before committing.

If a vendor isn’t willing to support you in a trial, big, big red flag.

Bonus: Imposters Spread Headless CMS FUD

The surest way to decloak an imposter is when they start spreading fear, uncertainty, and doubt (FUD). It’s bad form but effective. Often, you will find fear-mongering along the lines of “A headless CMS is great, but it has serious limitations… ‘ … Something scary about headless …‘… the only way forward is hybrid, let me tell you about that…”.

Fear is not a good advisor for architecting your future digital experience success.

I am not saying a headless CMS is for every brand, every organization, everyone — or not yet at least. However, when you choose to leverage the power of a modern CMS, be sure not to buy into an imposter.

View original content here

Related News:

• Everybody’s Arguing about Headless. Here’s What We Know
• Podcast: Taking a Critical Stance on Headless CMS
• Taking a Critical Stance on Headless CMS