The current trend in the CMS community is pushing organizations to consider going headless, which for most organizations is a momentous amount of effort. The reality is that having a well-thought-out CMS architecture can significantly help an organization address its current and future digital challenges and ongoing digital strategy.

Every few years, organizations have to rework their digital strategy starting with establishing a web presence, adopting a CMS, sharing content, building a responsive mobile website, creating personalized user experiences, and authoring voice-friendly content. This list won’t stop there. Headless CMSs are not a trend - they are a major shift in how organizations create and manage their content to make it easier to future-proof an organization's digital strategy for their next digital challenge.

Headless CMSs have been the talk of the town for several years. This post aligns with the direction that headless CMSs are taking the industry in while also focusing on the need for good data, APIs, and authoring tools.

To help keep this discussion focused, my goals (and hopefully takeaways) in this post are to emphasize the importance of:

• Defining a modern approach for organizations leveraging Drupal or considering moving to Drupal.
• Recognizing the reality that we may need to rearchitect our existing content architecture.
• Nudging our community to collaborate on a shared universal Schema.org-first data modeling approach with familiar entities, fields, and predictable relationships.

My organization is at a crossroads where our digital presence needs to become a multi-channel personalized and competitive digital experience. We were early adopters of Drupal 8 and, at one point, even considered moving to another CMS. Our content management strategy needs to change to allow our digital experience and the teams supporting these experiences to grow.

Decoupling in the early days of Drupal 8 was a new concept, and it would have added too much overhead, complexity, and risk to my organization's already challenging migration to Drupal 8. We were happy to be using modern software to build our first responsive website using a component-driven, front-end architecture.

Our content needs to be everywhere and tailored (a.k.a. personalized) to meet our consumer's needs. We need to rethink our approach to recognizing the maturity of Drupal's APIs, the stability of the data schema provided by Schema.org, and the challenge of building a personalized consumer user experience.

Our industry has moved from a mobile-first approach to a content-first approach, and now we are talking about API-first. "Content will always be king," and we need to ensure our content reaches the target audience.

Our APIs and data design provide the infrastructure and roads our content travels to our consumers. An organization still needs to have a mission with clearly defined business goals, and APIs just express the services and information that an organization offers.

Once in place, infrastructures and APIs can be difficult to change; therefore, we want reliable and stable APIs. We have established reliable APIs by creating and maturing standards like JSON:API and GraphQL. To build stable APIs, we need to look at our data models. The most reliable, common, and thought-out data model is Schema.org.

Schema.org is not a new thing; I have talked about it before and argue that we can't have a successful API-first approach to building a CMS without recognizing the need for a solid data model (a.k.a. schema), which should be a Schema.org-first approach.

A Schema.org-first approach extends the current API-first approach, recognizing that "content is king" and should always be the first thing an organization considers when building its digital presence.

Drupal has the tools to make a Schema.org-first approach to content modeling an industry standard. Drupal is the most flexible CMS on the market for creating a robust user interface for modeling, authoring, and managing content.

Well-defined Schema.org-first data only works when people have the tools to author and maintain it. Being able to just author and maintain content is an understatement of the actual requirements around an enterprise CMS. We also need to relate, preview, revise, moderate, translate, massage, augment, and distribute content. And Drupal does all of the above.

For example, in the Drupal community, we have established multiple patterns and user interfaces for building relationships between content. Out-of-the-box Drupal supports entity references which provides simple one-to-one or one-to-many relationships. The Entity Embed module makes it possible to have inline entity relationships. Lastly, Paragraphs make it possible to collect, stack, and present entities.

Drupal's flexibility is not limited to content creation. The Drupal community has collaborated on implementing and leveraging the best frontend tools for users to experience your content.

UX is where the rubber meets the road that drives consumers to your organization. Generally, UI and UX go hand-in-hand, but the UI discussed here is for creating content. The UX is for experiencing content; a user experience requires a user interface to interact with content.

The road for a user to experience and interact with your data is winding and forking. A CMS should not have a strong opinion about how users experience your content. Your CMS's content model and data should be as descriptive, flexible, and consumable as possible.

Going headless, also known as decoupling, establishes the separation of content and experience. A successful decoupling should make it easy for organizations to build a responsive website, publish content to voice-enable applications, distribute content to other systems, and provide personalized user experiences.

If your organization has a solid API with a content authoring user interface that makes it possible to create Schema.org-first content, building a rich multi-channel user experience should be easy. The enormous value of having thought out the three phases of your content, defining (API), creating (UI), and experiencing (UX) aligning, is that each step can evolve to meet the future needs and requirements for your organization's digital user experiences.

My last goal for this post is to nudge the Drupal community to collaborate to create universal, standardized, and shareable data. For me, this post serves as a proposal that my organization starts thinking about what is next for their Drupal implementation. For the Drupal community, I hope this post questions, and maybe answers, how we should leverage our tools and community to build standardized data models for our digital consumer user experiences.

This article is my third post about leveraging Schema.org as the foundation for implementing enterprise Drupal. Along the way, I have researched how and where the Drupal community is leveraging Schema.org. Nothing I have discussed here is entirely new; the challenge is building out a Schema.org-first approach, which provides a stable foundation that the Drupal community and organizations could adopt.

For me, it is time to create a sandbox Schema.org-first module and build a POC.

Below are my two other posts about Schema.org and Drupal and additional posts by other members of the Drupal community.

• Exploring a Schema-first approach to Drupal and Content Management Systems
• Using a Schema.org-first approach to build a single source of truth and a unified Content Management System

Preston So

• Hidden treasures of decoupled Drupal: The best-kept secrets of headless Drupal - part 1
• Decoupled Drupal in Practice: Architect and Implement Decoupled Drupal Architectures Across the Stack

Dries Buytaert

• How to decouple Drupal in 2019
• Drupal is API-first, not API-only

Others

• The future of CMS
• Is Headless CMS the Future? 5 Reasons the Answer Is a Big Yes
• Headless Drupal - What, When, How & Where -The Ultimate Guide To Decoupled Drupal