
Executive Summary
This week’s webinar was well attended, but the engagement levels were shallow.
The best question I got, and it was a genuinely good one, was: Howard, this project sounds like building the Death Star.
For those who don’t know, the Death Star was the Empire’s ultimate weapon, capable of destroying an entire planet. And yet the Rebel Alliance still refused to bow to this technological terror.
The unified solution to the metadata challenges we’re facing won’t destroy a planet, but it can radically improve how we understand data management.
Some frequently asked questions are:
- Can something of this scope and complexity be achieved?
- Is the project too big?
- Is each template dependent on an individual’s viewpoint and understanding?
- Does it sound like an Enterprise Data Model for Data Management Metadata?
Unfortunately, the answer to most of these questions is yes!
Before I try to answer those questions, I want to do three things: first, ask what I think are more significant questions; second, list the most important goals and objectives; and third, offer answers that help us de-risk the challenges ahead.

Figure 1. Data Management Template Development
More Significant Questions
So, what are the more significant questions?
- Can we afford not to know What deliverables we need to create?
- Can we afford NOT to understand How we should make the deliverables?
- Can we afford NOT to know What a GOOD deliverable looks like?
- Can we produce the deliverables independently WITHOUT understanding the relationships with other deliverables?
If you have ever been responsible for developing principles, policies, procedures or standards, you know the answer to all the above questions is yes.
If you’ve ever been part of an official or peer review, you’ll understand how important it is to have answers to these questions if you want the review to stay manageable.
If you’ve ever entered into a financial contract to produce data management deliverables, you’ve experienced what it’s like when nobody agreed on the answers to these questions beforehand.
Essential Goals and Objectives of a Data Management Unified Metamodel
Why do I need to spend so much time developing a unified metamodel?
Speak a common language.
Introducing Data Management into an Organisation should lead to clarity and understanding of our data.
Unfortunately, it typically leads to misunderstanding.
The root cause is that we speak a different language from the business. We need to learn our businesspeople’s language before we can expect them to learn ours.
Figure 2. Why Business and DM need a common language (language first)
Provide a common understanding of our data.
We can only communicate about data management once our language becomes familiar to enough people. Communication, after all, is the process of sharing thoughts, ideas, and feelings in ways everyone understands.
Define the expected behaviour required to manage data.
Once we overcome our language and understanding barriers, we must share behaviour.
I love this quote:
All unhappiness is due to wrong expectations!
Question: How can we avoid this hurt?
Answer: By agreeing on what our expectations are.
To agree, we need to standardise:
- our understanding of the deliverable,
- a procedure to create the deliverable,
- the measurement system of the deliverable
Figure 3. https://nrwinter.com/2016/10/15/expected-unexpected-behaviors-social-thinking-introduction-lesson/
Support data citizens in their search for knowledge and collaboration.
Typically, the deepest understanding and learning happens in anger and under pressure.
We learn the most when we have to learn for ourselves and then again when we need to explain to someone who doesn’t understand.
We learn for ourselves when no one else can answer our questions and we have to find them on our own. It helps to start the learning process from what we already understand, then work outward into what we don’t.
This process is different for all of us as our point of reference changes:
- Businesspeople start from their vantage point:
- Business Definition
- Business Process
- Business Report
- Developers start from the code they have written and where it is going wrong
- Data Modellers start from the entity they are busy modelling
- Data Engineers start from the data collection point
The key point is that different people start searching for knowledge from whatever deliverable they’re currently working with.
We can only bridge that gap in understanding by connecting the dots. Otherwise, people give up, get frustrated, and call a friend.
They may raise an issue if they don’t have the right friends.
How do we De-Risk the Unified Metamodel?
If you are still reading this article, you are probably looking for a way to succeed in building the Death Star.
Let us return to the original set of questions and provide appropriate answers:
- Can we achieve something so big and complex?
- We can beat “Big” by tackling one knowledge area at a time
- One team per knowledge area
- One or two people to unify
- We can beat “Complexity” by standardisation and harmonisation.
- Standardise DM Artefacts by producing Templates, SIPOCs and Scorecards
- Harmonise DM Artefacts by agreeing on purpose and relationships
- We can beat “Big” by tackling one knowledge area at a time
- Is the project too big?
- Yes
- How do we eat an elephant?
- One bite at a time, we can complete it gradually
- Don’t hide away and attempt to finish before you show your face.
- You will get lost and forgotten
- Build a Community of Interest that will contribute.
- Allow different people to tackle their areas of need and desire.
- How do we eat an elephant?
- Yes
- Template dependent on individual’s understanding and purpose
- Yes
- Harmonize purpose
- A simple statement of purpose agreeable to the community
- Perfection is the enemy of progression
- What is fit-for-purpose?
- Look for existing templates from Thought Leaders or Standards Authority.
- Harmonize purpose
- Yes
- Sounds like an Enterprise Data Model
- Yes
- Add Levels of Detail
- Create Abstract Artefacts
- A standard Policy Template
- A standard Issue Management Template
- Specialise Artefact for specific domains when appropriate
- Omit More technical details so that we can agree on business inputs
- Create Abstract Artefacts
- Different Sources of Input
- Top-Down
- Industry Definitions (DMBOK) of required deliverables
- Define artefact columns
- Link to related artefacts
- Middle-Out
- Build a Template
- Add related Templates when the original template requires connection or inputs from other artefacts
- Bottom-Up
- Adopt Existing Templates and conform to the DM Template.
- Add the necessary linkages to other artefacts.
- Top-Down
- Implementation Method
- Waterfall
- By Domain
- By Activity Phase
- By Activity
- By Deliverable
- Iterative
- Critical Data Elements
- Optional Data Elements
- Agile
- Minimal Viable Product
- Artefacts required for a specific use case
- Minimal Viable Product
- Waterfall
- Add Levels of Detail
- Yes
Final Comments and Challenges
This project is about Knowledge Management and creating a valuable Data Office that delivers on its ROI promises. To succeed, we have to be value-driven: every DM Template we create must provide value to the organisation and all the stakeholders involved.
Figure 4. https://www.geeksforgeeks.org/knowledge-management-meaning-concept-process-and-significance/
We’ll need a Data Management glossary to support the DM Artefact development, and the DAMA Data Management Dictionary is a good place to start.
Building all the Templates, SIPOCs, and Scorecards is not the end of your journey.
You need to operationalise all this work: the SIPOCs need to become Standard Operating Procedures so they turn into shared behaviour that’s embedded and sustainable.
Figure 5. Integrating, Embedding, Sustaining -> Shared & Common
Achieving this shared behaviour will require change management.
Ensure that the Template Development also provides the following:
- Training Presentations
- Sample Business Data
- Executive Summary
- More Significant Questions
- Essential Goals and Objectives of a Data Management Unified Metamodel
- Speak a common language.
- Provide a common understanding of our data.
- Define the expected behaviour required to manage data.
- Support data citizens in their search for knowledge and collaboration.
- How do we De-Risk the Unified Metamodel?
- Final Comments and Challenges
