The purposes of SOA governance has been to set the architectural vision and direction, lay the ground rules under which those activities are going to take place, and then foster collaboration between architects, and other people who engage in the processes of building solutions for companies, be they consumer focused, or be they within enterprise IT.
The whole thing is tracking your progress, where are you in this journey. It's not about installing a new pack of middleware and then declaring victory. You really have to measure along the way what you are doing, and how far you have gotten. Some measures that people start off looking at are things like reuse.
The whole notion of providing a service is to hide the layers of abstraction and to hide the complexity behind layers of abstraction, so that we can make changes behind the scenes that don't necessarily disrupt or alter the offering of the service. There are a lot of examples of this in the real world. Why hasn't IT been able to do a better job of capitalizing on those things?
This is one of those transformation opportunities. We're not just talking about Web services. We're talking about different ways in which we need to be able to flexibly compose and offer capabilities back to the business through a channel called a service. ... The adoption of services as a fundamental unit of commerce, if you will, within IT does something very fundamental to the way that people work together.
From HP's perspective, we are definitely trying to make sure that the collaboration between architects, quality assurance professionals, and operations personnel are there. That's kind of announcing that the various solution offerings that we're bringing to market are to make sure that none of these is an island. Those control points can reasonably be connected and allow for collaboration across all the different participants.
We're learning lots of interesting things about IT, and in particular, the ways that we can do things better. The whole notion of instilling an architectural vision to support change and flexibility; to give tools to the folks who are building composite systems, so they can better manage the roles and responsibilities for the various people that are participating in that; and better communicate with operations is something that we haven’t done very well.
It's really a matter of mapping your organizational maturity and what you're trying to achieve with the appropriate tools. People shouldn't be running out and buying tools, unless they really understand what problems those tools are going to solve, and the fact that certain organizations can introspect what they have done in the past and say what problems they want us to solve and or avoid.
The lessons that we're learning ... are specifically being applied to SOA right now, [but] have more far-reaching implications. As we look at things, like the different compositional patterns for systems that are coming -- Web 2.0 technologies, Ajax, rich Internet applications (RIAs), putting front ends on some of these things, or cloud computing -- all of these things are interrelated. My question is, should we not be applying these fantastic concepts and activities that we have been establishing through SOA governance more broadly to support all of these different types of next-generation composition?
From HP's perspective the answer is absolutely. The question is at what point are we going to be talking about next-generation application lifecycle management, or next-generation application composition and stop talking about SOA by itself as an island.
... There are more people coming to the table, more constituents coming to say, “How can I connect to these governance activities that are going on for services, but really for the purpose of generating some new business outcomes?” That, to me, is tremendously exciting.
I think one of the things you're going to see -- I'm not sure how far in the future, it's coming up more and more these days -- is an emphasis on understanding the business-to-business connections, or what some folks will call "federation."
I want to be very specific when I say "federation," because it is one of those overloaded terms that creates a lot of mystery. If we can take the wraps off of federation, what we're talking about is a pattern for how to expose the capabilities that I own within my domain to other domains. Those other domains could be within my organization, they could be elsewhere, or they could be third parties.
The good news is that SOA fundamentally supports that type of activity. The question is how well the tools support that activity today.
As we move into a more comprehensive cloud set of offerings, we're going to need to federate the different instances of services, metadata, their ownership, the consumption of those pieces, and really formalizing the relationships of using tools between the consumers and providers of those things.
When I say establishing relationships, I think about trading-partner agreements that get put in place, or supply chain agreements. They get put between supply chain partners about what information they're going to share and in what context they can use that.
We're really talking about doing the same kind of formalization with the consumption and providing of these various capabilities, in order for models like SaaS and cloud to scale up to the level that they need to in order to make a significant impact.