SOA Policy

Robert Laird 09 August 2012
John Falkl
Stephen Cocks
Arnaud Le Hors
Duncan Clark
Andy Ritchie

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.

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:

© Copyright IBM Corporation 2012 Trademarks
SOA Policy Page 1 of 9

SOA Policy Reference Architecture The SOA Policy Reference Architecture layers its representation of policy to support the existing SOA roles and personas. SOA Policy Page 2 of 9 .developerWorks® ibm. Roles for Usage of the SOA Policy Reference Architecture 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. • The Business Layer should be led by a business analyst or a representative from the business who can specify the needs of the Figure 1. Figure 2.

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. As the two parties begin to collaborate. a policy is simply a statement of a specific business need. Business Policy Layer At the highest level of abstraction. Policy Solution Example The following figure shows a very simple example for a Service Level Management requirement. and tactics that define the details of how the business requirement is going to be implemented and enforced across the organization. the policy is normally expressed in natural language (for developerWorks® • The Architecture Layer should be led by architects who are responsible for the integrity of the SOA. the Architectural Policy layer is used to define the common patterns that can be used to enforce those policies.g. English. Those business policies need to be defined in the context of the business solution to which they apply. and so on) and is used to communicate business requirements between business analysts and IT professionals. controlling a pricing service through policies defined in business rules) or they may be applied to the use of one service by another. One the business requirements have been decomposed into policies that can be applied to sets of services. At this level. • The Operational Layer reflects the specification of the runtime policy that implements the operational policy patterns. Services will usually have traceability to the business capabilities that they deliver. The SOA Policy reference architecture defines a number of components that characterize the way policy is realized in operational SOA solutions. Architecture Policy Layer The architectural policy layer provides patterns for integrating policy into the architecture adopted by the enterprise. this business policy is then decomposed into a set of objectives. Policies may apply to the way a service behaves (e. SOA Policy Page 3 of 9 . so that it is usually possible to quickly relate a business policy to the services that it will need to influence. French.

Do some customers have different response time requirements than others? 2. Examples might include "Response time must meet customer needs". Policy Tree example of SLA Policy Top down analysis Business Policy Layer Solution The policy tree analysis starts with a high level. However. What is an adequate response time? 3. simple statement of the business policy requirement. then the more detailed questions start. such as one may obtain from the business user or business analyst. This statement is then refined. What is the solution context in which this policy will apply? 4. What is a high cost transaction? 7. How do we measure a good credit risk? 5. Do risk levels affect what is high cost? We decompose the result as shown in the following figure: SOA Policy Page 4 of 9 . "Sell insurance policies only if the client is a good credit risk". Do different types of insurance policies have different risk levels? Figure 3. as wells as what needs to be measured to ensure policy compliance. still at a business level. The knowledgeable analyst might start asking questions like these: 1.developerWorks® ibm. Defining a high level business intent or goal is relatively easy based on conversations with the business users. to specify in more detail the implications of the business policy requirement. or "The CFO must approve high cost transaction".

the Solution Policies and the Governance Policies stages. Example for decomposing policy at the Business Layer Lets describe and decompose the policy for the business layer: Table 1. Select the Policy Domain(s) Each Domain identifies a common vocabulary Service Level Management Policy Domain is that should be used for consistent policy used definition. Its scope may be localized within a small business capability or broadly deployed across the entire the Policy Domains. Decomposition of policy from business goals Name Description Example Identify Business Goal A Business Goal is a statement of intent and Customer response time expectations should defines what needs to be done from a business be met point of view Derive Policy Directive The Policy Directive defines the intent of the The end to end customers response time (from Business Goal and therefore gives direction depressing the enter key to response received) as to how the business goal should be further should be less than 3 seconds decomposed. operations warning if this time is exceeded Scope the Solution Context The solution context defines where the Phase 1: Banking ATM Services only business directive will apply in the business. Situational awareness policies such as detection of patterns of events over a specific time period 2. The business policy sub domains to consider are: developerWorks® Figure 4. Quantify Business Objectives The Business Objectives defines what should KPI 1: Measure the maximum response time be measured in detail to track achievement of of the customer services and provide a critical the goal in the form of KPIs. It is further refined in the Solution Context. Industry specific policies which could implement industry standards or compliance regulations SOA Policy Page 5 of 9 . Business process policies which affect the behavior of the process at specific activity steps 3.

There are three main concepts in the Architectural layer that need to be considered. Table 2. Figure 5. • Solution KPIs: Decomposed from the Policy Directive and Business Objectives and influenced by the Solution Context. The main outputs from the business layer decomposition. update so that agile change can be accommodated in or delete any business policies classified as future. Service Level Management policies Decompose to Solution Policies The Policy Directive should be further refined All Banking ATM Services must provide a as we receive more detailed knowledge of the response to its service consumer in less than 3 context we are dealing with seconds Apply the Governance Policies The Policy Directive will need to be governed Marketing will have authority to create. This relates to where the SOA Policy marketing Lifecycle may be implemented. should be used to meet the business needs. • Policy Domains: Service Level Management selected in our example with Customer focus. 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. Example for decomposing policy at the Architecture 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. Architectural Policy Layer Solution Once a reasonable level of business policy is specified. These are shown in the figure and table below. if 4. which will be used at the Architecture layer.developerWorks® ibm. Architecture Layer Decomposition Name Description Example SOA Policy Page 6 of 9 . are: • Solution Policies: Decomposed from the Policy Directive and influenced by the Solution context.

to realize the service level required. Operational Policy Sets These are the result of transforming the Specific service policy sets include routing and solution policies into policy sets that can be monitoring policies. The SOA Policy Reference Architecture identifies four key non-functional policy areas implemented in the operational layer. SOA Policy Page 7 of 9 . All information services must respond provided by the business layer into policies that within 1 second. 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. Operational Policy Layer Solution Finally. at the operational policy layer. These are shown in the diagram and table below and described in more detail in subsequent developerWorks® Solution Policy Decomposition This activity defines how the architecture layer All banking services must respond within 2 is used to decompose the solution policies seconds. These operational policy areas provide the non-functional building blocks used for the architectural patterns described in the last This delivers the end to end policy management lifecycle using the deployed capabilities and products used to manage these policies. by allowing these existing components to be reused rather than having to develop a new solution. Selection of existing patterns accelerates time to value and development. Taking the Policy Tree example there are three main concepts in the Operational layer that need to be considered. This involves identifying the resources affected (service. can be applied to the SOA resources for the solution in context. can be used to enforce the latencies and route to the appropriate service usage of a particular implementation pattern. executed using the operational implementation of the domain pattern. provided by the existing Use an SLA Pattern that will monitor service SOA infrastructure. information. or process) Domain Pattern Selection Domain patterns. 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.

However the means of displaying the policy KPIs in dashboards and reacting to important exception criteria and alerts will still need to be configured Conclusion 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. enforce and monitor policies as part of a solution. Example of Operational Layer policy elaboration Table 3.developerWorks® ibm. Introduction of new terms in the policies may require that the configuration of the PEPs. Operational Layer Decomposition Name Description Example Collate policy sets across policies for any given The policy sets resulting from a particular SLA policies for Banking service interactions interaction policy directive need to be merged with other will need to be merged with existing security policies that are already deployed to any policies that protect the customer account data particular service interactions Map policy sets to PDP/PEP configuration The PDPs and PEPs used to interpret and The SLA mediation uses provider policy enforce the policies will often use the policy set latency statistics to determine available in association with other dynamic information endpoints that can deliver the required SLA to perform the enforcement. The IBM SOA Policy Reference Architecture describes how to systematically author. deploy. or their associated registries be changed to support the updated policies. It describes how this policy lifecycle interacts SOA Policy Page 8 of 9 .com/developerWorks/ Figure 6. 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. mediations. Map monitoring policy sets to KPI dashboards The policy sets from the architectural layer will Raise alert if the latency is GT SLM Policy or a and alerts define what needs to be recorded from each service utilization is GT 90% interaction.

Finally it describes how SOA policy aligns with and supports the overall Governance processes being adopted by the organization.shtml) Trademarks ( processes and applications. Reference Name Description developerWorks® with the SOA Development lifecycles being used to develop the solution Download the complete SOA Policy Reference Architecture © Copyright IBM Corporation 2012 ( SOA Policy Page 9 of 9 .