Bloor Research on MDM
Harriet Fryman comments on the explosive growth in MDM products, specifically those focused on customer data, and concludes:
"...the 70s was all about hardware, the 80s about tools, and in the 90s applications were king. Now we are in the decade of integration, and to be king means to be at the nexus of integration. Without hesitation, ...I see MDM as being that nexus, and the vendor who owns MDM will be king of this decade."This article gives a nice overview of the problem of MDM, although it glosses over some of the complexity. In particular, the issue of how much data to store in the customer master is not a simple one, and depends on a myriad of factors including performance requirements (system response time), the composition of the record requests, network bandwidth, message size, channel utilization, peak usage requirements, scalability, and so on.
I frankly disagree with Fryman's observation:
"So is the vendor activity occurring because technology is now available to make it possible? The cynic in me says no. I believe it is the usual grab for market share"Part of the reason MDM (and its sibling CDI) is coming into focus now is due to the maturity of the technologies required to address it. XML not only standardizes inter-application messaging, but provides a library of purpose-specific dialects (ebXML, RIXML, SWIFT, FpML, FIXML, etc.) to standardize the syntax. This is a relatively recent phenomenon, and without XML to interface between applications, companies seeking to reconcile the distributed data have been faced with a mix of obscure file formats and programming APIs.
Similar progress has occurred in defining standards for business rules (BEPL). Firming up the application specifications under J2EE with Servlets, JSP, EJB, JMS and so on has helped address interoperability issues. Even the IT architecture debate is slowly resolving with service oriented architecture (SOA) standards beginning to emerge.
MDM issues have been addressed in the past, to be sure, but the lack of these kind of standards has meant that efforts to do so were highly customized, tailored to the individual IT environment and application set. With the explosion in standards and protocols, there is enough commonality that applications designed to address MDM can now be designed. This in turn makes tackling MDM issues faster, cheaper and more likely to succeed. Lower the investment hurdle and more companies will take advantage of the solutions. If more companies buy MDM applications, more vendors will move to provide them. And the great circle of life is complete.
Fryman comments that:
"Corporate governance, customer intimacy, product lifecycle management, and many other business improvement strategies require what MDM promises"... and here she is right on target. These are the value-added applications that create sustainable competitive advantage. As operational efficiency issues are increasingly addressed - which they have had to be to ensure the economic viability of many businesses as margins have declined - these service-oriented and highly customized delivery capabilities are the next battleground for the mind-and wallet-share of the customer. What is noteworthy here is that in order for each of these applications to run correctly and deliver on the promise of added value, they must have clean, accurate data. Each application assumes that it is operating on accurate data, and makes no allowances for duplication of records, old phone numbers, incorrect mailing address, typographical errors or any other data quality issues that plague MDM deployments. It is largely the revenue opportunities that are addressed by these types of applciations that are driving MDM adoption.
Increasingly, software vendors are coming to realize the truth behind your assertion that "the vendor who owns MDM will be king of this decade". Vendors, however, are driven less by greed than by fear on this issue. What happens to IBM's banking applications if they let SAP come in and own the master customer record? What happens to Siebel's CRM applications if they let Oracle come in set up the master customer hub? Owning the customer master is this decade's equivalent of owning the database in the 1980s, or owning the desktop in the 1990s.
I like her comparison of the issues of the data model behind the customer master to the issues faced in constructing an LDAP repository, and agree there are some takeaway lessons there. I'm looking forward to her "king of the hill" predictions! What do you think? Does IBM walk away with it all? Is SAP the 800 lb. German gorilla? Or does the Oracle-Peoplesoft-Siebel merger provide the application suite to beat?


0 Comments:
Post a Comment
<< Home