As I've been looking at SOA governance solutions recently, I've been looking at a huge hole in the approach. While all SOA governance products do indeed consider the control and use of services, most are ignoring the data management issues, and thus are only solving part of the problem.

Services are really transactional behavior that fronts information, at their essence. While there are services that are built as true data services, and services that are more about transactional behavior, they are all services nonetheless and all must deal with, and manage information/data.

Design time and run time SOA governance products, while taking into account the concept of a service, typically skip over the concept of data management, specifically abstraction from the physical database, as well as the management of changes from orchestrations, to composites, to abstractions, and then to the physical data. Right now, most SOA governance systems deal with services first, data second, or not at all.

Considering this, those leveraging some of the SOA governance products out there may find that the coupling of the physical data structure to the services limits the ability for the architecture to provide agility. Moreover, as the data changes, SOA governance needs to account for changes and the impact to the service or services…a design time concept. Moreover, policy management during run time may not extend to the underlying data as well, and could cause issues considering that the services are not managed as a holistic unit.

My advice is to pay more attention to the data when considering SOA governance. The services are important, but they typically deal with information, and it's critical that we pay attention to that as well, else we're only solving part of the problem.

Posted by Dave Linthicum on May 31, 2007 12:54 PM