What Master Data Management can gain from SOA

IBM just launched a product, IBM InfoSphere Master Data Management (MDM) Server, which will purportedly interface with service oriented architecture. According to IBM, InfoSphere "offers deployment options that give customers the flexibility to use it for both entry-level MDM projects and high-volume SOA MDM systems with one platform."

Can SOA help make sense of the data that is wildly proliferating across our enterprises?

There's more buzz around the role SOA can play in getting a better grip on the data that is wildly proliferating across our enterprises. Pfizer has been doing a lot of work in the MDM-SOA area, as reported here a couple of months ago.

IBM explained in its announcement how MDM brings it all together:

"A retail bank can manage a customer's savings, checking and credit card as a single managed account -- a task that banks continue to struggle with from a technical perspective. A bank can also use the MDM Server to tailor product bundles, provide consolidated billing, payments, and statements, and customize service for an account. Additionally companies will gain more flexibility in creating and adding new product data and managing product hierarchies in their daily operations."

In addition, IBM said its MDM tool supports event notification and compliance management.

So where's the direct connection to SOA? SearchSOA's Rich Seeley explored this potential connection with David Corrigan, product manager, master data management at IBM:

"A common problem for SOA implementations where architects and developers find that they need a lot of different data sets from a lot of different sources. A lot of our clients in services-based industries have tried to SOA-enable and have a workflow or a middleware process or business process for opening a new account for example. Very quickly they realize that one critical step is understanding who the customer is, did they buy products from you before, what kind of relationship do you have? There's no one application that can answer those questions because actually the data is buried in multiple applications."

If SOA-based services can access such information from one consolidated place, in one common format, then the information is readily available.

Even if there won't be a direct link between SOA and MDM efforts, the SOA approach to decoupling content and context may provide guidance to the way data should be managed.

Vasco Drecun provides a deep dive into a semantic SOA approach to MDM, and what MDM can learn from SOA. The current challenge with MDM, Vasco observes, is the fact that "our systems are so much proprietary and closed that we do not even dare to question accuracy and adequacy of the meaning of the data within them. We simply close our eyes to the fact that we are really not masters of the master data. Consequently, we cannot really govern it, we cannot control it, we cannot influence its evolution. We can only hope for a comfort of knowing that all master data reside in a single system where we can at least see the field within a table where it is defined, regardless of its true semantic value to support all inputs and outputs of all processes that may need it."

Perhaps MDM should take a service-oriented approach, Vasco says:

"The only way to really control it is to understand all different meanings in all contexts within which the data adds value to information processing. And at the point of placing the informational reference between the content (data fields in a document type, e.g. 'street number of a ship to address') and context (input/output in the process flow using that document type, e.g. 'Transportation Order' or its clone 'Expediting Drop Ship Order') is where we need to capture that link. That is how decoupled content and context work in SOA process modeling."