soa policy reference architecture full article - ibm · pdf filesoa policy reference...

of 94 SOA Policy Reference

Architecture

SOA Policy Reference Architecture Full Article

Authors: Robert Laird, SOA Foundation Architect Andy Ritchie, BPM, Business Rules & Events Solutions Synergy Duncan Clark, ILOG Synergies Architect John Falkl, Distinguished Engineer & Chief Architect, SOA Governance Stephen Cocks, Architect, SOA Policy and Governed Service Gateway Arnaud Le Hors, Software Standards Architect


Architecture

Table of Contents

1. SOA Policy Reference Architecture Introduction............................................3

1.1 Abstract ............................................................................................................... 3

1.2 Purpose and Scope .................................................................................................... 3

1.3 Audience & Usage .................................................................................................... 6

1.4 The journey of policy................................................................................................ 8

1.5 Policy Management Primer..................................................................................... 13 1.5.1 Policy Administration Point (PAP).......................................................15 1.5.2 Policy Monitoring Point (PMP)............................................................16 1.5.3 Policy Enforcement Point (PEP) .........................................................16 1.5.4 Policy Decision Point (PDP) ...............................................................16 1.5.5 Policy Information Point (PIP) ...........................................................17

1.6 SOA Policy and SOA governance .......................................................................... 17

2. SOA Policy Reference Architecture Description............................................18

2.1 Policy Lifecycle Management ................................................................................ 19 2.1.1 Policy Lifecycle & Governance Policy ..................................................22 2.1.2 Policy Lifecycle................................................................................23 2.1.3 Policy Building Blocks.......................................................................35

2.2 SOA Policy Layers ................................................................................................. 41 2.2.1 Business Policy Layer.......................................................................42 2.2.2 Architectural Policy Layer .................................................................47 2.2.3 Operational Policy Layer...................................................................50

2.3 Service Development Lifecycle.............................................................................. 60 2.3.1 Service Lifecycle & Governance.........................................................61 2.3.2 Service Support & Delivery...............................................................62

3.0 Example for applying the SOA Policy Reference Model .............................63

3.1 Policy Layers – How to think about and decompose policy so that it is useful ..... 64 3.1.1 Mapping Business Requirements to Solution Policies and Policy Domains at

the Business Layer...................................................................................66 3.1.2 Using the Architectural Layer to leverage SOA Policy Lifecycle and Map

business policies to Architectural Policies ....................................................74 3.1.3 Operational Layer............................................................................84

4.0 Conclusion ........................................................................................................91

5.0 Mapping of SOA Policy Architectural Elements to IBM Product .............91

6.0 References and Appendix................................................................................92

6.1 References............................................................................................................... 92

6.2 Term Definitions..................................................................................................... 92


Architecture

1. SOA Policy Reference Architecture Introduction

1.1 Abstract

Every organization has and uses policy to make decisions that are important to the business and IT. Many times policy is created as a result of something negative happening in the organization. Management reacts by creating a policy to ensure that the actions of the organization follow the proscribed standards and guidelines that is manifested as policy. Efforts are made to automate the resultant policy implementation so that once policy is made, control is in place and will eliminate the negative event or at least control the consequences. There is a better way. Understanding the SOA Policy Reference Architecture allows the practitioner to be proactive instead of reactive about policy. This paper will provide a detailed understanding about the component parts of policy, where it can be effective, and where it should come from. Taking a top down approach allows the IT and business practitioner to use the goals and objectives of the business to drive policy understanding and decomposition into its component layers at the business, architectural, and operational level. The policy lifecycle will be explored so that the practitioner can manage and govern policy in an appropriate manner. The application of policy to resource management, specifically to the Service Development Lifecycle for SOA services will also be discussed. The paper finishes with an example that demonstrates in detail the process of creating policy.

1.2 Purpose and Scope

Policy is a word that most people have heard of, but often do not fully understand. The Merriam-Webster dictionary defines policy as “a definite course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions”. A more technical definition may be found in The Open Group’s SOA Ontology, which defines policy as “a statement of direction that a human actor may intend to follow or may intend that another human actor should follow. Knowing the policies that apply to something makes it easier and more transparent to interact with that something.”


Architecture

A “business policy” then, is a type of business directive that expresses the course of action that the business wants to have happen within a set of business conditions. OMG defines business policy and business rule as follows1: • Business policy: a broad directive that needs further interpretation (in business rules) in order to be put into practice, e.g. “Loans must be repayable”. Business policies may be documented in an enterprise BMM, or in a separate policy management system • Business rule: reference to a rule in the operational business, e.g. “A home mortgage must not be for more than 4 x the borrower’s salary”. Business rules make business policies practicable, and guide business processes Policy is most effective when it is defined in clear terms that are understandable and can easily be communicated to its intended audience and when it can be enforced accurately and consistently to achieve its intended purpose. In business solutions, having Policy defined to control the behavior of its resources in a consistent manner can align the Business and IT environments and provide agility to change the behavior quickly in a well governed manner. Policy management plays a key role in enabling policy and governance in any environment, including a service-oriented architecture (SOA). SOA practices help businesses identify and focus on optimizing the value of its key resources like services, processes and information. By adding policies to the SOA, we add points of control and agility for business and IT. This makes SOA more consumable and accelerates the usefulness and adoption of SOA solutions. Policy management is only applicable when policies are abstracted from the resources and enforcement points that they are eventually applied to. Where policies are implemented, enforced and tightly bound to the resource itself, the agility and flexibility within SOA is limited. Any change to the tightly bound policy requires the resource to also be updated and not just the policy. A separately authored and maintained policy, for example, “a transaction must complete in 2 seconds or less” has the advantage that it is abstract and can be applied to any service. This means:

• The policy can be applied to a variety of service, say a credit card service or a price lookup service.

1 “Overview of OMG Business Motivation Model: Core Concepts”, OMG Org, http://www.omg.org/oceb/BMM_Overview-Core_Concepts_%5B081208%5D.pdf, 8 December 2008


Architecture

• There is the ability to change the policy once centrally and have this applied to multiple services consistently which is not possible if the policy is tightly bound to a particular service.

• The policy says nothing about how or where it gets enforced. That

binding can take place later for a specific development, testing or production environment.

An SOA policy may define the principles and guidelines for a resource at design time, while another policy defines the principles and guidelines for a resource at run time. Design policies define and enforce a certain quality of service in the service development that helps to create a high quality of service. This helps the service’s runtime ability to function in an optimal manner. Policies are used at runtime to enforce specific standards and behaviors, for example to help maintain a certain level of service or to provide a secure environment. The nature of SOA - highly distributed, heterogeneous, and very dynamic - means that it is critical for its artifacts to be governed by specific business, technical, and regulatory policies. The goal, of course, is to first ensure that design time policies identify and fix quality issues and non-conformance before services are put into production. Runtime policies monitor and enforce actions in the production environment to provide a quality of service necessary for the proper transaction of the service to meet security, service level, and any other runtime standards. For the business, being able to readily change policy is a core component of having true business and IT agility. Many times today, that important business policy is buried in a set of procedural code that must be identified and changed system by system. This is an example of an anti-pattern that results in poor (or no) agility. Having business policy specified in one or more machine readable repositories that can be easily changed and tested is a “best practice”. Architects are concerned with addressing the usage of policies and policy infrastructure to support all aspects of Business and IT agility, including:

� What Business Goals, Directives and Objectives can be implemented by Policy?

� What are the Benefits for the business of solutions using Policy? � How will impact analysis on policy effectiveness be performed? � What is the lifecycle for a policy? � How do we categorize policies and their implementations in a manner that

is useful to the Business and IT?

The SOA Policy Reference architecture defines an enterprise approach to:


Architecture

� Use policy to realize business requirements � Obtain visibility and understanding of how policies should be used in the

business solutions � Establish architectural principles that support consistent realization of

policies and goals in those solutions � Provide tools and components to transform business goals and policies

into operational solutions � Adopt processes to govern and manage change management for the

policy component in the operational solutions

In this document we'll address:

� What are the components of a SOA Policy architecture? � What are the responsibilities of each policy component in that

architecture? � What are the details around the SOA Policy Reference Architecture that

allows the user to consider all SOA policy needs? � How can all needed policies, including Security policies, Service Level

Management policies, Business policies and Information policies all be supported within one architecture?

� Provide a detailed example of how to use the SOA Policy Reference Architecture

1.3 Audience & Usage

This document is meant for all roles who would be Authoring, Administering, managing and enforcing SOA Policies. Consider Figure 1 below and then the explanation of roles in the table:


Architecture

Figure 1 – Roles and their usage of the SOA Policy Reference Architecture Role Usage Business Analyst

� MUST use the business plans and objectives and refine them into business policies and domains that are needed for their implementation.

Enterprise Architect

� MUST translate the business policies and domains into the set of architectural and operational policy domains and standards and identify and apply those policy domains and standards to the architectural oversight of the enterprise with the SOA Architect, Infrastructure Architect and Security Architect.

SOA Architect � MUST work with the Enterprise Architect to understand the business, architectural, and operational policy domains and standards and then use this document to create guidelines and standards around architecting the use of

Business

Analyst

Business

Analyst

Business Policies & Domains

Business Plans & ObjectivesBusiness Plans & Objectives

Enterprise

Architect

Enterprise

Architect

Architecture & Operational Policies

and Standards

SOA ArchitectSOA ArchitectInfrastructure ArchitectInfrastructure Architect Security ArchitectSecurity Architect

Usage of Policy with SOA Services

Architecture

SOA Policy Infrastructure

Security Policy Patterns

SOA PolicyPatterns for

services

Policy KPI’s

Usage of the SOA Policy Reference Architecture

Service & PolicyRealization

Developer


Architecture

SOA services with policy (“Usage of Policy with SOA Services Architecture”)

� MUST create the specific policy patterns to be used in the architecting and operation of SOA services at the enterprise (“SOA Policy Patterns for Services”).

� MUST create KPI’s around policy usage so that how policy is used can be modified as the business changes (“Policy KPI’s”).

� MAY use this document to understand where to use Policy to enhance current solutions and create additional dynamicity.

� MAY use this document in conjunction with the SOA Policy Lifecycle document to understand importance of Monitoring in policy driven solutions to prove policy is being enforced.

Infrastructure Architect

