In working up another article this weekend I was going through the Web sites of the larger SOA governance guys to see what they have been up to, also to better define this notion of "SOA governance." In this process, a few things came to me:

First, everyone's definition of SOA governance is a bit different. Thus, what they offer fits their definitions. However, most are directories, repositories, or registries, at their essence, and may or may not include policy management.

Second, there is no clear architectural use case for most of these tools. In attempting to figure out how these tools fit into the "SOA problem" is difficult, when considering that we’re dealing with architecture, and not just a collection of applications and services. Best, these are application development support tools, akin to configuration management and metadata management of years gone by.

Finally, it appears to me that for these tools to be truly valuable to those building a SOA, they need to change their approaches...or SOA governance reform.

So, if I'm going to boil all of this down to common patterns, I would say that: SOA governance tools are really repositories that store information on what software components have been written and whether there are dependencies among different programs. In addition, they collect policy information, such as security access rules, and connects to project management programs. SOA governance tools are meant to improve oversight of ongoing application development, a design approach that advocates modular, reusable programs, and not overall architecture.

More later...

Posted by Dave Linthicum on September 11, 2006 06:23 AM