Your choice of a content management system (CMS) will affect everyone who relies on content for business results. Despite the importance of CMSs, it can be difficult to know what elements influence the outcomes that they can deliver.

Understand the factors that contribute to success. While the individual features of a CMS each play a role, how these features work together—or not—will determine what outcomes you can achieve. Many organizations make the mistake of focusing on CMS features individually instead of examining how they are designed to work together as a platform.

Content management systems have earned a reputation—not undeserved—for being difficult to navigate. This guide provides a non-technical introduction to significant factors in content management that will influence the outcomes your organization can achieve.

Clarify your decision parameters. Once you get past the jumble of CMS features and jargon, what factors are most critical, and which choice will be in the best long-term interests of your content operations? This guide will explore the factors necessary to ensure:

• Your content is maintainable and future-ready
• Your CMS setup promotes operational efficiency
• Your setup can adapt to evolving needs

This guide will explain the differences in CMS product categories so you can:

• Appreciate how features that are used or implemented will influence outcomes 
• Look beyond the presence of individual features to see how they interact 
• Understand the capabilities necessary to adapt to evolving requirements

Think about how content fits in the digital transformation of your organization. Most professionals believe that content operations should become more connected and unified. Enterprises need to respond to a changing competitive environment.

Issue	Before	Now
Scalability	Teams worked independently on specific websites and apps with little coordination.	Enterprises need to address and coordinate a growing range of diverse content. They can’t afford for their content operations to be siloed.
Omnichannel	Most content was intended for websites.	Organizations need to support a range of channels.
Ease of use	The choice was between simple tools that did little but required no training or complex tools that had more capabilities but required extensive training.	Organizations expect ease of use without sacrificing sophistication.
Agility	Organizations expected time-consuming workflows and difficulty when making operational changes.	Improving the speed of publishing and avoiding time-intensive handovers are priorities.
Adaptability to future needs	Old CMSs would need to be replaced every few years because they weren’t easily upgraded.	Cloud-based platforms can continuously upgrade. Enterprises want to be able to add enhancements to take advantage of the latest and best technologies, quickly and without disruption.
Dependability	Because CMSs would routinely need to be replaced (re-platformed), the content would also be reworked or replaced to fit website redesigns.	Organizations cannot afford the disruption of having to redo content when making design or technology changes.

Each of these issues suggests a need for greater flexibility in how enterprises work with content. But flexibility isn’t a discrete feature of a CMS. It depends on many factors, as we will see.

Table: How categories decide configuration

CMS category	Opinion about content management settings	Configuration
Page-oriented	Prescriptive: choices predefined	Fixed
Head-optional	Options as exceptions	Partly flexible
Headless-native	Open choice: publisher chooses among many options	Flexible

CMSs differ in whether features are fixed or flexible. Many CMSs seem to offer equivalent features, but on closer look, they vary as to whether the feature is fixed or flexible. While it may be possible to modify a fixed feature, it will require more effort than if the features provided or that can be added are flexible by design.

Look beyond the features. Capabilities are more than a checklist of features. The configuration of your CMS will determine whether the product will meet your needs. CMS products will vary in how readily they can be adapted to your organization’s specific requirements. Many CMSs permit a degree of customization of default settings or workarounds of them, but certain CMSs allow for a much higher degree of configuration.

Even though page-oriented CMSs can differ widely in their specific features, they embrace a similar approach to managing content. They typically positioned themselves as “all-in-one” solutions that will handle everything a web publisher would need to do. The vendor has decided on most settings, defining generic functionality that it believes is sufficient for most organizations. These CMSs aren’t designed to support flexible configuration and can be difficult or expensive to modify.

A focus on pages and documents. As reflected in its name, a page-oriented CMS is geared to building web pages and articles. This orientation influences how the content gets created and how it is delivered.

The output destination shapes how the content is composed. In a page-oriented CMS, layout templates strongly influence how the content must be created and how it can be used. Authors create content for a specific screen component or part of a web page.

The CMS vendor supplies predefined page types. The CMS vendor supplies default page structures used to generate the output. If the default page types don’t match what the publisher wants to express, the publisher must modify existing pages or custom-develop new page types. Flexibility may be limited.