� MUST use this document to create the SOA Policy solution specific deployment models for the overall SOA infrastructure in consultation with the Enterprise Architect (“SOA Policy Infrastructure”.

Security Architect

� MUST decide on which security standards and patterns are to be used for SOA and create the security policy patterns (“Security Policy Patterns”)

� MUST identify goals related to security domain and apply from a security perspective to the business solutions (“Security Policy Patterns”

Developer � MUST create realizations of services and policy using the “Usage of Policy with SOA Services Architecture”, “SOA Policy Patterns for Services”, “Policy KPI’s” from the SOA Architect, the “SOA Policy Infrastructure” from the Infrastructure Architect, and the “Security Policy Patterns” from the Security Architect.

Table 1 – SOA Policy Reference Architecture Roles & Responsibilities

1.4 The journey of policy

There are 2 main value aspects to policy that we have captured into a policy repository:

1. Value for IT teams deploying SOA solutions in a standardized manner that optimizes the value of such solutions.


Architecture

2. Value for Business users in specifying their business intent in a standardized and manageable manner and having the resultant business policies automated and easily changed in the future.

The adoption of SOA best practices has created an ideal environment for the introduction of several aspects of policy management inside an SOA solution. Such concepts as service, service composition, and service orchestration are now seamlessly recognized as “first class citizens” by development tools, middleware, and management solutions. The synergy between SOA and policy management is achieved by a number of benefits resulting from the introduction of policies:

1. Formalization - Policy domains have been identified and formalized into a standard representation of policy expressions. The resulting reduction of the ambiguity of the characterized policies makes them readily available for automation. Later in this document, we identify and discuss the set of policy domains that SOA Policy addresses.

2. Standardization - Common policy expressions and semantics for a

specific policy domain can be unified into an implementation-independent standard that guarantees that two different systems are compliant with the same policy regardless of their specific implementation.

3. Automation - The formalization and standardization of policy domains,

together with the recognition of these standards by tools, middleware, and management systems, allows the automatic and transparent configuration of these systems and the automatic enforcement of related policies. In some policy areas, the IT team may enable business visibility to the Business Policies or Rules via new tools. A business vocabulary is used that is easy for both IT and Business teams to understand. This has the added value of reducing the number of iterations between Business and IT teams to understand and successfully implement the business requirements. An example is providing access to view insurance quote premium policies authored in decision tables or in a natural language type format using an agreed business vocabulary.

4. Traceability - In a federated policy management system, traceability

between related policies at different levels of abstraction can be achieved by leveraging formalization, standardization, and automation. An important component of traceability is a policy information exchange mechanism between the different parts of the enterprise architecture in which policies are defined, transformed, and enforced. Formalization and standardization can provide a good basis for traceability. However, any manual management of the relationships across the horizontal and vertical policy


Architecture

dimensions is difficult to scale up to an enterprise level, which is where automation can play an important role. For example, policy traceability at the horizontal dimension means that a single policy can be traced with all of its relationships. This would include all create, read, update, and delete of the policy itself, who and when applied policy to the resources the policy is controlling, the various forms of the policy in the PAP, PEP, and PMP, and the detailed results of applying the policy to each resource. Policy traceability at the vertical dimension means that the origin of the policy can be traced to a business or IT objective and the resultant decompositions into policy of that objective, including the policy being vertically traced. It should be noted that policy traceability is a required SOA Solution building block, as described in a latter session.

5. Reuse - Reuse can be achieved at various levels by collecting policy

expressions and related values from best practices in the specific domain into a library of reusable policies. Alternatively, reuse can be achieved at a higher level, in which a tree of related policies of a different type and level of abstraction can guarantee compliance with mandates or standards at the business level. In any case, a single policy can be attached to one or more services, and therefore specified once but reused multiple times.

6. Dynamicity - Ability to request business changes which are policy driven.

This enables the changes to be implemented and deployed more quickly by IT and at lower cost with improved time to value. This is possible since the policy changes can be updated separately from the IT processes, services or applications which use the policies. Policy is updated by configuration updates or in some cases by separate business decision services. For example:

a. Business request to change the Service Level agreement for a specific group of customers to provide enhanced support.

b. Business request to change security password policies to increase security in a specific area.

c. Business request to change insurance quote premium policies for implemented as business rules.

7. Policies for Governance and Governance of Policy – Governance is

ultimately characterized by a series of “control points” that allow for checking that the governance policies have indeed been followed. Specification of policies for governance is likely to include instances where human decisions will need to be made. In other cases, there is an opportunity to automate the policy checking. Technical standards are an example of this where software can validate that the service has followed the standard, leaving the human to focus on governance tasks that cannot be automated.


Architecture

Policy, like any resource, should be governed in a manner that is consistent with the overall governance plan at the enterprise. Only certain individuals or roles should be allowed to perform each policy action. This includes the creation, reading, updating, and deletion of policy. It also includes the assignment of policy to a resource and the ability to trace a policy both vertically and horizontally (see Traceability above).

8. Change Management - In some cases for Business Policies, IT may

enable business users to change aspects of the policies directly in a controlled manner. This is extremely important in business situations where some business policies or rules may be changing on a daily basis to respond to market needs. Identifying the change management rules around policy will allow the enterprise to enable the direct stakeholders to update policy as quickly as possible while keeping the policy that is more sensitive to change within the control of the experts.

9. Policy Measurements - By ensuring well defined Business Objectives,

setting the measurement criterion, and KPI’s to measure policy effectiveness, we can make sure that policy effectiveness is optimal and benefiting the business. This allows the business either to confirm the policy is meeting the business goals and requirements or identifies that further policy change is needed.

Policy that has been captured into a policy repository can deliver significant value to two main groups. The value to IT and business can be summarized as follows:

Benefit areas for Policy Value to IT Value to Business 1. Formalization Agreed Policy domains

and Policy expressions reduce design work and repeated effort

Some new business requirements can be implemented faster

2. Standardization Improved and simpler integration across business

Reduced costs and less risk in projects

3. Automation Automation of policies can improve performance of IT systems.

Business Policies can be captured in form that both business and IT can understand and collaborate

4. Traceability Trace which business function(s) are using the policies

Reduced risk for new changes since dependencies can be viewed and validated


Architecture

5. Re-use Reduced time, effort & cost for ongoing maintenance & new business projects.

With IT being more efficient, more new business projects can be undertaken

6. Dynamicity Reduced effort to change and test solutions to meet new business needs

Business changes available faster to address changing market needs & opportunities

7. Policies for Governance and Governance of Policy

IT team has required controls to manage updates to policies that business solutions use. IT team has the SOA Policy building blocks necessary to control how policy is created, updated and used.

Business has auditable processes which control who and when policies are updated. Business has the ability to control who accesses the policy that it needs to control.

8. Change Management IT have good tools for Policy changes

IT can enable some business policies to be changed by business users

9. Policy Measurements IT can monitor IT Policy performance to identify problems and provide ongoing improvements

Business can monitor effectiveness of high level business policies to assess how effective they are using KPI’s

Table 2 – Benefits of Policy Usage

The nature of SOA - highly distributed, heterogeneous, and very dynamic, makes a set of business, technical, and regulatory policies very important for providing a common framework of rules and guidance for both the development (design time) and operation (run time) of services. Mapping the policy benefit areas into the 3 main policy points shows where those benefits will be realized in the policy architecture: Aspects Key factors Comments

Formalized Defined Policy domains & Vocabulary

Standardized Consistent semantics across business domains

Policy Authoring & Management

Dynamicity Policies can provide


Architecture

improved dynamicity for solutions

Change Management Dynamicity requires good tools for change management

Governance The best change management solutions have strong governance

Re-use Having policies managed & stored in central repository enables re-use

Automation Policies invoked and enforced by runtime applications, processes and services

Policy Enforcement

Traceability Trace who is consuming policies and results from policy decisions

Policy Monitoring Policy Measurements Ensure Policies meeting KPI’s set by Policy Objectives

Table 3 – SOA Policy Benefit Realization in SOA Policy Reference Architecture

1.5 Policy Management Primer

We are going to demonstrate that benefits arise to your organization from adopting policy as a control mechanism. SOA practices help businesses identify and focus on the key services of the business. By adding policies to the mix, we create points of control and agility for the business and IT. This makes your SOA more agile and consumable, improving time to value for business users with reduced costs for their projects, and therefore, accelerating the adoption of SOA solutions. A policy is an independent entity that may be applied to one resource or a variety of resources. In the case of SOA, a “resource” is a service, but the same concept may be applied to non-service resources. In a similar fashion, the assignment of the policy and any associated metadata, especially in a distributed environment, may take place to a variety of physical enforcement points and decision points.


Architecture

An SOA policy may define configurable rules and conditions that affect services during their design-time lifecycle and run-time lifecycle. Creating the set of policies will many times be an iterative process that starts with non functional business requirements, such as the security needs of the organization. Those policies then need to be managed to the policy target solution, as we discuss below. For example, architecture level policies are used as standards or guidelines to guide high quality of service at design-time, well before these services are made available in a production environment. Policies are used at runtime to enforce specific standards and behaviors, for example to help maintain a certain service level or to provide a secure environment. As a brief example here is a policy tree showing a business goal which has been refined into a Business Policy, had some architectural policies applied resulting in some operational policies.

Figure 2 – Business requirement to policy decomposition The organization of the basic policy architecture and definition of those key points are as follows:


Architecture

Figure 3 – SOA Policy Architecture Points

1.5.1 Policy Administration Point (PAP)

A Policy Administration Point (PAP) provides centralized administration, management, governance and monitoring of policies, including the assignment of policy to resources, and management of policy results from the distributed policy runtime engines. A PAP provides a single point of presence for policy management and governance. Policy is created and maintained according to a policy lifecycle and then assigned to resources (such as services) that require it. The policy lifecycle and resource assignment are governed in a manner that is standardized and repeatable. It is responsible for deploying policy in a standardized form to any resource runtime engine that subscribes to a policy or set of policies. It accepts management results from the resource runtime engines and is able to provide management functions to be effected based on those policy results.

Policy MonitoringPoint (PMP)

Policy AdministrationPoint (PAP)

Policy EnforcementPoint (PEP)

Policy Decision

Point (PDP)

ConsumerProvider

AuthorAuthor

Repository

Store

Repository

Store

Enforce

MonitorMonitor

Architectural Pattern for Service Policy:

Middleware

Policy Information

Point (PIP)

PAP – Policy Authoring,Policy Management,

Policy Runtime

PMP – provides overall picture on policy

results in the distributed environment

PEP – Evaluate PoliciesAnd take action

PDP – rendersAuthorization, eligibility,Or validation decisions Or provides calculated

result

PIP – providesExternal information


Architecture

1.5.2 Policy Monitoring Point (PMP)

A Policy Monitoring Point is a functional component that provides an overall detailed policy monitoring function (i.e. the big picture on policy in the distributed environment), including:

• Receives and makes ready for usage (translates) monitoring policy updates

• Captures real time collection and statistics analysis for display • Correlates, analyzes and visualizes the data fed in by the various real time

collectors including policy enforcement points • Provides a management console that provides visibility into the management

of distributed network of policy enforcement points and the status of these enforcements

• Logs, aggregates measurements and highlights significant events (as specified by monitoring policy)

• Provides monitoring policy analytics to PAP and PEP

1.5.3 Policy Enforcement Point (PEP)

A Policy Enforcement Point (PEP) is a functional point where policy is applied to a resource, including:

• Taking action to enforce policies

• Receives and makes ready for usage (translates) enforcement policy updates

• Provides enforcement metrics to the PMP • Provides enforcement policy results & analytics to PAP and PMP • The places where policies are actually applied and enforced change depending

on the lifecycle stage: o During design time, the service registry/repository itself is the point of

enforcement. o During runtime, policies are generally enforced by the underlying

intermediary (middleware) system that connects service providers with consumers.

1.5.4 Policy Decision Point (PDP)

A Policy Decision Point (PDP) evaluates participant requests against relevant policies/contracts and attributes to render an authorization, eligibility or validation decision or provide calculated results. It is typically associated with one or more Policy Enforcement Point’s (PEP’s) and provides specialized decision functionality that is not appropriate for a PEP.


Architecture

1.5.5 Policy Information Point (PIP)

A Policy Information Point (PIP) provides external information to a Policy Decision Point, such as LDAP attribute information, or the results from a database with information that must be evaluated to make a policy decision.

1.6 SOA Policy and SOA governance

SOA governance has a broad remit potentially covering processes, architectural principles and technologies. Some aspects of SOA governance can be automated and enforced through policies, and those policies themselves may be governed. This includes governing policies (applying governance to policies) and governance policies (policies used for governance decisions). Governing policies is addressed in “Policy Lifecycle Management” in this document. Using policies for governance decisions is addressed in the “Service Development Lifecycle” and “SOA Policy Layers” in this document.

An approach seeking to automate as much of SOA Governance as possible would typically address the most operational, easy to automate governance aspects first. The progressive delegation to automation of selected governance and management aspects is a positive trend that reduces the complexity of SOA Governance. However, as we address more strategic governance aspects, we realize that a more comprehensive and prescriptive approach is required in order to ensure that the governance adequately and consistently reflects business requirements. Such an approach enables us to: 1. Identify relevant policies starting from our business goals. 2. Define new roles and responsibilities related to the planning, definition, enablement, and measurement of the governance aspects. 3. Document the manual steps that are needed to enforce those governance aspects that cannot be automated. 4. Associate policies to relevant metrics in order to measure the effectiveness of the related governance aspect and its improvement. 5. Associate policies with specific activities and artifacts and their coordination with the manual steps.


Architecture

2. SOA Policy Reference Architecture Description The reference architecture delves into the details of the various policy components, what they do and how they interact with each other. The reference architecture provides enough information to implement a policy system. This includes breaking down policy into its various layers, the lifecycle for managing policy, and the application of policy to the Service Development Lifecycle. 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. The SOA Policy Reference Architecture assists the organization in understanding and properly creating its SOA Policy Architecture and ultimately, its SOA policy solution. It consists of 2 parts (see Figure 4 below):

1. Policy Lifecycle Management – Manages the authoring, transformation, enforcement, and monitoring of the policies. To understand how a policy expression can be used as a component of a policy-enabled SOA solution, we have to look more closely at the stages that a policy goes through on its way from authoring to being enforced and monitored. We refer to this as the policy life cycle. Once an enterprise has designed and implemented business solutions which use policy using this architecture, policy change management is easier. 2. SOA Policy Layers – Policy layers is a vertical dimension for policy classification which provides a level of abstraction for policies that includes business, architectural, and operational.

• The Business Layer should be led by a business analyst or a representative from the business that specifies policy that meets the needs their needs.

• 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.

In addition, the SOA Policy Reference Architecture has a strong interaction with the Service Development Lifecycle (SvDLC) and will also be discussed.


Architecture

Figure 4 – SOA Policy Reference Architecture

2.1 Policy Lifecycle Management

The Policy Lifecycle Management consists of 3 main areas as shown on the figure below:

Business Policy

Author

PolicyLifecycle

Management

Transform

Enforce

Monitor

Service Lifecycle

& Governance Policy

Policy Lifecycle

& Governance Policy

Architectural Policy

Architecture

Policies

ServiceDevelopment

Lifecycle

Model

Assemble

Deploy

Manage

Operational Policy

Operational

Policies

Service Support &Delivery Policy

Business

Policies

Policy Building Blocks

Business Policy

Business Policy domains for behavior and performance

Architectural Policy domains for SOA Resources

Operational Policy domains that are non-functional


Architecture

Figure 5 – SOA Policy Lifecycle within the SOA Policy Reference Architecture

1. Policy Lifecycle & Governance Policy - specify the policies that govern the Policy Lifecycle, identifying policies which provide standards and guidelines for the Policy Lifecycle. For example, such policies define how the policy lifecycle is governed for a given role or identity in an organization.

2. Policy Lifecycle - each policy will go through the Author, Transform,

Enforce, and Monitor phases.

3. Policy Building Blocks – provides the standardized policy functions to manage the policy lifecycle in a consistent and efficient manner.

It’s difficult to translate business goals and requirements into policies that can be applied to a wide range of resources. Further complicating this task is that it’s necessary to consider the impact at the business layer, architecture layer, and operational layer and create policy statements in an actionable form. Consider the following:

Business Policy

Author

PolicyLifecycle

Management

Transform

Enforce

Monitor

Service Lifecycle

& Governance Policy

Policy Lifecycle

& Governance Policy


Architecture

Policies

ServiceDevelopment

Lifecycle

Model

Assemble

Deploy

Manage

Operational Policy

Operational

Policies


Business

Policies


Business Policy





Architecture

Figure 6 – Policy Lifecycle provides policies to be used, by solutions created through Service Development Lifecycle

The Policy Lifecycle describes the sequence of policy management activities required to translate the business intents and goals into the realized set of business, architectural, and operational policies that standardize those intents and goals. As shown in Figure 1 on roles and their usage of the SOA Policy Reference Architecture, certain work needs to be performed prior to initiating the Policy Lifecycle. This includes examining the policy domains and vocabularies that are available for policy implementation and deciding if it is necessary to create new domains or policy vocabularies, or if it is necessary to enhance the vocabulary of an existing policy domain. Another way of stating this is to examine if the existing policy domain implementation contains a solution for specifying the particular policy needed. If it does not, then the architects must consider expanding the policy domains and/or vocabulary to accommodate the policy needs before the core task of actually authoring the policy specification can proceed. It’s easier, of course to just make policy updates to an existing solution. Contrasting that with creating new policy domains:


Architecture

Figure 7 – Changes to policy domain vs. changes to the policy solution

The ‘Policy Changes to Domain’ step includes the assessment and update of the policy domains and vocabularies as described previously. The architect should ‘plan’, ‘define’, and ‘implement’ the domain policy changes and then ‘monitor’ to see how well the policy domains and vocabularies are meeting the needs of the business. This monitoring provides information to the SOA Architect about how well the updated policy domain is working. When policy is not working well, for example, when policy is rejecting transactions it should be accepting, the SOA Architect will need to consider adjustments. The ‘Policy Changes to Solution’ addresses the instantiation of policy into specific rules, conditions, and actions. In an environment characterized by coding policy in procedural code, it was necessary to change policy via the System Development Lifecycle. This is inherently expensive and time consuming, requiring substantial investment by the enterprise in analysis, design, coding, testing and deployment. Far better is it to design services to use policies and business rules that are subject only to a Policy Lifecycle.

2.1.1 Policy Lifecycle & Governance Policy

We’ll now address policies that provide standards and guidance to govern the Policy Lifecycle. For example, such policies define how the policy lifecycle is governed for a given governance role or identity. The policy lifecycle & governance policy must be able to restrict access to policy authoring at a variety


Architecture

of levels for a role or specific identity. This could permit/deny access for three different dimensions. The first is authoring by a specific operation (create/read/update/delete). The second dimension is the level of policy authoring being allowed or restricted, which could include all policies, specific policy template patterns, individual policy templates, a policy set or a policy domain. The level of policy authoring is described in more detail in the next section on functions. The third dimension is the specification of a user role or specific user identifier. For example:

1. Permit create/update/delete to HIPPA policy domain to the role of health administrator.

2. Permit read to HIPPA policy domain to the role of any. 3. Permit delete to SAML Security policy template to the role of security

administrator

2.1.2 Policy Lifecycle

Let’s now look further into the SOA Policy Lifecycle in figure 8, which consists of 4 phases including Author, Transform, Enforce and Monitor.

Figure 8 – Policy Lifecycle Phases

Author

Transform

Enforce

Monitor


Architecture

These Phases are described in the following sections.

2.1.2.1 Author Phase

The goal of the author phase is to create the set of policies needed to support the business goals and objectives. In fact, policy creation is the result of a decomposition process where it is first necessary to understand the policy directives and then select the policy domains that are needed. The selected policy domains must be further decomposed into the needed policies using the existing vocabulary for that domain. Authoring is a function of the Policy Administration Point (PAP). The following table describes the different tasks related to the Author phase. Name Goals Tasks Governance Understand policy directive

The policy architect must understand the intent of the policy

1. Review the policy directive and make sure that its business goals and objectives are understood.

2. If the policy directive is not clear, discuss with the business analyst or equivalent until it is.

None

Identify policy domains

The policy architect must identify the policy domain or set of policy domains that are needed to solve the policy directive.

1. Review the policy domains and select the subset needed for this policy intent.

2. Identify the KPI’s for each policy domain selected.

Access to certain policy domains, for example security, may be restricted to certain roles. In such cases, it will be necessary to identify personnel that have that role and consult and work with them.

Identify the vocabularies

The policy will be authored using a

1. Review and determine if the

Only certain roles will be


Architecture

Name Goals Tasks Governance needed for each domain

domain specific vocabulary. Such a vocabulary may already exist in terms of policy templates or a rules engine. If not, the vocabulary must be enhanced.

vocabulary already exist in terms of policy templates or a rules engine with a sufficiently complete vocabulary.

2. If not, create or enhance the vocabulary for that domain so that it may solve the needs of the business intent.

allowed to create or enhance the vocabulary. It will be necessary to identify personnel that have that role and consult and work with them.

Author the specific policy statements

Author the policy statements in each policy domain identified previously.

1. For each policy domain, use the policy rules engine or policy templates, and specify the appropriate parameters to instantiate those policies.

2. Test the policies via simulation to make sure they do what you intend.

Only certain roles will be allowed to create, read, update, or delete in specific policy domains.

Table 4 – Author Phase Tasks

2.1.2.2 Transform Phase

The author phase is responsible for creating the set of policies that solve the business directive. But there is still work to be done in order for the policy to be applied to a resource and then understood so that it can be enforced. This next step in the policy lifecycle is the transform phase. The goal of the transform phase is to:

• associate policies with the resources they should be applied to, • deploy them to the set of PEPs, PDP’s, and PMP’s which are responsible

for those resources,


Architecture

• Transform the policy from their authoring form in the PAP to the execution form needed in the PEP, PDP or PMP.

To describe this process we will consider two main use cases: Use Case #1 – PAP, PEP, PMP: The first use case is based on a resource which is a SOA provider service. We want to:

• Associate and protect the SOA provider service with a Service Level Agreement policy, a message security protection policy, and a monitoring policy tied to a KPI.

• Deploy the policies from the PAP to the PEP and PMP that are responsible for this SOA provider service in a standard WS-Policy form.

• Transform the policy into a local execution form that is understood by the particular PAP or PMP.

Use case #2 – PAP, PEP, PMP with a PDP: The second use case is for a business decision with a PDP/PEP configuration. We want to:

• Associate the business decision policies with a decision service resource. The policies, for example, could be Industry compliance policies eligibility policies, or pricing policies,

• Deploy the policies from the PAP to the PDP which owns the decision services,

• Transform the policies with the PDP into a local executable form which the PDP can execute when invoked by the PEP.

The following table describes the different tasks related to the Transform phase for both of these use cases. Name Goals Tasks Governance Associate policies with resources

Each policy or set of policies must be associated (i.e. attached) to the resource or set of resources that they are relevant for.

1. Identify resources the policy or set of policies is relevant for.

2. Associate the policies and resources.

Only certain roles will be allowed to perform this task. It will be necessary to identify personnel that have that role and consult and


Architecture

Name Goals Tasks Governance work with them.

Deploy policies Use Case #1

The policies must be deployed to the PEPs responsible for the physical execution of the policy.

1. The PEP subscribes for all policies that it is responsible for transacting from the PAP.

2. As policies are published, any PEP subscribed to those policies is notified.

3. The policies are then retrieved in a standard form by the PEP from the PAP.

The PAP and PEP must be aware of each other and have appropriate security credentials if required.

Deploy policies Use Case #2

The policies must be deployed to the PEPs responsible for the physical execution of the policy

1. The PAP groups the appropriate policies together to form a decision services.

2. The PAP deploys and publishes the decision service to the PDP.

3. The PEPs which require this decision based on policy invoke the decision service from the PDP.

The PAP and PDP must be aware of each other.

Transform authored policy into internal representation

Instantiate specific policy or set of policies that have been authored.

1. The policy is transformed to a proprietary format that is required for that PEP.

None

Table 5 – Transform Phase Tasks


Architecture

2.1.2.3 Enforce Phase

The author and transform phases set up the policies to be published and then used by the appropriate execution units. The policies must then be enforced when events or transactions take place on the resources that the units are responsible for. A policy has the basic form of condition and action. When the condition for the policy is found to be true, its action is then enforced. For example, if too many transactions have occurred in a time period (the condition), the transaction is rejected (the action). It is sometimes necessary for the PEP to hand off a complex condition for evaluation to a PDP. Also, it is sometimes necessary for the PEP or PDP to retrieve database or file information from a PIP. The following table describes the different tasks related to the Enforce phase. Name Goals Tasks Governance Enforce policies

The policies must then be enforced when events or transactions take place on the resources that the units are responsible for.

1. Receive event or transaction for a resource.

2. Identify policies for that resource.

3. Enforce the policy using the PDP or PIP when needed.

The PEP will need connectivity and sometimes security access to the PDP and PIP.

Policy Analytics

Analytics provide an overall view, a management view of what’s going on in the distributed policy environment, and give the policy management function the opportunity to assess and take action.

1. Create results for policy execution whenever analytics occur.

2. Dispatch analytics to PAP and PMP.

Only certain roles should be allowed access to analytics.

Table 6 – Enforce Phase Tasks

2.1.2.4 Monitoring Phase


Architecture

Policy Monitoring is responsible for providing a management level of interaction with the actual execution of policies and recording how the KPI’s are actually performing in the real world. PEPs will usually exist in a distributed environment while a more centralized view is required for monitoring. This is where the PMP is important, because it provides a dashboard and big picture for what is really going on for policy execution. The following table describes the different tasks related to the Monitoring phase. Name Goals Tasks Governance Monitor policies and resources

The policies must be monitored when events or transactions take place on the resources that the units are responsible for.

1. Receive event or transaction for a resource or policy.

2. Periodically, identify policies for that resource.

3. Check if the policy condition is true and take action.

Interaction with operational units in the environment will need to be governed. ITIL is a good governance foundation in this area.

Provide policy audit

Policy runtime audit provides for the centralized logging of runtime activities for policies.

1. Provide reports and queries to runtime policy events.

Only certain roles should be allowed access to audit.

Policy Analytics

Analytics provide an overall view, a management view of what’s going on in the distributed policy environment, and give the policy management function the opportunity to assess and take action.

1. Create results for policy execution whenever analytics occur.

2. Create reports and queries for the analytics information.

3. Make the results available whenever a monitoring policy identifies an exception that requires operational attention.

Only certain roles should be allowed access to analytics.

Table 7 – Monitor Phase Tasks


Architecture

2.1.2.5 SOA Policy Lifecycle Example

The following illustrates an example of the policy lifecycle Use Case #1. Figure 9 – Policy Lifecycle Example Use Case #1. Author Phase 1. Translate Policy Directives into operational action – the policy directive needs

to be decomposed. In this case, the policy directive is ‘Credit Card Service must be available at all times’. After discussion with the business owner, the decision was made to have a hot standby that will be used if the primary service is too slow or unavailable. Further, Operations has agreed to be notified and take action on the primary service.

2. Identify Policy Domains – The policy directive refers to service availability. This aligns to the SLM Policy Domain.

3. Identify the vocabularies needed for each domain – The existing vocabulary is sufficient.

4. Author the specific policy statements – A Service Level Agreement (SLA) mediation policy is written to “Reroute to Secondary endpoint if Primary endpoint has latency > 3 seconds”. A monitoring policy is written to notify operations if “Average response time > 2.5 seconds”

Service

Policy AuthoringPolicy Authoring

ApplicationApplication

1. Author Phase (PAP) –

Translate policy

directives into specific

policy statement and

author that statement.

‘TooSlowAction’ Policy

created to reroute to

secondary endpoint

when primary endpoint

has an average latency

greater than 3 seconds.

2A. Transform Phase (PAP)

– the ‘TooSlowAction”

policy is assigned to the

‘Credit Card Service’

primary endpoint.

3A. Enforce Phase (PEP) PEP receives request

from consumer services for ‘Credit Card

Service’ provider service. If latency from

primary endpoint is > 3 seconds then

transaction is rerouted to secondary endpoint

Message

Message

MessageMessage

Message

Credit Card

Primary

endpoint

Credit Card

Primary

endpoint

Message

Message

MessageMessage

MessageCredit Card

Secondary

endpoint

Credit Card

Secondary

endpoint

2B. Transform Phase (PAP

& PEP) – the

‘TooSlowAction” policy

for ‘Credit Card Service’

is deployed from the

PAP to the PEP2C. Transform Phase (PEP)

– the ‘TooSlowAction”

policy for the ‘Credit

Card Service’ is

converted to PEP

internal representation

3B. Enforce Phase (PEP & PMP)

PEP sends information about

transaction and policy results

to PMP.

4. Monitor Phase (PMP) PMP

notifies operation when

monitoring policy breached

and sends management

information to PAP.


Architecture

Transform Phase 1. Associate policy with resources – Both policies are associated with the Credit

Card Service. 2. Deploy policy – SLA Mediation Policy is deployed to the PEP device that

handles transactions from any consumer to the Credit Card service. Monitoring policy for Credit Card service is deployed to the PMP device. Both are in WS-Policy format

3. Transform authored policy into internal representation – The PEP transforms SLA Mediation policy from WS-Policy format to internal policy format. The PMP transforms Monitoring from WS-Policy format to internal policy format.

Enforce Phase 1. Enforce Policies – as transactions occur, the PEP either lets transactions

pass through to Credit Card primary endpoint if latency is less than 3 seconds, or routes to Credit Card secondary endpoint.

2. Policy analytics – Information on the policy results are written to a data collector and then periodically disbursed to the PAP and PMP.

Monitor Phase 1. Monitor Policy Results – The Policy results are monitored and can provide

operation notification and action. 2. Policy analytics – Analytics are provided to PAP for management control.

2.1.2.6 Using the Policy Lifecycle in SOA development and governance

processes

All business changes of governed processes and solutions require a change lifecycle to govern them effectively, hence the need for dual lifecycles to manage the service development lifecycle and the policy lifecycle separately.


Architecture

Figure 10 – Governing Processes also has to be managed

Ultimately, a choice needs to be made for any specific policy solution, as to whether to implement using a policy or as procedural code. This choice will either be a solution design choice or a choice as mandated by an Enterprise Architecture Policy. Let’s take a simple example of a Business Process or Application which has some embedded decision logic and business function as shown in 11 below.

Figure 11 – Example of Process or Application with tightly coupled policies

In this example:


Architecture

• Process/application tightly binds decision logic or business functions. It makes no use of SOA design guidelines to separate the process flow and encapsulate the business function and decision logic as services.

• As a result policies influencing the behavior of the solution are tightly

coupled to the Service or System Development Lifecycle (SDLC)

• Whenever there is a change to policy, the whole process or application needs to be changed and redeployed.

• In many cases even for simple changes to policy, the deployment has to

wait for the SDLC to complete other changes to processes and applications which impacts time to market.

Now, let’s look into the details of the Policy Lifecycle and how it can provide the flexibility that IT and the business needs.

2.1.2.6.1 Using Policy Lifecycle for Service Level Management

(SLM) and Security Policies

SLM and Security policies will be applied, for example, in the middleware, in this case at the (ESB) level.

Figure 12 - Example of using separate Security and SLM policies to enhance SOA solution

In this example, we have made the architectural decision to:

1. Provide SLM via policies in a non intrusive manner via the ESB using an SLM pattern which uses the SOA Policy Lifecycle as described in section Error! Reference source not found. on page Error! Bookmark not defined.. Benefits include:


Architecture

• Agile control over which services from various service providers are allowed to be invoked from service consumers.

• Monitoring the performance of the services is centralized at the ESB and therefore much easier.

2. Manage security between the process or application and the business

services using security policies for service authorization and a Security pattern which uses the SOA Policy Lifecycle as described in section 3.1. Benefits include:

• It is easier to centrally manage service authorization and security

without changes to the services and processes managed in the service development lifecycle.

In this example, the Process and the Business Services are still managed by the Service Development Lifecycle. Some policies are still hard coded within this process or application decision logic. Changes to policy in these services are not agile or easy to change independent of the SDLC.

2.1.2.6.2 Using Policy Lifecycle for Business Policies

In this example, we are following good SOA design practice and controlling process decision logic by policy. We can separate out the decision logic into decision services. This enables a more agile solution and enables us use the SOA Policy Lifecycle for Business Policies when change is required.

Figure 13 - Example using separating business policy logic from process and services to improve solution agility.

We have made the architectural decisions to:


Architecture

1. Implement Business Policies as Business Rules within the SOA Policy Lifecycle which can be combined together and deployed as a Decision Service to meet the business needs of processes or business services. Section 3.3 and Figure 9 on page Error! Bookmark not defined. describe the pattern that enables this use of the SOA policy Lifecycle.

This pattern is normally used when there are business requirements to optimize the agility of the business logic in the solution. Benefits include:

• Process flow logic which is process specific stays within the process,

but the decision logic. For example: eligibility decisions, pricing decisions, or scoring, which may change at a different rate to the process, can be separated out and made far more agile.

• Re-use of business decisions and rules is possible across multiple processes or applications.

The Process and Business Services functional logic is still managed by the Service Development Lifecycle.

2.1.3 Policy Building Blocks

Policy building blocks are necessary for the competent management and functioning of SOA Policy. There are three main building blocks that support the ability to create policies, assign them to resources, and deploy them to policy runtime units for policy enforcement and monitoring. They are:

1. Policy Authoring – adding, changing, or deleting policy documents and policy sets with associated functions for the proper administration of said policy documents and policy sets.

2. Policy Management & Governance – adding, changing, or deleting the association of resources (e.g. services) with policy sets with associated functions for the proper governance and administration of this association.

3. Policy Runtime – functions for the administration of policies during runtime.

Policy Authoring, Policy Management & Governance and Policy Runtime are distinctive aspects of how policy must be enabled, but interact with each other in a well defined manner:


Architecture

1. Policy Authoring is responsible for creating and publishing a policy or set of policies and making those policies available for Policy Management & Governance.

2. Policy Management & Governance is responsible for governing and managing the policy or set of policies, including allowing such policies to be associated with (i.e. assigned to) resources. This function also covers deployment of the policies to the runtime units that enforce and monitor those policies.

3. Policy Runtime is responsible for the executable policy runtime machine enforcement and monitoring. This takes place in the runtime environment at Policy Enforcement Points (PEP) and Policy Monitoring Point (PMP).

Figure 14 shows in more detail the interaction between the PAP functions:


Architecture

Figure 14 – Policy must be enabled to be authored, governed, managed and deployed

Policy Set

Policya

Policyb

Policyc

Policyd

Policy Set

Policya

Policyb

Policyc

SOA Policy SOA Policy AuthoringAuthoring

Resource X

PEP 1 PMP 1

Resource Z

PEP 2

Resource Y

Policy Authoring

Policy Mgt & Governance

Policy Deployment

Web Services Web Services EndpointEndpoint

Consumer Consumer Service or Service or applicationapplication

Policy Enforcement & Monitoring

Policy Registry

Policy


Architecture

A competent PAP must support the following sub-functions to assist in the authoring, managing, governance, and running of policies: 1) Policy Traceability - It is necessary to keep track of the authoring of policies

(create, read, update, delete) and any subsequent action to them including action during the policy lifecycle such as retirement. This enables management of policy accountability. Rules: a) As a policy is created, published and then revised, there are potentially

