Agile SOA Governance: Illusion or Reality?

by Paul Allen, Senior Consultant, Cutter Consortium

Many service-oriented architecture (SOA) governance initiatives become bogged down in a bureaucracy that militates against the very agility that SOA promises in the first place. Is there a way to achieve agile SOA governance, or is this simply an illusion? Fortunately, our experiences show that there are responsive and practical approaches to SOA governance. As with most things in life, balance is the key. In this Executive Update, we consider how to introduce SOA governance in a planned yet incremental fashion, in small chunks, with respect to prioritized business outcomes and risks.

Despite the promises of SOA, many organizations are increasingly encountering difficult governance issues as they start to ramp up their early SOA efforts. For example, if a service is to be widely used, then who owns the service, who funds it, and how is it specified in a way that consumers can readily understand? SOA governance is essentially a response to achieving consistent answers to these kinds of questions. However, it is a response that must not sit in isolation but as part of IT governance that in turn should be an enabler of business governance. We define SOA governance as follows:

The part of IT governance that refers to the policies and enabling factors that ensure that an organization's SOA efforts sustain and extend its business and IT strategies, in a way that manages the associated risks and achieves the desired outcomes.

If we examine this definition, we can see there are three dimensions involved:

1. SOA policy -- the "what" factor in terms of the rules to be followed

2. Governance enablers -- the "how" factor in terms of people, processes, and technologies

3. Adoption strategy -- the "when" factor in terms of plans to make governance happen in tune with the organization's SOA maturity level

SOA POLICY

Policy is the keystone of governance. Without policy, governance is like a train without tracks. A policy is a set of assertions that govern specific policy subjects and are restricted to certain policy contexts. Some policies are mandatory, while others are guidelines. ¹

An SOA policy governs some aspect of services, as illustrated in Figure 1, which depicts a selection of types of SOA policy in a pyramid from business-IT alignment (at the top) through IT practices to infrastructure (at the bottom). There are several things to note about this pyramid.

Figure 1 -- The SOA policy pyramid.

First, a wide diversity of policies must be defined and managed. They will call for good planning and administration as part of an overall SOA governance framework.

Second, the overall categories -- business-IT alignment, IT practices, and infrastructure -- are general ones that allow dovetailing of SOA policy with your organization's existing IT policy. This is important for political as well as technical reasons, as any SOA governance initiative needs to sit comfortably with the status quo.

Finally, most of our industry's attention thus far has been focused on the lowest layers of the pyramid, reflecting of course on vendors' desire to sell software products supporting governance, such as policy management engines. Now, while an important part of SOA policy concerns technology, if an organization focuses solely on how its services are deployed and managed without paying sufficient attention to the business drivers and the IT practices used to build services in response to those drivers, that organization is very likely to end up with a set of well-managed "service spaghetti" -- point-to-point services masquerading as an SOA that simply relives an earlier integration nightmare using just another layer of technology. It is therefore in the upper layers of the pyramid where we need to raise our game, particularly if we are to achieve agile SOA governance.

ENABLING SOA GOVERNANCE

The enablers of SOA governance are usefully split along the familiar lines of people, process, and technology.

People enablers perform the roles necessary for SOA governance. Some of these roles are specifically focused on governance matters; for example, the SOA governance board and the SOA governance lead. Others, such as the SOA review board, may have a "leaning" toward governance.

Process enablers operate at management and operational levels. The former should be centralized as far as possible and is concerned with identification, definition, and maintenance of policies. The latter is distributed at the points of application and is concerned with enforcement of policies.

Technology enablers concern implementation of automated support for SOA governance and may include service catalog and repository, policy management and enforcement engines, and tools for modeling, service- level management, and change management.

ADOPTION STRATEGY

Some form of SOA maturity assessment is essential to gauge the adoption level of the organization in terms of the increasing scope of the effort, ranging from early proof-of-concept to full-blown partner programs much later. By performing a gap analysis ² of existing SOA governance capabilities (policies and enablers) against recommended capabilities defined within a maturity framework, we can start to prioritize and plan required SOA governance capabilities.

