I must be insane. 

I'm trying to organize a new SOA initiative, to cross some of the remaining boundaries between the different IT groups by taking "central" out of the picture.  I'm trying to get architect-to-architect collaboration in an area where we have not openly shared before.  And I'm trying to do it while still working at my regular work... no extra resources for this part of my job.

So, I'm using a wiki.  Direct.  Immediate.  Unedited.  Completely outside my control.

SOA by wiki. 

Nearly every initiative I've ever read about was "SOA by central planning" or "SOA by chaos."  Most failed. 

Let's see if coordination get us past the failures of those models.

This should be very interesting.  I'll let you know how it works out.

SOA brings change.  It is a change to the way we do IT business.  No question of it. Anyone who has tried to 'tack' SOA onto the side of an organization has seen the resistence that this generates.  "We've always done it that way before... why change?" 

One place where SOA has an impact, but few people speak openly about it, is the change that SOA has on the world of software testing.

There are some huge changes here:

1) Regression testing: The only hope you have for insuring that your service can handle itself in a changing environment is to create automated regression tests.  This was optional in the past. Now it is both Required and quite Feasable.  Since services have no User Interface, there is no need to worry about whether the control has moved. Maintaining an automated regression test script is much easier.

2) Boundary testing: If the intended use of a service is a good thing, what about the unintended use of a service?  Can the service survive being hit with FAR more requests than it was designed for?  Does it throttle itself?  Does it protect itself?  Can private data leak out? 

3) Integration testing: A LOT of the capability of a Service Oriented business app will move to the composition layer.  Testing the services helps to establish a baseline to show that the defects should be avoidable below the service line, but many of the bugs will occur because a composed service assumed that an underlying service would have a side effect that it does not have, (or vice versa).  As defects are found in Integration testing, the test cases need to be updated at the service level to insure that assumptions are constrained and tested.

4) Stub testing: you may need to test the composition layer before a service is available or while it is only 'local' instead of 'enterprise'.  For that reason, the test team needs to be able to generate 'stub services' that apps can call that behave in a manner that is compatible with the service definition, but has far less effect.  Otherwise, integrated testing is a joke.

5) New service validation and service compatibility validation: if a new service is entering an environment, and the goal is for the users of the existing service to transition over to it, then there has to be a way to test the new service to insure that it is compatible with the existing one.  Automated regression tests that were designed to test the existing service need to be pointed to the new service and failures noted.  Note that the team developing the new service is not likely to be the same team as the one that developed the prior one, so source code for the regression test must be available and shared and documented and stable.  This requires a level of 'test team integration' that many organizations will find challenging.

This is, I'm sure, a subset of the changes that SOA brings to the world of testing.  I encourage those who are involved in testing to share other ideas and concerns that they have come across with respect to SOA development.

I asked some folks in my talk before the US Partner Senior Architects Summit yesterday if they had created services that no one used.  Not surprisingly, some hands went up.  One architect piped up with this "I've seen a service that was used improperly and it brought down the enterprise."

Um, OK.  Sure.  I can write a service badly.  I'm sure you can too, without much effort.

Some folks would say "that's why we need SOA Runtime Management Tools!" 

Bunk.

Every app is completely responsible for protecting itself. 

Whether it is from a Denial of Service Attack to the web site, or an attempt at unauthorized access to the data, or an improper use of the service interface, apps must manage their own stability.  We need to realize that a service has the same flaws and foibles as any app.  It can be used.  It can be misused.

Plenty of ways to solve for this.  A subset, off the top of my head:

• test the heck out of your service interface.  Testing is our friend.
• configure for DoS attacks against the service interface
• use intermediaries that support throttling, so that you can manage the inbound traffic
• secure the interface, so that only members of known groups or even specific system accounts, have actual access.
• don't advertise.  Don't flag your 'service' entry in the repository as 'public' or 'feely callable' if you aren't. 

That is not a SOA Governance problem.  This is a training problem. 

My third post in a row about the notion of SOA Governance.  You'd think I was planning to speak about Governance this week.  (I am).

In general, Governance is a set of processes, responsibilities, and tools that reinforce good behavior and help avoid bad behavior.  With SOA Governance, we want to build a useful SOA environment, prove the ROI, and insure we don't screw up security.  We do this with policies and processes (mostly process).  Policy can only be applied to a small fraction of the governance problem.

Now, break it down further.  Only a fraction of SOA policies can be verified or reinforced with tools. 

Therefore, while SOA tools are useful, they don't deliver governance.   In my honest opinion, it is not rational to use the word Governance to refer to a tool at all.  After all, we don't refer to to Microsoft Operations Manager as a "systems governance tool," and SQL Server is not a "data governance tool." 

Here's a novel idea: Let's use similar words that have been successfully applied in other areas, so that the meaning is clear.  If MOM is a Network Management tool, then Systinet, IONA, and Amberpoint are Service Management tools. 

Tools manage.  People govern.

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:

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.

No one in IT wants to talk about Governance.  Why?  Because no one has a consistent clue what it is, and those folks that venture a guess usually come up with something frightening, overbearing, and/or expensive.

Good old FUD ("Fear, Uncertainty, and Doubt").  A great way to spoil your day.

Some words get overused.  SOA has been overused, although there is now a consensus on what it means, which means we can actually keep using it.  Other words, like alignment, and strategy, have so many different meanings that they can be twisted to mean "something good that I'm doing." 

"Governance" went the other way.  It is a word that has become synonymous with "something bad that you shouldn't do if you want to ship your code on time."  Except in the SOA world, where it means something altogether different.

Governance is basically a system of processes and decision rights that reinforce the good behavior of the organization and help to maintain balance between the passionate creative brain-stormers and the careful, conservative, dependables.  It is a system that fosters creativity while restraining wild thrashing.  Governance keeps good things in the mix while preventing bad things from happening.

It is not software for monitoring uptime.  It is not a process of oversight and financial audits.  Most of all, it is not a system that squeezes every idea until any spark of creativity is winked out. 

Governance is a good thing.  Unfortunately, we need to come up with another word.  This word is no good anymore.

How about "Constrained Empowerment"?  :-)