Using a Common Data Model with SOA

Lately I've been hearing a lot about common data models when it comes to SOA. As organizations attempt to figure out the data in the context of SOA they are driven many times to the notion of a common way to view data as a part of the architecture. Case in point is this post from Kjell-Sverre Jerijærvi who points out the need and the notion of a common or Canonical "Data" Model. "An important topic when designin

Lately I've been hearing a lot about common data models when it comes to SOA. As organizations attempt to figure out the data in the context of SOA they are driven many times to the notion of a common way to view data as a part of the architecture.

Case in point is this post from Kjell-Sverre Jerijærvi who points out the need and the notion of a common or Canonical "Data" Model.

"An important topic when designing service oriented systems is how to enable different services to share semantics to be able to be composed into working solutions."

While this is something I've been pushing for years, I'm now seeing some good thinking around this problem and some good technology behind it as well. The data is the single most important component of an SOA, and you need to think carefully about how the data is managed. Simply tightly coupling the data to the services won't serve the notion of agility, and you're really not solving your data problems.

"Making every service contract depend on the One True Schema will make it impossible for the services to evolve separately, they will no longer be autonomous."

Thus, the data is important, and you need to figure out management, aggregation, and abstraction approaches before you begin bolting on services. While many agree that starting with the data is a sound approach, the majority of SOA projects I see are starting with the services, and working back to the data. While that's not a horrible approach, you'll find that you'll be redesigning and redefining services after you figure out your data layer, and in many instances the services will have to change significantly.

Some key takeaways from all this:

  1. You need to face the data first and define a common data or abstraction layer so that the services are not bound to a particular schema, but enjoy the use of the data nonetheless. I would not push a common schema as much as an abstraction layer.
  2. The abstracted or common model should be tested like any other component.
  3. Don't focus as much on force fitting a data model as agreement across the service domains, and leverage a schema mapping layer to provide choices in the future and agility down at the data layer.