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
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
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 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:
- Do some customers have different response time requirements than others?
- What is an adequate response time?
- What is the solution context in which this policy will apply?
- How do we measure a good credit risk?
- Do different types of insurance policies have different risk levels?
- What is a high cost transaction?
- 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
Lets describe and decompose the policy for the business layer:
Table 1. Decomposition of policy from business goals
|Identify Business Goal||A Business Goal is a statement of intent and defines what needs to be done from a business point of view||Customer response time expectations should be met|
|Derive Policy Directive||The 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 Objectives||The 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 Context||The 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:
||Service Level Management Policy Domain is used|
|Decompose to Solution Policies||The Policy Directive should be further refined as we receive more detailed knowledge of the context we are dealing with||All Banking ATM Services must provide a response to its service consumer in less than 3 seconds|
|Apply the Governance Policies||The 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
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 Decomposition||This 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 Selection||Domain 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 Sets||These 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
Table 3. Operational Layer Decomposition
|Collate policy sets across policies for any given interaction||The policy sets resulting from a particular policy directive need to be merged with other policies that are already deployed to any particular service interactions||SLA 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 configuration||The 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 alerts||The 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 configured||Raise 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.pdf||Download the complete SOA Policy Reference Architecture|
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Follow developerWorks on Twitter.
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
Dig deeper into SOA and web services on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.