I woke up on New Years Day thinking about, and ultimately diagramming, enterprise omnichannel content architecture.
Yes, I clearly need some sort of work-life-balance intervention. But as long as it’s here, I’ll walk you through this diagram that outlines the elements of an enterprise omnichannel content architecture.
This architecture:
- assumes/hopes that you have an enterprise ontology, or at least an ontological mindset
- includes, and is guided by, strategy
- accounts for valuable enterprise assets
- includes a variety of asset-management systems
- supports a range of business intents
- facilitates both content and experience orchestration
- delivers content-powered experiences via many channels
(NOTE: This diagram is very schematic and highly aspirational. Sharing it mainly to get my thinking out in the open and to follow up on my LinkedIn post about it.)
The elements of omnichannel content architecture
For a big enterprise, creating publishing artifacts and user experiences that deliver the right content to the right person at the right time in the channel they prefer on the device of their choice at their current point in their journey involves a lot of architectural elements.
Let’s look at each of these in a little more detail.
Enterprise ontology
An omnichannel content architecture is best understood in the context of an enterprise ontology. An ontology articulates and codifies what you know about a domain, in this case the domain of your organization. It accounts for all of your enterprise’s business assets, goals, activities, etc., including the elements listed below that make up your enterprise content architecture. Depending on how your organization thinks about such things, the implementation of the ontology may be part of a semantic layer, an information layer, a knowledge graph, a digital twin, a logical twin, or perhaps some other semantic artifact.
There’s quite a bit of overlap between an enterprise ontology and your enterprise’s content ontology. To grossly oversimplify this relationship: Your enterprise ontology describes all of the entities in your organization and how they relate to one another, while your enterprise content ontology describes the content elements that you use to share information about them – for example, brands themselves vs brand messaging content, products vs product description content, courses vs curriculum content, etc.
Omnichannel strategy
An enterprise omnichannel strategy is informed by (and may also inform) your organization’s:
- research strategy and activities, including persona development, customer journey mapping, UX research, marketing research, business intelligence, and other types of inquiry and discovery
- brand strategy
- design strategy
- product strategy
- messaging strategy
- content strategy, including content-management strategy
- marketing strategy
- metadata strategy
- governance strategy
Like every box in this diagram, any one of these line items might represent an investment of millions of dollars and involve contributions from hundreds or thousands of people. Just think of the budget for research at IBM, for brand at Nike, for product at Procter & Gamble, or for marketing at Apple.
Enterprise assets
As an enterprise content architect, you have a lot to work with. These assets may include:
- an enterprise content model, a system-agnostic view of all of the content assets and elements that your organization has created and/or needs
- structured content like technical documentation authored in XML or precisely modeled content in a headless CMS
- semi-structured content like the content in most web CMSs
- unstructured content like the content in PDFs or slide presentations
- media assets like images, infographics, or video and audio recordings
- enterprise data like product prices, geographical coordinates, or media-asset metadata
- taxonomies of product attributes, customer preferences and affinities, content types, etc.
Like the water in a lake behind a hydroelectric dam, the potential power of these assets is realized only when they are guided into productive channels (which is what the rest of the diagram is about).
Asset-management systems
Data, information, knowledge, and other content about your organization may be stored and managed in any number of systems:
- one or more headless content management systems (HCMS)
- one or more web content management systems (CMS)
- one or more product information management systems (PIM)
- one or more component content management systems (CCMS)
- one or more learning management systems (LMS)
- one or more digital asset management systems (DAM)
- one or more customer relationship management systems (CRM)
- one or more customer-support knowledge base(s) (KB)
- one or more enterprise-support knowledge base(s) and wiki(s) (KB)
- one or more enterprise databases (relational, NoSQL, graph, vector, etc.)
- one or more taxonomy management systems
- one or more design systems
Like many/most technical products, decisions about which of these systems to use often falls to the IT department. A better approach is to always involve in your evaluation and procurement processes the business users and subject matter experts who use the systems.
Business intents
Organizations aspire to do a lot of stuff, and the realization of those business intents requires always requires content. Whether it’s the company’s tag line on the home page, a promotional offer for a landing page, a product name on an invoice, the script that guides a support representative’s conversations, or the description of an API endpoint in a developer hub, you always need content to address:
- enterprise branding
- product design
- product branding
- product promotion
- customer education (about your brand and products)
- content marketing (about the domain in which you operate)
- sales support
- customer support (post-sales)
- technical support
- staff training
- compliance
To this point, these intents have largely been addressed in single-channel, monolithic applications and, realistically, that will continue to be the case for a while. But the rise of API-first, decoupled architectures affords new opportunities to keep content development in the hands of domain experts while still contributing to omnichannel experiences.
Content and experience orchestration
Decoupled architectures require a new enterprise design role – the content-orchestra conductor. Both publication-like experiences and interactive experiences may be planned, developed, assembled, and distributed using content from any number of sources.
To oversimplify, the two main flavors of this emerging role are:
- content orchestration – concerned with the assembly of communication artifacts, publications like articles, blog posts, white papers, lesson plans, and annual reports – more of a publishing model
- experience orchestration – concerned with the creating of user interactions and complex experiences like personalized content, algorithmic feeds, and AI-generated auto layouts – more of a UX model
Many folks are thinking about this new role, and even developing tooling and platforms to accommodate it (Conscia, Netlify’s Connect, etc.), and industry experts are sharing their ideas about it, like content management expert Deane Barker’s LinkedIn post on Variables in Artifact Composition.
Distribution channels
Omnichannel strategy begins here, where your customers and users consume the content experiences you have created. Omnichannel content strategy acknowledges that your customers are indifferent to the communication and technical channels by which they receive your content. They just want the information and knowledge that will advance them in their current journey. That’s why my content architecture work always begins with research-backed persona development and customer journey mapping.
Conclusion
This post is simply an attempt to inventory these elements.
The challenge going forward is to painstakingly pluck content from the silos it’s trapped in. Whether that’s by consolidating content in fewer systems or (more likely), by adding a semantic layer (a content mesh, content graph, or similar), or by some other set of methods to facilitate content orchestration is yet to be determined.
