Mastering Data Management

More in Business Process Management

• Improving Business Processes with MDM
• Mobility: Inventing the New Division of Labor
• Take Charge of your Data Environment: IBM Performance Management Solutions
• Top 5 InfoSphere Demos at IOD

More in MDM

• Top Books for your MDM Library
• Recent Reads: MDM & Data Governance
• Big Data Governance: A Framework
• Predictive Data Governance for Business Transformation

More from Marty Moseley

• IAIDQ Blog Carnival: Data Fitness & Garbage
• Mind the Gap and Do Data Governance Better
• Measuring Data Governance: Metrics that Matter
• Measuring Data Governance: How Do You Know You’ve Made a Difference?

Share this Post

Recent Comments

• Lorraine Fernandes on Response: A Universal Identifier Isn’t a Silver Bullet
• Henrik Liliendahl Sørensen on Response: A Universal Identifier Isn’t a Silver Bullet
• Response: A Universal Identifier Isn’t a Silver Bullet | Mastering Data Management on 3 Best Practices in Identity Management

Your data governance board should make several declarations

When establishing data governance, organizational leaders must make declarations about the whys and wherefores of data management. In the past few years, I’ve been writing and speaking about “Agile Data Governance” as a way to adopt some of the best experience in Agile Software Development to the problems of Data Governance.

Let’s take a leap of faith and assume we agree that a successful data governance practice should be led by a group of influential organizational leaders (I call these folks a Data Governance Board). Let’s also (momentarily) forego the discussion of who should comprise this board. (I’m saving that for another post.) Instead, today we’ll discuss what the heck these folks actually do.

What should the DG Board be producing? Well, I call their primary work products “Declarations” – because they’re declaring a business statement of policy, principle, process, etc. The term defines the group of deliverables, but each one of them is distinct – here’s a brief run-down.

Principles

Principles are the highest-level declarations of “why” the quality of certain classes of data matter to an organization. Principles address how and why the organization values a particular class of data, as well as the value of achieving high data quality.

Principles may address the mission of the organization, the behavioral mores expected, and who benefits from the end result. These are almost like mission statements or statements of purpose for companies. My friend Jill Dyché calls them “philosophical touch-stones.”

Policies

Policies are measureable statements of “what must be achieved” to realize the goals of a Principle. A Principle can have several Policies that flesh out details , including:

• The levels of quality that must be achieved for each type of data
• Who owns the responsibility
• How exceptions and disputes are handled

Policies can refer to internal or external standards; regulations; rules or guidelines (such as privacy guidelines); or compliance with acts such as SOX, GLB and others. A Policy does not state how it is to be achieved, though. Those are specified by Process and Business Rule declarations.

Processes

Process declarations are definitions of tasks and procedures that, when executed, achieve the mandates (objectives or requirements) of a Policy. Processes state a number of details, including:

• Who does what and when they must do so
• The proper sequence to perform certain actions
• Who is involved and in what capacity (whether they are merely informed, consulted, or the approving body)
• How exceptions are handled
• How actions are communicated

For humans, this is typical workflow. For automated processes, this is event management, process flow, orchestration, etc.

Business Rules

Business Rules are discrete specifications of how a piece of data will be evaluated to see if it meets a Policy’s quality goals. A Business Rule describes:

• Which data elements are critical
• Which values and relationships are valid (or invalid)
• How to determine if a value is correct or allowable
• What to do when a value falls outside the bounds of what is considered acceptable

Business Rules can call reference data to check for allowable values, or they can call a profiling engine to check the validity of a set of data.

Metrics

Anything that has any value or that one wants to manage should be measured. Metrics are those “critical few” metadata captured about data transformations that provide insight into the quality of a piece of data.

These data capture who, what, when, where, why, and how a piece of data comes into existence, how it is grouped and associated with other data, how it is transformed, etc. It is by this that Data Governance boards can measure the quality of their most prized data.

Thoughts so far? I have more to say in a future blog…