Feeds

Mixed messages for master data management

IBM conference breakdown

Securing Web Applications Made Simple and Scalable

Opinion IBM's first European user conference on MDM (master data management) in Barcelona was certainly interesting, but I felt that the results were mixed.

For example, some users clearly felt the conference was useful, while others were disappointed. One investment bank I talked to felt the content was insufficiently technical and, in particular, that it did not address either scalability issues or the complex, heterogeneous environments which most companies have to manage. Still, I suppose you can't please everybody all of the time.

Another criticism I heard from several attendees was that the Gartner analyst who was supposed to set a framework for the conference was speaking at the end of the first day rather than the beginning.

I had rather more serious reservations about this particular presentation as I disagree with his segmentation of the market, and did not feel that a sufficient distinction was made between MDM on the one hand and instances of MDM such as CDI (customer data integration), GSM (global supplier management) and PIM (product information management) on the other.

I will start with this second issue. To me, CDI, PIM and the like are subsets of master data management (MDM). MDM is, essentially, non domain-specific. There are two reasons why this is important. The first is that if vendors, users, pundits et al continue to treat CDI, GSM and similar applications as separate and distinct then we will end up with exactly the same siloed applications that have been the bane of IT for the last two decades.

Suppose, for example, that you want to implement a master data management solution for SLAs (service level agreements). That would involve a customer, a supplier, various services, a contract and metrics. In other words, such an application would span multiple master data domains, some of which are about people (customers, suppliers) and some of which are about things (services, the contract itself, metrics).

If we make the assumption that existing CDI solutions can be easily extended to support suppliers and that PIM solutions can encompass contracts and services (there seems to be a consensus that PIM and CDI require significantly different capabilities) then what we don't want to have to do is to build an application that has to span two different systems, putting us straight back into the EAI (enterprise application integration) stuff that we'd rather avoid.

So, given that "people" and "things" are distinct, what is needed is a common set of services that support as much as possible of these in a single platform, with only a very specific and minimised set of differentiated capabilities on top of the platform that relate to CDI, PIM or whatever. This platform then becomes the MDM base upon which application instances are implemented.

As far as how you break down the market is concerned, I felt that the model presented was too simplistic. In our view, there are three approaches that you might take: a registry, which is where you have a reference mapping to the various participating applications; a repository, where you extend the registry by including a mapping to the elements that make up the "best record"; and a hub, where the best record is actually held within the hub. This contrasts with the model that was presented, which only differentiated between hubs (albeit with sub-classes) and registries. A more detailed discussion of our approach is included in Harriet Fryman's recently published MDM Report.

The speaker at the conference spent very little time discussing registries, but the importance of registries and repositories is that they are much less disruptive (and less expensive) to implement. For example, Purisma claims a typical implementation time of just four to six weeks compared to the months, or even years, that you might take over a hub. The scalability issues referred to above also go away.

It is our belief that what users would really like is a way to start with a registry (or repository) and the ability to migrate, progressively, to more complex implementations.

Copyright © 2006, IT-Analysis.com

Bridging the IT gap between rising business demands and ageing tools

More from The Register

next story
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
KDE releases ice-cream coloured Plasma 5 just in time for summer
Melty but refreshing - popular rival to Mint's Cinnamon's still a work in progress
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Another day, another Firefox: Version 31 is upon us ALREADY
Web devs, Mozilla really wants you to like this one
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
prev story

Whitepapers

Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Seven Steps to Software Security
Seven practical steps you can begin to take today to secure your applications and prevent the damages a successful cyber-attack can cause.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.