There is a unified pricing model behind these editions, though this apparent step forward is rather handicapped by the pricing model being distinctly opaque. It is based on no less than four parameters: edition, industry, data domains being managed and how many records are being mastered. When something becomes this complex it gives the sales force considerable flexibility (presumably the intention) but is potentially confusing for the customers, and possibly IBM’s own staff.

Fortunately, as well as this partial step forward on the marketing side, there is some actual code in the release. The Initiate matching engine, which was well regarded, is now used across the product line for probabilistic matching (the old Quality Stage approach is still available fro deterministic matching). The workflow engine BPM Express is bundled in with the enterprise edition, meaning that very complex sets of workflow and permissions can now be handled, if need be in a real-time manner. There is a much-needed overhaul of the old PIM user interlace in the new Collaborative Edition. Other enhancements are present, such as integration with the Guardium Data Activity Monitor.

All this amounts to a significant release that at least starts IBM on a path to unifying its MDM technologies. This will be a long path, as there are still three underlying, different, server technologies here. However at least customers now have a sense of the MDM direction in which IBM is heading now even if they need to realise that it will be a long and winding road before they get there.

I will be participating in a series of MDM-related talks in this region in August, starting in Mumbai, then moving on to Singapore, Hong Kong and Beijing, then Melbourne and Australia. The topic is “customer centricity” and how MDM can help build up a better view of the customer. This is a major headache for most enterprises, who usually have multiple competing systems holding customer data (an average of six systems according to an Information Difference survey, with some companies having over 100 systems holding customer data). On a project in Australia that I was involved with some years ago one company thought that it had 25,000 customers. After a project to rationalise and combine the various systems holding customer data the true figure turned out to be just 5,000 – a huge difference.

Understanding customer profitability is important. In one project at a US manufacturer I was involved with, a careful review of the cost allocation process revealed that a significant proportion of contracts with customers were in fact loss-making to the corporation. What was worse was that many of these were larger contracts, where customers had demanded, and received, large discounts due to their scale. Following this review a number of contracts were re-negotiated, paying for the cost of the master data project within months.

It can be seen that getting control of your customer data is important and can yield significant monetary benefits.

The forum focuses on improving customer data. It is hosted by Informatica and sponsored by Capgemini. The detailed schedule and how to register can be found here:

http://au.vip.informatica.com/?elqPURLPage=9107

If you are in the region and are free on one of these dates, then I hope to see you there.

I am curious as to whether MDM will merely follow the contours of this conventional technology adoption pattern, or whether it will be different, which it may be since a key difference is that MDM requires more significant business engagement than many technologies. For example I was speaking at a conference in Sweden last week and was a little surprised at how new MDM appeared to be in a country that is generally an early adopter of technology. I am curious as to whether MDM practitioners have noticed any cultural differences in the way that MDM is being tackled? If so please post a comment of your views on this blog.

http://ecm.elearningcurve.com/Andy_Hayler_s/72.htm

will do the job, and of course there are alternatives. I was most amused by the conversation with one recruitment person, who has been asked by a big systems integrator to urgently recruit experienced MDM consultants in order to populate a project that they have apparently already sold to an unsuspecting client. I am guessing their pitch to the client was not “We have no idea what this MDM thing is, let alone any experience in it, but if you give us a load of money we’ll definitely try and hire someone who does”. Or in this case hire someone else who doesn’t know what it means to find someone who might do and may know someone who does.

Don’t you just love the world of consultancy?

Andy

Join me for a webinar this Wednesday (at 11 EST = 16:00 UK time) on how to build the business case for an MDM project. It contains lots of practical information to make a proper business case, including data from our latest research e.g. on how much MDM projects cost to maintain once live.

You can register for it here:

http://register.mdmdqu.com/forms/MDMDQURegistrationForm

It is even free!

http://www.debtechint.com/dg2010/

which this year is in the attractive setting of San Diego (the place with perhaps the best climate in the USA). Naturally as a conference delegate you will be influenced solely by the agenda and the speaker quality rather than the prospect of a sunny location, but I just thought I’d mention it.

There will be some excellent speakers, and also me giving the keynote. As a reader of this blog I am happy to offer you a discount should you be able to attend. Just quote the following code when booking: IDDG100 – please be aware that this code expires on May 7th.

