Business Value of Master Data Management

In recent posts Aaron Zornes (@azornes: MDM and Next-Generation Data Sources) and Henrik Liliendahl Sørensen (@hlsdk: Another Facet of MDM: Master Relationship Management) shared their vision about the future of Master Data Management as a discipline that does not only mitigate architectural flaws of the past, but will create business value for the years to come. They identified management of relationships as a next-generation focus, and Henrik even suggested the terms Master Entity Management and Master Relationship Management.

Indeed, this is another reminder that successful Master Data Management is based on Master Data Modeling which actually distinguishes Master Entities and Master Relationships. Moreover, here is the historic opportunity to underscore the business value of (Master) Data Modeling.

Party (as described in my comment post What domains are people managing with MDM?) refers to any natural person or legal entity that is relevant for a business. High-quality Party data are necessary ingredients, but to generate business value, an organization needs to win Parties as Customers, Suppliers, Employees etc., i.e. to create and record relationships between those Parties and the business.

In a traditional siloed approach, Parties and their relationships with the business organization are not differentiated. Parties in the role of Customer are kept in sales systems, Parties in the role of Supplier in procurement systems and Parties in the role Employee in systems related to Human Resources. This approach neglects a.o. that

• A Party can e.g. be Customer and Supplier
• A Party can be Customer in multiple sales systems that may coexist and be used depending on the product / service which was ordered
• Even within the same organization, Marketing, Sales, Order Processing and Accounting will naturally have a different understanding of what a "Customer" is
• Depending on the industry, even one purchase (order) / contract may have multiple "Customers", e.g. the roles of Contract Partner, Beneficiary and Payer may be represented by different parties.

Conclusion: The differentiation of Master Entities and Master Relationships is not only paramount for a structurally-sound approach that allows to generate a complete view of all relationships which a party has with a business organization. It is also a crucial prerequisite to extract and distill the value-critical components from the Master Entities and thus to reliably evaluate the actual benefits and costs as well as the opportunities and risks of a business connection based on the detailed benefit / cost / opportunity / risk that come with each single role that a Party occupies.

A Different Introduction to Data Governance

Most likely, you have heard the term Data Governance before, or even read multiple attempts to define it...

No, Data Governance is not just a hype, and it's not the latest intrigue of your IT department. It's not about pushing responsibilities or blaming people. It's not about being picky, and you don't only do it to please others.  

It does not even require more work, actually it's the opposite, and - put in simple words - the principles of Governance can be summarized as: Do things right the first time!
 

And Data Governance: Do all things data right the first time!

Who wants to question this approach? What is the alternative? "Do it sloppily now, we'll fix it later if necessary!"? Well, if it's not necessary why even taking the time to do it sloppily? And if it's necessary, why spending additional time later when it's much easier (faster, more economical) to do it properly right away?

In any event, too many organizations have 'let it go' for too long, over time data issues have accumulated - and that's why we are talking Data Governance now...

Modeling Party-to-Party Relationships

Inspired by a question that was raised on a data modeling forum, namely, how relationships between instances of the master entity Party should be modeled, I created a representation as of image 1.

Image 1 - Click on image to enlarge it

To illustrate a solution by example, the model includes a

• 1-to-1 relationship (Is_Married_To)
• many-to-1 relationship (Is_Child_Of_(Mother))
• many-to-many relationship (Is_Employed_At)

as well as a relationship attribute (Employment Start_Date).

This model is normalized, i.e. built in a way that it enforces the maximum of  semantic / business rules (particularly maximizes mandatory (NOT NULL) attributes) and referential integrity. Attributes and relationships are assigned to the specialized level, since e.g.

• a Legal Entity is a Party, but does not have a First Name,
• only a Person can be employed at a Legal Entity.

The normalized model serves as a reference for an operational process / application that creates, updates and/or deletes instances of the included entities.

Image 2 shows a “soft” (denormalized) model of the very same scenario.

Image 2 - Click on image to enlarge it

