Moving to a headless CMS: a recipe for success

The tide of technology investments has taken a turn towards MACH architectures. Despite this shift, content is a domain where adoption often lags behind, or is hampered by fear of failure. This is often because organisations don’t know how to exploit the benefits that a headless CMS can bring. Luckily, there’s a recipe for success.

If your organisation has been taking strides towards a microservice-based architecture, the chances are you’re part of an ever-growing club with clear digital ambitions. And, you’d be in good company. The MACH Global Research published earlier this year shows that IT decision makers who have shifted their strategy to software developed according to MACH principles (microservice-based, API first, cloud native and headless) have high expectations in terms of the benefits they can reap. They expect this new breed of software to make them more agile, flexible and responsive, especially in a difficult economic climate.

Moreover, from a user experience perspective, MACH solutions are gaining traction not just for their developer-friendly API access but also for their enhanced graphical user interfaces. These improvements in usability have expanded their appeal beyond engineering circles.

A new mindset in an old business paradigm

Despite the opportunities offered, resistance to widespread enterprise adoption of headless content solutions still exists. On paper, technology and digital executives agree that well-structured content, the foundational element needed to power an effective content API, is a good thing: they’re aware that it’s one of the foundations for highly desirable features like omnichannel and personalisation. 

However, when it comes to making the leap towards implementation, they find it hard to gain alignment across functions that have been using traditional CMSs for many years. This means they only manage to adopt headless for a limited number of use cases. For example, they may choose a headless CMS to support the development of an app, but decide to not consolidate their wider content estate into one system. This is because they believe paying for an extra (less expensive) CMS is preferable to winning over the internal resistance to move all users to the newer technology. 

This resistance is often borne out of concerns with skills and the shift in mindset required to use it. Internal users feel structured content is harder to model, harder to manage and harder to design with, and this leads to concerns that they will lose speed and agency in the swap.

And while there is an element of truth to this perception, the changes required to solve these issues are not as dramatic as most people think. Adopting a headless CMS just requires a bit of rethinking of internal capabilities.

Who’s afraid of headless CMS? 

Let’s take a fictional company called Big Company X. They’re established in their industry and have digital ambitions that include offering an omnichannel experience. In order to do that, they’re thinking of centralising their content in a brand new headless CMS, so they can simplify the way they serve content across different endpoints and locales.

Different teams and functions are currently creating content for different purposes across Big Company X. Some of these functions and teams are resistant to change. They rely on the old CMS to allow them to publish content using a number of components and templates without having to rely on developers. They expect both autonomy, and a set of functionalities that either matches or surpasses the current CMS. 

Then there’s a more recent internal division, tasked with building a new set of digital tools and services that will be central to the omnichannel experience: their teams might be wary of a CMS because they’re relying heavily on prototyping to define interfaces, interactions and content. They use tools like Figma to hand over content to developers, and while this is proving challenging from a content management perspective, they’re not aware there could be safer and more effective alternatives. 

Finally, like many big enterprises, they have pockets of data and content created in operational teams and hosted in other systems: CRM, ERP, PIM, support scripts, right down to spreadsheets. 

Allowing all these teams to have the same type of access to the CMS wouldn’t be ideal.   In all likelihood, it would result in competing and conflicting demands, with no clear way of making decisions because no one is ultimately accountable for business rules around content storage and management, an all too common scenario with consequences cleverly described by Gaby Turner in her post on content architecture. However, does this mean that Big Company X needs a central team for all things content? Although some people argue that content should be a central function, that doesn’t mean that everything content should be the responsibility of one team. Content architecture should be, but content production should be devolved. How so? This is where the concept of team topologies can help.

Lessons from team topologies

There’s an ever growing awareness of the sociotechnical link between systems and people using them. Ruth Malan, an expert in systems architecture and design, brilliantly summarised the cost of not considering this link: “if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.” 

Team topologies, in a nutshell, is a framework used in agile organisational design to define teams and their interactions to align system and org architectures, to ensure “fast flow”. The flow represents the creation of value, for customers and users, internal and external. The goal is to avoid building or buying software that’s too big to handle and teams that are either disengaged, or pulled in all directions.

To avoid this, each service should be fully owned by a team with sufficient knowledge and capacity to build it and run it. Dependencies with other teams should be made explicit by three main types of interaction: collaboration, enablement, and provision of a service. With this approach you can assign the mastery of a technology domain to one team, and spare the rest of them the time and effort required to overcome the associated learning curve, leaving other teams free to create other types of value.

This approach to team organisation can be easily applied to the content domain. The most famous application of team topologies, DevOps, has even inspired the modern approach to content publishing and management: ContentOps.

Step 0: Establish a culture of visibility and continuous improvement

Properly written recipes start with describing what and how to prep in advance, and this piece of advice aspires to be in that category. In this case, the preparation required involves a general direction of travel for the whole company: to make the most of composable technology, your organisation needs to already have a degree of business agility, or a strong focus and incentive to evolve in that direction backed by senior leadership.

Consolidating a large content estate into a headless CMS isn’t any different, and it will require the willingness to work on incremental value. So, avoid starting with extensive design and migration plans. Instead, plan to start small, learn and share your approach and priorities with the rest of the organisation. This strategy not only fosters trust, but it also ensures a smoother transition for all departments that will eventually migrate to headless. By the same token, avoid creating dependencies with software licences that are about to expire: transformation and looming hard deadlines are rarely a successful combination.

Step 1: Separate the domains of concern in content publishing

We mentioned earlier that some technology domains require a steep learning curve. In content management the most challenging aspects to grasp are content architecture and content modelling. There are three primary components: structure, semantics and workflows. You can find more details in Gaby’s blogpost, but in short:

• Structures define the density and the granularity of the data models and schemas (content models) in the headless CMS.