Yet there is a considerable source of rules that are obscured from view. Some are tied up within business applications, while there is another class that are also opaque: those locked up within extract/transform/load ETL rules, usually in the form of procedural scripts. If several source files need to be merged, for example to load into a data warehouse, then the logic which defines what transformations occur are important rules in their own right. Certainly they are subject to change, since source systems sometimes undergo format changes, for example if a commercial package is upgraded. Yet these rules are usually embedded within procedural code, or at best within the metadata repository of a commercial ETL tool. Mike’s article proposes a repository that would keep track of the applications, data elements and interfaces involved, the idea being to get the rules as (readable) data rather than buried away in code.

The article raises an important issue: rules of all kinds concerning data should ideally be held as data and so be accessible, yet ETL rules in particular tend not to be. It is beyond the scope of the article, but for me there is a question of how the various sources of business rules: ETL repository, MDM repository, data quality repository, database catalogs etc can be linked together so that a complete picture of the business rules can be seen. Those with long memories will recall old fashioned data dictionaries, which tried to perform this role, but which mostly died out since they were always essentially passive copies of the rules in other systems, and so easily became out of data. Yet the current trend towards managing master data actively raises questions about just what the scope of data rules should be, and where they should be stored. Application vendors, MDM vendors, data quality vendors, ETL vendors and database vendors will each have their own perspective, and will inevitable will each seek to control as much of the metadata landscape as they can, since ownership of this level of data will be a powerful position to be in.

From an end user perspective what you really want is for all such rules to be stored as data, and for some mechanism to access the various repositories and formats in a seamless way, so that a complete perspective of enterprise data becomes possible. This desire may not necessarily be shared by all vendors, for whom control of business metadata is power. An opportunity for someone?

Large companies have hundreds of applications, even after they have finished implementing an ERP system (and then re-implementing it to reduce the number of ERP instances). One company I work with owns up to 600 applications, another to 3,500. In many cases data needs to be shared across applications, and of course the very fact of having so many systems can cause master data issues to occur, since each application frequently generates and maintains at least some master data that it needs rather than being fed such data by a consistent enterprise-wide master data repository.

One key difference between MDM hubs and a data warehouse is that a warehouse needs to have clean, pure data; this is achieved by an extensive process of data cleansing and validation that is conducted outside the warehouse prior to data being loaded, perhaps through a mix of data quality tools and ETL processing. Indeed one major issue is that in order to come up with high quality data for the warehouse, business rules end up being embedded in sometimes complex ETL scripts, which are opaque and hard to get business people to engage with. A good master data hub should be able to take on much of this burden of strong and managing business rules, and may be a more productive place to carry this out. For example it may be more effective to use probabilistic techniques to help determine matches angst potential data sources (say, multiple product masters) rather than needing to hard-code business rules, as usually happens with ETL scripts. If this is the case then you may be able to get away with a much smaller set of business rules in an MDM hub than were typically necessary in ETL scripts. In turn this reduction of complexity may be able to cause a lot of the maintenance effort needed in maintaining such scripts to be go away.

I have not seen any quantitative analysis out there of the relative productivity of MDM hubs v ETL processing for storing business rules, or the potential effect that this could have on the support effort needed to maintain interfaces. However it was always the case that a high proportion of overall support effort in an enterprise was associated with interfaces, so even a small effect here could have a significant saving in terms of IT costs. I think there is an opportunity here for someone to do some serious research into this area, getting hard data rather than making hand-waving benefits statements. If followed through, it would not surprise me to see this as an area where properly implemented MDM could have a significant effect on IT support costs. Given that so many people claim that making a business case for MDM is one of the biggest obstacles, this would seem to me a fruitful area of further research.

The course can be accessed here:

http://ecm.elearningcurve.com/The_MDM_Market_How_to_Select_a_Vendor_p/mdm-03-a.htm

Its price is what seems to me almost absurdly cheap (eLearning Curve is new and they are trying to promote things), but as a reader of this blog you can take advantage of a special offer as well. When buying the course just quote the following voucher code:

AHDisc11R

and you will get a further discount of 20% off the already amusingly low list price. Seriously, this is a real bargain. Over five hours of chunky, in-depth material, to absorb at your leisure.

As the old Derek Bok saying goes, if you think education is expensive, try ignorance.