Governance ensures consistency across projects

Service oriented architecture governance is a critical success factor for any organisation wanting to pursue SOA as a software delivery strategy.

Service oriented architecture governance is a critical success factor for any organisation wanting to pursue SOA as a software delivery strategy.

If you are just starting out with SOA (running a pilot, executing the first project or two), then it is not going to be top of your list to think about.

However, as soon as you get a few projects in and want to apply SOA consistently across projects and over time, it is really important to have processes and supporting technology in place that can help you get a high level of consistency in what you do.

That is what governance really is about in the context of SOA. Re-use is possible without a coherent governance approach, but it is a lot easier to build services for re-use, and then reuse those services, if you are tackling quality management issues consistently through the service lifecycle.

Governance comes in a couple of "flavours", but there is really just one issue: how can you ensure that your different teams and skill sets - from requirements management, through design, development, deployment, operation and subsequent change management - are properly aligned and handing off to each other effectively?

However, the "market" seems to have decided that there are two parts to the story: "design time governance", which focuses on quality issues when you are building services, and "runtime governance", which focuses on helping with quality issues with services once they are deployed.

You cannot have everything. At least people are starting to think about the issues.

At design time, governance systems invariably revolve around some kind of development metadata store where you store all your artefacts and manage them effectively.

At runtime, governance systems invariably revolve around some kind of runtime metadata store for storing service level agreements, policies, service interface details, and so on, and quite often a set of "agents" which sit in the network, monitor runtime behaviour and (sometimes) actively enforce policies that you set in order to control runtime behaviour.

For example, you can set security policies which are enforced to ensure that all inter-service communication is encrypted.

Read more on Web software

JavaOne: JBoss on SOA middleware, Java EE and data services There's traditional middleware and then there's SOA middleware and determining where they might converge or diverge is still a work in progress for vendors, says Craig Muzilla, vice president of Red Hat Inc.'s Middleware Business Unit. At JavaOne in San Francisco this week to tout Tuesday's release of Red Hat's JBoss Operations Network (ON) 2.0 integrated middleware management platform, he acknowledged that the product is only a first step when it comes to SOA management. Before the technology can advance, vendors need to define what makes SOA middleware unique and where it fits into the larger middleware picture, which is a question he hopes to have answered by the end of the year. Since he was at Sun Microsystems Inc.'s annual Java conference, he also pondered the future of the Java Enterprise Edition. And finally, on the one year anniversary of Red Hat's acquisition of MetaMatrix, he offered an update on the emergence of data services.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.