different roles and different individuals who make changes to the policy. b) It is important to be able to reconstruct who did what and when to a policy. c) If changes were supposed to be made to a policy and were not, the

traceability will show that no changes were made. d) If changes are made by a person or role that should not make such

changes, traceability will show that there are flaws in the authorization policy for policy lifecycle changes.

e) Traceability for policies must include any authorization changes that affect ability to effect policy authoring or changes (for example, adding new roles that may address policy or adding roles that can affect a particular policy domain), user management changes (for example, users assigned to additional user groups), or similar changes.

f) Traceability on the creation, modification and deletion of policy templates and policy sets is supported.

g) Traceability of the association of a policy with a resource (further described in the Policy Association item below)

2) Conflict Analysis & Resolution - Conflict analysis for policy is the ability to

identify when two policies have a subset of those policies that are in conflict with each other and cannot both be enforced. Conflict resolution is the ability to suggest changes to one or more of the policies to eliminate such conflict.

3) Resource Definition – is the ability to define resources in such a manner as

to allow policy association with those resources.

4) Policy association – A resource (such as a service or an operation of the service) can be associated (i.e. assigned) to one or more policies or policy sets. A policy association indicates that the policy set should be applied to the resource at runtime. a) Ability to apply policy set at various levels of the resource (for example at

an entire service, a single operation, and how policy is used (input message, output message, or both)

b) Ability to apply policy set to a set of resources, for example, all services that are classified as “HR” services.

