<<Recently, a client approached me with a quandary. When designing XML
schemas for Web services, how do you balance the desire to use industry
standards such as UBL ( Universal Business Language) or CICA ( Context
Inspired Component Architecture) to support data interoperability with
the unique needs of particular domains and sub-systems within the
enterprise? The client's service design team is rightfully concerned
with the competing interests of internal enterprise standardization,
interoperability with external entities, and addressing the unique needs
of local domains and process constraints. How can these competing needs
be effectively managed when designing the schema for a given service?
*The Standard Answer*
Naturally, you start by giving the standard answer - "it depends". This
is an essential and carefully crafted phrase that all consultants are
taught to give according to page 17 of /How to Win Clients and Influence
Budgets/. Of course, the standard answer is rarely sufficient, but it is
not without merit. It is certainly true that the decision regarding
your data model design depends significantly upon a host of factors:
* Which use cases are high priority?
* Which use cases are high impact (to stakeholders and/or to customers)?
* Which systems and/or processes are mission critical?
* Are you including industry standard data models in you enterprise
out of necessity (i.e. ONLY when you are forced to interact with
other entities), or is it part of a broader modernization effort
within your organization?
* Do interoperability challenges or integration challenges currently
contribute most significantly to your development and/or
maintenance costs?
* Which interaction scenarios are of higher priority, internal or
external service calls?
* Would aligning more closely to one of the available models lead to
a significant reduction in data mapping activities or is the
environment simply too fragmented to support this?
* Is there one particular system or business process that is unique
and skewing perceptions regarding our service data models?
While all of these questions (and many more) are important and aid in
facilitating a thorough examination of the problem, we rarely have the
time to examine each problem from all possible angles. Consequently, we
must look toward guidelines and rules of thumbs.
*Guidelines for Managing Multiple Service Schema*
1) Your business processes should only work with a single data
model if at all possible. Business processes are best designed to be
data model agnostic and operate off of an internal, process-centric
model. I explained the importance of process-centric data models in a
previous post
<http://soamatters.com/blog/2008/12/03/which-came-first-the-soa-or-the-data-model-part-1/>.
2) Your services should work with as few data models as possible
(one model being preferable). This is just good commonsense. For each
data model that is added to the mix, your development time and long-term
maintenance costs increase at a non-linear rate. The pain will
intensify and it will do so rapidly with each new model you add to the mix.
3) If your services are going to work with multiple models, you
should put some sort of taxonomy / categorization scheme in place to
distinguish the data models used by services. For example, services
that are outward facing might use a data model accepted more broadly by
the industry. Services used by a particular LOB might use a certain
data model, and services used by another LOB might use another. Another
distinction could be infrastructure services vs data services vs
application services. Regardless of the approach, there needs to be
some methodology that is objective and governable for when one data
model is used vs when another data model is used.
4) Data model transformation is a necessary evil. It should be
done only when necessary and you should contain the transformation to a
designated component. Transformation activities should be handled by
intermediaries (data services, ESB, network appliance, other mediation
framework) when possible rather than building it into the internals of a
service or process. This keeps your services clean, provides a nice
reusable transformation mechanism, keeps your interoperability more
loosely-coupled, and provides for agility and extensibility in the future.
Juggling multiple data models within a service oriented environment is
no one's idea of fun. When possible, aim for a more comprehensive and
strategic analysis of the environment (see the 'Standard Answer'
outlined above). When this is not realistic, try to use the above
guidelines and rules of thumb to help you tactically navigate the murky
waters of data model incongruity. Service design isn't easy, but it
doesn't have to be rocket surgery either. Best of luck!>>
You can find this blog at:
http://soamatters.com/blog/2009/03/03/juggling-multiple-data-models-with-services/
Gervas
