SOA Policy Reference Architecture Full Article

Transcription

1 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 Page 1 of 94

2 Table of Contents 1. Introduction Abstract Purpose and Scope Audience & Usage The journey of policy Policy Management Primer Policy Administration Point (PAP) Policy Monitoring Point (PMP) Policy Enforcement Point (PEP) Policy Decision Point (PDP) Policy Information Point (PIP) SOA Policy and SOA governance Description Policy Lifecycle Management Policy Lifecycle & Governance Policy Policy Lifecycle Policy Building Blocks SOA Policy Layers Business Policy Layer Architectural Policy Layer Operational Policy Layer Service Development Lifecycle Service Lifecycle & Governance Service Support & Delivery Example for applying the Model Policy Layers How to think about and decompose policy so that it is useful Mapping Business Requirements to Solution Policies and Policy Domains at the Business Layer Using the Architectural Layer to leverage SOA Policy Lifecycle and Map business policies to Architectural Policies Operational Layer Conclusion Mapping of SOA Policy Architectural Elements to IBM Product References and Appendix References Term Definitions Page 2 of 94

3 1. 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 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. Page 3 of 94

4 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 follows 1 : 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, 8 December 2008 Page 4 of 94

5 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 architecture defines an enterprise approach to: Page 5 of 94

6 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 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 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: Page 6 of 94

7 Usage of the Business Policies & Domains Business Plans & Objectives Business Analyst & Operational Policies and Standards Enterprise Architect SOA Architect Infrastructure Architect Security Architect Usage of Policy with SOA Services SOA Policy Patterns for services Policy KPI s SOA Policy Infrastructure Security Policy Patterns Developer Service & Policy Realization Figure 1 Roles and their usage of the Role Business Analyst Enterprise Architect Usage MUST use the business plans and objectives and refine them into business policies and domains that are needed for their implementation. 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 Page 7 of 94

8 Infrastructure Architect Security Architect SOA services with policy ( Usage of Policy with SOA Services ) 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. 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. 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, 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 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. Page 8 of 94

9 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 Page 9 of 94

10 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. Page 10 of 94

11 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 3. Automation Automation of policies can improve performance of IT systems. 4. Traceability Trace which business function(s) are using the policies Reduced costs and less risk in projects Business Policies can be captured in form that both business and IT can understand and collaborate Reduced risk for new changes since dependencies can be viewed and validated Page 11 of 94

12 5. Re-use Reduced time, effort & cost for ongoing maintenance & new business projects. 6. Dynamicity Reduced effort to change and test solutions to meet new business needs 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. 8. Change Management IT have good tools for Policy changes 9. Policy Measurements IT can monitor IT Policy performance to identify problems and provide ongoing improvements Table 2 Benefits of Policy Usage With IT being more efficient, more new business projects can be undertaken Business changes available faster to address changing market needs & opportunities 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. IT can enable some business policies to be changed by business users Business can monitor effectiveness of high level business policies to assess how effective they are using KPI s 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 Policy Authoring & Management Formalized Defined Policy domains & Vocabulary Standardized Consistent semantics across business domains Dynamicity Policies can provide Page 12 of 94

13 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 Policy Enforcement Automation Policies invoked and enforced by runtime applications, processes and services 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 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. Page 13 of 94

14 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: Page 14 of 94

15 PAP Policy Authoring, Policy Management, Policy Runtime Architectural Pattern for Service Policy: PMP provides overall picture on policy results in the distributed environment Policy Administration Point (PAP) Author Store Repository Monitor Policy Monitoring Point (PMP) PEP Evaluate Policies And take action Consumer Enforce Middleware Policy Enforcement Point (PEP) Provider PDP renders Authorization, eligibility, Or validation decisions Or provides calculated result Policy Decision Point (PDP) Policy Information Point (PIP) PIP provides External information Figure 3 SOA Policy Points 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. Page 15 of 94

16 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 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 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. Page 16 of 94

17 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. Page 17 of 94

18 2. 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 assists the organization in understanding and properly creating its SOA Policy 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 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 has a strong interaction with the Service Development Lifecycle (SvDLC) and will also be discussed. Page 18 of 94

