SOA governance is one of those topics that mean different things to different people in the world of SOA. I'm a bit tired of briefings by governance vendors who start out the conversation with "What's your definition of SOA governance?" Thus, I've seen design repositories, directories, and even development tools sold as "SOA governance" products.

I guess I can't blame them; I mean, there is really no accepted definition of SOA governance out there. And not only are the vendors defining SOA governance in different ways, but the analysts and press are as well. So, who's right? Let's wimp out, and go to Wikipedia:

"SOA Governance is an emerging discipline which enables organizations to provide guidance and control of their service-oriented architecture (SOA) initiatives and programs."

I'll go with that one, but I have my own spin on this as well, especially considering that there are really two flavors emerging: Design time and runtime. It's important to understand the differences, and that you may indeed need two SOA governance products, at the end of the day.

Design Time SOA governance, as the name implies, typically provides an integrated registry/repository that attempts to manage a service from its design to its deployment, but typically not during runtime execution of the services, albeit some do.

Key components of design time SOA governance include:

• A registry and/or repository for the tracking of service design, management, policy, security, and testing artifacts.
• Design tools, including service modeling, dependency tracking, policy creation and management, and other tools that assist in the design of services.
• Deployment tools, including service deployment, typically through binding with external development environments.
• Links to testing tools and services, providing the developer/designer the ability to create a test plan and testing scenarios, and then leverage service testing technology.

In essence, design time SOA governances works up from the data to the services, gathering key information as it goes. Thus, you typically begin by defining the underlying data schema and turning that into metadata, and perhaps an abstraction of the data. Then working up from there you further define the services that interact with the data, data services, and then transactional services on top of that. You can further define that into processes or orchestration. All this occurring, with design time information managed within the design time SOA governance system.

Runtime SOA governance works and plays in the world of SOA management, and should be linked with design time SOA governance, but often is not. Thus we have design time, which is all about defining the policies that need to be enforced by the services and implemented by the consumer that's going to consume the services. Thus, runtime governance is the process of enforcing and implementing those policies at service run time, but may do other things as well (see below).

Runtime SOA governance, like design time SOA governance, comes in many flavors due to the number of vendors in that space and how it's being defined by that vendor. There are no defacto standards as to what runtime SOA Governance needs to be, but there are certain patterns that are emerging.

Runtime SOA governance typically supports:

• Service discovery
• Service delivery
• Security
• Setting and maintaining appropriate service levels
• Managing errors and exceptions
• Enabling online upgrades and versioning
• Service validation
• Auditing and logging

As we progress in the world of SOA, the notion of SOA governance will morph into more solid foundations of technology, and the standards around this space should mature and normalize. What's important now is the need for this technology. SOAs are indeed complex, and you have to create or implement a mechanism that's able to track and manage of the service assets within the organizations. Considering that, SOA governance systems will have to be standard equipment for most SOAs.

Posted by Dave Linthicum on February 5, 2008 05:39 AM