Tuesday, June 27, 2006

Classifying MDM products

In his article on the IBM MDM conference Philip Howard makes the distinction between different MDM approaches, which is useful but I feel does not go quite far enough. As he says, at one extreme you have "hubs" where you actually store (say) customer data, and hope that this is treated as the master source of such data (a non trivial project then usually ensues). At the other end you have a registry, which just lists the various places where master data is stored and maps the links to the applications which act as the master, and a repository, which goes further in picking out what he calls the "best record" and is sometimes called the "golden copy" of data. The distinction between a repository and a regiistry is a subtle one which Bloor makes. I feel that there are other aspects which are useful to categorize though, beyond just the storage mechanism. Some MDM products are clearly intended for machine to machine interaction, synchronizing master data from a hub back to other systems e.g. DWL (now bought by IBM). However there are other products which focus on the management of the workflow around master data (managing drafts, authorizing changes, publishing a golden copy etc), and so deal more with human interaction around master data. Kalido MDM is one example of the latter. This is another dimension which it is useful to classify tools by, since a customer need for synchronized customer name and address records between operational systems is very different from workflow management.

The article notes that IBM does not score well in the recent Bloor report on MDM, but hopes for better things in the future. Certainly IBM did something of a shopping spree once they decided to tackle MDM, and bought a PIM product, a CDI product and a few others while they were at it, so it is perhaps not surprising that it is difficult to see an overall strategy. I absolutely concur with Philip Howard in that MDM needs to be treated as an overall subject and not artificially segmented by technologies that deal with product, customer or whatever. In one project at BP we manage 350 different types of master data, and it is hard to see why a customer can reasonably be expected to buy 348 more technologies to go beyond product and customer. This example illustrates the absurdity of the technology per data type approach which is surprisingly common amongst vendors.

Software is hard to rearchitect, and customers should always look carefully at vendor claims of some overall gloss on top of multiple products, compared to something which was designed to handle master data in a generic fashion in the first place.


Post a Comment

<< Home