Governing SOA

SOA (service-oriented architecture) promises enterprises endless advantages: increased code reuse, reduced integration expense, better security, and -- the big payoff -- greater business agility. Whether you achieve those benefits, however, probably has more to do with your policies and procedures than the quality of your code.

Counterintuitive as it may seem, SOA requires more organizational discipline than previous development models. Your intuition might tell you that flexibility results from fewer rules, not more, but that's not the case.

Think of today's automobile: The reason you don't have to go to the Ford tire store to buy new tires for your Ford car is a direct result of standards, processes, and regulations. These rules and regulations give you the flexibility to buy tires anywhere and know that they will work on your vehicle.

That sort of standardization provides the underpinnings for SOA across an organization. To prevent IT from being overwhelmed by this new complexity, the industry has created classes of software -- registries, repositories, and run-time management systems -- that help keep all the rules straight. But creating an SOA demands more than using SOA-based tools. It requires that IT organizations make serious choices about design, which results in design rules.

Rules to live by

Design rules specify interfaces, eliminate certain paths from consideration, and delineate boundaries between subsystems. A primary goal of architecture is to increase modularity and create well-defined abstractions based on service APIs. After those choices have been made, they must be recorded, communicated, and enforced. Design rules combined with enforcement are typically called "policies."

Click for larger view.

The development and enforcement of SOA policies and procedures goes by the name SOA governance. Governance and architecture go hand in hand. In the same way that building codes, standards, and even inspections give building architects a context within which to work and ensure that their designs will fit in the community, SOA governance provides context for system architects and designers.

"Without SOA governance, you end up in a Web services version of DLL hell," says Roman Stanek, chief software architect and founder of SOA registry provider Systinet. "SOA governance gives consistency, predictability, and allows big apps to be built from small pieces."

If you've already got a strong IT governance process in place, it will serve you well as a foundation for SOA governance. If you've relied on informal governance in the past, moving to SOA will likely require some changes in how you manage development and operations. "Most organizations will fail miserably if they don't implement the right form of governance," says Anne Thomas Manes, vice president and research director at Burton Group. "SOA is about behavior, not something you build or buy. You have to change behavior to make it effective."