A re-platforming exercise for a company can often seem like a daunting exercise in not only technology delivery but also in operational change management, however, it is often a necessary step to keep up with the rapidly changing world of digital experiences. Your customers are continuing to raise their bar in terms of digital experience expectations. Does your technology stack provide you with the foundations to meet and exceed these expectations?

This article is written for those who are early on in their journey of either a brand new major website project or a re-platforming journey. I will share with you the insights that we have learned over the past decade in building sites that scale effectively and hopefully inspire you to make progressive technology choices that set you up for success tomorrow as well as today.

Starting off with some simple goals

Technical architecture diagrams can often seem very overwhelming initially, but they are easy to comprehend if we understand the goals of the various pieces involved. As we discuss the various platforms and services that might make up your modern technical architecture, keep in mind the following simple goals that underpin our direction in making these choices:

• We are looking to deliver an exceptional user experience for a consumer-facing website/app.
• We would also want there to be a great developer experience for our team who is actually putting this thing together. Developers who enjoy the tech they are working on will undoubtedly be more engaged with the project and motivated to deliver a great outcome.
• We want our technology stack to be composed of the best-of-breed tools and services. We don’t want to lock ourselves into a one-stop shop platform that does one thing really well but leaves us very short in other areas.

How to compose a platform with best-of-breed SaaS solutions

The past decade has seen an unprecedented level of innovation in the overall digital experience that customers are able to receive. The pace of innovation has been driven primarily by advancements in both Technology as well as User Experience. This fast-paced evolution has been quick to identify the flaws in the older generation of traditional CMS platforms, which have struggled to adapt themselves into the new API-centric digital world that we currently live in.

Modern websites are built with flexibility in mind, moving away from traditional all-in-one style platforms in favor of a “choose your own adventure” style composition of the best Software as a Service (Saas) that fits the requirements. Building a modern API-centric platform allows you to easily plug in new capabilities into your technology solutions, rather than being at the mercy of your “core platform” adding a particular feature that you need.

This becomes more of a critical factor when we are dealing with large sites and web applications that go beyond simply displaying some static or dynamic content but are more feature-rich in their nature. These types of projects could have challenges such as:

• Integrations with e-commerce platforms, payment gateways, customer support systems, etc.
• Tightly managed publishing workflows that involve handovers of a piece of content across multiple disciplines and teams
• Management of multiple brands, sites/microsites under one umbrella while minimizing duplication of engineering effort as much as possible
• Rapid deployment of new transient pages or microsites to support marketing campaigns, without having to compete for prioritization of your company’s digital squads
• Requiring a single overview of your digital world when it comes to auditing content and experience across the channels

Unlike a traditional CMS, an enterprise-grade headless CMS can help you address the above points. Among its many advantages, the headless CMS is developer-first in its API-centric approach, as well as being platform-independent, allowing it to be a centralized source of truth for your content regardless of the channel.

Developers love using Headless CMS

Developers are always wanting to use the latest and greatest in technology on their projects, so having a technology stack composed of the best-of-breed tools is a great way to attract and retain engineering talent into your team.

Most headless CMSs are not constrained to learning and using a bespoke DSL; instead, they can use GraphQL or regular REST APIs to do all of their interactions with the content. This approach of employing standard web technologies lends itself well to using modern techniques such as:

• A modern front-end framework (React.js, Vue.js, or Angular.js)
• A serverless architecture such as AWS Lambdas
• Proxying requests into your own middlewares or microservices

The end result of the above is that developers are able to hit the ground running rapidly, easily plugging the headless CMS into their existing modern tools and services. Having an enthusiastic delivery team that is bought into the technology stack is a key part of the successful delivery of modern projects.

Decision frameworks for adding Headless CMS into your technology stack

There are a number of different lenses to consider when selecting your approach to managing content in your organization. Five techniques that we like to consider at Bound to help our clients make progressive and pragmatic decisions about their tech stacks are:

