Policy-based SOA Will Enable Increased Business Value And Agility

[Posted by Randy Heffner]

One of my favorite Forrester survey statistics to quote about SOA is the proportion of service-oriented architecture (SOA) users that see how important SOA can be for changing their business. In our Enterprise And SMB Software Survey, North America And Europe, Q4 2008 (taken after the start of the current economic crisis), 38% of Global 2000 SOA adopters said they are using SOA for strategic business transformation. This is a very high level of business impact — and far more value than was ever credited to object-oriented or component-based development. Why is this important to note? Many think of SOA first as a technology for reuse, like objects and components, and miss the reality that SOA is much more about business design and flexibility. By missing the business perspective on SOA, they miss the fact that SOA is the foundation for a much broader shift in application architecture and its relationship to the design, monitoring, and optimization of business processes.

And this brings us to the importance of policy-based SOA as an area of technology strategy for enterprise architects to pay attention to. Many SOA adopters already use security and management policy with their SOA-based services, and the future allows a much broader impact by applying other types of policy, including business policy, to SOA implementations. Among Forrester’s top 15 technologies, policy-based SOA is the highest in terms of newness and complexity, which means that, although the potential for business flexibility and value is there, it will take longer to understand, plan for, and adopt policy-based SOA than it will take for other top technologies. As a first step, architects should ensure that they understand the concepts so that they can set the right time frame for building toward policy-based SOA as they build platforms and patterns for SOA.

To begin to understand policy-based SOA, consider security and management. Products like SOA appliances, enterprise service busses (ESBs), and SOA and Web services management solutions provide for policy-based that control service execution. You  define a security policy (e.g., “service requests must be accompanied by a WS-Security SAML token to identify the service consumer”) using the SOA product’s administration tool. At runtime, the SOA product intercepts the SOA request, applies the security policy, and either rejects the request (if the policy is not met) or forwards the request to the service for processing. The important point here is that the policy is declared separately from the service, allowing it to change without changing the service itself. In a similar way, policies for production monitoring (e.g., response time and availability) are declared separately and applied at runtime. Some of the benefits of this type of policy separation include:

• The active policy is easily and widely visible. If the policy is buried in the service implementation, the only definitive way to determine the active policy is to look at the code.
• The failure responses are highly configurable. SOA products provide multiple ways to respond to a policy failure, and these can be changed without changing the service.
• Monitoring and auditing are both configurable. SOA products can provide dynamically configured data for auditing service operations and usage.
• Monitoring may include business-level insight. Besides technical operations data, SOA products can extract business data from service requests and responses, thereby enabling business-level monitoring.

These same concepts can be applied to business policies associated with SOA-based services. Examples of such policies include:

• If total expenses are less than $50, route the expense report SOA request to the automated approval service, else route it to the manager approval queue service.
• If the submit order SOA request is from a gold customer, mark it to bypass the credit check.
• If the medical order SOA request is for a medical procedure from category 1, send an audit copy of the request to the medical quality assurance and risk management queue.

By extracting such decisions from the internals of service implementations, we provide the business with ready access for changing and optimizing business processes. But here’s the issue: Without a broad perspective on SOA policy, organizations can implement policy silos for SOA that duplicate tools and infrastructure for each different type of SOA policy. Security policy might be contained in an SOA appliance silo, management policy might be in an SOA management solution silo, business policy might be in an ESB silo. The two biggest problems this creates are 1) it is difficult to get a complete picture of a given SOA service’s production processing, and 2) it duplicates infrastructure and processes for policy authoring, auditing, and life cycle control.

Therefore, Forrester recommends taking a step back to understand the full possibilities, requirements, and business value of policy-based SOA. This will allow architects to craft an incremental and evolutionary strategy for starting small, typically with security or management policy, and growing into the full range of value available with policy-based SOA.

To read more about policy-based SOA, go to the five-part report series that begins with How To Get Started On SOA Policy Management.