19 Policy Lifecycle Management Policy Lifecycle & Governance Policy Business Policy Business Policy domains for behavior and performance Business Policies Architectural Policy Service Development Lifecycle Service Lifecycle & Governance Policy Author Transform Architectural Policy domains for SOA Resources Policies Model Assemble Enforce Operational Policy Deploy Monitor Policy Building Blocks Operational Policy domains that are non-functional Operational Policies Manage Service Support & Delivery Policy Figure Policy Lifecycle Management The Policy Lifecycle Management consists of 3 main areas as shown on the figure below: Page 19 of 94

20 Policy Lifecycle Management Policy Lifecycle & Governance Policy Business Policy Business Policy domains for behavior and performance Business Policies Architectural Policy Service Development Lifecycle Service Lifecycle & Governance Policy Author Transform Architectural Policy domains for SOA Resources Policies Model Assemble Enforce Operational Policy Deploy Monitor Policy Building Blocks Operational Policy domains that are non-functional Operational Policies Manage Service Support & Delivery Policy Figure 5 SOA Policy Lifecycle within the 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: Page 20 of 94

21 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, 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: Page 21 of 94

22 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 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 Page 22 of 94

23 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 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. Author Monitor Transform Enforce Figure 8 Policy Lifecycle Phases Page 23 of 94

24 These Phases are described in the following sections 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 None Identify policy domains Identify the vocabularies The policy architect must understand the intent of the policy The policy architect must identify the policy domain or set of policy domains that are needed to solve the policy directive. The policy will be authored using a 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. 1. Review the policy domains and select the subset needed for this policy intent. 2. Identify the KPI s for each policy domain selected. 1. Review and determine if the 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. Only certain roles will be Page 24 of 94

25 Name Goals Tasks Governance needed for each domain Author the specific policy statements 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. Author the policy statements in each policy domain identified previously. 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. 1. For each policy domain, use the policy rules engine or policy templates, and specify the appropriate parameters to instantiate those policies. allowed to create or enhance the vocabulary. It will be necessary to identify personnel that have that role and consult and work with them. Only certain roles will be allowed to create, read, update, or delete in specific policy domains. Table 4 Author Phase Tasks 2. Test the policies via simulation to make sure they do what you intend 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, Page 25 of 94

26 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 Page 26 of 94

27 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 Transform authored policy into internal representation The policies must be deployed to the PEPs responsible for the physical execution of the policy Instantiate specific policy or set of policies that have been authored. 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. 1. The policy is transformed to a proprietary format that is required for that PEP. The PAP and PDP must be aware of each other. None Table 5 Transform Phase Tasks Page 27 of 94

28 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 Policy Analytics The policies must then be enforced when events or transactions take place on the resources that the units are responsible for. 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. Receive event or transaction for a resource. 2. Identify policies for that resource. 3. Enforce the policy using the PDP or PIP when needed. 1. Create results for policy execution whenever analytics occur. 2. Dispatch analytics to PAP and PMP. The PEP will need connectivity and sometimes security access to the PDP and PIP. Only certain roles should be allowed access to analytics. Table 6 Enforce Phase Tasks Monitoring Phase Page 28 of 94

29 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 Provide policy audit Policy Analytics The policies must be monitored when events or transactions take place on the resources that the units are responsible for. Policy runtime audit provides for the centralized logging of runtime activities for policies. 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. Table 7 Monitor Phase Tasks 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. 1. Provide reports and queries to runtime policy events. 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. Interaction with operational units in the environment will need to be governed. ITIL is a good governance foundation in this area. Only certain roles should be allowed access to audit. Only certain roles should be allowed access to analytics. Page 29 of 94

30 SOA Policy Lifecycle Example The following illustrates an example of the policy lifecycle Use Case #1. 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. Policy Authoring 2A. Transform Phase (PAP) the TooSlowAction policy is assigned to the Credit Card Service primary endpoint. 4. Monitor Phase (PMP) PMP notifies operation when monitoring policy breached and sends management information to PAP. Application 2C. Transform Phase (PEP) the TooSlowAction policy for the Credit Card Service is converted to PEP internal representation Message Message 2B. Transform Phase (PAP & PEP) the TooSlowAction policy for Credit Card Service is deployed from the PAP to the PEP 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 3B. Enforce Phase (PEP & PMP) PEP sends information about transaction and policy results to PMP. Message Message Service Credit Card Primary endpoint Credit Card Secondary endpoint 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 Page 30 of 94