SOA Governance - Software is about 20 percent

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.

Comments

• Anonymous
  April 21, 2007
  Nick, I couldn't agree more. It's unfortunate that the tech vendors involved have chosen the branding they have, as it is confusing people and may contribute to the word becoming meaningless. It's almost ironic that when phrases come into usage that are about business objectives or working practices (and not the technology of the day), the technology industry creates a new type of technology that claims the new phrase. And to your title, I'd go further and say it contributed far less than 20% of the likelihood of an SOA initiative being successful in an organisation. I posted <a href="http://sol1.blogspot.com/2006/10/soa-governance-is-not-about-technology.html">similarly</a> recently. Regards, Sam.

• Anonymous
  April 22, 2007
  As I've stated here a few times before, while I do believe in the notion of SOA governance the available tools and technology will only get you a small part of the way down the true SOA governance path. A...

• Anonymous
  April 23, 2007
  One common mistake that I see folks making is the assumption that once you have policy, you can encode and enforcement becomes magic. Unfortunately, the bulk of policy is still human-centric (I would conjecture that the majority of your heavy-hitting policy falls into this category) and requires some form of (potentially long-lived) workflow-based approval process to ensure that a policy is being adhered to. Too many vendors use the example "If you have a policy that says your services have to be WS-I compliant, then our tooling can do the enforcement for you" as a way of selling their PEP technology. What about policies like "Before a service goes into a production, an appropriate technical and business owner must be assigned"? These can't be encoded and enforced in an automated fashion ... the capabilities around handling these policies need to be better addressed by the tooling vendors out there.

• Anonymous
  April 23, 2007
  So, I just read your latest post, where you cover off my thoughts. Still, I think it's worth repeating.

• Anonymous
  May 11, 2007
  I Think 20% is realy the max. Business is not interested in SOA or what else, they care for agility, cheap, not being tied in by IT on a certain technology. IT you want is built as a SOA, be my guest, but please deliver by tomorrow :-)