In a recent post, Informatica Perspectives colleague Dave Reed talks about the importance of a strong data integration and quality infrastructure to MDM efforts. Another important aspect of MDM is the powerful relationship between MDM and SOA.

This is not always an easy relationship; in fact, Gartner’s Andrew White recently opined that there is even fear among some companies with SOA efforts underway that adding MDM to the mix would be a form of “overkill.”

However, to reiterate what I said in a post a few months back, SOA and MDM need each other. SOA in and of itself holds little value to an organization unless it provides the capability to open up information to the enterprise. As is the case with SOA, successful MDM is a silo-breaker, invoking collaboration across the enterprise. MDM helps assure that the information populating SOA-based services is accurate, timely, and consistent.

A Gartner study of retailers, cited by White, found that many of these organizations  are attempting to unravel point-to-point spaghetti integration within their multiple channels, such as retail outlets, call center systems, and Websites. Many retailers are moving toward service-oriented architecture approaches, but this still does not address the yawning gaps in cross-enterprise data integration. Something is still missing from the equation, and that is the quality of the underlying data.

“SOA will help – from the perspective of replacing one set of pipes for another set of pipes that have more in common (and so can be interchangeable) but the underlying data is messed up! Unless the semantic model is simplified, thus ensuring the data semantics in the different systems mean the same thing, then a better integration mousetrap will fail to provide the benefits expected.  One set of pipes will be replaced with another set of pipes but the stuff flowing through the pipes will remain messy.  This is the ‘SOA-needs-MDM’ argument.”

Dan Power, a consultant in the data integration space, also echoed these sentiments in a recent article, observing that SOA enablement is a “hidden benefit” of a successful MDM strategy. In turn, SOA offers a means to further the goals of data integration and data quality within MDM efforts. The two key questions to address when embarking on MDM, he relates, are “What’s the data quality component of the MDM strategy?” and “What does the integration component look like?”

Unfortunately, too many companies attempt to carry out an MDM effort “using technology from the late 1990s or early 2000s – or even worse, through point-to-point custom code,” Power says. In addition, if SOA is built out without an MDM strategy, “all too often, underlying data quality issues prevent the new business processes from achieving their goal.”

SOA is designed to integrate services and applications in a networked fashion – versus point-to-point. Thus, the data flowing through the architecture needs to also reflect the network effect. And, “by using MDM as a foundation for SOA, you can be sure you’re providing high quality, proactively governed data to the rest of the enterprise through the services you create,” Power says.

Kyle Gabhart also talks about the “strong synergy” between MDM and SOA in a recent article. “The effective adoption of SOA requires a well-designed data model at the physical and logical levels,” he says. “Many organizations even aim toward the development of a canonical domain model.”

Gabhart even observes that the two disciplines share common principles, including the following:

• Reusability: “A primary driver of MDM is to allow applications to share data safely and avoid duplication; SOA heavily promotes the re-use of services throughout the enterprise.”
• Discoverability: “The Master Data Repository exposes data to applications in the enterprise; the Service Registry and Repository exposes services to a SOA.”
• Abstraction: “In MDM the complexity of the underlying data model is hidden from consumers; in SOA the complexity of the underlying service implementation is hidden from consumers.”
• Business-IT alignment: “Master data is business-focused by design, creating a master data model provides a common data abstraction across the enterprise; this model is exposed through services within a SOA.”

Lorain Lawson urges practitioners from both sides of the equation to put their heads together when planning new directions for enterprise architecture. “Your enterprise architect – or whoever is in charge – needs to do some serious planning and know a lot about data modeling or you’ll have problems,” she advises. “Given the potential expense of both SOA and MDM, I think you’d be well-advised to take the data modeling question seriously.”

When implementing these two disciplines in tandem, Power urges the creation of three layers of abstraction on top of the underlying data layers themselves:

• Data Services layer: “A combination of simple or ‘atomic’ data services, with more sophisticated composite data services, which might combine several of the simpler data services as part of one more complex or complete data service.”
• Business Services layer: “Created using a BPM tool, which resembles prior ‘workflow’ products, but offers more sophisticated capabilities for connecting to data sources, and publishing robust, reusable services for use by packaged or custom composite applications.”
• User Interface/Composite Application layer: “Strings together off-the-shelf and custom packages, user interface elements, portlets, etc. This layer is where the end users initiate processes, approve results and perform the bulk of their day-to-day work.”

The way to achieve accurate, complete, timely and consistent data for SOA is through an MDM hub, Power relates, with tight integration to and from critical source systems. “By having clean data at the data service layer, the business services will be more reliable, trustworthy and useful,” he says. “The applications built or integrated on top of the business service layer will be more innovative, take less time and money to build and test and will be more flexible and less expensive to maintain.”