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.
In the end, the governance process you create must match the culture of your organization. Some companies do better with more centralized processes, while others have better luck with decentralization.
Building an SOA enterprise architecture
An SOA enterprise architecture is one of the most important artifacts that the governance process produces. But building one is no small feat. In fact, you might as well reconcile yourself to the idea that it will never be completely finished.
So what’s the order of assembly in the never-ending task of building an SOA enterprise architecture? For many organizations, the most effective route is to build pieces just in time. Start with an interoperability framework, since it’s the easiest part of the enterprise architecture to create. An interoperability framework is a list of supported standards that has been annotated with meta-information, including status indicators that say which standards are required, suggested, supported, or ready for sunset.
As a rule of thumb, work on policies that will make the biggest difference first. Almost every significant SOA project, for example, chokes on authentication and authorization issues at one point or another. Without a coherent policy, each project will go its own way and the result will be incompatibility and costly retooling later on.
Registries are another area where policies can make a difference early on. Plan out your registry strategy and then make sure that you have policies in place to support it.
Enterprise and system-level reference architectures show developers, architects, and project managers the preferred way to do everything from building hooks in their code for WSM (Web service management) tools to preferred hardware deployments for high-availability applications.
“If you don’t have a reference architecture in place, the project team will take the path of least resistance,” says MomentumSI’s Biske. “Reference architectures can be too general, giving the application architect too little guidance, or too specific, giving them no leeway.”
Biske also makes a strong argument for reference architectures as part of the review process. “Architectural reviews tie the project back to the reference architecture, but if there’s no documentation that projects can be judged against, the architectural review won’t have much impact.
Investing in the right tools
Some organizations put off buying registry and WSM tools in the interest of cost, hoping they can show value first and ask for the tools budget later. The problem with that strategy is that you give up some of the most effective incentives you have to establish governance early in the game.
Registries are used for managing and communicating governance artifacts as well as automating key governance activities. Registries are also important for enforcing policies. By setting up a registry for production-level services and writing policies to achieve that status, you can control the properties of services that are used inside your organization. For example, you might require that production-level services meet certain security, identity, and even financial standards. Reviews of the service before it’s promoted to production can enforce those policies effectively.
Where registries provide the leverage you need to enforce design-time and deploy-time policies, WSM systems – such as those that Actional, AmberPoint, and SOA Software provide – help enforce runtime policies. Because WSM tools proxy deployed services, they can ensure that authentication happens in a certain way or that service levels are met.
For policies they can’t enforce directly, WSM systems provide a single point for auditing and logging service interactions. In addition to being a critical part of SOA governance, WSM tools also save developers from building features such as security, logging, and exception handling into their code, thus increasing reuse and code correctness.
Evangelism and expertise
Governance works best when it’s built into the organization. One of the organizational support structures that practitioners mention time and again is the COE (centre of excellence). A COE can showcase best practices, evangelize SOA, and answer questions. “Creating a centre of excellence helps communicate the tough lessons learned about SOA to the rest of the organization,” says Bob Laird, an IT architect in IBM’s SOA practice. “The centre of excellence spreads expertise, develops standards, and communicates best practices.”
In many cases, PMOs (project management offices) already control how and when projects happen, so they’re a great place to set up unintrusive enforcement. Laird says, “A strong project management office organization is critical if projects are spread across multiple development silos. Without the PMO, you get integration gridlock. The PMO governs the project portfolio and works with the centre of excellence, which provide enforcement and adherence to standards for those projects, thus increasing interoperability.”
Along the way, the funding process can be your best friend or your worst enemy. As Biske notes, “Scope gets defined early, but when you get into the project, you find out that the scope has changed.” If it’s difficult or impossible to scale funding levels accordingly – probably because the project was defined in a na
