An important part of implementing Master Data Management (MDM) is to capture the business rules that exists within the implementing organization and build those rules into the solution. In addition, and maybe even more important, is the quest of crafting new business rules that helps making master data being of more value to the implementing organization.
Examples of such new business rules that may come along with MDM implementations are:
- In order to open a business account you must supply a valid Legal Entity Identifier (like Company Registration Number, VAT number or whatever applies to the business and geography in question)
- A delivery address must be verified against an address directory (valid for the geography in question)
- In order to bring a product into business there is a minimum requirement for completeness of product information.
Creating new business rules to be part of the to-be master data regime highlights the interdependency of people, process and technology. New technology can often be the driver for taking on board such new business rules. Building on the above examples such possibilities may be:
- The ability to support real time pick and check of external identifiers
- The ability to support real time auto completion and check of postal addresses
- The ability to support complex completeness checks of a range of data elements
Multi-Domain MDM, Santa Style, is the title of a post on this blog made a couple of years ago. This post was about how a multi-domain Master Data Management solution could look like in an organization doing business as we think Santa Claus do.
Many organizations around the world who has recently embraced Master Data Management (MDM) has added Data Governance as an imperative parallel or integrated initiative. I guess Santa could have followed that path too.
Below are some thoughts about data governance considerations at the Santa Claus place based on a concept from The Data Governance Institute mentioned in the post Data Governance: Day 2:
What does it mean to be naughty or nice? I guess that must be a key question faced by Santa and his team every day. Santa is probably in no better position here than your are in many real world organizations. It is challenging to document key principles that everyone refer to every day as it turns really hard when you try to put them in a common shared business glossary.
Is Santa able to implement data governance based on the roles that the elves and the reindeers have had in daily operations around Christmas or does he have to ask Rudolph to head up a Data Governance Office or even become Chief Data Officer?
Reactive Issue Resolution
What should Santa do when the logistic elves insist on chimney positions in UTM and the reindeers can only use WGS84 coordinates? If Santa’s data governance programme does not solve this one you better watch out when Santa Claus is coming to Town.
I guess this is the time for blog posts about big things that is going to happen in 2015. But you see, we could also take a route away from the motorways and highways and see how the traditional way of life is still unfolding the data quality landscape.
While the innovators and early adopters are fighting with big data quality the late majority are still trying get the heads around how to manage small data. And that is a good thing, because you cannot utilize big data without solving small data quality problems not at least around master data as told in the post How important is big data quality?
Solving data quality problems is not just about fixing data. It is very much also about fixing the structures around data as explained in a post, featuring the pope, called When Bad Data Quality isn’t Bad Data.
A common roadblock on the way to solving data quality issues is that things that what are everybody’s problem tends to be no ones problem. Implementing a data governance programme is evolving as the answer to that conundrum. As many things in life data governance is about to think big and start small as told in the post Business Glossary to Full-Blown Metadata Management or Vice Versa.
Data governance revolves a lot around peoples roles and there are also some specific roles within data governance. Data owners have been known for a long time, data stewards have been around some time and now we also see Chief Data Officers emerge as examined in the post The Good, the Bad, and the Ugly Data Governance Role.
As experienced recently, somewhere in the countryside, while discussing how to get going with a big and shiny data governance programme there is however indeed still a lot to do with trivial data quality issues as fields being too short to capture the real world as reported in the post Everyday Year 2000 Problems.
Working with data governance and data quality can be a very backward looking quest. It often revolves around how to avoid a recent data disaster or catching up with the organizational issues, the process orchestration and new technology implementations needed to support current business objectives with current data types in a better way.
This may be hard enough. But you must also be prepared for the future.
The growth of available data to support your business is a challenge today. Your competitors take advantage of new data sources and better exploitation of known data sources while you are sleeping. New competitors emerge with business ideas based on new ways of using data.
The approach to inclusion of new data sources, data entities, data attributes and digital assets must be a part of your data governance framework and data quality capability. If you are not prepared for this, your current data quality will not only be challenged by decay of current data elements but also of not sufficiently governed new data elements or lack of business agility because you can’t include new data sources and elements in a safe way.
Some essentials in being prepared for inclusion of new kinds of data are:
- A living business glossary that facilitates a shared understanding of new data elements within your organization including how they relate to or replaces current data elements.
- Configurable data quality measurement facilities, data profiling functionality and data matching tools so on-boarding every new data element doesn’t require a new data quality project.
- Self-service and automation being the norm for data capture and data consumption. Self-service must be governed both internally in your organization and externally as explained in the post Data Governance in the Self-Service Age.
Much of the talking and writing about data governance these days is about how to start a data governance programme. This includes the roadmap, funding, getting stakeholders interested and that kind of stuff. Focussing on how to get a data governance programme off the ground is natural, as this is the struggle right now in many organizations.
But hopefully when, and not if, the data governance programme has left the ground and is a reality, what does the daily life look like then? I think this drawing can be a good illustration:
The drawing is taken from the Data Governance Institute Framework provided by Gwen Thomas.
As a fan of agile approaches within most disciplines including data governance, it is worth remarking that the daily life should not be seen as an end result of a long implementation. It should certainly be seen as the above concept being upgraded over time in more and more mature versions probably starting with a very basic version addressing main pain points within your organization.
When starting a data governance programme there is typically a lot of existing business rules to be documented in a consistent way. That is one thing. Another thing is to establish the process that deals with data aspects of changing business rules and taking on new business rules as touched in the post Two Kinds of Business Rules within Data Governance.
The ongoing service and the issue resolution part is very much relying on some kind of organizational structure. This could include one of my favourites being collaboration fora between data stewards, maybe a data governance office and usually a data governance council of some name. And perhaps having a Chief Data Officer (CDO) as mentioned in post The Good, the Bad, and the Ugly Data Governance Role.
Dear fellow data governance practitioner. Unless you work in the United States, where today is a day off because of thanksgiving, you are supposed to create business value today.
Data governance is about creating business value. Like everything else going on at a workplace. It should be needless to say so. So therefore there is no reason to read a recent Jim Harris blog post called Data needs a Copernican Revolution.
Actually, I don’t think the problem for people working with data governance is understanding the need of creating business value. The problem is knowing how to prove business value. One way of doing this is requesting guidance for that. Actually, you can do that on Nicola Askham’s blog right here.
A very common starting point for producing tangible outcomes in a data governance programme is setting up a business glossary. The alternatives, or next/previous steps, for a business glossary were discussed in the post Metadata Musings by a Nerd.
First, in my eyes a business glossary (or whatever you call such a thing) is indeed a useful deliverable in its own right. In order to support a data governance programme you will need to add things besides definition of terms. One important element is documenting business rules as reported by Nikki Rogers at The University of Bristol here.
A business glossary should ultimately morph into full-blown metadata management or meet data dictionary and/or metadata repository initiatives that also may grow in your organization. What full-blown metadata management means was touched recently by Brian Brewer in a blog post called Gartner Says More Metadata. This post cites a blog post by Darin Stewart of Gartner (the analyst firm). The Gartner post is called Big Content Needs More Metadata.
How did you develop your business glossary?
- Did you start with a business glossary and then morphed into the data dictionary and metadata management discipline and lingo?
- Did the business glossary grow from the metadata management work?
- Is the business glossary just sitting there doing what it does?
We all know the problem: We use the same term, but means two different things. Or: We use two different terms, but actually mean the same thing.
Within data management this is a huge challenge. The solution is ….. Well, there are different terms:
Business Glossary is one term. The term is explained in an artcle on B-eye-Network by Lowell Fryman here. Using the term business glossary implies that you have a business approach to the issue. Implementing a business glossary is often mentioned as a part of a data governance framework.
Data Dictionary is explained on Wikipedia here. Using the term data dictionary implies that you have a technical approach to the issue. Having a data dictionary is sometimes mentioned as a part of a Master Data Management (MDM) solution.
Metadata Repository is also explained on Wikipedia here. Using the term metadata repository implies that you have a somewhat nerdish approach to the subject as seen in the post Metadata Meatballs. Addressing metadata is often stated as an important subject within the data quality discipline as shown in the post Perfect Wrong Answer.
Multi-Domain Master Data Management (MDM) is about dealing with master data in several different data domains as customer (or party), product, location, asset or calendar. The typical track today is starting in one domain. There are many, even contradicting, good reasons for that.
Depending on in what industry vertical you are the main pain points that urges you to start doing MDM belongs to either of the MDM domains. Customer MDM is the most common one typically seen where you have a large number of customer records in your databases. We see starting with product MDM in organizations with many products in the databases. This is for example the case for large retailers and distributors.
It can be other domains as well. One example from a MDM conference I recall is that Royal Mail in the UK started with the calendar domain. Besides that this domain had pain points for that organization a reason to do that was to start small before taking on the big chunks.
Even though you start with one domain, you must think about the end state. One thing to consider multi-domain wise is the data governance part, as you will not come out well if you choose different approaches to data governance for each master data domain. Of course, the technology part is there too. Choosing a solution that eventually will take you all the way is appealing to many organizations looking for a MDM platform.
Another approach to multi-domain MDM can be through what I know at least one MDM tool vendor calls Evolutionary MDM™. But we can call it other things. Agile or lean MDM for example. Using that approach you do not solve everything within one domain before going on to the next one.
It is about eliminating as many pain points as possible in the shortest feasible time-frame.
Back in 2010 I played around with the term Data Quality 3.0. This concept is about how we increasingly use external data within data management opposite to the traditional use of internal data, which are data that has been typed into our databases by employees or has been internally collected in other ways.
The rise of big data has definitely fueled the thinking around using external data as reported in the post Adding 180 Degrees to MDM.
There are other internal and external aspects for example internal and external business rules as examined in the post Two Kinds of Business Rules within Data Governance. This post has been discussed in the Data Governance Know How group on LinkedIn.
In a comment Thomas Tong says:
“It’s really fun when the internal components of governance are running smooth, giving the opportunity to focus on external connections to your data governance program. Finding the right balance between internal and external influences is key, as external governance partners can reduce the load/complexity of your overall governance program. It also helps clarify the difference between a “external standard” vs “internal standard”, as well as what is “reference data” vs “master data”… and a little preview of your probable integration strategy with external.”
This resonates very much with my mindset. Since 2010 my own data quality journey has increasingly embraced Master Data Management (MDM) and Data Governance as told in the recent blog post called Data Governance, Data Quality and MDM.
So, in my quest to coin these 3 disciplines into one term I, besides the word information, also may put 3.0 into the naming: “Information Quality 3.0”, hmmm …..