I start any new content management project by learning the client’s domain: what their mission is, what problems they are facing, and how they think this project will help them today and in the future. For me, this is an immersive process. The goal is to gain a complete high-level understanding of the organization’s business.
The tipping point happens when most of the answers to my questions align with my assumptions. Next step is to document the content model that's been bouncing around my head, asking some further questions to find any potential gaps in the model.
While each organization is unique, the model is rarely a new one. It is often based upon a similar model I have used before. While the business entities and types of content may change between clients, typically the pattern is old. Learning to recognize those patterns and being able to leverage them is key to increasing the success of your content management projects.
The Early Days of Content Management
When content management started, everything revolved around content types. Invoices, resumes, correspondence, and any number of other items, depending on the group using the system. The design process was the same for every project:
- Identify the content types.
- Identify possible unique identifiers.
- Determine what additional metadata was needed.
- Throw the resulting content into a taxonomy.
It was simple. The taxonomy gave context to each piece of content. Invoices would sit in a folder structure that included the fiscal year and the billing company. The taxonomy indirectly provided metadata for the content and grouped related content together. For example, all invoices for a specific project would be in the same folder.
Eventually, content systems grew from departmental solutions into broader enterprise solutions. It eventually became clear that we could no longer look at content in isolation.
Related Article: Content Management Needs Come in Many Flavors
Logical Models Are Universal
When broader content solutions entered the picture, it became necessary to look beyond simple content types. It was time to take a step back and create logical models for the business. That meant modeling customers, projects, transactions, employees and anything else that interacted with information. The resulting model was able to grow and adjust with the business.
To create a good logical model, think about all of the business entities involved in the process. The entity could be a client, a mortgage application or a benefit request. Much of the metadata remains the same as it was for document types, but now you store it at a higher level. Afterwards, consider the content each entity contains. The resulting content types have much less metadata as they now inherit common characteristics from their related entity.
While creating the logical model, if you adjust your model to match the capabilities of your content management system, you are not being abstract enough. Take it up a level. This is a business model and should be completely independent of the underlying business systems. Don't think about how you will implement the model — you will make that decision later.
Learning Opportunities
Webinar
Mar
29
The CX Commute vs. the CX Joy Ride
Is your CX traffic holding up your customer's journey?
Webinar
Mar
29
Is Your Microsoft 365 Data Recoverable? How to Survive the IT Hotseat When Data is Lost
See why MIcrosoft recommends third party backup
Webinar
Mar
30
An Optimized Customer Contact Strategy Combines Transparency and Intelligence: The State of Outbound Communications
Learn from the Neustar-commissioned Forrester Consulting study on challenges and solutions for contact centers
Webinar
Apr
5
Adopt a Modern Digital-First Marketing Strategy
Learn how to use a composable DXP to your advantage
Related Article: When it Comes to Content Management, Master the Essentials First
Content Modelers: Avoid This Trap
A key aspect of this discussion is the concept of the business entity. This was a central part of the case management paradigm push 15 years ago. The key difference is that people treated cases as silos when, in reality, cases are just one dimension of the information. That singular view was rooted in the concept of people working with folders in the physical world.
Content modelers need to avoid this mental trap. Folders are buckets to store things. Folders should not be used to represent a business object without careful consideration. Every document won't fit into a single, logical, business entity. This means using folders as a stand-in for business objects doesn't work as content can only belong to a single folder.
Related Article: Technology Alone Is Never the Answer
Learn and Adapt Your Content Models
Take a moment to look back on past content projects. Do you see patterns in how you modeled and used content? How effective were those models?
- How did the models work in each scenario?
- What were their strengths?
- What were their weaknesses?
- How much of the result was from how you implemented the model?
As you move to your next problem, you can adapt existing patterns to the new challenge. Often it is just changing the fields to those unique to the client.
We can do a lot to improve how we implement content systems. Thinking about, adapting and reusing existing patterns is a great way to leverage past success and avoid past failures. Just remember, do not force a problem into a pattern. There are multiple patterns and not everyone solution you have implemented will match up to your next challenge.
Learn how you can join our contributor community.
