Unified Metamodel for Data Management Specialists

Written By Modelware Systems
Data Management Template Development

Figure 1. Data Management Template Development

This week's webinar was well attended, but the engagement levels were shallow.

The best question, which certainly wasn't bad, was: Howard, this project seems like building the Death Star.

For those who don't know, the Death Star was the Empire's ultimate weapon, able to destroy an entire planet. Interestingly enough, the Rebel Alliance refused to bow to this technological terror.

The unified solution to the metadata challenges we are facing will certainly not be able to destroy a planet, but it can radically improve our understanding of data management.

Some frequently asked questions are:

  1. Can something of this scope and complexity be achieved?

  2. Is the project too big?

  3. Is each template dependent on an individual's viewpoint and understanding?

  4. Does it sound like an Enterprise Data Model for Data Management Metadata?

Unfortunately, most of the answers to these questions are Yes!

Before attempting to answer the above questions, let me ask what I believe are more significant questions. Secondly, I would like to list the most important goals and objectives. Thirdly, I will provide answers that will help us de-risk the challenges that we are facing.

More Significant Questions

So, what are the more significant questions?

  1. Can we afford not to know What deliverables we need to create?

  2. Can we afford NOT to understand How we should make the deliverables?

  3. Can we afford NOT to know What a GOOD deliverable looks like?

  4. 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.

Suppose you have ever been part of an official or peer review. In that case, you will also understand how important it is to have answers to the questions if you want the examination to be manageable.

If you have ever entered into a financial contract to produce data management deliverables, you have experienced what it is like not agreeing on any of the questions.

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 of this is that we speak a different language to the language of business. We need to learn the language of our businesspeople before we expect businesspeople to start learning our language.

Why Business and DM need a common language (language first)

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 if we make our language familiar to many. Communication is the process of sharing thoughts, ideas and feelings in commonly understandable ways.

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:

  1. our understanding of the deliverable,

  2. a procedure to create the deliverable,

  3. the measurement system of the deliverable

Support data citizens in their search for knowledge and collaboration.

Typically, the best and most profound 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 can answer our questions, and we must find the answers. It is beneficial to start the learning process from the point of understanding and then delve into areas we don't understand.

This process is different for all of us as our point of reference changes:

  1. Businesspeople start from their vantage point:

    1. Business Definition

    2. Business Process

    3. Business Report

  2. Developers start from the code they have written and where it is going wrong

  3. Data Modellers start from the entity they are busy modelling

  4. Data Engineers start from the data collection point

The critical point is that different people will start searching for knowledge from the deliverable they are currently working with.

We can only bridge the gap in their understanding if the dots are connected. People will then give up, get frustrated and then 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:

  1. Can we achieve something so big and complex?

    1. We can beat "Big" by tackling one knowledge area at a time

      1. One team per knowledge area

      2. One or two people to unify

    2. We can beat "Complexity" by standardisation and harmonisation.

      1. Standardise DM Artefacts by producing Templates, SIPOCs and Scorecards

      2. Harmonise DM Artefacts by agreeing on purpose and relationships

  2. Is the project too big?

    1. Yes

      1. How do we eat an elephant?

        1. One bite at a time, we can complete it gradually

      2. Don't hide away and attempt to finish before you show your face.

        1. You will get lost and forgotten

      3. Build a Community of Interest that will contribute.

        1. Allow different people to tackle their areas of need and desire.

  3. Template dependent on individual's understanding and purpose

    1. Yes

      1. Harmonize purpose

        1. A simple statement of purpose agreeable to the community

      2. Perfection is the enemy of progression

        1. What is fit-for-purpose?

      3. Look for existing templates from Thought Leaders or Standards Authority.

  4. Sounds like an Enterprise Data Model

    1. Yes

      1. Add Levels of Detail

        1. Create Abstract Artefacts

          1. A standard Policy Template

          2. A standard Issue Management Template

        2. Specialise Artefact for specific domains when appropriate

        3. Omit More technical details so that we can agree on business inputs

      2. Different Sources of Input

        1. Top-Down

          1. Industry Definitions (DMBOK) of required deliverables

          2. Define artefact columns

          3. Link to related artefacts

        2. Middle-Out

          1. Build a Template

          2. Add related Templates when the original template requires connection or inputs from other artefacts

        3. Bottom-Up

          1. Adopt Existing Templates and conform to the DM Template.

          2. Add the necessary linkages to other artefacts.

      3. Implementation Method

        1. Waterfall

          1. By Domain

          2. By Activity Phase

          3. By Activity

          4. By Deliverable

        2. Iterative

          1. Critical Data Elements

          2. Optional Data Elements

        3. Agile

          1. Minimal Viable Product

          2. Artefacts required for a specific use case

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 must be Value-Driven. Every DM Template that we create must provide value to the organisation the all the stakeholders involved.

https://www.geeksforgeeks.org/knowledge-management-meaning-concept-process-and-significance/

Figure 4. https://www.geeksforgeeks.org/knowledge-management-meaning-concept-process-and-significance/

We will require a Data Management glossary to support the DM Artefact development. Using the DAMA Data Management Dictionary as a starting point is helpful.

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 to become shared behaviour, embedded and sustainable.

Integrating, Embedding, Sustaining -> Shared & Common

Figure 5. Integrating, Embedding, Sustaining -> Shared & Common

Achieving this shared behaviour will require change management.

Ensure that the Template Development also provides the following:

  1. Training Presentations

  2. Sample Business Data

To find out more make sure to join the webinars and follow us on LinkedIn to join the conversation

If you want to receive the recording, kindly contact Debbie (social@modelwaresystems.com)

Don’t forget to join our exciting LinkedIn and Meetup data communities not to miss out!

Modelware Systems
Previous

Clearing the Skies for Cloud Data Warehousing
Next

Data Governance Needs Risk Management