c) Ability to consider whether a policy can be applied to a specific resource and, if not, provides the ability to respond with a message as to why such an association cannot take place.


Architecture

d) Input / output message – ability to apply a policy on the front end of the provider transaction (the input to the provider) or the response (response from the provider).

5) Resource analysis - Resource analysis helps to identify the current status of

a resource with respect to policies. The function provides the ability to understand the specific policies which are already associated to the resource.

6) Impact Analysis – Impact analysis for a policy helps to identify the potential

impacts to changing a policy. Be able to identify which resources are applied to a specific policy and in what manner (i.e. at the service level, operation level, for a consumer service, provider service, or both).

7) Policy Pub/Sub - Policy pub/sub provides the ability to bind policy

enforcement points to operational assets (i.e., which enforcement or monitoring point handles which policies and resources).

a) Policy must be distributed in a standard form (WS-Policy, XACML, etc.) b) The PAP must have the capability to deploy policy to the right set of PEP’s,

PDP’s and PMP’s via a standardized subscription / notification / registration mechanism.

c) The PEP/PMP has the option to pull the policy update at a time of its choosing (real time, during a non busy time, etc.)

8) Policy Set Lifecycle – A policy set is the grouping of one or more

policies together to provide a policy pattern that solves a specific business or IT problem. A policy set lifecycle needs to exist that provides for the governance of the policy set for create, update, and delete of the policy data structures, including the policy set.

9) Policy Runtime Usage – There is a need to validate that published policies

are in fact being used as contemplated. This means being able to query what resources the policy is applied to and where the resource/policy pair is being enforced. As per the Pub/Sub requirement, Policy Enforcement Points (PEP’s) will subscribe for all policies for the resources that they are responsible for. This query/report will, among other things, help identify a policy/resource that has no PEP to enforce it.

10) Policy Audit - Policy runtime audit provides for the centralized logging of

runtime activities for policies. There are usually a multitude of policy enforcement points and its non optimal to require operations to review the logs of each such device in order to determine the overall policy audit results. Instead, there should be a centralized policy logging function that shows


Architecture

results from all policy enforcements. Many times, the policy audit function is performed by the Policy Monitoring Point.

11) Policy Analytics - Policy analytics is responsible for providing information on

how often policies are being accessed, how often those policies are “triggering”, i.e. taking action, and where vulnerabilities may exist that need to be addressed. Analytics provides an overall view, a management view of what’s going on in the distributed policy environment, and give the policy management function the opportunity to assess and take action. Policy management is then able to use this information to have an overall view of the runtime state of the business. Further, the results of policy enforcement may suggest that changes to policies may need to be made. For example, if policy analytics show that a policy is never getting enforced, this may mean that the policy has been defined in an incorrect manner and needs adjustment.


Architecture

2.2 SOA Policy Layers

Figure 15 – SOA Policy Layers within the SOA Policy Reference Architecture

This section will discuss the business, architectural, and operational layers. Policies at each layer have a different focus. It’s easy to say that policies at the business layer should be specifying the business rules or intent, but what does that mean? What are the typical areas that should be considered from a business perspective? The same concept is true at the architectural and operational layer. What are the architectural concerns that should be thought about for policy implementation? What operational domains does the competent policy architect need to think about and provide policy for?

Business Policy

Author

PolicyLifecycle

Management

Transform

Enforce

Monitor

Service Lifecycle

& Governance Policy

Policy Lifecycle

& Governance Policy


Architecture

Policies

ServiceDevelopment

Lifecycle

Model

Assemble

Deploy

Manage

Operational Policy

Operational

Policies


Business

Policies


Business Policy





Architecture

2.2.1 Business Policy Layer

Anything that affects business behavior and performance within a business solution is a candidate for a policy at the business layer. There are 3 main (but not the only!) aspects of business policy that one should consider when thinking about the possible used of business policy at your organization. They are channel specific information, the content provided, and the context the policy is being used in.

• For channel specific information, not all channels are treated the same in terms of business policy with respect to the availability to users / clients, employees, capability available, or cost of purchasable items. For example, “if “channel” is the “web channel” then provide a 5% discount on all items in the “furniture” category”. Note that channel based implications exist for other policy domains including the security domain and mediation domain.

• Probably the biggest aspect around enforcing business policy is using the

content provided. This could be party based information like customer, employee, supplier, item, order, policy based information. For example, “If customer is in the customer category “Gold” then ……. “

• Context provides an additional aspect for business policy. A business