In this model, Persons and Legal Entities are not distinguished on the entity level, and all relationships are submerged under a generic many-to-many representation. As a result, there is nearly no enforcement of semantic rules and referential integrity.

Accordingly, the denormalized model is not suitable for an operational application. Depending on the purpose, it may be useful as a data warehouse model provided that its instances have been captured using an application based on the normalized model and then mapped / ETL'd into a database created from the denormalized model.

Please be invited to weigh in.

What is Data Governance?

Since Data Governance was introduced as a term, a variety of definitions has emerged which has caused contradictory interpretations and understanding of its meaning. Some people use Data Governance as a synonym for Data Quality, others believe it is something complementary. A third group considers Data Governance to be similar to Data Management...

Inspired by recent discussions, I like to offer the definition I refer to during my projects:

Data Governance is an organization's practice, based on documented policies and standards, to accomplish and maintain

• Data Regulation Compliance
• Data Strategy Compliance
• Data Security
• Data Quality

while applying the principles of Economy.

Data Regulation Compliance is the goal to comply with international and national laws and standards as well as with industry-specific regulatory requirements related to an organization's data.

Data Strategy Compliance is the goal to comply with (additional) data-related strategic and tactical directives which have been defined and issued by the organization's executive level and/or a line of business' management.

Data Security is the targeted degree of protecting the organization's data from corruption, theft, loss and unauthorized access.

Data Quality is the targeted degree of availability, provenance traceability, completeness, conformity, validity, correctness, consistency and timeliness of data that make it suitable for the organization's purpose of use.

Applying the principles of Economy means to accomplish and maintain the aforementioned targets with the highest possible return-on-investment (ROI), respectively, with the lowest cost (particularly considering the cost of inaction (COI)).

 

Please be invited to weigh in.

Who Is Responsible for Master Data?

Most organizations are run based on the assumption that their business can be hierarchically structured with well-defined exclusive tasks and responsibilities – so if everyone “minds his business”, the organization as a whole will do well. At some point in history, when the benefits of information technology were discovered, the IT department was added to the org-chart, and one after the other operational department began to use IT’s service to automate “their” business. The natural result over the years: a siloed application structure.

Now that the benefits of sharing and shared information such as Master Data have become obvious, organizations realize that neither their departmental nor their application structure is made for sharing: Master Data either has too many “masters” (having the right to modify it, e.g. Sales, Customer Service, Order Processing, Accounting) or none (when it comes to the responsibility to maintain its quality (completeness, cleanliness, integrity etc.))

Since IT as the common information service unit “has all the data”, it comes to no surprise that very often they initiate enterprise-wide tasks such as Master Data Management. However, IT is a service department, does not represent the business and does not have the business expertise in detail (otherwise IT could run the whole business alone). 

So who should be in charge of Master Data Management (and other topics related to shared information)? Given the limitations of the endeavor to succeed in a hierarchical world, given all known negative effects related to shared responsibilities, all eyes need to turn on the one and only that represents the business as a whole - the CEO. Yes, this endeavor is “Chefsache” (My apologies for the German expression, but apparently there is no term in the English language that expresses the same intensity of engagement in one word).

“Chefsache” includes

• CEO’s executive sponsorship
• CEO’s complete understanding, full consent, active driving and regular status check (which is more than just “buy-in”)
• Alignment of all CxOs on this common target
• Creation of a permanent (as this endeavor is a program, not a project) organizational unit with the head of this unit directly reporting to the CEO.

This newly created organizational unit will own the Master Data (primarily Master Data belonging to the domains "Party" and "Location") and be responsible for Master Data Management, i.e.

• Define the business data models for Master Data (and related business functions / rules!)
• Conceive and evaluate (later: own and conceptually maintain) the Master Data Management solution
• License the right to create / update Master Data to other organizational units
• Create / update reference data (i.e. third-party data that is important for the business, e.g. currency codes, country codes, tax rates)
• Check and maintain the quality of shared data in regular service intervals (e.g. integrity verifications, cleansing)
• Represent Master Data Management in related projects

Please be invited to weigh in.