So your CIO says “build SOA.” You do a search and plop down your hard earned cash on a SOA Governance tool. Do you now have what you need for SOA Governance? Nope.
Most of it is outside the scope of software.
Don’t get me wrong. If I have a SOA environment, I’d like to know some things that software CAN help me with. I’d like to know what services are running that are not compliant with security policy, or that expose private data, or that allow unauthorized access to otherwise-secure system services. That is useful. That is ‘runtime governance’ or ‘service monitoring.’
But it is not comprehensive SOA governance. Not even close.
The whole point of SOA is to create an agile environment, making it easier to build fully integrated applications from the get-go. This is the goal. If your services don’t allow you to build service oriented applications, then you have wasted your money and time. Governance is about making sure you don’t waste your time and money by building the services you don’t need, or failing to build the services you do need.
Governance helps you to do the following activites. These activities occur at particular stages of software development (planning, envisioning, design, construction, deployment, support, maintenance) as follows:
|Activity||What it gives you||Stage|
|Business Service Analysis||An understanding of the data entities and process steps that drive the need for the creation of a service.||Planning|
|Service Partitioning||An understanding of the different levels of services (data level, orchestration, composition, management) needed to meet the needs of the business, what each service will do. This drives the definition of business events and documents.||Planning, Design|
|Event and Schema design||A plan for the behavior of the services that meets the operational, informational, and business process needs of the organization. Behavior is often described as a protocol, but it can include service level expectations, exception management and compensation definition||Planning, Design|
|Security Policy Creation / Management||A set of standards for how services will be secured, what level of authorization is needed for services of different types, how network boundaries will affect the access to different forms, levels, and types of data.||Planning|
|Operational Policy Creation / Management||A set of standards for how services will be constructed so that they can be seen, tracked, managed, audited, and monitored.||Planning|
|Policy enforcement||Automated application of policies to services running in the network||Deployment, support|
|Service Monitoring||Automated monitoring, logging, and tracking of service calls to insure that service levels are maintained and to aid in debugging and exception handling.||Deployment, support|
|Rogue service discovery||Automated discovery of services running in the network to capture services that may offer uncontrolled functionality, backdoor access, and audit gaps.||Support|
|Service Registry / Repository||Tools for sharing information about services, both with consuming applications and with the people who create or use them.||Planning, Design, Construction, Support|
|SOA Project Compliance||A process for insuring that projects funded in corporate IT departments actually consume or deliver the services needed by the enterprise.||Envisioning, Design, Construction|
I highlighted only a few rows: Policy enforcement, Service monitoring and Rogue service discovery. These are the areas largely covered by the leading “SOA Governance Tools.” While these elements are important (honestly), they are about 20% of the story.
A little CYA here, so I’m not flamed by the vendor of such-and-such software:
1. There are probably software packages that overlap in some ways with the ‘uncovered’ areas, but there is not a lot of visibility to these areas, and these are not largely the features that these tools compete on. When they exist at all, they are “extra” features.
2. Many tools, in order to support policy enforcement, will provide a tool for entering and managing a library of policies. That is not the same as Policy creation. It is policy encoding. To say this is policy creation is like saying Outlook’s address book creates customers. Policy creation is a business process. You can buy policy templates, but you cannot buy policies.
3. My opinions are my own and do not reflect those of my employer, or the partners of my employer, or anyone else on Earth.
Unfortunately, the competition between the vendors hoping to capitalize on the SOA ‘movement’ have become louder and more strident as each day goes by. Because it is normal to draw attention to your product, and proclaim it as loudly as you can, I cannot blame the vendors of “SOA Governance” software for drawing attention away from the rest of the needs in this list.
However, if you are a SOA practitioner, you inevitably run into needs in each of these areas. You need to do each activity in some way, as part of your governance strategy. You will have people, process, and tools aligned around each and every one.
So if you are setting out on your SOA journey, don’t for a minute think that you can purchase a software package to give you comprehensive SOA governance. Most of the governance you need is outside the scope of software at all. It is in the people and process, decision rights, funding mechanisms, and IT leadership that allow you to build, govern, and manage a SOA-based infrastructure.