solution may have a common business process for handling Insurance Claims such that it enforces business activities in a specific order to align with industry regulations and policies. It may, however, offer different types of claims through the common process. For example, “Home Contents Insurance”, “Home Building Insurance”, “Car Insurance” and “Bicycle insurance”. As such some process activities need some context specific rules to implement appropriate business policies to handle the claims effectively.

2.2.1.1 Situational Aware Policies

Situational Aware policies are typically industry specific and help guide best practices behavior for that industry. Depending on the industry, it can be tightly regulated and therefore subject to regulatory policy that must be identified and articulated in such a manner that it is actionable. Many industries have forums that identify best practices or standardized policies for handling common situations. In some cases, such policies are implemented in tool kits that consist of specific policies that can be used and modified as necessary. The following are examples:


Architecture

Type Description Example The Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security Rules

The HIPAA Privacy Rule provides US federal protections for personal health information held by covered entities and gives patients an array of rights with respect to that information. At the same time, the Privacy Rule is balanced so that it permits the disclosure of personal health information needed for patient care and other important purposes. The Security Rule specifies a series of administrative, physical, and technical safeguards for covered entities to use to assure the confidentiality, integrity, and availability of electronic protected health information.

If this is customer information, then it must be encrypted whenever it is data in motion or data at rest.

Industry Regulation Policies

Policies defining Health and Safety, Equal Opportunities for Internal Business Operations for HR processes Policies defining interchanges of messages and transactions between businesses to improve speed of operations and reliability / security of operations i.e. Inter Banking transactions and Clearing operations Policies defining detailed stages in complex operations for improving consistency, standards and reducing ability for inappropriate behavior with Anti Money Laundering regulations and Basel II regulations.

If transaction > $10,000 then record of transaction will be sent to government revenue authorities.

Table 8 – Situational Aware Policy Examples

2.2.1.2 Business Situation Policies


Architecture

Business situation policies allow for pattern recognition from data about situations that are of interest to the business. For example, a series of business events may occur that indicate that a valuable customer has stopped buying. By notifying the proper business personnel of this pattern, intervention can occur, perhaps with a visit to the suddenly quiet business or an offer of a one time discount in a constrained time frame. In other words, business situation policy can be used to identify the correlation of complex events that, in and of themselves, are not particularly interesting, but taken as a whole provide valuable information that needs to be acted upon. Typically, such actions will result in a potential opportunity that increases revenue or decreases costs. Type Description Example Business Sales and Investment Opportunities

Policies that detect market upward or downward trends over a period of time to improve business returns and investment decisions. Also policies which detect situations where client or supplier buying, selling behavior can be used for additional selling, marketing opportunities.

1. Always attempt to up sell a customer to the next tier of service when they call with a question and have > $100 per month in billings.

Malicious Business Behavior

Policies which detect fraudulent behavior or monetary business transactions, for example, Credit Card purchases or money laundering. In this case defining policies in terms of the value constraints, geographic aspects, time periods between transactions, or security required before transactions can be permitted will decrease the chances of malicious business behavior.

1. For transactions > $500 and < $10,000, where the country the transaction is taking place in is not the customer home country and prior notification of this has not taken place, then identify a potential fraud situation.

Table 9 – Business Situation Policy Examples

2.2.1.3 Business Automation & Process Policy

This sub-domain defines policies for the behavior of specific business logic or Business Services. For example, for Business Process Management (BPM),


Architecture

how can policy be used to orchestrate the flow of process in an automated and consistent manner. This allows for a specific control point when business policy can be changed. Examples include: Type Description Example Pricing, Tax based calculation Policies

Policies defining multiple aspects which relate to calculating Prices that optimize sales across geographical areas, marketing incentives and factor in loyalty aspects / bonuses for customer retention purposes. Tax Rates based on expected revenue governments expect to receive need to be factored into calculations like state taxes or Value added taxes.

If customer is > 25, has had no claims in last 3 years and does not drive a sports car, reduce quote by 15% for automobile insurance

Supplier Policies

Policies which define criteria by which suppliers can be chosen as a preferred supplier for specific items of a certain quality level, and the expected prices and delivery aspects required to ensure maximum uplift and profitability can be achieved.

If this transaction is for a purple widget of superior quality, then supplier of choice is XYX Company. If transaction is for white widget then ask for quotes to find lowest current price from all approved suppliers.

Manufacturing, Distribution/Shipping Policies

Supply Chain and Manufacturing policies to do Procurement, Assembly tasks and QA tasks at specific parts of Manufacturing process to optimize efficiency and costs Policies optimizing costs of shipping and adhering to industry regulations on denied party lists for shipping

If the supply is needed within 24 hours and VP approval has been obtained, then authorize overnight shipping, otherwise use normal shipping.

Employee / HR Policies

Policies defining the stages of the hiring processes, and what skills required and time periods to hire Policies defining when the business decides when to provide salary

If job application is received for post which is already allocated then send a “Thank You but post allocated


Architecture

changes & bonuses based on business performance

response”

Client sales & Marketing Policies

Policies defining what sales channels to best sell products at specific prices to maximize business revenue and profitability Policies defining customer focused sales promotions to enhance products selling well to further increase market share, Introduce new products at initial attractive prices to increase adoption, or to clear stock on poorly selling lines and reduce inventory

If this is a ‘gold’ customer, then transfer this call to the Gold Customer Call Center.

Table 10 – Business Automation & Process Policy Examples

2.2.1.4 Service Level Management Policy

Business policies also address service level management, including various aspects of business performance, non-functional standards and guidelines, customer satisfaction policies, and enterprise operations policies.

Type Description Example Business Data Security

Identifying the security needs of a particular data domain and creating policy to secure that domain

All product pricing can be viewed by anyone but can only be changed by a manager in the product pricing group.

Business Performance Policies (Service Level Agreements)

Defines the performance aspects of customer facing processes and situational awareness solutions. Examples include banking transactions, internet sales transactions, and supermarket queues.

All web transactions must respond to the customer within 3 seconds.

Business Complaints Policies

Determine what steps and what time periods are allowed for customer complaints in order that these complaints should be handled to provide fast,

If this is a ‘gold’ customer complaint, then respond within 24 hours, otherwise


Architecture

responsive service while allowing business time to investigate properly.

respond within 48 hours.

Business Competitive Policies

Attracting market share and additional business demonstrating value for money.

If proof of a lower price is provided, the store will match that price.

Business Quality Policies

Provide QOS on sold goods by providing extended guarantees on product quality by providing service for multiple years at a reduced rate or part of purchase price.

If the product breaks within the first year, a replacement will be shipped.

3rd party service Policies

Defines agreed levels of service for 3rd party’s which provide ability for enterprise to meets its internal and customer focused service policies, for example policy around usage of a public cloud instead of a private cloud.

If this is a cloud service, then no proprietary data is allowed.

Internal Enterprise and Cross enterprise Service Policies

Defines how performance service levels are achieved for departmental or Cross enterprise processes and situational awareness solutions. Examples include HR processes, Internal Inventory management and warehousing and payroll, and policies for using more cloud resources in times of high demand.

Information about employees who leave the company must be available for 3 years.

Table 11 – Service Level Management Policy Examples

2.2.2 Architectural Policy Layer

Policy is used at the architecture layer to effectively manage the process, service and information elements of a service oriented architectural solution. The architectural policies themselves represent points of control or configurable constraints on the behavior of the architectural solution. The SOA Policy Lifecycle Management defines the architectural principles and best practices needed to develop those architectural policies and apply them to the solutions so that they operate together effectively.

2.2.2.1 Architecture Process Policy

Architectural process policies provide configurable control of the manner in which the processes operate. This allows policy to be used to control the decisions or


Architecture

paths taken within a process or the roles or individuals to which the activities and tasks should be routed or assigned. This use of policy allows the processes themselves to be controlled using policy. Examples of process policy include:

Example Description Example Process Flow Decisions

Processes will often contain decision points where the optimal decision will evolve over time and need to be defined by policy rather than defined as part of the process. Control of the decision by policy gives the business the ability to optimize and manage the process decision using the Policy management lifecycle.

Business rules can be used to provide eligibility decisions as part of an insurance process, routing to separate process paths for eligible or ineligible insurance quotes.

Process Governance policies

There is often a need for escalations and exception handling within processes that will vary as the organization changes. The governance roles and responsibilities (as defined in a RACI matrix) can be defined as policies and thus configured into the process allowing the governance required.

When activities in an insurance quoting solution become overdue, escalation routes automatically to the correct manager to ensure that the quote is reallocated and the customer satisfaction is maintained.

Table 12 – Architecture Process Policy Examples

2.2.2.2 Architecture Service Policy

Architectural service policies provide configurable control to services to provide effective usage, routing and quality of service within the solution. Examples include:

Example Description Example

Quality of Service Routing

SOA provides a flexible means of sharing services across multiple consumers and clients. However the requirements of each consumer may be different and policy is used in conjunction with an ESB to route to the appropriate endpoint of the service to deliver the required quality of service.

Customers are categorized as Gold, Silver and Bronze and are offered different response times when obtaining information about their accounts. These response times are defined through


Architecture

policies and used by the ESB to route to an appropriate service that can deliver that response.

Service Security and Integrity

Maintaining security and integrity in a solution will often require the use of standard patterns that determine the protection to be applied to information passing between services in the solution. This security will depend on the particular context of the interaction and policy can be used to configure the behavior of the interaction within this context.

All customer data must be confidential implies that when passing this information between services, encryption of the data will be required.

Table 13 – Architecture Service Policy Examples

2.2.2.3 Architecture Information Policy

Architectural information policies provide configurable control of information used within the solution. This ensures secure and optimal quality of information when the information is being created, read, updated, and deleted across the services in the solution. Example Description Example Information Security

Information will often need to be protected in terms of who can see or update what elements of data. As the information is made available through services it becomes increasingly difficult to define the context in which a service should allow access to the information it manages. By using policy to define the conditions under which the information may be accessed or changed in the service, the system architecture allows the security goals to be maintained across different and evolving contexts.

A customer can only modify their own personal data. This data can be accessed by systems on behalf of the customer but not by marketing or third party systems. This would typically result in the use of XACML policies being applied to the service interactions to say whether the information could be accessed.

Information In modern solutions the confidence that Case management


Architecture

Quality can be placed in information is often subject to interpretation and depends on the history and provenance of the information. Policies can be used to identify certain situations that warrant changes in that confidence or require other activities to occur.

solutions require activities to be initiated when the correct information becomes available.

Table 14 – Architecture Information Policy Examples

2.2.3 Operational Policy Layer

Policy at the operational policy layer is specific policies that are actionable and are rendered as settings and entitlements. This section addresses the main areas of common usage of operational policy but is by no means exhaustive.

2.2.3.1 Security Policy

The following policies come under the broader grouping of runtime Security Policies and should be considered together: Access Control Policies for access to runtime resources Message Protection Policies for protection of data contained in messages at runtime Integrity Policies to ensure that data is not invalid or does not become invalid In order to secure an enterprise, we must consider the following key broad requirements: Denial of Service Prevention Policies to ensure that runtime services do not become unavailable due to a deliberate denial of service attack.

2.2.3.1.1 Access Control Policies

Access Control is fundamental to security in order to ensure confidentiality and integrity of both runtime resources and management data. Although the operational policies for access control at runtime and management differ, the concepts of access control remain the same.


Architecture

There are three key aspects to access control: Identity Management, Authentication and Authorization. Although these three elements should be considered together, the policies for each aspect differ. For this reason, the policies are considered in turn for each below.

2.2.3.1.1.1 Identity Management Policies

Identity management concerns the management of the identity of the users within the enterprise. This includes the management of userid's along with the grouping of userid’s into roles such as ‘customer support personnel’. The grouping of userid’s to roles allows the easy application of security policies to a set of users who perform similar functions. Identity management can encompass more complex concerns, such as Identity Federation (establishing a single Identity to be used across multiple domains). As its definition suggests, identity management is an action performed at management time (and not during runtime) even if the managed identities are used during runtime.

Type Description Example Audit and remove old user identities

This policy is realized by a regular check of User Identities.

If user id not used within 1 year, archive and delete from LDAP

Require password change

This policy is usually realized by automated email and mandatory user identity revalidation if password is not changed within the required timeframe.

If Password > 80 days old, send email for password change. If Password > 90 days old, suspend userid.

User Identity Management

Policies that define who can manage User Identities

If Role not = User_Administrator, reject access to LDAP

Table 15 – Identity Management Policy Examples

2.2.3.1.1.2 Authentication Policies

Authentication is the act of confirming an identity to be true. Aspects of authentication include origin authentication, integrity, and confidentiality. The user interface that the Security Architect uses to define the authentication information that must be passed in the message will vary depending on the product that is used to deploy the policy but, ultimately the policy should be converted to a standard machine-readable WS-SecurityPolicy


Architecture

Type Description Example Authentication Identifying the origin of a message

securely. If username/pw is found in LDAP, allow transaction to proceed.

Table 16 – Authentication Policy Examples

2.2.3.1.1.3 Authorization Policies

