Organizations use policy to guide decisions that are important to both the business and IT. Many times, policy is reactive, and created as a result of something negative happening. The SOA Policy Reference Architecture shows how the practitioner can be proactive with policy creation and maintenance, including the ability to manage and automate that policy. This article and its more detailed attachment provides a framework for defining policy starting with business goals and objectives and then decomposing those into the business, architectural, and operational policies necessary to properly control the organization. An example of using the SOA Policy Reference Architecture to create the policy decomposition will be given to aid the reader in understanding the details.


Robert Laird, Executive Architect, IBM  

Robert LairdBob is an Executive Architect with IBM in the SOA Advanced Technology group, performing worldwide consulting for IBM customers in the area of SOA Governance and SOA Architecture since May, 2006. He is a co-author of IBM's SGMM (SOA Governance & Management Method). He is a member of the industry TOGAF (The Open Group Architecture Framework) SOA Governance working group, has written two books on SOA: 'SOA Governance, Achieving and Sustaining Business and IT Agility', and 'Executing SOA, A Practical Guide for the Service Oriented Architect', and has two patents pending in the area of SOA Governance. Bob has over 20 years experience in the telecom industry at MCI and Verizon Business. He was the MCI chief architect, leading the enterprise architecture group and working across the entire order to cash suite of applications. He led the development of the SOA based single stack strategy to simplify the multiple network and applications silos. Bob has driven the strategy, planning, and execution of MCI's product development in the area of contact centers, IP/VPN, VOIP, IMS, and managed services. For OSS, he has led successful implementations to automate network provisioning, network restoration, and network management. Prior to joining MCI, Bob worked as a consultant for American Management Systems (AMS) and Ideation, Inc. He has MS and BS degrees in Computer Science from Purdue University and has been granted two patents in the area of telephony. He has spoken at various industry forums, written for The SOA Magazine and been quoted in CIO Insight, Telecommunications, Infoworld and Computerworld.

John Falkl, Distinguished Engineer and Chief Architect, SOA Governance, IBM  

FalklJohn Falkl is an IBM Distinguished Engineer and the Chief Architect for SOA Governance within IBM’s Software Group. John’s responsibilities include driving the overall technical strategy and product requirements for SOA Governance functionality, as well as coordinating SOA Governance activities across IBM organizations. John led the Governance Incubation Project for the IBM Software Group CTO. With this project, John led the establishment of key SOA Governance processes and aligned the software product strategy against these baseline use cases. Of his 28 years with IBM, John spent 12 years in IBM Global Services where he lead a number of high impact projects, most recently the definition and development of an SOA Management service offering for IBM’s Global Business Services organization. John holds 3 industry certifications in IT Technology and has a significant background in enterprise architecture and development (including 9 years in management). John has also led many high level technology studies within IBM.