At the same time, while an idealized implementation plan is necessary, the introduction of SOA policies and governance enablers requires careful handing. There are potentially hundreds of policies, and we do not want to swamp the governance undertaking before it gets off the ground, making life too onerous for architects and developers alike. Moreover, many organizations face hybrid software and hardware environments -- a legacy jungle -- that have evolved over a number of years. A balanced approach seeks to cut a path out of the legacy jungle in a step-by-step way. We need to evolve the SOA by managing risk through incremental business process improvements. In short, we need "just enough" policy.

Organizations must move forward at their own pace and in a way that is realistic in terms of their current SOA adoption level. Moreover, the approach taken to SOA governance must be in tune with the overall governance requirements and political climate. SOA governance has to be seen as one component in organizational change management. We recommend an incremental approach over increasing scope and business focus, as illustrated in Figure 2. Thus, policies toward the top of the policy pyramid grow in importance as we move through time.

Figure 2 -- An incremental approach to SOA governance.

JUST-IN-TIME SOA GOVERNANCE

In the early stages of SOA adoption, the emphasis is on basic technology enablers and infrastructure policies. As the organization moves through the stages of adoption, we must turn increasingly upward through the pyramid.

In addition, our experiences show that it is a mistake to lead with change. We need to identify and prioritize the business outcomes that SOA should support and map these outcomes to desired SOA outcomes. This requires a certain ingenuity or flair.

For example, suppose a company commissions a quick SOA maturity assessment that reveals its SOA projects are out of control and that governance is required to bring things back in line. It transpires that the company's stock price has suffered because of poor customer experience and that a key contributing factor is identified as the inability of supporting software systems to accurately track and trace the handling of complaints, despite the prior introduction of a complaints service. As a result, the complaints-handling process falls far short of the desired outcome of, say, 90% resolution of complaints within 24 hours. However, there is now no way to measure the satisfactoriness of the complaints service. And it turns out, when we check the SOA maturity assessment, we find this is fairly typical of many of the services that have been developed -- in short, misalignment of services with business requirements turns out to be a major risk factor, a "governance hotspot."

How might we start to address this situation? A practical approach to agile, or just-in-time SOA governance needs to recognize that it is too early to attempt the challenge of moving to a pure supply-consume software process based on a complete SOA governance framework. In our example, we might introduce a simple policy that states that every service must support at least one business process and associated business outcome. We'd then plan to introduce the right people (service architect), processes (SOA lifecycle deliverables), and supporting technologies (policy engine) to implement this policy.

Of course, it's important not to trivialize the effort involved. For example, such an approach includes introducing some of the key disciplines of the SOA process in an evolutionary fashion through an SOA center of excellence. ³ The emerging new SOA disciplines should then work in iterative fashion within the context of the incumbent software lifecycle. However, we will have been tackling a real business problem with a measurable outcome on the end of it: 90% resolution of complaints within 24 hours.

SUMMARY

Enterprise-wide adoption of SOA governance poses a significant organizational change management challenge. While SOA governance frameworks and maturity models provide structure and direction, they must not be allowed to sink the IT ship through sheer weight of bureaucracy. While just-enough planning is essential, agile SOA governance must attack measurable business outcomes in a timely fashion, using imagination and flair. In addition, it must sit comfortably with respect to existing IT governance structures and software lifecycles, leveraging the status quo with minimal political disruption.

ENDNOTES

¹ Allen, Paul. "Quality of Service: You Can't Measure What You Don't Specify!" Cutter Consortium Enterprise Risk Management & Governance Executive Report, Vol. 5, No. 3, 2008.

² Rau, Kenneth. "The Gap Analysis: A How-To Guide." Cutter Consortium Business-IT Strategies Executive Update, Vol. 10, No. 11, 2007.

³ Allen, Paul. "The SOA Center of Excellence." Cutter Consortium Enterprise Architecture Executive Update, Vol. 11, No. 14, 2008.

ABOUT THE AUTHOR