Authorization is establishing the right of the authenticated identity to access the resource in question. Authorization might be role based (for example, all managers may access a particular document) or based on an individual. When the appropriate authentication has occurred in order to validate that a message is from a user known to the enterprise, the authorization step establishes whether the user has the right to access the resource to which the message is targeted. The Enterprise Architect defines access to resources by means of centrally managed authorization policies and rules. Authorization may take a variety of forms. SOAP Message Security defines the basic mechanisms for providing secure messaging and for using security tokens that represent a set of claims. WS-Authorization extends this by definition additional primitives and extensions for security token exchange. Another machine readable standard for authorization policies is eXtensible Access Control Markup Language (XACML). Type Description Example

Authorization Establish the right of the authenticated identify to access the resource in question

if the Identity of the message originator matches the CustomerId of the data in the service and the action is read or

if the Identity of the message originator is of the role ‘Customer Support Personnel’

Table 17 – Authorization Policy Examples

2.2.3.1.2 Message Protection Policies


Architecture

Message protection could be viewed as a special type of access control that applies to ‘in flight’ rather than ‘at rest’ data. The same concepts apply in terms of the authentication and authorization of parties accessing messages but the mechanisms for message protection are very different from those of access control. Message protection policies define requirements on messages to ensure that the data contained within the message remains confidential and maintains its integrity. Message confidentiality is ensured by encrypting the message prior to its sending and then performing the appropriate decryption on message receipt. There are a variety of encryption algorithms that may be considered for this purpose. Message integrity is a guarantee to the message receiver that the message is from who it says it is from and that it has not been tampered with during transit. Message integrity is achieved through associating a digital signature with the message which proves the originator, cannot be forged and can be validated by the recipient. There are a variety of algorithms that may be considered for this purpose, Message protection not only applies to messages containing customer information, it should also apply to messages containing any potentially sensitive information within the enterprise. In particular, message protection should be applied to policy data when it is in flight. In practice this is a concern that should be guaranteed by the integration capabilities provided by the PAP, PEP, and PMP. Type Description Example Origin Authentication

Identifying the origin of a message securely.

Accept messages only from node ‘ABC7543’

Integrity Authentication

Detecting that no entity has tampered with information.

Use Public Key Infrastructure to authenticate integrity

Confidentiality Ensuring that only the intended recipient of information is able to view it.

Use Public Key Infrastructure to ensure confidentiality

Table 18 – Message Protection Policy Examples

2.2.3.1.3 Data Integrity Policies


Architecture

Ensuring the integrity of data (be it management data or resource data) is more than simply restricting access to those who are authorized to update the policies. Type Description Example Data Validation Necessary data fields and when

validation is required Validation rules defining the minimum requirements of service data or metadata in the context of service lifecycle governance.

Data Decay Rates defining how regularly customer data re-validated to ensure that it does not get out of date.

Issue a customer details update form each year with an insurance renewal

Table 19 – Data Integrity Policy Examples

2.2.3.1.4 Denial of Service Prevention Policies

Ensure that runtime services do not become unavailable due to a deliberate denial of service attack via appropriate security policies. Type Description Example Denial of Service

Policies to prevent overwhelming of provider service due to excessive number of transactions meant to disable.

If unexpectedly high traffic from a set of internet nodes, then throttle from those nodes

Table 20 – Denial of Service Prevention Policy Examples

2.2.3.2 Service Mediation Policy

Mediation policies enable mediation or reliable transactions between a consumer and a provider service or application and are of many different sub-types.

2.2.3.2.1 Service Level Agreement policy


Architecture

Operational implementation of SLA policy focuses on conditions where a particular statistic being measured has been violated. As a result, specific action will be taken, such as putting the offending transaction in a queue for later processing, throttling (rejecting) the transaction, or re-routing the transaction to another provider that is in better shape to handle the transaction. Type Description Example Service Level Agreement’s

Compare current state to SLA limits and take action when violated

If response time of Service X endpoint is > 5 seconds then queue transaction

Table 21 –Service Level Agreement Policy Examples

2.2.3.2.2 Messaging & enrichment policy

This policy enables the consumer service to be filtered or transformed.

Type Description Example Filter Identify and take action on any content,

metadata, or network variables. Filter on messages from node ‘ABC7543’

Message Enrichment

Insert header info, SAML token, Kerberos token, transaction ID, etc.

Insert SAML token

Validation Enforce incoming/outgoing XML schema, well-formedness

Validate XML schema matches pattern

Transform between varying data formats - XML, Text, Binary, etc., from one schema to another, from one transport protocol to another, etc

Transform XML into COBOL copybook

Table 22 – Messaging & Enrichment Policy Examples

2.2.3.2.3 Routing policy

This policy enables the consumer service to be routed to the appropriate provider service when certain criteria are met.

Type Description Example


Architecture

Transaction context and/or message content

Analyze originating URL, protocol headers, transaction attributes, etc., Analyze legacy or XML content.

If msg-type = ‘gold’ route to gold provider

Leverage a routing table for real-time decisions

Quickly deploy routing changes, including protocol conversions

Use msg_key to lookup Exec_Routing_Table for routing IP.

Retrieve routing information from other systems for real time decisions

Retrieve routing information from other systems (E.g., databases, web servers, file servers, etc.)

Use msg_id to lookup LDAP Table for routing IP

Table 23 – Routing Policy Examples

2.2.3.2.4 Protocol mediation policy

This enables the service to bridge inbound and outbound protocols.

Type Description Example Simple configuration

e.g. HTTP �� MQ �� Application server �� FTP �� ESB

Convert HTTP to MQ

Request-response and sync-async matching

Matching separate transactions to take action

Match asynchronous request and response transactions and take action

Fully guaranteed, once and only once delivery

Guaranteed delivery Guarantee delivery to an MQ queue

Table 24 – Protocol Mediation Policy Examples

2.2.3.2.5 Partner & customer gateway


Architecture

This gateway enables the service to extend connectivity from organization to customers, partners, and suppliers (aka Trading Partner Management).

Type Description Example B2B protocol enforcement

Enforcing protocol type to and from business partner zone

Validate protocol is HTTPS

B2B access control, message filtering, and data security

Automatic security and filtering actions to and from business partner zone

Access control from partner zone to validate security

Table 25 – Partner & customer gateway Policy Examples

2.2.3.2.6 Mediation Device Management

This device enables the management of the resources of the mediation device.

Type Description Example Cache Management

Manage amount of memory used for cache

Increase cache by 1 Gigabyte if free memory is < 100 Megabytes

Device Management

Manage various device attributes Set device on

Table 26 – Mediation Device Management Policy Examples

2.2.3.2.7 Reliable Messaging / Atomic Transactions

There are two more mediation policy sub-types that enable reliable transactions between a consumer and a provider service or application.

Type Description Example

Reliable messaging

An Application Source (AS) wishes to reliably send messages to an Application Destination (AD) over an unreliable infrastructure. To accomplish this they make use of a Reliable Messaging Source (RMS) and a Reliable Messaging Destination (RMD). The AS sends a message to the RMS. The RMS uses the WS-

Transaction is using reliable messaging


Architecture

ReliableMessaging (WS-RM) protocol to transmit the message to the RMD. The RMD delivers the message to the AD. If the RMS cannot transmit the message to the RMD for some reason, it must raise an exception or otherwise indicate to the AS that the message was not transmitted.

Atomic transactions

An all-or-nothing property. The actions taken by a transaction participant prior to commit are only tentative; typically they are neither persistent nor made visible outside the transaction. When an application finishes working on a transaction, it requests the coordinator to determine the outcome for the transaction. The coordinator determines if there were any processing failures by asking the participants to vote. If the participants all vote that they were able to execute successfully, the coordinator commits all actions taken. If a participant votes that it needs to abort or a participant does not respond at all, the coordinator aborts all actions taken. Commit directs the participants to make the tentative actions final so they may, for example, be made persistent and be made visible outside the transaction. Abort directs the participants to make the tentative actions appear as if they never happened. Atomic transactions have proven to be extremely valuable for many applications. They provide consistent failure and recovery semantics, so the applications no longer need to deal with the mechanics of determining a mutually agreed outcome decision or to figure out how to recover from a large number of possible inconsistent states.

Transaction is using Atomic transactions

Table 27 – Reliable Messaging / Atomic Transaction Policy Examples

2.2.3.3 Service Delivery & Support Policy

Define standards, guidelines, rights and responsibilities for IT services management and operations.

2.2.3.3.1 Service Delivery


Architecture

This sub-type includes policies to define and enable various service delivery capabilities.

Type Description Example Service Level management

Specify service catalog and service levels available to customers. Ensuring services are delivered when and where they are needed.

HR customers receive lower priority

Network and Capacity Management

Managing supply and demand of IT resources to minimize cost and maximize business performance Managing network and resource configuration to meet business need

Add additional server when utilization exceeds 85%

Availability Management

Maintaining reliable resources and applications while minimizing maintenance downtime. Risk management, Resiliency and prioritization to ensure services are available when needed.

Clusters must be used for high priority services

Table 28 – Service Delivery Policy Examples

2.2.3.3.2 Service Support This function uses policies to provide consistent and automated responses for service configuration & deployment.

Type Description Example Service Request, Problem and Incident management

Reduce service downtime and time to repair and ensure IT services support the business need.

Provide first level support within 2 hours for gold customers

Change, Release and Configuration Management

Provides for the managing of provisioning of tested software and IT services and deployment to environment(s) and minimize risk when changes are introduced – especially in service dependencies.

Change support policy


Architecture

Rollback Backout unforeseen incidents to a stable working position.

Rollback policy

Table 29 – Service Support Policy Examples

2.2.3.4 Service Monitoring Policy

This type of operational policy monitors services and provides instruction to the operations group on actions to take. Type Description Example Monitoring Operational policy to monitor services

and provide instruction to the operations group on actions to take.

If average response time for Service X is greater than 10, notify operations of critical problem.

Table 30 – Service Monitoring Policy Examples

2.3 Service Development Lifecycle


Architecture

Figure 16 – Service Development Lifecycle with the SOA Policy Reference Architecture The Service Development Lifecycle (SvDLC) is similar to the System Development Lifecycle (SDLC) but is applied to SOA service development instead of applications. Service Development is the creation of the “resource”, in this case a service that one or more SOA policies may be applied to. Taking that thought to its logical conclusion, the SOA Policy Reference Architecture can become a “Policy Reference Architecture” and the Service Development Lifecycle becomes a “Resource Lifecycle”. There is a rich suite of material about the Service Development Lifecycle and Service Oriented Modeling and Architecture (SOMA). Dr. Ali Arkansan’s summary of SOMA (click on SOMA) with links to various resources including his original paper should be reviewed for additional detail.

2.3.1 Service Lifecycle & Governance

A service registry that is managing the service lifecycle must have the ability to create and affect policy to govern that service lifecycle. Governance teams

Business Policy

Author

PolicyLifecycle

Management

Transform

Enforce

Monitor

Service Lifecycle

& Governance Policy

Policy Lifecycle

& Governance Policy


Architecture

Policies

ServiceDevelopment

Lifecycle

Model

Assemble

Deploy

Manage

Operational Policy

Operational

Policies


Business

Policies


Business Policy





Architecture

should establish policies and procedures that support the architecture, design, and development teams ability to follow standards for preferred technologies, design patterns, interface patterns, naming conventions, coding practices, testing practices, service versioning and documentation requirements. They should also establish policies and processes that facilitate service creation and enhancement. There are 3 main benefits from separating out the policy lifecycle from the service development lifecycle:

1. Improving the agility of IT solutions to better meet business needs 2. Better definition as to whether the scope of the policy is across the

business and multiple functional areas or simply in the context of 1 capability

3. It allows governance and change to be managed across a broader range of roles. The policy lifecycle allows some business users to influence policy domains more directly where the Service development domain is mainly managed and governed by IT.

2.3.2 Service Support & Delivery

The purpose of service support & delivery policy is to establish policies for service packaging, configuration, registration, instrumentation, and capacity planning. For example, a common area of difficulty is the configuration of runtime service policy to the policy enforcement points with deployment in such a manner that the operational work is distributed appropriately. It’s cleaner and more efficient to do this centrally with configuration policy than to try and work across the distributed devices one by one. Frequently, a proxy server must be configured and then policy established as part of a runtime handler stream of actions upon the service. Coordinating all of this with service support policy can optimize the results. Service support & delivery policy also concerns itself with standards and facilities that support service monitoring, management, and security and helps ensure that the runtime infrastructure provides visibility into runtime operations, can enforce runtime policies, and detect and address runtime anomalies. The IT Infrastructure Library, ITIL (®), is a series of documents that are used to aid the implementation of a framework for IT Service Management (ITSM). This framework defines how Service Management is applied within specific organizations and is the industry standard.2 For example, a policy could be put in place that measures the percentage of time an SLA (Service Level Agreement) policy that is rerouting traffic to a secondary server is actually doing so. When more than 20% of traffic is being rerouted to a secondary endpoint, then an alert

2 http://www.itil-itsm-world.com/


Architecture

