Comments on: Can “single view” of master data be achieved without an MDM technology?

By: Vishal Puri

Vishal Puri — Fri, 06 Mar 2009 17:04:56 +0000

Andrew, In my experience the ultimate litmus test or any MDM architecture is its ability to provide a scalable data quality solution. Even without thinking through a whole lot, I can imagine the ESB based MDM solution wont be able to provide deduping capability online or offline, unless I have a clean separation of applications as (one single) master and slave(s) wrt a particular set of master data. Any other topology (highly likely) will force the ESB to maintain more intelligence and state than it really should.
It is the same litmus test against which pure federated/EII architectures fail when it comes to being extended for MDM. (BTW EII is a perfect example of a non ESB based registry implementation)
Regarding the bundling of a one big elephantile (i am copyrighting this word) solution that covers MDM and your aptly named “MMDM”, isnt something I would really like to see. Metadata management and model driven architectures should be generic capabilities with wide ranging applications across all data segments (master, analytical, transactional etc). Bundling them within an MDM product is only going to drive proprietary implementations, higher costs and integration problems when it comes to addressing other applications of metadata management

By: Andrew White

Andrew White — Wed, 25 Feb 2009 13:47:28 +0000

Omer, thanks again for the comment. I see why you made the connection between ESB and registry-based (style) of MDM. I agree that such a style is highly dependent on a working ESB/infrastructure. I would argue however that an ESB can be a critical element (or some such messaging capability) in almost any large-scale MDM implementation – independent of style. So while registry is critically dependent on it, the other styles may need it also. And to be clear (in case we were not), I think we agree that implementing an ESB is NOT the same as implementing registry based MDM, though they are closely related.

Regarding your question: there is a growing need for tools/solutions that manage “across MDM silos” or to be more precise, “master data stores” that may include one or two significant engines, and application oriented data stores that store (among other things) master data of some kind. Early adopters of MDM are now implementing their second, or third domain (product, customer, supplier, asset, location etc) and seeing that “interoperability” is needed between all data stores, and some management/governance capability “across” them. Though not entirely new, what is new is the collection of this stuff into one “solution”. It needs a hefty dose of metadata modeling, semantic modeling, analytics/metrics, workflow, rules, and so on. In fact, its a kind of “master-master data management” engine though not quite that. For this reason we will see an increasing need for what vendors will call, “governance applications” even though that sounds like an oxymoron.

By: Omer Farooque

Omer Farooque — Wed, 25 Feb 2009 07:10:12 +0000

From an implementation perspective – you really wouldn’t want to apply the registry based approach without employing an ESB – hence my reason for equating the two styles.
On your comment about metadata management – I would agree that it is a far better (albeit long term results oriented) approach. Interestingly we are finding that consuming or sharing metadata across the authoring application / product and design time / run time applications is not a given, even though all products / apps may follow standards/specifications like XML,CWM, MOF, etc – primarily because of how each vendor decides to leverage the extensions within the specification they adhere to. Our attempt at addressing this invariably involved establishing metadata inter-changes that could translate between products / applications that manage metadata. Surprisingly there is a lack of products that fit this capability – What kind of work are you seeing being done in this area?

By: Andrew White

Andrew White — Mon, 23 Feb 2009 22:45:20 +0000

Omar,
Thanks for leaving the comment. I agree with your views. However, I did want to explore one item that is less simple than it might look. You say, “on MDM – the technology and the relevance of an ESB / message based clearing house – which is very similar to (in-fact one of the possible implementations of) registry style of MDM implementations”. I would agree that an ESB based approach is close to a registry based MDM implementation style, but I do not think that they are the same. In fact, it is quite possible to implement an ESB and yet not achieve MDM; and it is possible to implement a registry based MDM style without an ESB (though hard to do). I don’t really look at ESB technology that much, but messaging models are really only part of the solution. Registry based MDM has a register, a link, a key, that maps source to recipient. That is much more than a message. Even those vendors with strong ESB architectures that talk of MDM maintain somewhere a map (you have to) even if it resides on an ESB. But I would not suggest to a user that they implement such a virtual MDM hub. It would be far better to use metadata management to do that than an ESB. What do you think?

By: Dan Nicollet

Dan Nicollet — Mon, 23 Feb 2009 22:39:01 +0000

Interesting. I second Farooke in that a messaging-based MDM system will undoubtedly fit better with newer enterprise applications that do not function in batch. Furthermore, the enormous overhead of such an approach seems quite contrary to the premise of enterprise automation: lowering risks and costs of doing business. Web Services and SOA based systems could work well with such a clearinghouse but even better and especially cheaper if they included a central MDM hub like Siperian…

By: Omer Farooque

Omer Farooque — Thu, 19 Feb 2009 19:47:43 +0000

The ability of client organizations to be able to actually achieve a single version of truth for any domain (Item, customer, vendor or location) they operate on is dependant on their ability to change “bad habits” or reform. The discipline (as you rightly called it) that is needed to achieve an MDM objective is often times in conflict with the customers “Standard Operating Procedures” – which would invariably involve getting what they want immediately at whatever costs (long or short term) – this in my experience advising clients and realizing MDM solutions at various customers is what dictates how successful the MDM initiative is going to be – its almost like getting on rehab after a prolonged addiction.
On MDM – the technology and the relevance of an ESB / message based clearing house – which is very similar to (in-fact one of the possible implementations of) registry style of MDM implementations – this is typically a good fit for customers that have either already on-ramped on a solid ESB / SOA enterprise wide initiative with their main application of concerned hooked into the ESB infrastructure and consequently also aligned to consuming / reacting to trickle feeds. Bear in mind most customer that have a large legacy footprint are predominantly batch oriented and getting them to adapt the trickle feed mechanism is not only a challenge – but in some ways unfeasible as the ROI of re-architecting these systems that from all customer expectations perspective meets or exceeds(currently) their expectations. For relatively younger (read open systems based) enterprises the registry style and the hybrid style (hub and some variant) fit nicely with the clients current capabilities to adapt and confirm to the rigors of MDM (as a discipline).
I find it interesting that among the leading contenders in the tools landscape – IBM, TIBCO, Oracle, SAP and Microsoft – the variation in styles offered and techniques is so wide and deep that almost any venture into the MDM space requires a thorough assessment of which techniques within specific products offered by the respective vendors is most important or critical for the specific clients need, domain and industry vertical.