Teaming up for SOA

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 (center of excellence). A COE can showcase best practices, evangelize SOA, and answer questions. “Creating a center of excellence helps communicate the tough lessons learned about SOA to the rest of the organization,” says Bob Laird, an I T architect in IBM’s SOA practice. “The center 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 center 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 MomentumSI’s 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ïve fashion — you can end up in big trouble. “Figure out how it all ties back to the IT governance

and funding process,” he says, “or service development will fall by the wayside when project pressure builds.”

Further downstream, be sure to align financial incentives with governance objectives: If people are rewarded for doing things that are counter to building an effective SOA process in your organization, you’ve lost the battle before you’ve begun. Cultivating successful SOA projects may require that you change how money gets allocated to projects. Biske recommends a “funding funnel” that identifies the cost of initial projects, plus or minus 50 percent. “At each iteration or major milestone in the development process, do a review,” he says.

In other words, at each stage, the collar on the project cost can be tightened until the true cost is dialed in. Biske adds, “project scorecards provide the information for making the right decisions.” With sufficient projects in the overall portfolio, some will come in high and some low, providing good budget control and flexibility at the same time.

 

One step at a time

Governance isn’t something you build and then use; it’s a constantly evolving entity that must have the methods of its own evolution built in. As such, you shouldn’t feel pressure to get it all done. In fact, diversity of implementation should be expected, according to Anil John of Johns Hopkins. “There is no one-size-fits-all when it comes to governance.” Be proactive at putting a few good policies and processes in place and then listen to feedback.

Remember that the point of governance is to encourage proper behavior. Monitor how your SOA efforts are working — or not. John adds, “The desirable behaviors that need to be encouraged in an SOA implementation may conflict with the existing mechanisms in place as part of IT governance. The mechanisms that are in place for the management of IT need to be extended and modified to account for SOA.” When you find resistance to the SOA goals you’ve set, modify the process. Governance that monitors its effects and evolves is the only kind that will ultimately succeed.

— Phillip J. Windley