by Randy Heffner

Get SOA Policy Management Right: A To-Do List for IT Leaders

May 06, 20096 mins

IT leaders must understand the general characteristics of the SOA policy life cycle. This will help you to watch over critical control points and organizational relationships. Here's some practical advice from Forrester Research SOA expert Randy Heffner.

IT leaders must understand the general characteristics of the SOA policy life cycle. This will help you to watch over critical control points and organizational relationships. Here’s some practical advice from Forrester Research SOA expert Randy Heffner. SOA policy management is an advanced means of building flexibility and business value into service-oriented architecture (SOA) strategy. SOA policy is emerging as a feature in many types of SOA related products, and your architects should have it on their radar screens. If it sneaks into your SOA strategy without a clear plan, your organization may paint itself into a corner and miss important opportunities to achieve SOA policy benefits.

SOA policies are defined separately from the SOA-based services they control, which allows flexibility in different domains of service characteristics ranging from business operations (monetary limits, transaction routing, etc.), service-level management, deploy controls, security, and more. SOA policy management adds value in two ways: 1) it allows your SOA-based services to change more quickly in response to business changes, and 2) it extends and reinforces your SOA governance processes during both development and production operation, resulting in more reliable and efficient SOA operations.

From your perspective as the CIO or IT leader, it is important to understand the general characteristics of the policy life cycle, which will help you to watch over critical control points and organizational relationships. Key characteristics of getting the SOA policy life cycle right include:

Getting a clear connection with the original source of the policy. Every policy has at least one original source within the organization—a person or team that directly cares about, is responsible for, or is affected by the policy. Your policy management processes must have appropriate integration points and approval checkpoints with these varied original policy sources.

Elaborating policy from the general to the specific. In the early stages of the SOA service life cycle, a policy may be specified in a more general, abstract way, but your SOA platform can only enforce that policy when it is rendered in a concrete, executable form. The policy life cycle, including policy authoring and management tools, will control the transformation and/or translation from abstract to concrete policy—and ensure traceability between the source and the final implementation.

Managing groups of related policies. For some policy domains and policy types, it is useful to manage a group of related policies as a set. For example, to streamline service-level agreements for your SOA services, the service user might choose the appropriate entry in an operations policy group (perhaps with higher chargebacks for higher QoS). Policy groups help to curb growth in the number of policies the organization must manage. They also simplify the model for executives, who can refer simply to the policy group without knowing the details of all the policies in the group.

Ensuring appropriate policy change control. Runtime policy changes, by definition, change the operation of production systems, which affects IT and business operations. SOA governance specifies that there should be appropriate controls over policy changes, but the specific levels of and mechanisms for control will vary by both policy domain and type of policy. Your policy management processes must support a variety of flexible control mechanisms for approving and activating policy changes across the various policy domains and types.

Building an appropriate “air gap” between development and production. Auditors examining your IT processes, applications, and infrastructure, driven by both good industry practice and regulations such as Sarbanes-Oxley, will want to find a clear and definitive separation (i.e., an “air gap”) between development and production. The key requirement is that only those responsible for production operation should be able to activate anything (policy or otherwise) within the systems running the business. Conversely, those responsible for activating production changes should have no ability to materially alter the content of the production changes. Policy management blurs this line by externalizing aspects of a service that were previously contained in the program code of an application. Thus, your processes and infrastructure must provide for the service policies authored at development time the same type of controlled, staged migration that all other production application assets go through.

The industry’s infrastructure and best practices for SOA policy management have much room to grow before they will be robust and mature. Thus, only very early adopter organizations are typically ready for full-on pursuit of SOA policy management. More conservative firms should take small steps, going only so far as using the out-of-box capabilities of their SOA security and management infrastructure and their SOA repository. But even with these first steps, it is important for architects to understand the scope of the SOA policy management life cycle and its key touch points with SOA governance and the SOA service life cycle. CIOs should hold architects accountable for ensuring that early steps with SOA policy have a path forward to a broader and deeper use of SOA policy.

To evolve and build policy management into your SOA governance and life-cycle processes:

1. Start by identifying the policy domains you will first use. Policy domains will drive the highest priority requirements for your policy management processes; therefore, identifying these domains will do the most to scope and prioritize your policy management implementation tasks. This provides a focused starting point, from which your architects should understand how additional policy domains will be added in the future.

2. Identify and implement policy approval points. As you expand policy management to each new policy domain, identify where and how approval for policy changes will take place as well as who will give approval. Starting with policy authoring tools, design either manual or automated approval processes according to the capabilities of your infrastructure and tooling (and, potentially, the affordability of customizing the tooling to implement automated or workflow-based approvals). Effective approval processes provide a strong foundation for effective, controlled policy management.

3. Plan for and implement policy assessment. Do not assume that the job ends with simply enforcing policy. Downstream auditing and compliance is an important sometimes mandatory part of the process. Even if it were not, policy management is most effective when the loop closes with assessment and ongoing improvement of policy operations.

Randy Heffner is a Vice President at Forrester Research, serving Enterprise Architecture professionals. He is a leading expert on architectures and design approaches for building enterprise applications that are secure and resilient in the face of continuous business and technology change. Randy will be speaking on how to take SOA governance to the next level at Forrester’s IT Forum 2009.

Follow everything from on Twitter @CIOonline