Website oriented. The page-oriented CMS is not designed to support diverse publishing scenarios. The CMS is set up to publish content to the web channel. If customers need to access content outside of a web browser (for example, in a mobile app or a chatbot), the publisher will need to use other tools or else needs to customize the delivery capabilities provided by the CMS. For example, with one CMS, you may need to create a “custom REST endpoint” to deliver your content to a mobile app (we’ll discuss APIs and their significance shortly). With another one, you may get REST API functionality that would allow you to deliver content to non-website channels, but it’s hard to tailor your content for other channels because the CMS’s authoring UI is based on predefined page types and is geared to building web pages. These CMSs need major revamping or overhauling to support publishing to non-website channels.

Design customization possibilities. While the CMS internally defines the layout and presentation of web pages, publishers may be able to override this setup for some or all of their content.

Partitioned mode of operation. Although the default settings rely on page-building templates, users can elect to bypass these defaults to create structured content. When organizations decide to develop customized content structures that have different characteristics than the predefined page types, they will need to manage them separately using different operational procedures. In some cases, CMS workflow support functionality may not be available for custom-structured content.

Need a separate tool to create reusable content pieces. The built-in editor of modified page-oriented CMSs does not support creating modular content. Employees who need to create reusable content pieces must use a separate editor, often developed by a third party.

Partitioned content: a mixture of predefined page types and user-defined structure. The content’s structure is often predefined, at least in part, by the CMS instead of by the publishing organization. Some structural elements may not be relevant to the publishing organization.

API delivery added. Modified CMSs often provide add-on or plug-in APIs to enable content to be delivered to touchpoints other than websites. What the API can deliver will depend on the profile of the source content. Because modified CMSs may store content in diverse ways, they may require more than one API to deliver content and not all content can be delivered to all destinations.

Predefined enhancement choices. Opportunities to enhance capabilities with external third-party tools depend on the underlying CMS architecture. When publishers want to supplement the internal capabilities of their CMS with external tools, their integration choices may be limited to a short list of vendor-provided or approved options.

Content is independent of layout. A headless-native CMS doesn’t manage the presentation layer. As a result, the internal organization of the content in the CMS, which shapes how authors create and use the content, doesn’t have to be bound up with how content is presented to customers on their devices. The content can be defined independently of a specific UI design, what’s known as “decoupling”. When that’s done, the redesign of a website or app won’t necessitate a change to the content—existing content can continue to be used in the new UI design. Decoupling content from UI design makes the content more flexible.

Publishers decide their content’s structure and organization. Instead of relying on a template supplied by the vendor, the publishing organization decides how to create and structure
their content to reflect their business priorities. They can define what parts of their content are important to manage (to reuse, personalize, update easily, or optimize). This gives them greater control over the details within their content.

Any kind of content can be modular. When using a headless-native CMS, publishers can structure their content to be flexible and platform-independent.

API delivery by default. All content created and managed in a headless-native CMS is delivered to websites, apps, and other consumer touchpoints using an API.

Content can be published anywhere. By using an API, the same content can be published to multiple places and channels.

May have limited preview of content. Some headless-native CMSs don’t provide the ability for authors to preview what the content will look like before it is published.

Open integrations. Headless-native CMSs generally support the ability to integrate other vendors’ tools and apps to support content operations. These CMSs are designed to connect to third-party applications readily, providing a wider range of enhancement options than possible with other CMS architectures.

How content gets structured in the CMS influences the types of content and experiences your organization can create and deliver.

A basic difference in CMSs is whether they rely on templates that fix the content’s structure or whether they enable the publisher to decide the content structure themselves. This can influence the diversity of content the CMS supports.

• Web pages: All CMSs can produce web pages, but some CMSs will only support fixed page layouts, while others support modular flexibility, which allows the composition of web pages to change as needed. 
• Non-website channels: Only some CMSs are designed to address content for touchpoints other than websites.

The characteristics of content flexibility involve several aspects, summarized below.

Table: Differences between fixed and flexible structure