Stephen Cocks (, Senior Software Engineer, IBM

Stephen Cocks headshotStephen Cocks is a senior software engineer at IBM's development laboratory in Hursley, UK, where his current responsibilities include working with product teams to define, architect, and deliver SOA policy-based capabilities. Since joining IBM in 1989 Stephen has worked in a variety of roles on many of IBM's key WebSphere products including IBM Business Process Manager, IBM WebSphere Enterprise Service Bus, and IBM WebSphere Application Server.

Arnaud Le Hors (, Software Standards Architect, Linked Data Standards Lead, IBM

Arnaud Le HorsArnaud Le Hors, a member of IBM software standards group, is responsible for driving the coordination of several IBM standards activities from a strategic and technical point of view. Arnaud has been working on open standards for 15 years, both as a staff member of the X Consortium and W3C and as a representative for IBM. He has been involved in every aspect of the standards development process, including technical, strategic, political, and legal, both internal and external to an SDO and to a company like IBM. Arnaud was involved in the development of standards such as HTML and XML and one of the lead architects for Xerces, the XML parser developed by the Apache Software Foundation. Arnaud is currently IBM's Linked Data Standards Lead.

Duncan Clark (, IT Architect, IBM

Duncan ClarkDuncan Clark is an architect currently managing requirements for integrating the IBM Operational Decision Management product with other IBM products and solutions. He is based in IBM Hursley Labs and over the last year has been responsible for demonstrations and integrations including IBM ODM, BPM, and Tivoli products. He managed the integration of the ILOG embedded Rules into BPM 7.5 and the development of support pack LA71 providing integration tooling and development patterns for using ODM with Business Process Manager. Prior to this, Duncan was an architect working in the WebSphere Service Registry and Repository team with responsibilities for the SOA Governance and Policy Management aspects of WSRR.

Andy Ritchie (, Senior Software Engineer and Architect, IBM

Andy Ritchie is a Senior Software engineer and architect in IBM focused on BPM and Decision Management. His main focus is on joint solutions with multiple IBM products and regularly works with IBM services and technical sales teams on client solutions and methodologies. With more than 27 years in IBM he has a broad and varied experience. Business Policies and rules are part of his core role in Decision Management working on Banking, Retail, Telecoms solutions for Eligibility, Compliance and Pricing decisions and rules. He has also architected IBM SOA Middleware, solutions in multiple industries so SOA Service Governance with Policies is also key. Previous to this he spent an 18 year period in IBM Development on ISDN, X.25 communications and Speech products.

09 August 2012

Also available in Japanese Vietnamese

How to Use this document

This document is meant to be a brief tutorial for understanding and using the SOA Policy Reference Architecture. For a more detailed understanding on this subject, including a fully worked example, access the full document from the Reference section.

Consider the figure below for an understanding of typical policy roles for who would be Creating, Authoring, Administering, Managing and Enforcing SOA Policies:

Figure 1. Roles for Usage of the SOA Policy Reference Architecture
roles for soa policy

SOA Policy Reference Architecture Description

The SOA Policy Reference Architecture is based around the management of services using policy as shown in the figure below.

Figure 2. SOA Policy Reference Architecture
Business Policy, Architectual Policy, Operational Policy

The SOA Policy Reference Architecture layers its representation of policy to support the existing SOA roles and personas.

  • The Business Layer should be led by a business analyst or a representative from the business who can specify the needs of the business.
  • The Architecture Layer should be led by architects who are responsible for the integrity of the SOA.
  • The Operational Layer reflects the specification of the runtime policy that implements the operational policy patterns.

Business Policy Layer

At the highest level of abstraction, a policy is simply a statement of a specific business need. At this level, the policy is normally expressed in natural language (for example, English, French, and so on) and is used to communicate business requirements between business analysts and IT professionals. As the two parties begin to collaborate, this business policy is then decomposed into a set of objectives, strategies, and tactics that define the details of how the business requirement is going to be implemented and enforced across the organization.

Those business policies need to be defined in the context of the business solution to which they apply. Services will usually have traceability to the business capabilities that they deliver, so that it is usually possible to quickly relate a business policy to the services that it will need to influence.

One the business requirements have been decomposed into policies that can be applied to sets of services, the Architectural Policy layer is used to define the common patterns that can be used to enforce those policies.

Architecture Policy Layer

The architectural policy layer provides patterns for integrating policy into the architecture adopted by the enterprise. Policies may apply to the way a service behaves (e.g. controlling a pricing service through policies defined in business rules) or they may be applied to the use of one service by another.

Operational Policy Layer

The Operational policy layer provides the deployed products and software infrastructure that realizes the business solutions and the use of policy within those solutions. The SOA Policy reference architecture defines a number of components that characterize the way policy is realized in operational SOA solutions.

Policy Solution Example

The following figure shows a very simple example for a Service Level Management requirement.

Figure 3. Policy Tree example of SLA Policy Top down analysis
Business Policy, Architectual Policy, Operational Policy

Business Policy Layer Solution

The policy tree analysis starts with a high level, simple statement of the business policy requirement, such as one may obtain from the business user or business analyst. This statement is then refined, still at a business level, to specify in more detail the implications of the business policy requirement, as wells as what needs to be measured to ensure policy compliance.

Defining a high level business intent or goal is relatively easy based on conversations with the business users. Examples might include "Response time must meet customer needs", "Sell insurance policies only if the client is a good credit risk", or "The CFO must approve high cost transaction".

However, then the more detailed questions start. The knowledgeable analyst might start asking questions like these:

  1. Do some customers have different response time requirements than others?
  2. What is an adequate response time?
  3. What is the solution context in which this policy will apply?
  4. How do we measure a good credit risk?
  5. Do different types of insurance policies have different risk levels?
  6. What is a high cost transaction?
  7. Do risk levels affect what is high cost?

We decompose the result as shown in the following figure:

Figure 4. Example for decomposing policy at the Business Layer
Business Policy Layer

Lets describe and decompose the policy for the business layer:

Table 1. Decomposition of policy from business goals
Identify Business GoalA Business Goal is a statement of intent and defines what needs to be done from a business point of viewCustomer response time expectations should be met
Derive Policy DirectiveThe Policy Directive defines the intent of the Business Goal and therefore gives direction as to how the business goal should be further decomposed. It is further refined in the Solution Context, the Policy Domains, the Solution Policies and the Governance Policies stages. The end to end customers response time (from depressing the enter key to response received) should be less than 3 seconds
Quantify Business ObjectivesThe Business Objectives defines what should be measured in detail to track achievement of the goal in the form of KPIs.KPI 1: Measure the maximum response time of the customer services and provide a critical operations warning if this time is exceeded
Scope the Solution ContextThe solution context defines where the business directive will apply in the business. Its scope may be localized within a small business capability or broadly deployed across the entire business.Phase 1: Banking ATM Services only
Select the Policy Domain(s)Each Domain identifies a common vocabulary that should be used for consistent policy definition. The business policy sub domains to consider are:
  1. Situational awareness policies such as detection of patterns of events over a specific time period
  2. Business process policies which affect the behavior of the process at specific activity steps
  3. Industry specific policies which could implement industry standards or compliance regulations
  4. Service Level Management policies
Service Level Management Policy Domain is used
Decompose to Solution PoliciesThe Policy Directive should be further refined as we receive more detailed knowledge of the context we are dealing withAll Banking ATM Services must provide a response to its service consumer in less than 3 seconds
Apply the Governance PoliciesThe Policy Directive will need to be governed so that agile change can be accommodated in future. This relates to where the SOA Policy Lifecycle may be implemented. Marketing will have authority to create, update or delete any business policies classified as marketing

The main outputs from the business layer decomposition, which will be used at the Architecture layer, are:

  • Solution Policies: Decomposed from the Policy Directive and influenced by the Solution context.
  • Solution KPIs: Decomposed from the Policy Directive and Business Objectives and influenced by the Solution Context.
  • Policy Domains: Service Level Management selected in our example with Customer focus.

Architectural Policy Layer Solution

Once a reasonable level of business policy is specified, then it can be decomposed into the architectural layer policies that will be needed to implement the business policies. The architectural policies refine the business policy as needed in order to ensure a high quality design for the solution and identify which policy pattern, if needed, should be used to meet the business needs.

There are three main concepts in the Architectural layer that need to be considered. These are shown in the figure and table below.

Figure 5. Example for decomposing policy at the Architecture Layer
Architecture Policy Layer

At this point in the SOA Policy lifecycle we have shown a means for authoring and transforming business policies down to operational policy sets that can be associated with each service invocation.

Table 2. Architecture Layer Decomposition
Solution Policy DecompositionThis activity defines how the architecture layer is used to decompose the solution policies provided by the business layer into policies that can be applied to the SOA resources for the solution in context. This involves identifying the resources affected (service, information, or process) All banking services must respond within 2 seconds. All information services must respond within 1 second.
Domain Pattern SelectionDomain patterns, provided by the existing SOA infrastructure, can be used to enforce the usage of a particular implementation pattern. Selection of existing patterns accelerates time to value and development, by allowing these existing components to be reused rather than having to develop a new solution. Use an SLA Pattern that will monitor service latencies and route to the appropriate service to realize the service level required.
Operational Policy SetsThese are the result of transforming the solution policies into policy sets that can be executed using the operational implementation of the domain pattern. This delivers the end to end policy management lifecycle using the deployed capabilities and products used to manage these policies. Specific service policy sets include routing and monitoring policies.

Operational Policy Layer Solution

Finally, at the operational policy layer, the business and architectural policies can be further decomposed into the set of actionable operational policies that are needed in order to enforce and monitor the policy and ensure it is meeting the original needs of the business.

The architectural layer provided the means to map the business policies onto the functional policies interpreted by the processes and services and non-functional policy sets that control how the architectural patterns are configured in the operational solution. The SOA Policy Reference Architecture identifies four key non-functional policy areas implemented in the operational layer. These operational policy areas provide the non-functional building blocks used for the architectural patterns described in the last section.

Taking the Policy Tree example there are three main concepts in the Operational layer that need to be considered. These are shown in the diagram and table below and described in more detail in subsequent sections.

Figure 6. Example of Operational Layer policy elaboration
Operational Policy Layer
Table 3. Operational Layer Decomposition
Collate policy sets across policies for any given interactionThe policy sets resulting from a particular policy directive need to be merged with other policies that are already deployed to any particular service interactionsSLA policies for Banking service interactions will need to be merged with existing security policies that protect the customer account data
Map policy sets to PDP/PEP configurationThe PDPs and PEPs used to interpret and enforce the policies will often use the policy set in association with other dynamic information to perform the enforcement. Introduction of new terms in the policies may require that the configuration of the PEPs, mediations, or their associated registries be changed to support the updated policies.The SLA mediation uses provider policy latency statistics to determine available endpoints that can deliver the required SLA
Map monitoring policy sets to KPI dashboards and alertsThe policy sets from the architectural layer will define what needs to be recorded from each interaction. However the means of displaying the policy KPIs in dashboards and reacting to important exception criteria and alerts will still need to be configuredRaise alert if the latency is GT SLM Policy or a service utilization is GT 90%


SOA Policy provides the means to deliver business agility and responsiveness in SOA solutions but requires a systematic approach to governing and managing those policies. This document has summarized the recommended practices and lifecycle that should be adopted to realize solutions that can leverage the SOA policy building blocks and patterns provided by the various policy technologies.

The IBM SOA Policy Reference Architecture describes how to systematically author, deploy, enforce and monitor policies as part of a solution. It describes how this policy lifecycle interacts with the SOA Development lifecycles being used to develop the solution services, processes and applications. Finally it describes how SOA policy aligns with and supports the overall Governance processes being adopted by the organization.


SOA_Policy_Reference_Architecture_Full_Article.pdfDownload the complete SOA Policy Reference Architecture



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks

Zone=SOA and web services
ArticleTitle=SOA Policy