SOA Means Coming TogetherBy Bob Rhubart
Collaboration across stakeholders is key for SOA to succeed.
A service-oriented architecture (SOA) is a busy place, a complex clockwork of interconnected, interdependent, and widely distributed moving parts, including those that enjoy a nice cup of coffee in the morning. As such, SOA demands extraordinary collaboration across a broad spectrum of stakeholders. Getting those stakeholders to behave as a cohesive community can be about as easy as teaching bears to tap dance, but that cohesion is an important objective of SOA governance.
Oracle ACE Director Mike van Alst, principal consultant at IT-Eye in the Netherlands, describes SOA governance as an organizational process focused on guiding behavior. “It’s how you organize your work, how you organize your responsibilities, how you define your strategy and your mission, and translate all of that down to the technical artifacts,” van Alst says.
Cathy Lippert, Oracle’s director of product management for SOA governance, notes that SOA, compared to predecessor architectures, places increased demands on its stakeholders. “SOA, by definition, has to be a lot more collaborative because you have different people producing, providing, and consuming services, processes, and other assets,” says Lippert.
Sharon Fay, product manager for Oracle Enterprise Repository, compares SOA governance to a three-legged stool. “Governance really consists of people, process, and tooling,” she explains. “If you’re not thinking about all three legs of the stool, you’re not going to have effective governance.”
The challenge, however, is that although many SOA stakeholders understand the need for governance, few want to be governed.
“People view governance as some big, heavyweight review process with presentations to give and 100-page documents to fill out,” says Todd Biske, a senior enterprise architect at Monsanto and the author of SOA Governance (Packt Publishing, 2008).
Biske suggests that SOA governance should focus first on policies as a means of articulating the desired behavior. “That gives you the flexibility of executing in a number of different ways, ranging from a more heavyweight review process to more of an education- and communication-focused process to try to give people the information they need to make good decisions.”
From there it’s a matter of engaging the stakeholders who represent the primary lines of business in the organization. In order to ensure the necessary level of expertise, that effort should be led by an architecture team. “You really need a couple of good architects who are not only able to see through the quagmire of all of the decisions to be made in convincing the business to go a certain way, but also are able to show the vision to the rest of the organization,” says van Alst.
The architects can’t do that job without executive support. “Make sure that what you are doing in SOA and governance is in alignment with the objectives of key executives,” says Lippert. “Having that air cover is extremely important.”
Even with executive support, SOA governance shouldn’t alienate stakeholders along the food chain. “An architecture board will never be able to see it all, so you need input from all different levels,” say van Alst. That includes developers.
Fay recommends recruiting “alpha dogs,” developers who buy into the governance process and its value. “They turn around and tell their friends and really serve as advocates for the program,” she says.
Getting off to a good start means taking small steps. “Governance is an iterative and incremental process,” Fay says. “The important thing is to start simple, with a few things that are going to bring high value and high impact to your organization.”
Your governance will mature as your organization matures. Decisions will be made about how services are designed and used even if no formal SOA governance is in place, with potentially chaotic results. Taking the appropriate SOA governance steps to organize SOA stakeholders into a cohesive community will help to keep SOA on track by ensuring that those decisions are the right ones. Tap shoes are optional.
Bob Rhubart ( email@example.com ) is manager of the OTN architect community, the host of the OTN Arch2Arch podcast series, and the author of the ArchBeat blog ( blogs.oracle.com/archbeat ).