In a previous post I blogged about the strong synergy between SOA and MDM. More recently, I explored the subject of service oriented data modeling (part 1 of this post) and how to resolve the inevitable conflicts that arise between your SOA view of data and your enterprise or MDM view of data. In this second article, we explore a second scenario (see below).

Scenario 2: Client B has an existing SOA implementation and has recognized that the underlying physical data is disparate and incongruous. They decide to move forward with an MDM initiative to clean-up the design, management, and overall stewardship of information within the enterprise. They must then decide whether to derive their master data model from one of several sources:

• the canonical data model used by their SOA business services and business processes
• the data model that has been adopted within their industry (ACORD, ARTS, HL7, SID, etc.)
• a top-down view of how data is used within the enterprise
• a bottom-up abstraction of the existing physical data models aimed at data consistency, quality, manageability, and perhaps even schema reuse

All of these approaches represent valid strategies toward developing an enterprise model for master data. So how does Client B move forward?

Analysis: Selecting the appropriate strategy is partly a matter of applying successful patterns and identifying similarities with previous successful implementations. Beyond applying one’s expertise, it is important to consider the business drives behind these initiatives. There are (or at least should be) higher-level business drivers that have led the organization to head down the SOA and MDM paths. These business drivers will provide context regarding the value that the enterprise needs to get from enacting change. This will provide a lens through which to evaluate these strategies. For example, if interoperability with other industry organizations is important or if the facilitation of merger and acquisition activity is of high priority, then option 2 is preferable (base the data model off of accepted industry standards). Another example might be a prioritization to support business process threads as a part of a broader business optimization effort. This would point toward either option 1 (SOA-centric data model) or option 3 (top-down enterprise decomposition), requiring more detailed requirements gathering to select between these two strategies.

Summary
Data modeling is a bit of an art form, scientific discipline, and dark magic all rolled in together. Effectively modeling enterprise data is challenging enough, but then resolving conflicts that occur with other data management efforts creates even more complications. In these two posts, I have articulated findings from two recent engagements involving SOA and MDM and that inevitable collisions that occur from a data modeling perspective. Hopefully you have found something insightful and useful within this information. I welcome your feedback as well as your experiences in these areas.

Read the original blog entry...