Todd Biske: Outside the Box

I think there’s going to be a butterfly effect of blog postings from the latest ZapFlash. As always, the ZapThink guys (in this case Jason) have managed to take a hot topic (SOA Governance), look at it from an unexpected angle (chaos theory), touch on many of the key aspects of it, get people thinking about the possibilities down the road, and introduce just enough controversy to get people talking about it (like me).

The first thing that struck me was when Jason introduced two views of SOA Governance. He states:

There are two faces to SOA governance, however. On the one hand, SOA governance simply means governing a SOA implementation initiative — for example, communicating corporate policies to developers implementing Services, and giving them the tools they need to follow those policies as they assemble the various elements of the SOA implementation. On the other hand, there’s a broader, more strategic definition of SOA governance: IT governance in the context of SOA.

The example of IT governance that he uses later in the article is that of a business executive changing the SLA associated with a corporate report to require a one-day turnaround rather than a one-week turnaround. My first question is whether or not this constitutes SOA governance. This isn’t the first discussion around SOA governance that has broached into this territory, and the truth is that there is no solid definition of what is SOA governance and what isn’t.

The source of the confusion, as I see it, is that both areas Jason describes involve policies. Does this mean that the act of setting policies is always an act of governance? The concern I have with Jason’s example is that the act of the executive changing the policy is an example of poor governance. How many governments enable this kind of legislative power? This sounds like a dictatorship. I’m not implying that executives shouldn’t be empowered, but policies shouldn’t be enacted or changed without a thorough understanding of the consequences.

The second thing that struck me about this article is that in typical ZapThink fashion, this scenario is absolutely possible. It may not be the business executive, but it certainly could be an operations staffer, or even worse, it could be the system itself! I recently replied to a query on a mailing list about applying SOA in areas outside of business applications with an operational management scenario that was fully automated. The automation was controlled by policies that could be performed by intelligent infrastructure with operational interfaces exposed as web services, orchestrated through a BPM platform. All aspects of this are declarative in nature.

The real risk that Jason is pointing out has more to do with automation of processes that it does with governance. With more and more systems being configurable through declared policies, this leads to automation possibilities, which in turn can lead to exactly the possibility that Jason describes.

The takeaway, as I see it, is that the industry is continuing to move in the direction of empowering the user, all driven by a desire to have our systems be more flexible and responsive to business change. We have to think about what the impact of that future state is. If the business users have the power, what governance has to be in place around the changes that they can now make?