Well what a day!  The week ended on a high for me, and by the looks of it, for the attendees of the conference.  Despite the lovely London sunshine a good number of folks remained in the hotel to chat about SOA and application development.

I had a couple of 1-1’s with clients, and also had the pleasure of speaking on MDM.  The 1-1’s were very interesting.  I had a few questions about specific vendors since clients are always concerned about vendor maturity and capability, so this remains a frequent topic.  Some other questions we explored included: 

• It seems pretty obvious that my firm has or should identify master data domains, such as product, customer, and organization, but what about “agreement” or “order”?
• Any clear, obvious MDM principles or best practices?
• You have talked about how business applications (and business intelligence) needs to evolve to support an “MDM awareness” – are there any examples yet in banking?

Order and Agreements: There constructs clearly include master data (an order is an aggregation of products and/or services, a client, and a data, along with other bits and bobs such as price, terms, rules etc.  But an order or agreement is just that – an aggregation.  There are many of them, and they operate like a transaction: actual specific transactions (a sale, a fulfillment, a settlement) are all logged against the order in some fashion.  The content of the order or agreement includes master data, but also other data.  Lastly, MDM implies a living governance infrastructure and process, so that again separates orders, agreements, and master data.  The lifecycle of orders, and agreements, needs its own kind of governance, but it would be different.  It is highly unlikely, and I could not think of a single instance, where a firm would want to govern “order” as if it were master data.

MDM Principles/best practices:  We have published several notes on best practices; some focused on specific domain oriented MDM (such as Top Ten Best Practices for MDM of Customer Data, and Top Ten Best Practices of MDM of Product Data) and also some other notes on what to do and what not to do when setting up your MDM initiative, or looking more broadly at other information management strategies.  A good source for what is out there is our periodic, “Roundup of Master Data Management and Related Research”, last updated Q4 2008.

“MDM Aware” Applications: this is a new area of research and one that is proving particularly interesting.  In talking with those users that were innovators or early adopters of MDM we are seeing that an increasing number of firms are implementing now the second, or third, MDM technology in support of their own MDM strategy.  As these processes and systems come on line, the ease (or difficulty) with which MDM systems interact with data stores (business application, packaged or developed applications, business intelligence data warehouses) becomes complicated.  Some firms have little ability to “open up” the legacy applications and interaction is very basic.  Other firms have some ability to “open up” part of the legacy infrastructure and so the dialog about how MDM works and interacts with these systems becomes more complex, and so interesting.

Of course, most applications do not “play well with others”.  Additionally we know that architecturally MDM is shifting a focus for data integration from “point to point” (many of them) to fewer “hub and spoke” models.  But if the legacy applications are not easily accessed, the degree to which an ideal MDM implementation style can be adopted becomes harder.  Some initial business applications vendors (i2 Technologies in SCM, Soft Solutions in retail) and a few others, are beginning to externalize their master data model such that “control” could be wrested from the business application to an external, 3^rd party system (ie MDM).  Though not a panacea, this does make interaction between MDM and the business application easier, if only the MDM applications were mature enough to monitor and control what goes into those externalized data stores…  Bottom line: if MDM as a discipline is to take hold and grow, many, many more business application oriented data stores have to be made “MDM aware” in order to simplify the information infrastructure.  If the master data models remain, as they are now, firmly hidden behind the application “firewall”, then integration between MDM and the rest of the application stack will be ‘traditional’ and as such, an opportunity for lower costs will be lost, and more importantly, a degree of agility for the IT stack will be lost also.  

My presentation, entitled, “Does SOA need MDM, or Does MDM need SOA?” seemed to go well.  I was lucky enough to attract a sizable audience (this was the only MDM session at the event) and we covered a high level overview of MDM, and then explored the various interplays between SOA, application development, and value of MDM.  The conclusion I tried to draw out was that:

• For MDM be effective, it (the technology enabling MDM) needs to be part of the services infrastructure that comprises the SOA strategy as this simplifies how the technology works across the business, and
• For SOA to be effective in more complicated environments, that is, heterogeneous “semantic bounded” data stores, MDM needs to be adopted before hand else the any composed application would have to incur the cost of coping with semantically inconsistent data every time it was executed. 

Based on the questions from the audience and the feedback during the afternoon, and at the closing session, MDM and SOA is a popular topic and the content seemed to strike a chord with many attendees.  Who knows, maybe I will be back next year…perhaps with a user panel to talk about the interaction between MDM and SOA…