In my ongoing efforts that are part of the update to the 2009 Gartner Magic Quadrant for MDM of Product Data, I took a vendor briefing last Thursday that got me thinking about the link between MDM (the technology), and MDM (the discipline). The vendor – whose name shall remain anonymous, shared their strategy with us, and I have to say I was more confused at the end of the briefing than I was at the start. Before I talk about the vendor specifically, let’s explore the point that the briefing spawned in my head.
Certainly users have been trying to achieve “single view” for many years, before the phrase master data management was coined. The problem of trying to maintain a semantically consistent definition of master data across the business has been a long standing desire for most firms. It is because business (and to a great extend, IT also) has grown to be so complex, that since 2000 many firms have begun to look to specific tools to help.
In my travels I speak with hundreds of clients each year, and on top of this, vendors provide numerous references. Overall maybe 5% to 10% report that they have tied to build a legitimate, stand alone MDM technology themselves. Almost all of these report that the effort is too great and too costly and hence they prefer now to look to specialists who live and die based on their MDM skills. However, in 2008 I did meet 3 end users organizations that had really impressive MDM disciplines established, enterprise wide and/or globally, without externally sourced MDM technology. So it can be done.
Now back to the vendor briefing: This is a large business applications vendor that has a large client base that is virtually all heterogeneous in that they all have lots of different business applications. The vendor has decided to build their own MDM capability – but it is not like any other MDM strategy I have seen. The basic concept is that each business application that the vendor sells (and there many) is being extended in order to publish data and messages to a specific industry-neutral data model. This data model operates as a clearing house; each application that links to a ESB will use the ESB as a massive message oriented clearing house for master data changes. As a master data change takes place in one application, it sends the change to the ESB; the ESB maintains the rules over where the data needs to go.
Most MDM strategies thus far have focused on some specific data repository that acts as the central clearing house and authoritative source of master data. So after an hour I was left with the question – could an event-driven, message-based architecture, based on a centralized ESB yield the same business oriented value proposition (single view) without an MDM application? I was not able to answer the question on the call; but I thought later and think that there is an answer. This architecture could emulate an MDM implementation (a pseudo-registry style), but there is a much larger overhead; and the offering is far less “open” than the name implies. So the applicability of this offering, in view right now, is very limited. But at least it made me think about how MDM could be achieved without the technology we refer to as MDM today.
Hopefully the vendor has the good sense to test the limits of their strategy. And if it is found to be wanted – as I believe it is – they have the good sense to change it.
6 responses so far ↓
1 Omer Farooque // Feb 19, 2009 at 3:47 pm
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.
2 Dan Nicollet // Feb 23, 2009 at 6:39 pm
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…
3 Andrew White // Feb 23, 2009 at 6:45 pm
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?
4 Omer Farooque // Feb 25, 2009 at 3:10 am
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?
5 Andrew White // Feb 25, 2009 at 9:47 am
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.
6 Vishal Puri // Mar 6, 2009 at 1:04 pm
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
Leave a Comment