Fixed structure	Flexible structure
Defined by page types or templates; the content may be organized in folders	Defined by content types that are related (linked to each other) within a content model
Decided by the vendor – modification is limited by the constraints of the CMS	Decided by the publisher, who can choose how to structure their content
Channel specific (content is designed to be outputted to a specific channel)	Channel independent (content can be reused in many channels)
Provides little or no ability to connect different items together	Provides a modular structure that allows authors to compose larger items by connecting them together in a range of combinations
Can be a “black box”: authors and developers must decipher how the structure is put together	Is transparent: both authors and developers can perceive the content’s structure and have a common understanding of it

When a CMS supports a channel-independent structure, the content can be combined in diverse ways and be reused on different websites and other channels. A page or UI-dependent structure doesn’t allow this flexibility.

Be aware that the ability to publish to more than one channel does not mean the content is truly channel independent. A CMS may let the publisher create content for more than onechannel, but not all content will necessarily be modular and able to be used flexibly. CMSs can vary in the extent that the same content can be reused in different scenarios.

Full flexibility versus selective flexibility. Some CMSs will offer selective flexibility, which limits what types of content can be reused. The content’s structure is not fully flexible when content reuse is limited to:

• Parts of web pages
• Content in specific UI components
• “Content fragments”
• “Information snippets”

By contrast, a CMS that provides a unified enterprise content model will support content that is fully modular, reusable, and ready for any channel. With an enterprise content model, publishers have the flexibility to plan what opportunities authors can target and how it is provided to readers. Content is stored in a format-neutral manner that makes it future-proof.

How will you build your content, and what can you do with that content once it’s created? The tool that authors use influences many aspects of the content process:

• Productivity: Does the tool help authors develop content in a strategic way? 
• Quality: Does the authoring tool promote good content practices? 
• Flexibility: Can authors develop a diverse range of content? Can they connect different kinds of content together?
• Learnability: How much training is needed to use the authoring tool? 
• Maintainability: Does everyone use the same authoring tool, or do different groups use different tools?

Kinds of authoring tools. Writers may use various kinds of authoring tools:

1. Page editors focused on page styling, which resemble word processors
2. Page editors that manipulate page components such as paragraph blocks
3. Text editors that require writers to add code (such as Markdown) to their writing
4. Structured content editors that break content into sections according to its meaning and purpose

Some authoring tools provide a preview of a web page before it is published. This can be helpful when authors will be responsible for deciding how parts of the content are ordered within a page in cases where this is not done automatically. Page editors generally offer a preview; other tools may not offer a preview.

Authoring tools are associated with the CMS in various ways. They may be a:

• Default, built-in tool that works with how the CMS is set up
• Alternative tool integration that replaces the built-in tool if the default tool is not adequate
• Offline tool that is used instead of the in-built tool to develop the content

Why content delivery is important

APIs deliver content, connecting the content that’s stored in the CMS to various UIs where customers interact with the content. They provide the ability to search, retrieve, and deliver selected content to different destinations. An API query can specify the subject matter of the content as well as which parts of content are desired.

Most CMSs now have APIs, but not all APIs offer equivalent flexibility. An API’s delivery flexibility will determine:

1. The delivery scope: the types of content available from an API
2. The delivery details: the granularity of information that can be specified in a query

APIs can vary widely in what they can retrieve and deliver, as their utility can depend on the structure and organization of content stored in the CMS. APIs may provide access to various dimensions, depending on the CMS:

• Web pages
• Parts of web pages
• Content for specific UI components
• Structured data for apps
• Modular (channel-independent) content that can be of any content type

Is all content globally available? If not all content can be delivered using an API, that will limit where the content can be delivered. It will be difficult or impossible to provide certain kinds of content in specific channels. Even if you can work around limitations, the content’s formatting might make it hard to process in some channels.

An API-first approach offers the greatest flexibility, giving the publisher control over to which user interfaces and channels to deliver the content and allowing them to refresh any details presented to users immediately. These APIs can deliver finely targeted content to customers. Publishers are not limited to preconfigured modules defined by the CMS (such as page parts, UI components, or app screens). They can decide to which frontend UI to deliver the content that would provide the best experience for customers.