Guide to SOA governance

To hear Benjamin Moreland tell it, service-oriented architecture governance is a constant corporate battle against techno-clutter. “We don’t want a junk drawer of unsupported services in our SOA registry,” says Moreland, director of IT foundation services in the Property and Casualty group at The Hartford, an insurance company in Connecticut.

To keep SOA development from spinning out of control, Moreland requires that before anyone publishes a new service to the company’s SOA registry of reusable code, IT support must be lined up. “If a business group requests a new service, we want to make sure that there are IT groups to maintain and support that service,” he says.

Within its P&C group, The Hartford has implemented top-down governance that keeps business and IT groups from proliferating junk services to the group’s master Universal Description, Discovery and Integration (UDDI) registry. This approach to SOA governance is emerging as an industry best practice.

“You can’t scale an enterprise SOA if you don’t automate governance through administrative workflow,” Moreland says. But he adds an important caveat: “As more services are developed on your SOA, that workflow could become a bottleneck.”

And make no mistake: SOA governance often involves new layers of business and IT bureaucracy. In other words, companies may need to institute a high-level planning and prioritizing process, under which new services are approved and SOA-wide corporate policies are hammered out. The policy decisions made in this occasionally political process govern how the corporate SOA is implemented in design time and operated in run-time.