SOA Best Practices Digest

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.

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:

1. We recognize this as an opportunity to modify the model and bring it in-line with real business usage.
2. 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.