One reason for the lack of new posts here is that I’ve been attempting to write my first article for the Mastering Data Management blog. After several false starts, and falling back to old school pencil and paper to finally get going, it’s finally done! So, for anyone interested in master data management, here is the very latest Mastering Data Management front page hot off the press:
If you’ve visited any developerWorks spaces recently, you’ll have noticed there’s been a bit of a change; the old spaces application has been sunset. All is not lost though, and redirects are in place for the various new homes for old spaces, including the MDM Workbench space.
Instead of just migrating from spaces to a group on My developerWorks, I took the chance to open it up to a wider community of MDM Developers. While I do miss some of the features of the old spaces, one big advantage of the new group is that it’s much easier for anyone to participate.
Apart migrating information from the old MDM Workbench space, most of the activity in the group so far has been new people joining, which is a great start. I’m also looking forward seeing who the first person to add a new bookmark or feed will be. (I’m almost tempted to have another little competition to encourage people with a much prized Hursley postcard, just for a bit of fun!)
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)
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.
Back from first day at that MDM Summit Europe, so a few rough and ready notes I scribbled down along the way. (Might return to tidy them up later in the week… or perhaps not!)
First up was the keynote from conference chairman Aaron Zornes. The first thing that grabbed my attention was the need for flexibility in mashing up data… yep, mash-up. I’d already been pondering how mash-ups could apply to MDM in light of recent Lotus Mashups and my new job. It was also interesting to note that MDM could be the first experience of SOA for a company. SOA was mentioned a couple of times through the day as being a big help for MDM technology.
Second up was David Corrigan who did a good job talking about trends in MDM rather than specific details on IBM products. He touched on the danger of building silos of master data, and there was some hint of this in some of the other sessions I went to. Something I hadn’t heard before was the goal to have the right view of data, not simply a single view of data. (Quick show of hands shows that the audience is largely from IT not business side.) Good news for my new job is that MDM user interfaces are among the five key product requirements. His biggest sales pitch for IBM was the large established client community that already exists for IBM MDM products. One example being PostFinance and Jochen Schneider described their project. I guess more of them might be found at the British Library for IOD UK tomorrow.
Last keynote was from Colin Richard who talked about data governance. As he predicted, “Data Quality Firewall” stood out as a new meme here! (That’s not all he said but it was hard to remember the rest after that great phrase!)
Next up I chose Ed Wrazen’s industry innovation session. He mentioned a growing spreadsheet mentality in business and, here’s that word again, a desire to mash up data from different systems because it takes IT too long to make changes to production infrastructure. Hmmm, spreadsheets2.0?
I started the afternoon on track 2 with Tony Richardson’s presentation about ContactPoint. This is master data on a national scale. Web services seem to be a key component, allowing end users to carry on using the systems they are familiar with, just now equipped with an interface to ContactPoint. He also mentioned the security aspects but disappointingly didn’t go into them in any detail. In contrast with prereqs mentioned elsewhere, a feature of ContactPoint was that there were no reliable unique identifiers.
Next up in track 2 was a panel on best practices in government services. Kathy Watts, Ian Cohen and Tony Ellis answered questions from the audience on linking data governance with MDM, problems and how to secure business sponsorship.
For a bit of variety I switched to Kimi Walker and Kjell Wittmaack talking about MDM in large enterprises in track 3. Another mention of data in spreadsheets- I see a pattern emerging! They showed a bit more detail on some possible metrics to build a business case for MDM. The data owners and roles were interesting, especially the acknowledgment that there needed to be well defined paths to escalate problems- a single owner could not know everything about data that has homes across the business.
And finally, for today at least, another IBM customer. Peter Stocker and Paul Theriault tackled tactical problems to strategic solutions. Project management 101 was a reminder that MDM should primarily be a business journey. Indeed, referring to MDM could be counter productive if the business perception is hostile to “IT science projects.” Focusing on a sound business case for short term payback means they can stop after solving an immediate problem, but they have paved the way to build out the MDM vision if the business supports future projects.