• Digital Maturity vs. Integration Matrix: Using this simple matrix attempts to answer the confronting question: “Are we ready for a headless CMS?”
• Weighted Total Scores: Tallying up a set of weighted scores helps answer the question: “Is a headless CMS the right type of technology for our circumstances?”
• Enterprise Content Management Maturity Curve: I like to use this technique to find out: “Whereabouts are we in terms of our path to this new technology being the strategic solution across the organization?”
• Cost-Benefit Analysis: We use this technique to answer the question: “Do we go with a high-end premium headless CMS or just with something cheap for now?”
• Competitor Analysis: This is one of those techniques that I cannot live without—it has a very simple question that it tries to address: “What is everyone else doing?”

The following section of this article illustrates the general idea of how to use these types of decision frameworks and techniques in the context of the type of CMS that is right for your needs. You can mix and match the techniques you use to get a more comprehensive set of considerations; you can discover that one particular framework really hits the mark when it comes to your project’s unique situation.

The Digital Maturity vs. Integration Mix

This is one of my favorite techniques, as it really aims to simplify the decision and the way that you should be thinking about the decision of going headless for your organization. Sometimes what you really need is a very simple way of thinking about things to help make what could be a complicated decision. The argument of this framework is that when dealing with a project that requires extensive API integrations and is delivered by teams with a high level of maturity in delivering digital projects, the headless CMS is the correct solution. The matrix then attempts to find to what extent that assumption is true and at what point that stance should be reconsidered. It is important to keep in mind that the way this matrix is shaded could vary from company to company, taking into account cultural differences with regard to technology decisions.

This matrix makes the following claims:

• A team that has a high level of maturity in delivering digital projects will prefer to work with a more technically powerful tool that is the headless CMS.
• Web/mobile projects that require a lot of integrations with various third-party services will probably already be taking an API-centric approach to delivery, where a headless CMS plays right into that strategy.
• A headless CMS is not necessarily the right choice for all organizations and projects. For example, simple websites for teams that have a low level of digital sophistication.

Using a Weighted Total Score for your decision

A Weighted Total Score requires answering all of the questions and tallying the totals. Each business can consider its own set of questions and how important each question is by weighting the scoring appropriately. There is also the cultural element of your organization with regard to how progressive or conservative it tends to be with technology decisions. It is possible to calculate a cutoff score that favors a headless CMS over a regular CMS (or vice versa).

The following table can be used as a starting point for your own decision framework:

Question	Yes	No
Does your company already have a digital team well versed in working with a modern front-end framework such as React.js?	10	5
Will your content be used across multiple sites or mobile apps?	10	5
Will your project require integrations into many different internal or third-party API services?	10	5
Will your website/app be a consumer-facing project that needs to deliver an excellent and modern User Experience?	10	5
Does your company have the infrastructure capability to host APIs and modern front-end apps?	10	0
Will you have the available resources for ongoing maintenance of a newly created modern web app and APIs?	10	0

The Enterprise Content Management Maturity Curve

It can often be very useful to map out what the journey will be like for a new technology to become fully integrated within an organization. One exercise that I find useful for this is to map out a Maturity Curve, where various key phases of maturity are labeled along a horizontal timeline. It is important to remember that when a new technology is introduced into a company, you don’t jump immediately into the Frontier level overnight. Having a clear vision of the Frontier level helps to provide that technology vision to align the adoption.

The Maturity Curve below depicts a set of phases that I have witnessed across many of our various enterprise-level clients over the past handful of years as we have rolled out headless CMS integrations. We have been lucky enough to work together with a number of Frontier-level large organizations to get a sense of how a large-scale rollout takes place.

It is almost a necessity to go through the various phases of this maturity curve to prove out a new technology and de-risk a major transformation program.

Cost-Benefit Analysis for comparing a high-end headless CMS to a cheaper solution

