More on the Common Data Model Thing

Sometimes when I find other blogs referring to my blog it’s just a matter of reflection…”here’s a good idea” and all that. Sometimes, however, they add good ideas. Case in point is Jean-Jacques Dubray’s post on InfoQ that addresses my post last week on the Common Data Model, and dealing with it within an SOA.

From the article:

“David’s experience shows that relying on a common set of schemas may prove to be inflexible when designing service interfaces because ‘it will prevent these services to evolve separately’.

SOA is about creating assets which can be reused in different contexts, often in context unknown at design time, and maximizing the benefits of SOA amounts to maximizing the reuse of your services by the largest set of consumers possible. However, it would be naïve to think that consumers will always be in the position to adopt the point of view of the provider or that both the provider and the consumer can always adopt the same point of view. Even if this were true today, overtime, the consumer and provider may not be in the position to evolve at the same time towards a newer version of the interface.”

The point is that services are dynamic little creatures, and their need for data varies from service to service. Attempting to adapt to a common static structure is almost imposable…albeit it looks good on paper. The notion of conformity never works in the world of data, or the world of integration. The need to see information in the context of dynamics semantics is just too compelling and valuable.

Jean-Jacques goes on to discuss how to deal with semantic differences, or transformations.

“The first steps towards more manageable transformations, is to capture the semantics of the information contained in your messages and derive consumer and provider interfaces from these semantics. This is what Dave calls an ‘abstraction layer’ or others call a canonical data model or an ontology. In this abstraction layer, the structure is less important than the normalization of the semantics. This problem is not new, David Webber, way back in 1998 had introduced the concept of bizcodes, to normalize diverging names XML formats and deal elegantly with localization. ”

Addressing the use of ontologies in context of this problem domain is a good idea as well, and I’ve certainly written enough about ontologies, including in my last book, so I won’t dwell on it here. I consider ontologies a good approach when dealing with complex semantic domains, albeit I’m not sure too many people outside of Jean-Jacques, and a few others would agree with me. Indeed, we seem to all collectivity talk about how ontologies are a great idea, and nothing seems to come of it in terms of mass movements towards that approach. Perhaps the day of ontologies is coming; I’m clearing seeing an interest in using them within my practice, and I’ve made them part of my methodology.

“Semantics have to be managed precisely under strict governance processes and tested as Dave points out. Traceability to physical artifacts such as a service interface definition or a database schema are key to develop a successful ontology.

Here are some details about using an ontology in a Service Oriented Architecture:

a) Service interface need to be designed from the ontology (with their own structure, but utilizing the semantics of the ontology and only these ones)

b) For arbitrary consumers and providers, the design and implementation of transformations is greatly facilitated by the traceability established earlier between the ontology and service interfaces, and if they were designed from the same ontology, some of the transformation could be automated or directly inferred.”

More good ideas.