Singing from the same song-sheet

One of the most difficult aspects of SOA implementation is ensuring successful collaboration among the many groups involved. This article offers some sound advice around getting all the players to sing in harmony.

Most organizations start down the road to service-oriented architecture with a pilot project of some kind. The result is often a great technology learning experience and a handful of useful services upon which a related set of apps can be built and modified easily. But an isolated project seldom builds the skills needed to persuade multiple groups to collaborate on broader SOA development.

The path from an isolated SOA project to an initiative that spans various departments or business units crosses a Rubicon. “A new set of individuals entering into a federation is an inflection point. Each of these tribes brings their own culture. When you’re running a pilot there’s one tribe. Moving beyond the pilot means involving more cultures – and that changes everything,” says Miko Matsumura, vice president of SOA product marketing for webMethods.

Simply put, good governance requires intense collaboration. The technical parts of SOA aren’t the most difficult. Instead, the hard stuff centres on what some pundits call “Layers 8 and 9” of the OSI seven-layer model: economics and politics. Governance is all about managing Layers 8 and 9.

In the book IT Governance, Peter Weill and Jeanne Ross define governance as “specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.” According to Anil John, enterprise architect at Johns Hopkins University’s Applied Physics Laboratory, “SOA governance should be considered an extension of existing IT governance that deals with the decision rights, processes, and policies that are put into place to encourage the adoption and operation of an SOA that may cross ownership boundaries.”

Governance deals with patterns of interaction, acceptable standards, and the creation of communication channels. Done right, governance also aligns the incentives in the organization with the goals of SOA and sets up SOA support structures.

Scaling up IT governance to match SOA ambitions doesn’t have to be paralyzing, boring, or difficult. All you need is a rational, collaborative approach.

Building a Governance process
IT managers who embark on the SOA journey tend to think of SOA governance in terms of project planning and funding. Those are vital activities, of course, but technical governance – policies, interoperability frameworks, and reference architectures – is where the rubber meets the road. The most important thing to get right in the governance process is to establish the communication patterns that will create, approve, and propagate these artifacts.

The trick, says Todd Biske of the consultancy MomentumSI, is to use the appropriate governance tool at every phase: “You need to bring the right parts of governance (project, funding, and technical) to bear on the project at the right time.” Project, architectural, funding, and customer reviews tie governance to implementation in appropriate ways and make governance tangible to architects and developers.

The enforcement mechanisms you build into governance are crucial. If you’re not enforcing policies, they’re just suggestions. We’re not talking about thugs in jackboots; just make sure that architectural reviews, routine audits, project scorecards, and other measurement activities are tied to natural gating activities such as project planning, project funding releases, and code promotion.

Equally important is to ensure that your process includes an effective feedback loop. As webMethod’s Matsumura says, “A governance mechanism is intrinsically federated. It is neither a ‘you must follow this cookbook’ nor is it something that’s completely fluid. Create a structure that allows for evolution. Policies are manifested in law, and law evolves according to feedback from enforcement. Adjudication procedures built into your governance process will provide feedback on your enforcement process.”

Feedback mechanisms should also include a review board for the process itself, because constant tweaking of the process is a fact of life. A review board leads to continued evolutionary improvement.