As a decision maker, what do you need to know to plan the setup, organisation and take-up of a new headless CMS system? Our guide by senior technical lead Emily Feinson gives you a clear overview.
When building a new customer-facing website, many organisations use a content management system (CMS) to separate content concerns (owned by an editorial team) from functional concerns (owned by a development team). Traditionally, CMSs have contained both the content and its presentation, so that editors can see, edit and publish their changes in context.
However, the use of a ‘headless’ CMS – which consists of the admin user interface (UI) only, with content delivered via APIs – is becoming more popular as it allows flexibility of UI, multi-channel publishing and scalability. Separating the responsibilities in this way has the advantage of giving different teams ownership over their respective parts but introduces new boundaries of responsibility that need to be managed.
The importance of the operating model
An effective operating model (that is, ways of working and management processes) can make the difference between a team battling to get releases out once a month, and seamlessly releasing multiple changes a week.
The operating model for a headless CMS build should cover responsibilities of teams and individuals, the different types of changes that are supported and the processes for each. It is important that testing, verification and signoffs are of high value with minimal overhead to:
- Reduce the risk of ‘exceptional cases’ needing to bypass the processes, and
- Minimise friction to live – the longer this takes the more risk there is of changes conflicting and other issues being introduced.
There are multiple factors to consider, but we will discuss three main elements: the technical setup of the CMS, content workflows, and the organisational context.
1. Technical setup
There are two main ways of integrating with a headless CMS:
- Content can be fetched dynamically at run-time – this means that the site will immediately reflect published content.
- Content can be statically “baked” into the build when creating the frontend assets – this needs a new build and release.
Fetching content dynamically is a great way of giving content editors freedom to make content live extremely rapidly, but has a couple of trade-offs to consider:
- This type of build will require more emphasis on in-CMS reviewing and preview functionality (seeing the updated content in-situ before it goes live). When choosing a CMS, it is important to consider support for previewing, which may be tech stack dependent.
- How to handle situations where both code and content need to be updated at the same time. In a run-time model, this will be tricky. One way to deal with this would be to enforce that changes are backwards compatible, so that the code can always be released first (or vice versa).
On the other hand, build-time integration will be more closely aligned to a traditional build and release approach, with releases being deployed and tested outside of the CMS before going live. This can make it harder to facilitate real-time previewing to support the content team, but simultaneous code and content changes come out of the box. As each content change requires a new build and deployment, it is worth investigating the use of webhooks from your CMS to trigger deployments into the relevant environment whenever content is published.
2. Content publish workflows
You need to consider the workflows the content team use to manage their changes, including publish controls and auditing.
An appropriate peer review process should be defined, as well as guidance for how other CMS features (such as scheduled publishing) will be used. Define the different roles and permissions within the CMS and use those to implement approval processes and/or publish controls. When selecting a CMS, is it crucial to take into account any must-haves. Some CMSs come with no workflow features at all, while others have fully customisable workflows, and there are plenty more that exist between those extremes.
It is also important to define what testing needs to be done at each stage and where that responsibility lies, to avoid defects falling through the gaps. Content editors should have their own process to test changes themselves, but in complex or highly regulated environments an additional review by another team may be required to prevent publishing incorrect information.
3. Organisational context
Organisations and teams work differently on projects, so working alongside existing processes is intrinsic to designing the operating model that will work for everyone.
Effectiveness in up-take of the headless CMS situation will only be effective with buy-in from the different parties involved. For example, the security team will need to be assured that security concerns are being considered, while change management teams will want assurances for a defined level of control and auditing.
Particular care must be taken when the operational context demands that concurrent changes must be made, especially when these come from different teams. This is because it introduces risk of information accidentally being published prematurely.
To some extent this will need to be a manual process – if content is diverging then that needs to be managed by the team – but there may be CMS features that can help with this. For example, there may be a comparison tool to see changes between different versions of the content or even a ‘branching’ feature, which allows different versions to exist alongside each other.
Getting inspiration and support
Headless CMS builds are ever increasing in popularity, and for good reason. However, the needs of a particular product, team and organisation must be considered in order to design a way of working that:
- Unlocks the potential flexibility and agility that can be achieved through using a CMS, and
- Prevents introducing operating headaches that arise from distributed responsibility of moving changes through the system.
If you’re thinking about changing your system architecture, it can be helpful to have a chat with our team. Businesses of all shapes and sizes trust us to successfully deliver their mission-critical software. Try us.