is raised to operations to consider possible action on the server that contains the primary endpoint.

3.0 Example for applying the SOA Policy Reference Model

This section gives a detailed example for how to use the SOA Policy Reference Architecture to analyze and create the set of policies needed for your organization. We’re going to describe how to take the business requirements, goals, and objectives at the business level, and refine the business needs so that we can:

• Transform the business policies into actionable policies and business rules across the Business, Architectural, and Operational Layers.

• Use the Policy Lifecycle to add improved business agility. • Identify which Policy domains are applicable and how to use Policy

Patterns.

This work in your organization will be led by various architects as described in Figure 1 – Roles and their usage in the SOA Policy Reference Architecture. Various policy sub-domains are associated with each layer as shown below:


Architecture

Figure 17 – Detailed SOA Policy Reference Architecture

3.1 Policy Layers – How to think about and decompose policy so that it is useful

Various policy sub-domains are associated with each layer.

Business Policy

Author

Policy

Lifecycle

Management

Transform

Enforce

Monitor

Service Lifecycle

& Governance Policy

Policy Lifecycle

& Governance Policy


Service

Development

Lifecycle

Model

Assemble

Deploy

Manage

Operational Policy

Service Support &

Delivery Policy

Business

Policies


Business Policy

Business Policy domains for behavior and pe rformance

Architectural Policy domains for SOA Res ources


Business

Policies

Business

Policies

Business

Policies

Process Service Information

Security Monitor Mediation


Architecture

A very simple but intuitive method for thinking about policy and then decomposing the policy into its component parts it to use a Policy Tree as shown in Figure 18 below. The policy tree example shows how a business requirement is refined into one or more business policies at the business layer. The Business Policy should be considered from a Process, Service, and Information resource point of view. Lastly the policies can be mapped to support specific technologies at the operational layer. This shows a very simple example for a Service Level Management requirement.

Figure 18 – Policy Tree example of SLA Policy Top down analysis

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. 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


Architecture

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. 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.

3.1.1 Mapping Business Requirements to Solution Policies and Policy Domains at the Business Layer

The business layer provides a means to transform the requirements defined in the business policy layer into Solution Policies within specific Policy Domains as the first step towards implementing these as operational policies. 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?

The business layer of the SOA Policy Reference Architecture provides a framework to address these questions and decompose what are really business goals into the set of business policy metadata that is required to fully specify policy at the business layer. The following figure shows how the various business layer entities get decomposed into more detailed tasks.


Architecture

Figure 19 - Business Policy Layer decomposition into more detailed tasks

For simple changes to an existing environment using policy, only a subset of these entities may need to be used. However for those readers new to this area or considering larger changes, we shall explain all aspects of this in the following table. Name Description Example 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

The end to end customers response time (from depressing the enter key to response received) should be less than 3 seconds.


Architecture

Name Description Example Governance Policies stages

Quantify Business Objectives

The Business Objectives defines what should be measured in detail to track achievement of the goal in the form of KPI’s.

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: 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 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

The Policy Directive will need to be governed so that agile change can

Marketing will have authority to create,


Architecture

Name Description Example Policies be accommodated in future.

This relates to where the SOA Policy Lifecycle may be implemented.

update or delete any business policies classified as “marketing”.

Table 31 – Decomposition of policy from business goals

The following sections will take you through a step by step approach, starting at a simple level using a Policy tree to identify what tasks at the business level are required in all cases in an example depicted below.

Figure 20 - Align Policy Tree example with Business Layer tasks.

3.1.1.1 Business Goals and Policy Directives

Using guidance from Industry bodies which define Business Policy like the Business Motivation Model (BMM) from OMG, business goals can be refined into:

• One or more Policy Directives defining intent of goal. • One or more detailed Business Objectives defining what should be

measured in detail to track achievement of the goal in form of KPI’s. In our example on Figure it is easy to map the Business Goal to the Policy Tree policy of:

“Customer response time expectations should be met”,


Architecture

It is worth noting that the statement is quite vague, but this is not uncommon as a starting point in clarifying what the business priorities are. It is also easy to map the more detailed and specific “intent” as a Policy Directive:

“The end to end customer Service response time

should be less than 3 seconds “

It is more specific but, it still has no context on where it would be enforced.

3.1.1.2 Solution Context and Policy Domains

The next logical steps are to determine whether, considering solution context and Policy domains, this is a new business policy influencing a new or existing business area.

Figure 21 – Business Layer Policies also require a Content and Domain

If there is a change to an existing policy in an existing policy domain these steps may not be required. If there is a broad context for the Policy Directive, it may be useful to implement this in stages, which may also help with some interim business objectives

3.1.1.3 Solution context & Scope of the Policy Directive

In our example let’s assume the project has 3 phases:


Architecture

Phase 1 – Banking ATM Services only Phase 2 – Add Banking Loan Services Phase 3 – All Banking Services

To assess which of the Policy business sub-domain aligns with the Policy Directive we need to review and think about the four sub-domains of Situational Policy Awareness, Business Situation Policy, Business Automation & Process Policy, and Service Level Management Policy as defined in Error! Reference source not found. and can be seen in Figure on page 69.

3.1.1.4 Policy Domain of the Policy Directive

In our example since the policy directive is about service performance levels the natural fit is Service Level Management policies. There normally are two categories for such SLM policies:

• Customer satisfaction policies defining what client expectations to

succeed in the marketplace are. • Enterprise Operation policies defining how the internal business needs

to be run to be efficient and successful.

As our example identifies “customers”, it is a straightforward mapping to a Customer Satisfaction SLM Policy domain.

3.1.1.5 Policy Refinement, Business Objectives

Once the context is well defined the next logical steps are to decompose the Policy Directive into Solution Policies and to identify how to measure the Policy Directive in the Business Objectives.


Architecture

Figure 22 – Full Policy Business Layer Model

3.1.1.6 Solution Policy Refinement

Taking the Policy Directive and the Solution Context which were more specific in the areas the policies had to apply to (i.e. ATM Services and Loan Services), we can decompose the policies into:

• All Banking ATM Services must provide a response to its service consumer in less than 3 seconds.

• All Banking Loan Services must provide a response to its service consumer in less than 3 seconds.

3.1.1.7 Business Objectives and KPI’s define how we measure the

Business Directive performance

Decomposing the policies from business goals and objectives is an important milestone, but measuring the effectiveness of the policies is also important and often forgotten. Without these metrics, it is impossible to provide to the business stakeholders information on how effective any policy solution is. It also limits the ability to apply ongoing changes to fine tune a solution for improved performance.

In our example we need to measure service latency within the Service Level Management domain for all service requests by customers.

The Business Objective for the solution is:


Architecture

• Monitor all ATM services to ensure they provide < 3 second latency. • Measure average latency of all ATM services. • Provide a warning to business users if 3 second latency is exceeded.

In addition there is the possibility of refining KPI’s further into Red, Amber and Green status for ATM Services:

• Set Green condition if no Banking ATM services exceeds 3 second latency in 24 hour period.

• Set Amber condition if at least one service exceeds, but less than 0.05% of all banking ATM services exceed 3 sec latency in 24 hour period.

• Set Red condition if more than 0.05% of all banking ATM services exceed 3 second latency in 24 hour period AND send Alert Message to Operations to Fix Immediately.

3.1.1.8 Business Policy Governance

Policy Governance defines how Policy directives will be governed or changed in the future. It provides policies for the SOA Policy Lifecycle governance as well as SOA Development Lifecycle Governance. In our example when the business goal is assessed on what the frequency of change might be and by which roles in the organization we find:

• Marketing will manage and optimize this policy on a monthly basis.

At the SOA Policy Lifecycle Governance level we need to ensure that:

• A Marketing role has authority to change any policies within this

solution scope at a later date.

3.1.1.9 Completed example at the Business Layer

Bringing the whole example together at the business level provides us with the following summary in Figure 23:


Architecture

Figure 23 – Completed example using the Business Layer Model

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 KPI’s – 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.

In simple cases, where some changes are being made to an existing policy which is already active in an existing Policy domain and the KPI’s don’t need to change, only the Solution Policies may need to be changed.

3.1.2 Using the Architectural Layer to leverage SOA Policy Lifecycle and Map business policies to Architectural Policies

The architectural policy layer provides a means to transform the requirements defined in the business policy layer into operational policies as shown in Figure 24 below.


Architecture

Figure 24 – Architecture Layer considers both Policy and Service Development

Starting from the Policy Tree example we will illustrate how the architectural Policy layer is used to perform this transformation. In order to consistently perform this transformation Architects leverage the key aspects of the SOA Policy Reference architecture:

• The Service Development Lifecycle – which defines the processes used by the organization to develop and manage their SOA Business solutions. This describes how all the applications are built and integrated.

• The Architectural Policy Patterns which describe common patterns for implementing certain types (domains) of policy enforcements. These patterns are reusable and describe how the PAP’s, PEP’s, PMP’s, etc. are integrated together with the solutions to realize, enforce, and monitor policies as part of the solutions.

• The SOA Policy lifecycle management activities and tools are used by the architects to manage and change the policies used to configure the patterns and thus deliver the business agility into the solutions.

A summary of the Architectural elaboration of the Policy tree example is shown in Figure 25 below, starting from the output of the Business Layer.

Business Policy

Author

PolicyLifecycle

Management

Transform

Enforce

Monitor

Service Lifecycle

& Governance Policy

Policy Lifecycle

& Governance Policy


ServiceDevelopment

Lifecycle

Model

Assemble

Deploy

Manage

Operational Policy


Business

Policies


Business Policy




Business

Policies

Business

Policies

Business

Policies




Architecture

Figure 25 – Overview of Architectural layer policy elaboration

There are three main concepts in the Architectural layer that need to be considered. These are shown in the table below and described in more detail in subsequent sections. Name Description Example 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

Use an SLA Pattern that will monitor service latencies and


Architecture

Name Description Example accelerates time to value and development, by allowing these existing components to be reused rather than having to develop a new solution.

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.

Table 32 – Architecture Layer Decomposition The remaining sections elaborate the SLA policy tree example through the Architectural layer.

3.1.2.1 Decomposing the Solution Policies

The first step in the refinement of the solution policies is for the architects to identify the SOA solution resources to which the policies will apply. In order to consider this, they use the SOA Policy Reference Architecture layer to identify the types of resources that are relevant, as summarized below:

Architecture Process Policies provide configurable control of the manner in which processes operate. Examples include: • Process Flow Decisions to determine activity flows and exceptions. • Process Governance policies to ensure compliance and audit. Architectural Service Policies provide configurable control of services to provide effective usage, routing and quality of service within the solution. Examples include: • Decision Service policies to use rules to configure the way decisions

are made. For example pricing or eligibility. • Quality of Service Routing policies to ensure efficient delivery. • Service Security and Integrity policies to protect resources.

Architectural Information Policies provide configurable control of information used within the solution. Examples include: • Information Security policies to protect information. • Information Quality policies to ensure confidence in information.


Architecture

In our example, the solution policies focus on Quality of service routing and we need to identify the particular services that will contribute to the overall business goals and KPI’s. We have two different services that may contribute to the overall Banking ATM customer response:

• An information service that accesses and validates a customer’s card and account details from their bank to authorize cash withdrawals.

• A banking service which identifies how the ATM can interact with the local bank systems to handle cash withdrawals and uses the above information service.

We will also need to divide up the overall service level budget between these two types of service and thus associate individual SLA policies with each service. Taking the SLM Solution Policy and refining it, we allow 2 seconds overall latency for the banking services, and 1 second for the information service. This gives IT some leeway to meet the business goals easily. This results in the policy tree example shown in Figure 26 below.

Figure 26 – Policy Tree Example after decomposing the customer service policy.

3.1.2.2 Identifying the Policy Domain Patterns

The next step in the architectural refinement of the policies is to identify the architectural patterns that will be relevant for the policy domains and resources


Architecture

that are needed. These patterns represent capabilities that are already deployed in the infrastructure and allow policies to be quickly applied to the solution resources using SOA principles. These are illustrated in Figure 27 below.

Figure 27 – Use of Policy Points to implement Domain Patterns

In our example there is an existing pattern for implementing Service Level Agreements as shown in Figure 28 below. If this pattern did not exist there would need to be a new development initiative started to develop a new pattern that would support the type of policy required.


Architecture

Figure 28 – Selected Pattern to implement SLA Policies

This pattern provides the following essential capabilities that we will need for the SLA policies and the associated KPI metrics:

• An ESB that can assess service quality and select service endpoints that can deliver the required service level.

• Each service can be monitored to obtain individual metrics. • The metrics can be aggregated to produce the dashboards used to

indicate how well the customer service level policies are working. • The metrics can be used to categorize the services in terms of their

latency and thus their appropriateness. In terms of our policy tree we can now complete the next stage of our elaboration as shown in Figure 29.

Consumer Provider

Author Service Policy

Repository

Enforce

Monitor

Pattern: SLA Management

ESB

SLA Policies

Service Performance


Architecture

Figure 29 – Policy Tree example after selecting domain pattern.