The broader CMS market leaves technical and business managers spoiled for choice, ranging from simple open-source DIY solutions to enterprise-grade solutions such as Kontent. It is important to be aware of the trade-offs between the two ends of the spectrum when committing to your platform of choice, especially when the project represents a long-term strategic shift towards Headless and a Content-as-a-Service approach within your organization. We start off a Cost-Benefit Analysis by identifying the relevant benefits and attempting to apply a tangible value figure against each of them. The derived value for each benefit will vary from company to company. As a starting point, let us discuss some of the benefits of using a more high-end headless CMS compared to a lower-budget solution:

1. Easy to configure plugins and integrations with a variety of popular third-party services. If your broader tech stack comprises popular services, this alone can save your project a lot of effort.
2. A sizeable following amongst the development community allows for easy troubleshooting and support. You can join the Slack and Discord channels to stay up to date as the platform evolves. Having the community provide clear answers can make for much smoother project execution.
3. A fully hosted solution with SSO for easy enterprise integration makes for a smooth transition and less friction during adoption. Without this, consider the possible costs associated with the change management, security auditing of company accounts in a new service, and management of accounts as your team members change.
4. A focus on enterprise clients and projects means that security and content governance are of the highest priority. View audit logs of content changes, and control precisely which content types and items certain groups have access to. This also plays into the point of the solution being fully hosted, which means that you don’t need to go through setting up new enterprise environments for it to live in.
5. Battle-tested SDKs that support popular frameworks and languages mean that your team can plug and play, using the SDK to achieve common tasks. This allows your development team to spend less time in any initial Proof of Concept project to easily validate your technical approach. A stable SDK also means that you are less likely to have production incidents due to a developer’s misunderstanding of the platform during integration, as the SDK will take care of that.
6. Uptime and performance SLAs that you would expect from a platform that is powering very high traffic sites and applications. This point can be one of the more prominent ones when comparing lower-budget DIY solutions and self-hosted solutions—are you able to confidently maintain the same level of uptime with round-the-clock DevOps support?

With some of these points in mind, you can start to put together a high-level Cost-Benefit Analysis. When dealing with high traffic consumer-facing sites for large enterprises, it quickly becomes apparent that there is a lot of value to be extracted from a high-end premium headless CMS such as Kontent. This same technique can also be applied to learn: “Do we need an off-the-shelf headless CMS, can’t we just build something like this ourselves?” However, for that question, we have another technique that we prefer to use, which is explained in the next section.

Conduct a Competitor Analysis to understand what other noteworthy websites are doing

Conducting a Competitor Analysis is one of those go-to techniques in the arsenal of any curious professional—we simply love to take a sneak peek at what other great sites are doing, with the very simple philosophy stating that “if it works for them, then it will probably work for me as well.” Here are some considerations to keep in mind when conducting a competitor analysis for a CMS:

• Have they managed to achieve a level of User Experience that I would be happy with for my project?
• Would this site get the level of traffic that I would be expecting for my site?
• What is the organizational complexity of this company? Is their world more simple or more challenging than mine?
• What is the performance like on their site? If I do some simple performance benchmarking for load times, would I be happy with the same results?

When conducting a Competitor Analysis we like to provide an overall score out of 10 for each of the sites that I am reviewing. The sites can then be grouped together into buckets, for example, by which CMS is powering their experience. It can be useful to see if there is a trend emerging for what CMS platform powers the sites that you have given the highest scores.

Summary

Remember that your selection of a CMS platform is often a long-term decision, not only for your current project but potentially for many future projects to come. It is important to make these decisions with a progressive mindset, optimizing for the maximum possible User Experience not just for today, but also for tomorrow. The digital world is a very competitive landscape in today’s world—and, in many ways, your CMS is the backbone of the entire digital experience for your customers.

If you need more help deciding on a CMS, do have a read of this great article on How to choose a headless CMS.

If you have already made the exciting decision to use a headless CMS for your business, be sure to check out my articles on Effective content modeling, where I explain the processes that we go through at Bound to model out powerful and intuitive content models for our clients.