CMS and Headless CMS Components and Implementation

This blog post describes major components and features of content management systems, which let non-technical subject matter experts edit content used by downstream systems such as websites. It then lists some aspects specific to headless CMS solutions. If you have any suggestions to add to these lists, please comment on this blog post. This post is an expansion of Navaneethakrishnan (NAVAN) Sundarrajan‘s LinkedIn Update “Headless CMS Features” that featured this image:

So, thanks Navan! It’s a great start, but I have a slightly different perspective.

Note the first box in Navan’s image: SaaS-based. While it is possible to decouple content management from content delivery without SaaS, the real value comes from having the CMS vendor host the content management environments and content delivery services, which means SaaS.

At the same time, SaaS is not specific to headless. Any CMS may be able to run in a SaaS environment and provide content delivery services, even if that CMS includes a content rendering engine.

Otherwise, I tried to separate CMS features from those specific to headless.

CMS

Any CMS will likely include some variant of the following components.

• Text Data Storage: The ability to store any kind of text (simple text, HTML, JSON, or anything else) in a data repository as part of a structured record consisting of some number of field values.
• Binary Data Storage with Metadata: The ability to store binary data, such as media, in a data repository with a separate structured record containing metadata.
• Data Modeling: The ability to define the structure of records as a collection of fields with properties that affect their functionality, such as the type of the field. Data modeling is a key feature of CMS implementation that may require custom field types, which allow customers to extend the CMS record editing user interface.
• Workflow: A system for enforcing an editorial process before content appears on public websites and elsewhere.
• Internationalization/regionalization/translation: The ability to translate records from one language to another, typically including logic to retrieve data from a default language when that data is not available in the requested language.
• Versioning: The ability to store versions of records in the content management system as users make updates.
• Omnichannel Publishing: The ability to replicate the appropriate version of each record in each language from the content management system to one or more read-only repositories to support previewing, staging, export, content delivery, and other capabilities.
• Collision Management: Features to detect and prevent, prompt, or otherwise resolve situations in which two users attempt to edit a single record.
• Extensible User Interface: A browser-based editorial and management user interface that CMS customers can customize with features such as integrations with external systems.
• Rules Engine: Lets relatively non-technical users configure aspects of the system through a browser-based user interface rather than coding, configuration files, or other development techniques, such as to control workflow or webhooks.
• CMS Security: CMS users must authenticate and must be authorized to take action on content, typically based on logins and role membership. Typically, the CMS provides an authentication mechanism that customers can replace with their own if desired.

Components of Headless CMS

From my perspective, these are the main components specific to headless CMS:

• Content Management APIs: HTTPS endpoints to access, import, update, delete, or otherwise manage data and to trigger CMS functionality such as publishing.
• Content Delivery APIs: HTTPS endpoints to access published data from the CMS, often including GraphQL and synchronization APIs.
• Media API: Retrieve binary assets, often including capabilities to optimize and otherwise transform images.
• CDN: For performance and reliability, headless CMS vendors back content delivery and media APIs with Content Delivery Networks (CDNs).
• Webhooks: Triggered by events in the CMS to notify external systems with payloads of data about events in the CMS, such as record creation.
• CLI/CLT: To assist with automation and scripting, headless CMS vendors provide command line interfaces/tools that invoke their APIs according using command line parameters and information from processing environment.
• SDKs: Software Development Kits to facilitate usage of APIs and webhooks from specific development platforms.
• Microservice Architecture: While it would technically be possible for any CMS to expose services, due to their simplicity, consistency, and other benefits, development has a different feel and cadence when working only with products built on service-based architectures intended for SaaS.

Headless CMS Implementation

While headless CMS provide various facilities to support these features, each requires implementation for individual solutions.

• Personalization: From audience segmentation and profiling to advanced content targeting based on intent identification.
• Testing/Optimization: Presenting variants of content on the published site to determine the effectiveness of each, typically applying the most valuable content to the greatest audience.
• Previewing: The ability for CMS users to access page visualizations before publishing content. With headless CMS, previewing depends on the technology used for content delivery.
• Hierarchy Management: Headless CMS do not provide a natural hierarchy of records like a file system, but function more like a document database with records grouped by content type rather than by parent/child relationships. Web solutions tend to be hierarchical, requiring content delivery to determine hierarchy based on the URLs of records in the CMS.