The big lie in the headless CMS world is that the channel doesn’t matter.
I don’t mean that multichannel or omnichannel doesn’t matter. All channels matter or we would not invest in them, and no headless vendor should focus on the web as the only channel. Still, for most of our real-world implementations, the web is the primary channel, and many organizations do not invest in complex data re-use strategy across web properties or even a single web property, let alone multiple channels. Data re-use is often more of a focus during the sales process and sometimes the implementation process than the use phase of the solution. In many organizations, no matter how developers design systems to avoid data duplication, users cut and paste text and require the ability to override almost anything shared.
I don’t have any statistics to support any of that, but any headless CMS that wants to target most of the market must focus on use cases for the web. Even a static JSON file system (think github) can support various Content-as-a-Service use cases, making it very hard for headless CMS vendors to compete at the commodity level. Headless CMS vendors need to differentiate themselves on other factors, such as CMS usability, data structuring capabilities, and human factors.
Simple solutions can require separating entries (records) that represent pages into numerous related entries. Vendors often use reusability to justify this scattering of data. The wrong level of normalization in content type definitions creates usability, management, performance, complexity, and various other challenges.
Strong data modeling capabilities, such as Contentstack modular blocks that allow storing complex data structures inline within a single entry, avoid the challenges associated with separating what CMS users see as a single page or record into numerous related entries. Along with a highly usable CMS user interface, these types of flexible data structures address common challenges with headless implementations, allowing developers to implement and CMS users to focus on either pages or fragments depending on requirements, without reducing the potential for data reusability and multichannel deployments.
This matters for a few reasons. It matters because considering the web as the most common use case influences the features that CMS vendors implement. Maybe most importantly, it shapes the way we define content types for individual solutions, where we must find the normalization balance appropriate for each customer and project, which depends on having a CMS with data structuring capabilities flexible enough to meet any possible requirements. The data models that result have a strong impact on how users think and feel about the systems, which is what really matters in the end.
Deliverystack.net 