3.1.2.3 Mapping the decomposed solution policies to the pattern

The final step is to define the set of policies that will actually be needed to use the SLA pattern for each of the services. In this case we need to consider how the Policy Authoring can transform the solution policies into a set of policies that can be executed using the domain pattern in the Operational Layer. This step needs to consider the Operational Layer implementations of the PEPs, PDP’s, and PAP’s that support the domain pattern. This also needs to include how the KPI’s can be obtained and displayed as shown in Figure 30 below.


Architecture

Figure 30 – Transforming the Solution Policies & KPI’s to policy sets.

In our example we require two types of operational policy:

• A configuration and mapping that can route requests to an endpoint that has capacity. This will map into a routing policy for each service.

• A recording of the latency of each interaction to maintain statistics on whether the SLA response was met. This latency can also be used to characterize each service allowing the ESB to interpret the service level requests in the context of current service performance.

Each of these configurations will be different according to the consumer invoking the service (each consumer may need a different SLA) and therefore we will require both routing policies and monitoring policies to be combined into a single policy set. Thus, for each type of service we invoke as part of the overall interaction, we need to build a policy set containing these distinct policies. This policy set is the main output of the transformation stage of the policy lifecycle shown in Figure 31.


Architecture

Figure 31 – Policy Tree example after mapping the solution policies to the domain pattern.

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.

3.1.2.4 Optional - Architects select specific products to implement the

Pattern within the Solution Context

Where an operational solution implementing the pattern using policy is already deployed this stage is not required. However when transforming a business or extending a policy domain to a different part of the business, the next logical step is for the SOA architects to select the specific products required for the PAP, PEP, and PMP and finalize how these interact together if this has not yet been done.


Architecture

3.1.3 Operational Layer

The operational policy layer provides a means to enforce and monitor the policies as part of the operational deployed solutions shown in Figure 32 below.

Figure 32 – Operational Policy Layer

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. Name Description Example Security Policy

• Access Control Policies for access to runtime resources.

• Message Protection Policies for

AAA (Authentication, Authorization, and

Business Policy

Author

PolicyLifecycle

Management

Transform

Enforce

Monitor

Service Lifecycle

& Governance Policy

Policy Lifecycle

& Governance Policy


ServiceDevelopment

Lifecycle

Model

Assemble

Deploy

Manage

Operational Policy


Business

Policies


Business Policy




Business

Policies

Business

Policies

Business

Policies




Architecture

Name Description Example protection of data contained in messages at runtime.

• Data Protection Policies to protect data at rest.

• Integrity Policies to ensure that data is not invalid or does not become invalid.

• Protection against Denial of Service Attacks to ensure that runtime services do not become unavailable.

Accounting) policy implemented as WS-SecurityPolicy or XACML policy configuration selected for each service interaction involving customer account data.

Service Mediation Policy

• Service Level Agreement policies for throttling, rerouting or reporting SLA violations.

• Messaging and enrichment policy for consistently filtering or transforming messages.

• Routing policy to route requests to an appropriate service based on message or status criteria.

• Protocol mediation policies to bridge inbound and outbound protocols.

• Partner and customer gateways to extend connectivity outside of the DMZ.

• Mediation Device Management to configure device attributes such as memory.

• Reliable Messaging Interactions to ensure messages are not lost and transactionality is maintained.

Routing policy configuration for each interaction. This will be selected dynamically based on the customer service level in the record. Endpoints for the service implementation will be selected based on historic latency measurements.

Service Monitoring Policy

• Monitoring policies monitor services and provide instruction to operations group on actions to take.

• KPI monitoring and reporting into service dashboards.

Logging policies attached to each interaction determine what information needs to be recorded in order to calculate the KPI’s and monitor adherence to the required Service Level Agreement.


Architecture

Name Description Example Service Support and Delivery policy

• Service delivery policies ensure availability and capacity of IT or service resources.

• Service Support policies provide management of provisioning, fault resolution and downtime minimization.

Repeated Service level exceptions should trigger provisioning of additional service capacity.

Table 33 – Operational Policy Types Operations managers leverage three key aspects of the SOA Policy Reference Architecture shown in32:

• The Service Development Lifecycle – which defines the processes being used by the organization to develop and manage their SOA Business solutions. This describes how all the applications use the deployed operational PDP’s and PEPs and thus define the deployment destination of the policy sets to configure any particular type of interaction to realize the policies required.

• The Architectural Policy Patterns describe the common patterns for

implementing certain types (domains) of policy enforcements. These reusable patterns describe how the PAP’s can specify multiple different policies (and their associated policy sets) and merge them to be enforced by the PEPs and PMP’s.

• The SOA Policy Lifecycle management activities and tools are used by the

architects to manage and change the policies that are used to configure the patterns and transform them into the policies and policy sets. At the operational level the policy sets from different policies are combined at the PEP or PDP, tested and activated in the production systems thus delivering the business agility into the solutions.

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.


Architecture

Figure 33 – Overview of Operational layer policy elaboration

Name Description Example 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 PDP’s 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

The policy sets from the architectural layer will define what needs to be

Raise alert if the latency is > SLM


Architecture

Name Description Example dashboards and alerts

recorded from each interaction. However the means of displaying the policy KPI’s in dashboards and reacting to important exception criteria and alerts will still need to be configured.

Policy or a service utilization is > 90%.

Table 34 – Operational Policy Decomposition The Operational Layer provides the implementation of the various PAP’s, PDP’s and PEPs and will usually provide the capabilities to automatically realize the tasks described above. The remaining sections elaborate the SLA policy tree example through the Operational layer showing the tasks that these operational products will need to perform.

3.1.3.1 Collate policy sets across policies for any given interaction

In the Policy Tree example the main functional policy at the operational layer relates to realizing the service level agreement on any particular interaction. The first task is to make sure that other policies associated with the interaction are retained. In this case the customer's account details must be protected so all interactions with the banking service and information service will need to use encryption. This means that the policy set provided from the architectural layer needs to be combined with any existing policy sets associated with invocations of these services. The combined policy set now includes operational policies in an enforceable form (e.g. WS-Policy) for Routing, Monitoring, and the existing security policies. This policy set combines the service level request policy with other interaction policies such as message protection policies to ensure that the account information is protected by encryption.

3.1.3.2 Map policy sets to PDP / PEP configuration

While some policies (e.g. WS-Security) may be fully defined within the policy set itself, others may use dynamic information or registry lookups for enforcement. This means that the mediation interprets the policy in the context of the interaction and the status of the available services. In order to meet the service level agreement we need to make the mediation enforce the following policy:

“Select banking service where latency is less than 2 seconds"


Architecture

So the policy will define the latency required (2 seconds). This might be dynamic based on the customer. For example, gold customers have a 2 second response time, while silver customers might have a 5 second response time. In this case, information from the interaction would have to be used to determine if this was a gold or silver customer. In our example the requirement is defined by the consumer service rather than the customer which means that the mediation can retrieve the requested latency from the policy set associated with the interaction. The second part is then to route a particular service request to a particular service endpoint that can meet this latency requirement. The service endpoints available will be dynamic and vary according to system load. These will be managed and monitored separately and the dynamic information maintained in a registry. Based on this registry information the mediation can then perform a lookup and select an endpoint that meets the requested latency. Mediation designs may well cache these lookups, so that requests can be routed straight to a suitable endpoint based purely on the policy.

3.1.3.3 Map monitoring policy sets to KPI dashboards and alerts

The final activity in the operational layer is to configure monitoring such that the goals of the policy directives are measurable and visible. In our example we can also consider the following conditions to be of interest:

“Raise alert if latency is > SLM Policy" or "Raise alert if service utilization is > 90%”.

As part of the policy set associated with the interaction, certain characteristics of the interaction will be recorded. The PMP is the monitoring capability in a policy domain which monitors service performance at runtime. Monitoring Policy sets will configure the information to be recorded by the PMP. In order to provide visibility, or take action from this monitoring, the operational layer has to consider two aspects. The first relates to configuring the KPI’s in a dashboard so that the Business Users (and Operations Managers) can see how well the SLA’s are being adhered to. Part of the design process for a domain should be to define the dashboards and means of checking the KPI’s. It is the Operational Managers task to make sure those new displays for these new KPI’s are added to the dashboards so the policies can be monitored and their impact on the business assessed. The second aspect relates to identifying situations where an action needs to be taken as a result of what is being monitored. In our example this could include identifying alerts to the management dashboard if a significant number of


Architecture

interactions were not meeting their SLA’s. These alerts could also trigger provisioning of additional resources / services to meet the need. This form of operational systems management is becoming commonplace in dynamic infrastructures and cloud. The operational policy layer is the main point at which the application policies can be easily related.


Architecture

4.0 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. 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 lifecycle 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. A worked example has been provided that illustrates how the layers of the SOA Policy reference architecture help decompose policies from the business goals and intents, through architectural patterns being used to realize certain policy domains through to the operational deployed enforcement points that realize and monitor those original goals. It is hoped that this paper has provided the reader the structure, insight and understanding needed of the SOA policy lifecycle such that they can competently deliver the benefits of policy usage in their organization.

5.0 Mapping of SOA Policy Architectural Elements to IBM Product SOA Policy Architectural Element

IBM Software Release Comments

PAP WSRR v7.5.0.2 Supports WDP v5 and

WMB v8 for policy enforcement and Tivoli ITCAM for SOA v7.1.1.3 or v7.2 for policy monitoring

WSRR v8 Same as above, but adds user friendly policy widget for policy enforcement syntax


Architecture

PEP WDP v5 Full support for WS-Mediation-Policy

WMB v8 Partial support for WS-Mediation-Policy

PMP Tivoli ITCAM for SOA v7.1.1.3

Supports Situational Policy only in PAP

Tivoli ITCAM for SOA v7.2

Supports Monitoring Policy in PAP and adds the Service Endpoint table

6.0 References and Appendix

6.1 References

“Overview of OMG Business Motivation Model: Core Concepts”, Object Management Group, , 8 December 2008, http://www.omg.org/oceb/BMM_Overview-Core_Concepts_%5B081208%5D.pdf “Business Motivation Model (BMM)” – Object Management Group, May 2010, http://www.omg.org/spec/BMM/1.1/

6.2 Term Definitions

Term Definition

Conflict Analysis & Resolution

Conflict analysis for policy is the ability to identify when two policies have a subset of those policies that are in conflict with each other and cannot both be enforced. Conflict resolution is the ability to suggest changes to one or more of the policies to eliminate such conflict.

Policy Administration Point (PAP)

Provides policy capabilities that allow authoring of policy, management and governance of the policy and its assignment to resources, and administration of policy results during runtime.


Architecture

Term Definition

Policy Analytics Responsible for providing information on how often policies are being accessed, how often those policies are “triggering”, i.e. taking action, and where vulnerabilities may exist that need to be addressed. Analytics provides an overall view, a management view of what’s going on in the distributed policy environment, and give the policy management function the opportunity to assess and take action.

Policy Association A resource (such as a service or an operation of the service) can be associated (i.e. attached) to one or more policies or policy sets. A policy association indicates that the policy should be applied to the resource at runtime.

Policy Audit Provides for the centralized logging of runtime activities for policies.

Policy Decision Point (PDP)

Evaluates participant requests against relevant policies/contracts and attributes to render an authorization, eligibility or validation decision or provide calculated results.

Policy Enforcement Point (PEP)

Provides the capability to receive policy from the PAP and apply the policy to a resource transaction and enforce the policy decision.

Policy Impact Analysis Identifies the potential impacts to changing a policy. This includes being able to identify which resources are applied to a specific policy and in what manner (i.e. at the service level, operation level, for a consumer service, provider service, or both).

Policy Information Point (PIP)

Provides external information to a Policy Decision Point, such as LDAP attribute information, or the results from a database with information that must be evaluated to make a policy decision.

Policy Monitoring Point (PMP)

Provides a summary of operational results for policy enforcement and policy monitoring of transactions with appropriate queries, reports, and management consoles and data made available for review and action.

Policy Pub/Sub Provides the ability to bind policy enforcement points to operational assets (i.e., which enforcement or monitoring point handles which policies and resources).


Architecture

Term Definition

Policy Resource Analysis

Provides the ability to identify the current status of a resource with respect to policies. The function provides the ability to understand the specific policies which are already associated to the resource.

Policy Resource Definition

Ability to define resources in such a manner as to allow policy association with those resources.

Policy Runtime Usage Validates that published policies are in fact being used as contemplated. This means being able to query what resources the policy is applied to and where the resource/policy pair is being enforced.

Policy Traceability Ability to keep track of the authoring of policies (create, read, update, delete) and any subsequent action to them including action during the policy lifecycle such as retirement. This enables management of policy accountability.

SOA Policy Layers A vertical dimension for policy classification that provides a level of abstraction for policies including business, architectural, and operational.

SOA Policy Lifecycle Management

Manages the authoring, transformation, enforcement, and monitoring of the policies.

soa policy reference architecture full article - ibm · pdf filesoa policy reference...

Documents