Consultant
Composable architecture may represent the foreseeable future of most enterprise business solutions but can present new challenges to users navigating the various systems that provide individual Packaged Business Capabilities (PBCs). With a focus on headless Content Management Systems (CMS), This blog post describes some of these issues and potential techniques to address them.
This blog post is part of a series about challenges that organizations face when implementing composable solutions. For more context on these topics, please read the introductory post before proceeding with this one.
All headless CMS products are designed for omnichannel delivery. Omnichannel means that multiple content delivery systems such as the website, dedicated mobile apps, kiosks, and others can all use content from the CMS. Headless CMS marketing often focuses on the potential value of omnichannel content delivery.
For most organizations, the first and possibly only purpose of the CMS is to manage content for the website. The focus of headless CMS vendors on omnichannel content delivery can result in solutions that are not optimized for managing web sites. Many CMS products do not focus on this most common use case, which can lead to drawbacks for users responsible for web initiatives including steep learning curves, lacking features, and decreased usability, productivity, and satisfaction.
In relation to omnichannel, vendors also tout capabilities for content re-use, including the ability for multiple channels, multiple websites, and multiple pages on a single website to use a common set of data. While omnichannel capabilities may sound appealing in the sales process, the web is almost always the primary content delivery channel for most organizations. Most face significant challenges supporting even that one channel. Cross-channel content strategies are difficult to develop, implement, and govern over time.
In the vendor selection process, unless you don’t plan to use the CMS to implement websites, avoid excessive vendor focus on omnichannel capabilities. Focus on your requirements for the web as the primary content delivery channel. Confirm that the vendors support omnichannel delivery and move on to other proprieties.
Even if your organization has a well-defined content strategy for data re-use and near-term requirements for multichannel delivery, you will likely still benefit from working with a CMS that focusses on the web as the primary channel. Determine how the CMS will address your use cases for website creation and maintenance. The best CMS offerings can address the most common use cases for every channel, and there are no CMS features specific to web that would interfere with the ability of a CMS to support content omnichannel re-use strategies.
The remainder of this post considers the need for omnichannel delivery, but focusses on the web as the primary channel for delivering content from the CMS.
Because headless CMS do not include HTML generation facilities, they do not inherently provide capabilities for previewing content in the context of the published site. Business users typically require a preview environment to evaluate their changes before publishing. If you will use the CMs to power websites, commit to investing in an architectural approach that supports previewing content in the context of a website.
Some headless CMS vendors provide facilities to support preview, but this typically requires customers to use specific technologies dictated by the vendor, precludes various architectural options such as retrieving content from a search index rather than the CMS or using static site generators, and works against the objective of decoupling the content delivery front-end from the CMS back-end. The result is a website tightly coupled to the CMS, which locks the customer into the vendor’s solution.
Customers that require preview environments are responsible for implementing their own solutions to meet this need. When selecting a CMS, consider how you will implement a web preview environment.
Before users can update content, they must navigate to that data in the CMS. Especially when managing large volumes of data, CMS users can struggle to locate the content that they wish to maintain. The CMS may allow users to search for records of an individual content type, but users do not always know the content type of every record used in a page, and searches can return long lists of matching records.
Unfortunately, most headless CMS products do not include a content tree representing hierarchical relationships between CMS records, which can make it significantly easier for users to navigate to their content. Those that do include a content tree may require CMS users to define relationships between records manually rather than simply creating new records at the appropriate location in the content tree. When selecting a CMS, consider whether it provides a content tree, whether intrinsically or through well-supported optional capabilities.
Another approach that makes it much easier for users to find content is to add features to the site preview environment that, when accessed, take the CMS user directly to individual content records in their source systems. Some vendors provide toolsets that help to achieve these capabilities, and organizations can implement custom features to achieve this objective, but this results in greater vendor lock-in. Third-party solutions can facilitate this objective without tightly coupling the front-end to the CMS, and can be especially useful when the website presents data from multiple systems such as both CMS and commerce.
When selecting a CMS, consider whether and how you can implement features that let users edit content directly from the preview environment.
CMS products can easily house fragments of data for reuse, where the front-end stitches those pieces of content together for management and delivery. This can place undue burdens on both CMS users and developers that need to work with numerous fragments to manage a single page. Few CMS products provide features that let users intuitively manage all the data required for a single page through a comprehensive lens, instead requiring navigation and management of the individual fragments. To edit the content for a single page, CMS users may need to edit, translate, workflow, and publish multiple records in the CMS. Code to present pages must follow references from one record to another, complicating the code and potentially negatively impacting performance.
Organizations may favor CMS products that provide enhanced data modeling capabilities that reduce the need for fragmenting data. Rather than treating every piece of data as a flat list of fields, some CMS products support nesting fields within other fields, allowing the management of larger volumes of data in a single record rather than depending on references to data managed separately.
When selecting a CMS, evaluate its data modeling capabilities to ensure that they meet your use cases for data management. Beware of vendors that respond to questions about complex data structures by suggesting that fragmenting data makes it reusable. Data is reusable whether stored in fragments or larger records. You may find that much of your content is less reusable than anticipated, and fragmenting that data only makes it more cumbersome to use.
With the current state of technology, it is not truly possible for businesspeople to compose applications from components provided by a vendor without technical assistance. Organizations continue to depend on architects and developers to implement their solutions. The quality of collaboration between business and technology teams, especially considering their reliance on third-party advertising agencies and systems integrators, presents impediments to implementing solutions that deliver on customer expectations including intended capability, usability, and flexibility.
To address this concern, the creation of innovation teams within business units and the rise of the citizen developer role can provide bridges between the business and technical teams focusing on delivering solutions as complete products rather than individual capabilities. Rather than the business handing requirements to developers to implement, organizations should treat experience management initiatives as collaborations between business and technical teams. This approach reduces the risk of projects failing to meet expectations.
Established organizations may have developed routines and expectations around the separation of roles and responsibilities, often to define accountability. To achieve the objectives of composable architecture, it can be important to address corporate culture to improve collaboration and share accountability for results. Recognize that innovation can be disruptive. Consider how you can leverage technologies and whether you can expand skills and roles to empower citizen developers.
It can be difficult to develop and cumbersome to implement and use a content strategy that truly supports all intended possibilities for content reuse including omnichannel content delivery. Many organizations see the potential value of an omnichannel content strategy during the CMS sales process. Unfortunately, the teams responsible for strategy and product selection are not always the same individuals responsible for the implementation and use of the resulting system. Many organizations find that they do not have the resources or expertise to define and implement such a strategy effectively, and many determine that their requirements and use cases for presence on multiple channels do not fit an omnichannel data management strategy.
Rather than shoehorning all channels into an overarching omnichannel content strategy, it can be advantageous to treat each channel separately, recognizing that there can be advantages to managing messaging separately for each. Re-use data wherever possible, recognizing that a headless CMS provides facilities that can reduce duplication and resulting synchronization issues, but employ omnichannel content strategy only where it is appropriate.
Sign up for our newsletter.