Recently I have been engaged in two Master Data Management (MDM) initiatives within the context of a larger Service Oriented Architecture (SOA) adoption plan. In both cases, the client found themselves at an impasse regarding how to resolve conflicts between the master data model and the data model required for one or more SOA artifacts (i.e. business process, service interface, etc.). Each client approached the problem from a different direction, but the conflict was essentially the same. Who wins and gets to run with their view of enterprise data? The MDM team or the SOA team? Alternately, the EA team might be wondering whether the MDM vision is compromised for the SOA vision or vice-versa.
##CONTINUE##
Scenario 1: Client A has decided to build a canonical data model, independent of existing applications or business processes. The client follows a simple process:
- Build a Conceptual data model
- Identify Logical Sub-domains (Logical grouping of data)
- Construct Logical data model for this sub-domain
Now if a business process comes into picture (e.g. “pay claim to the provider”), this would involve accessing data from the Provider and Claims data domains. How can the client build the schema, and not break the relationship that is established in the logical canonical model? Alternately, how can the client connect this schema to the base canonical model? Either the master data model must be compromised for the sake of the service oriented view of the enterprise, or the service oriented view must be altered to align with the master data initiative.
Analysis: So the real problem here is that we have created a model in a vaccuum and we are now faced with a specific utilization of data that is potentially giving us new insight into how data is actually used within the business. There are a couple of perspectives here:
- We recognize this as an opportunity to modify the model and bring it in-line with real business usage.
- We dismiss it as a user/customer oddity that needs to be managed.
If we update the model based upon this new info there are risks that we have been skewed by a single process, but perhaps we recognize broader truths from the things this process brought to light. If we do not change the canonical model, then we either convince the customer to accept the ’standard’ model, or we put some data mapping in place so that the business process is able to engage services that are standardized in their respective data models. Regardless of the approach taken, service oriented design best practices would dictate that the business process only see a single data model. This could be a unique model derived from business use cases or the canonical model that was created previously. The origins are irrelevant, as long as the business process sees one model for data. Otherwise, the business process is no better than an Enterprise Application Integration (EAI) workflow and brings with it all of the complications around maintaining custom integration logic and juggling of disparate data models. This carries with it unacceptable maintenance costs, it is brittle, and prone to becoming outdated and unreliable.
Summary
The effective adoption of SOA requires a well-designed data model at the physical and logical levels. Many organizations even aim toward the development of a canonical domain model. The intersection between MDM and SOA is surfacing with increasing frequency and I expect this trend to continue for the next couple of years.
In this first post, I have explored one scenario regarding the conflict between an enterprise data model and a SOA-specific model. In a follow-up article, I will parse through an additional scenario from another client experience.
Part - 2
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.
BY Kyle Gabhart
Source：SYS-CON
Copyright ©1994-2009 SYS-CON Media.
All Rights Reserved. All marks are trademarks of SYS-CON Media.
Posts
0 comments:
Post a Comment