• Semantics play a double role, with the definition of the entities, attributes and relationships captured in the content models, but also defining what we call “glue metadata”, that is vocabularies, taxonomies, ontologies or linked data that will allow interoperability between the CMS and other systems.

• Workflows combine the decisions on which actions are allowed for each content type (down to the single attribute) and which type of users can perform that action.

Once the content architecture is implemented in the CMS of choice, it’s easy for other users who are only skilled in “content production” to create single instances of content using content models defined by the central team. 

Step 2: Turn content architecture into a central function

With this in mind, you can reorganise and consolidate CMS and data skills that you had scattered throughout the organisation into one team for maximum impact. They’ll be responsible for your content architecture, and the organisation’s content management goals: ensuring that content is presented in a certain way, is correctly retrieved, is modular and/or reusable, and works within interoperable systems.

Abstracting the creation and management of the content structure from the production of content will allow you to:

• Keep the specialist skills you need for content architecture (including content modelling, taxonomy management and development) in one team, rather than dispersing them across the org, while still allowing peripheral teams to create and manage content independently;

• Keep your skilled content modelling practitioners free to explore more difficult use cases;

• Ensure there’s governance in place to maintain a consistent architecture, with clear and documented architectural design decisions;

• Have a single team discovering and maintaining canonical sources of data or content, or connecting to them if they’re hosted in other systems; 

• Hold and enforce standards and policies around content, if there are no other internal functions that are accountable for them (like brand or digital).

Step 3: Fill the content management skills gap 

One of the biggest changes introduced by MACH technology is a specialisation of the various components in the experience stack that used to be packaged as features or modules in monolithic platforms. In the case of content, headless CMS is almost entirely focussed on “content management”. This means that if you’re currently using one, you already have at least one person that could be part of this central team. Often their job title reads “content manager” or “content editor”, and they have at least a basic understanding of the domain and the technology. 

They will probably need some upskilling in terms of structured content, as they will have to shift their mental model of “building pages” to “creating content assets”, but they represent the bridge between your old and your new content domain, and they will have intimate knowledge of your current content types. 

Your first team member will need some help from an experienced content strategist to map the existing ecosystem, identify the new content entities, and get the first content types going. They’ll probably stick around to look at how to migrate old content into the new system. Depending on the complexity of the use cases that need to be implemented (personalisation, reuse, omnichannel, automation), you might need to hire, at least temporarily, someone with specialist skills in complex content architectures. And obviously they’ll be supported by engineering to run spikes, create proof of concepts and deliver code when needed.

In some cases, especially where the experience depends on the orchestration of content and data coming from different systems, you might need specialised skills in taxonomy and ontology (the “glue metadata”), however this role might be split across different teams, or there might be an entire team looking after semantics and semantic technologies if they play a crucial role in your organisation. The task here is to establish the dependency and make it clear to all teams and roles involved.

Step 4: Establish connections and interactions across the organisation

We already mentioned the separation of “content concerns”. This separation becomes crucial when content serves different purposes and is created and managed across different functions (product, marketing, support, and so on).

However, creating a dependency based on a central team can feel quite scary in organisations that are transforming, and still learning to be agile. This is another scenario where the team topologies framework can help.

In team topologies there are four types of team, namely:

• Stream-aligned teams are aligned to a flow of work from a segment of the business domain;

• Enabling teams support a stream-aligned team to overcome obstacles and detect missing capabilities;

• Complicated subsystem teams provide expertise where significant technical domain knowledge is needed;

• Platform teams represent a grouping of other team types that provide a compelling internal product for stream-aligned teams.

The central team we have described so far has all the characteristics of a “platform team”, since it’s a complicated sub-system type that provides an internal product for other teams and enables them to detect missing capabilities. 

Now, let’s look at how they would interact with other teams. There are three topologies for team interaction:

• [x] as a service

• Collaboration

• Enablement

The compelling product in this case is content architecture. The team’s core duty would be to provide it as a service to the rest of the organisation, who count on them to create and manage core CMS assets and configurations. As a result, other teams only need to access the authoring module to create the content they need. 

This central team would also collaborate with other teams for time-boxed initiatives, to create new content types, run technical spikes to enable front-end innovations or design system integrations, or to discover and connect datasets or content hosted on other systems. These initiatives would be prioritised and shared on a roadmap to ensure visibility across the organisation.

And last, but not least, they could enable CMS users, by onboarding them and providing a first-line level of support which, in time, could even become part of the ‘platform’ offering.

Step 5: Pause, reflect, and build on your learnings

What I’ve described is an ambitious vision that won't happen overnight. However, it’s a vision providing a direction of travel that can be used to inform the new team’s priorities. Remember the prep work: you need to allow the team to create incremental value, and in order to do that, they need to be able to deliver a small amount of work that provides them valuable feedback to build and iterate upon - or to start again, in the case of failed experiments. 

Team topologies promote the concept of “thinnest viable platform”, which sometimes can be as small as a wiki page, if that’s all other teams need to use the technology. However, as complexity grows, together with channels, front-end, integrations and so on, the ‘platform’ layer might grow in complexity as well.

This is where the potential of team topologies really shines, as the framework can also be applied to refine and change teams’ shapes and interactions, as the internal needs evolve and mature.

Moving to headless

Moving to a headless CMS is an exciting prospect for many businesses. Starting small, gaining traction and experimenting will all be crucial in successfully deploying the technology within your organisation. 

However, to make it a reality you don’t need swathes of people or large investments. And by centralising the architectural function, you can promote business and customer value, giving content publishers across the organisation the ability to create relevant, personalised, channel-agnostic content across your entire organisation.

If you’re looking to embark on this journey and are considering your options, or are coming unstuck with investments made to date, we’d be very happy to talk to you.