Okay so I've spent a while in the last 10+ years on various MDM (Master Data Management) programmes and its come down to a very simple reason why lots of MDM programmes fail..
People screw up MDM programmes by forgetting what MDM actually is.The first bit is that people look at the various different MDM packages and then really miss the point. Whether its Oracle UCM, Informatica, SAP MDM, IBM MDM, Initiate, TIBCO or anything else people look at it and go...
Right so this is what we do, what else can we fit into itNow this is a stupid way to behave but its what most people do. The use the MDM piece as the starting point. The reality is that MDM is only about two things
- The cross references of the core entity between all the systems in the IT estate
- The data quality and governance around the core entity to uplift its business value
And that really is it. The more attributes that are added beyond the those required for these two elements then the more expensive and more complex and less effective your MDM solution will be.
The other core part of this is that there really are only a very limited number of bits to MDM, its about three things
- Things - assets, accounts, parts, products, etc
- Parties - individuals, organisations, customers, suppliers, etc
- Locations - postal addresses, email address, web addresses, physical address, geo locations, etc
That really is it from an entity perspective then you've got the relationships for those entities (and remember a relationship is just the keys to do the match) which means
- Parties to Things
- Parties to Locations
- Things to Locations
- (Parties to Things) to Locations (e.g. a persons specific account address)
There really isn't much else to do it really is just
So why do people screw up?
Well first off is because they do something like picking a customer mastering package and then trying to master product information or product relationships within it (e.g. Asset to Location).
Secondly because they start extending the number of attributes rather than creating a cheap ODS.
Thirdly because they create their own versions of the relationships because of a belief that business rules that they have change the entity model rather than actually just being data quality rules against the standard entity model.
So the reality is that MDM is simple, its about the data quality and matching, which means its about the business governance of information.
And that is the real reason that most MDM programmes fail to deliver, because in order to get to the business governance of information and make MDM simple you have to do an awful lot of hard work in building up the trust between the business areas and IT that governance can be done in a way that benefits rather than impacts business.
MDM isn't a technology solution its a simple business solution, the problem is that IT people tend to make it a complex IT solution because they can't make it a simple business solution.
Technorati Tags: SOA, Service Architecture
9 comments:
Steve - I agree w/ almost everything you state, and appreciate your laser focus on the issue. Might I suggest another core responsibility of MDM? that would be that it's responsible for determining the uniqueness of the master entity, returning an authoritative "record" of a party, location or thing. That's really goal #1 from a business perspective, and it does this by accomplishing your job #1, building a cross-reference. But determining and managing uniqueness is the higher-order goal, I believe. Yes, it is the implementation of a policy from a data governance perspective, but it's not the policy itself.
Also, I love the fact that you call out the human tendency to add on all sorts of additional attributes and responsibilities, but here's one use case that I actually agree with: sometimes, when you now have this "master" view of your parties, places and things (as well as interrelationships), you want to attach new attributes that don't seem to live anywhere else. In commercial examples, you might want to create "lifetime value" on a party who happens to be a customer. But there's no other logical place to put that, since a) the other systems that not easily modified, b) they're vanilla and under strict rules not to modify them, c) the users who calculate lifetime value don't use the most logical system or d) the logical system only has a small subset of the data and cannot /will not manage the hundreds of millions of rows of data required to create the "one identity" for the master entity. In those cases, it might be easier to let the master data service manage those few attributes.
Btw, it was for these reasons, as well as the proper positioning of an MDM solution in an enterprise software stack as a service, that I renamed our product the Initiate Master Data Service, when I joined Initiate as CTO back in 2007. Since then I've written and blogged about your very point many times.
Keep it coming!!!
Marty I agree, my point is exactly that, uniqueness is indeed the thing and that is the x-ref....
BUT
Lifetime value is an ODS thing not an MDM thing, so sure you could tack them onto the MDM piece but wouldn't it be better to develop a lightweight ODS approach which allied to MDM and considers federated information as its base... there could be a product in that ;)
Great post Steve. Thank you for pointing out how important people are in MDM. We have a community for IM professionals (www.openmethodology.org) and have bookmarked this post for our users. Look forward to reading your work in the future.
Steve. Good article. I like the simplicity of it.
But what about events? Are they "things" or a separate entity?
Things you can think of (in your example of assets) are malfunctions of assets or maintenance actions performed by a mechanic on an asset.
Events as it the types are just things and they have relationships in the same way.
Hi Steve,
I enjoyed your article, I agree with most of the things you state and the good diagram, I am currently tasked with an MDM project for a Provincial Government where I have more than 500+ silos applications.
I have looked at Tibco,SAP MDM,Oracle AIA, Kalido MDM etc can I ask How do you work with PartyRole and RolePlayers in terms of Government, as you might have a Person as an Employee/Patient/Criminal/Manager/Parent/Child/Trainer/ etc at the same time the person is involved in more than one Organization as CEO,CIO etc that can be a parent of other Organizations etc how can one deal with those type of relationships
tnx
Themba,
This is exactly why you should use a Party model as what you are saying is that there is a single Individual but they are playing a number of different roles. Now some of these roles will have additional information so you may have a structure of
Individual which has children of employee, patient, criminal etc and identify at the individual level and create additional child identification records as required.
Alternatively you can consider employee, patient, criminal etc as being unique pieces of identification but have a party-to-party relationship of 'is' between so someone can be the CEO of the company and a customer and have to separate identity records linked by an 'is' relationship
Interesting perspectives and no right or wrong answer from my perspective. One should always factor in cost of integration into the equation regardless of location of storage (ODS vs MDM). Get data into the hands of the people that care about it, that is the only way to drive the quality discussion and if its better served to those users via an MDM hub then maybe thats the best answer…..waiting for a bunch of database people to perform quality on attributes can be expensive.
I agree with getting the data into hands but the challenge of using an MDM tool as an ODS is that its a VERY expensive overkill to try and add some quality.
My experience is that you are better off getting the core Master Data really good than trying to be slightly reasonable across a broad set of attributes. As people see what good quality master data brings they begin to see the value in investing in quality elsewhere.
Be great at the core... you'll fail if you try to be great at everything.
Post a Comment