Master Data Management links: August

Another random selection of MDM related links, this time all turning up in my inbox at about the same time. The first one is from a five part series on SearchSOA.com which reminded me of earlier musings on the relationship between MDM and SOA:

• SOA with MDM prevents messaging confusion

The definition of MDM still seems to me to be quite subjective, with subtle differences depending on who you talk to. (Someone I know rather unkindly suggests it’s just a glorified database!) The next two links both have something to say about what problems MDM is trying to address:

• Is smart DM an alternative to MDM?
• Can you “do” MDM without data quality?

What’s the best definition/example of MDM you’ve seen?

And finally, now seems like a good time to mention the Information on Demand conference. As well as meeting people with real world experience of this kind of thing, there are technical sessions for the MDM Workbench which is what I actually work on.

Advertisement

Are SOA and MDM inseparable?

Reading “MDM and SOA, a Strong Partnership” on the Hub Solution Designs blog reminded me that it was about time I rescued this post from the depths of my collection of drafts.

To be useful, services must at some point deal with information, whether that’s product information, account information, a customer record or something else that is of interest to your business. It doesn’t take too long when you look at even the most basic web service examples before you spot something like ‘getCustomer’. You don’t need to look far; this post about RESTful services has account as well as customer for example.

Of course, if you aren’t writing this web service for a brand new company, the obvious question is where is the information about the customer going to come from? If you don’t consider master data management before taking the plunge with SOA, you’ll either end up with defacto master data appearing in an add hoc way, possibly based on the order services are exposed without any thought about data quality, or a whole bunch of conflicting data from duplicated services. It’s not a one way street either, master data management systems are easier with service oriented approaches.

Here’s what a few others have to say on the subject:

• SOA and MDM: Two Integration Solutions That Go Great Together?
• Master Data Management and Service-Oriented Architecture
• Master Data Management Paves the Way for SOA

Update: I read New trends in Enterprise Software Enterprise 2.0 and MDM today which also has quite a nice introduction to how MDM and SOA are related. (14 April 2009)

Master Data Management Summit Day 2

Day two of the MDM summit was good but in many ways a consolidation of the messages from day one so rather than breaking down the points in to individual sessions, here’s a quick selection of things that made it on to my notepad, in no particular order. (Thanks to these speakers: Aaron Zornes, Cliff Longman, Sean Cassidy, Dileep Srinivasan, Simon Slocombe, Tony Ellis, Holger Wandt, Carsten Kraus, Colin Rickard, Kathy Hunter, Ed Wrazen and Brian Amo.)

Storing data is not the same as mastering it. You don’t have to slavishly master all data. Can have payload data along with master data.

Top ten MDM evaluation criteria includes developer productivity, which is something I’ve indirectly blogged about before. Time to value is important.

The presenters really don’t like people in business using spreadsheets to hold data! Should have kept a tally of how often this came up.

What risks can you reduce if you trust the data? What new risks might you be willing to take?

MDM isn’t a silver bullet for fragmentation. MDM projects are currently concentrated within departments, lines of business or geographies, with localised implementations. Companies could end up with several ‘single’ versions of the truth! Even if that wasn’t the case, companies with their own MDM hubs are going to start merging sooner or later.

These questions can be useful to uncover data ownership and escalation paths… What is it? How do you know when it’s wrong? What do you do when it’s wrong?

MDM is not really new. The problems are definitely not new. MDM is as much about the business processes around data as the technology, which is largely existing technology packaged in a new way.

Just discovered this post hiding in my pile of drafts, so before it makes itself at home there, I’m kicking it out, warts and all.

I’m also signing up to the Yahoo Master Data Management group to continue the quest to master MDM.