SOA Governance Technical Standard : SOA Governance Process Activities

 

The purpose of this appendix is to provide information regarding suggested governing and governed processes. The information is intended to provide guidance and thought-leadership for consideration as you define the governing and governed processes for your organization or company. They do not have to be followed verbatim. The activities in the appendix represent key SOA governance activities. There may be additional IT governance-related activities needed as part of normal portfolio and lifecycle management.

The appendix is divided into two major sections: governing processes and governed processes. The processes correspond to the content in the main sections of this SOA Governance Framework document. Each section is divided into subsections. Each subsection includes process and checkpoint tables. The process tables provide suggestions for process names, goals, inputs, activities, and outputs. Each process table is followed by a checkpoint table. The checkpoint is a key activity listed within the process table that serves as an approval point within the process.

SOA Governing Processes

The SOA governing processes are applied to the SOA governed processes as described in SOA Governing Processes. They are Compliance, Dispensation, and Communication.

Compliance Activities

Compliance reviews may be triggered by multiple events:

  • SOA process-based during the execution of the governed processes
  • Project management-based, such as approval gates or project task milestones
  • Vitality-based (triggered by the SGVM; could be temporal or event-based)

Compliance reviews may be conducted as part of a standard quality review, such as the checkpoint at the end of a Design phase within a system development methodology. Compliance may also be measured via an ongoing monitoring and analytics method, such as an information collection method during the operation of the governed processes.

Compliance reviews may also be initiated as part of an ongoing monitoring process cycle, such as the SGVM. The cycle may specify that processes be reviewed at specific temporal-based dates within a fiscal year, such as every three or every six months. The cycle may also specify event-based triggers related to business or IT events, such as major organizational changes affecting the membership of the SOA Governance Steering Board.

The compliance results indicate where the governed processes conform to the compliance requirements and non-conforming exceptions. The exceptions should be adjusted or re-aligned in order to meet the compliance requirements, or the Dispensation process may be initiated.

PROCESS

Perform Compliance Review

Goal

Determine adherence or non-conformance based upon the established SOA governance compliance criteria and strategies.

Input

Compliance review request

Service change proposal

Service contract

Service policy

Compliance evaluation criteria

Activities

Conduct compliance assessment

Ensure that compliance gaps have been documented

Ensure that gap resolutions are identified

Evaluate risk of non-conformance

Document governance vitality metrics

Output

Compliance validation

Compliance risk analysis

 

CHECKPOINT

Document Compliance Completion

Input

Compliance review request

Service change proposal

Service contract

Service policy

Compliance evaluation criteria

Compliance decision and resolution

Activities

Identify open compliance requests

Collect compliance results, such as decisions, non-conformance risks, compliance follow-up action items, compliance reviewers, and compliance evaluation criteria used

Close the compliance request

Output

Compliance documentation

Used Guidelines

SOA Governance Compliance Management Guidelines

Dispensation Activities

If compliance requirements cannot be met, the Dispensation process may be initiated. The Dispensation process activities are to conduct an appeal and request a dispensation. A dispensation approval may be fully or partially granted, or not granted. If the dispensation is not granted, then the items not in compliance must be corrected. If the dispensation decision is not agreed with, the issue may be escalated to the next level of governance.

If a new condition, obsolete condition, or error in the dispensation guidelines occurs, then a trigger should be issued to the SGVM process.

PROCESS

Manage a Dispensation Request

Goal

The processes defined within the governance framework or contract for resolving disputes between parties.

Input

Dispensation log

Appeals request

Escalation contacts

Disputed service contract

Service policy

Incident reports (unresolved)

Problem report

Service audit reports

Service performance reports

Service user interaction report

Service test results

Activities

Receive and log the appeals requests

Identify the proper reviewers for the dispensation review

Conduct the dispensations review

Document the dispensation results

Perform the dispensation follow-up activities at the specified time or event (relevant when the dispensation approval is for an interim time period until a final corrective solution is in place)

Close the dispensation request

Output

Contract violation resolution (resolved dispute or escalation)

Service change proposal (possibly)

Service contract (possibly updated)

Service policy (possibly updated)

Dispensation log

 

CHECKPOINT

Document Dispensation Completion

Input

Contract violation resolution (resolved dispute or escalation)

Service change proposal (possibly)

Service contract (possibly updated)

Service policy (possibly updated)

Dispensation review results

Activities

Review open dispensation request

Collect dispensation results, such as decisions, accepted risks, dispensation follow-up action items, dispensation reviewers, and dispensation evaluation criteria used

Close dispensation request or schedule follow-up actions per the dispensation results

Output

Dispensation documentation

Used Guidelines

SOA Governance Dispensation Management Guidelines

Communication Activities

The SGVM Plan phase identifies the SOA governance stakeholders, defines the communication strategy and plan, and then identifies the communication channels to be used. The SOA governance communication activity is to execute the Communication Plan and measure the associated compliance.

PROCESS

Communication

Goal

Communicate according to the communication strategy.

Input

Stakeholder analysis (from SGVM Plan phase)

Communication strategy (from SGVM Plan phase)

Communication plan (from SGVM Plan phase)

Communication channels (from SGVM Plan phase)

Activities

Execute the communication plan

Output

Media as specified in the communication plan

 

CHECKPOINT

Measure Compliance to Communication Plan

Input

Communication plan

Activities

Conduct compliance assessment of the executed communication plan tasks

Output

Compliance report

Compliance exceptions

Compliance corrective action plan

Compliance dispensation plan

Used Guidelines

SOA Governance Metrics Guidelines

Standard Project Management Guidelines

SOA Governed Processes

SOA governing processes are executed to provide governance to the planning, design, and operational SOA processes, referenced in this document as SOA governed processes. This section provides information regarding the goals, inputs, activities, and outputs of the SOA governed processes. Process checkpoints denote key approval points. This information may serve as the starting point for defining new SOA governed processes. It may also be used as a validation to identify gaps in existing SOA governed processes.

To better understand the interactions between the SOA governed processes, the information flow between the SOA governed processes in Main SOA Information Flows shows the relationships between the major process components.

Main SOA Information Flows

Main SOA Information Flows

Information Entity

Description

Solution Change Request

Description of proposal for solution change

Solution Description

Description of a solution

Service Consumer Contract

Description of the contract between a consumer and a service provider

Service Need

Description of the requirements of a service

Service Change Proposal

Description of proposal for service change

Service Re-use Plan

Description of the existing services a solution wants to use

Service Producer Contract

Description of the contract between Service Portfolio Management and the service producer

Service Description

Description of the service

A full set of possible SOA information entities can be found in SOA Governance Process Information Entities.

Service Portfolio Management Activities

PROCESS

Service Portfolio Planning

Goal

Identify needed changes to your service portfolio, including new services, changes to existing services, re-factoring of existing services, and retiring of existing services.

Input

New service needs

Service change proposals

Service usage plan and contracts

Service funding model

Enterprise architecture plan

Activities

Manage new service needs received and analyze their business justification

Manage service change proposals

Manage new and changed service contracts

Identify and manage changed service policies

Identify service capacity in relation to service usage needs from the service contracts and propose changes to the services if needed

Plan for service obsolescence

Plan for service versioning

Analyze emergent usage patterns to identify shortcomings or gaps in the current service portfolio

Assign ownership to new services

Assign funding to new services

Assign appropriate classifications or other information used to locate the service within your service catalog

Catalog the services that will be created, enhanced, used, or retired as part of the projects that implement the service roadmap

Validate service planning against the enterprise architecture plan

Output

Service roadmap

New overview service descriptions including, e.g.:

Service contracts for the first consumers

Service policy

Service classification

Service ownership

Service funding

Service version

Business justification

Usage plan (if the service will use other services)

Updated service descriptions

 

CHECKPOINT

Approve Service Roadmap

Input

Service roadmap

New overview service description including, e.g.:

  • Service contracts for the first consumers
  • Service policy
  • Service classification
  • Service ownership
  • Service funding
  • Service version
  • Business justification
  • Usage plan (if the service will use other services)

Updated service descriptions

Activities

Approve service roadmap

Approve service description (as above)

Output

Approval of service description

Approval of service roadmap

Used Guidelines

Service Portfolio Guidelines

Service Classification Guidelines

Service Ownership Guidelines

Service Business Justification Guidelines

Service Change Management Guidelines

Service Contract Guidelines

Service Policy Guidelines

 

PROCESS

Service Identification and Business Justification

Goal

This process identifies services from a business process decomposition, requirements for information as a service, or application decomposition.

Input

Business needs

Solution process

Enterprise architecture

Service portfolio (existing services, both planned and operational)

Activities

Analyze if the service is justified to the current business strategy and EA and fits with the long-term goals of the organization

Analyze if the service can perform according to the desired business needs (both functional and non-functional)

Analyze the re-use potential of the service

Analyze the costs of operating and consuming the service

Output

Service identification

Service characteristics

Service portfolio (existing services, both planned and operational)

 

CHECKPOINT

Approve Identified Services

Input

Service identification

Service characteristics

Service portfolio (existing services, both planned and operational)

Activities

Review the identified services

Approve identified service definitions

Output

Approve selected service definitions

Used Guidelines

Service Identification Guidelines

Service Taxonomy Guidelines

 

PROCESS

Service Ownership

Goal

This process identifies and manages service domains and service ownership (need to identify domains and owners for the services that may arise from solution development and also services that may be consumed by the solution).

Input

Service portfolio

Activities

Classify the service to understand what domain it belongs to

Analyze service ownership (has an impact on service funding)

Output

Service classification

Service ownership

 

CHECKPOINT

Approve Service Ownership

Input

Service classification

Service ownership

Activities

Ensure compliance to guidelines

Output

Approval of service ownership

Used Guidelines

Service Classification Guidelines

Service Domain and Ownership Guidelines

 

PROCESS

Service Funding

Goal

This process establishes the rules for service funding as well as enhancing the services and mechanisms used to provide incentives for service re-use (or charge-back).

Input

IT funding model

SOA governance principles

Organizational & financial structures

Activities

Define the service funding model based on the IT funding model, governance strategy and principles, SOA maturity level, and organizational & financial structures

Output

Service funding model

Service incentive model

 

CHECKPOINT

Approve Service Funding Model

Input

Service funding model

Service incentive model

Activities

Ensure that a funding model exists and is used

Output

Approval of service funding model

Used Guidelines

Service Funding Guidelines

 

PROCESS

Service Change Management

Goal

Additional change management concerns beyond traditional deployments exist for loosely connected solutions where build dependencies are not easy to control within configuration management. Examples include:

1. A package application which is interfaced via an API is upgraded to a newer version.

2. A package application which is interfaced via an API has new configuration applied which gives it different behavior to the integrated transaction. This can also happen if the underlying data changes in context; that is, the business rules associated with that data are altered.

3. A database which is interfaced via a database connector is altered at the table, element, index, or table space level. This type of change can break the implicit binding between the database and the connector.

4. The operating system can be altered via an upgrade or completely swapped out to a different O/S. This type of change can impact a remote connector software driver and disable it.

5. The network can be altered in many ways, where changes to the DMZ, firewall, routers, and hubs can negatively impact the lower-level bus services of the integrated solution.

6. Other application services which provide support to the distributed solution can change without warning; proxy server, web server, LDAP, etc.

7. Components outside of the LAN and WAN can negatively impact the integrated solution; for example, loss of Internet, remote SOAP/XML/HTML packets are altered. Any B2B transaction has this type of issue.

These application, infrastructure, and environmental impacts are outside of the scope of classic configuration management tools. Appropriate change control processes have to be stringent and well devised to capture such a large scope, and are difficult to implement (and rarely are). Integration solutions are notorious for being susceptible to such events. Managing services potentially adds one more risk to the integrated enterprise; however, there are techniques which can minimize the risk and actually make them less risky than the aforementioned.

Input

Service change proposal

Service contract (new and revised)

Service policy (revised)

Service implementation change

Service portfolio

Activities

Analyze possible service implementation change to ensure service consistency; if necessary define changes to service interface

Analyze service change proposals

Analyze revised service policy

Analyze new and revised service contracts

Analyze the change request including the cost of redevelopment, revalidating the service, and the solutions using the service

Prioritize service changes and revise service roadmap

Output

Service portfolio (revised)

Service change

 

CHECKPOINT

Approve Service Change

Input

Service portfolio

Service change

Activities

Ensure compliance to guidelines

Output

Approval of service change

Used Guidelines

Service Change Management Guidelines

Service Versioning Guidelines

Service Policy Guidelines

Service Contract Guidelines

Service Lifecycle Governance Activities

PROCESS

Service Definition

Goal

The process of creating new or changed functional and non-functional requirements for the service based on the service needs and consumers the service will support.

Input

Service Description (from Service Portfolio Management) including:

Contracts for the first consumers:

  • Policy
  • Classification
  • Ownership
  • Business justification
  • Usage plan (if the service will use other services)

Service Processes

Activities

Using the services need, the contract, and the requirements from the service consumers:

  • Define the functional requirements for the service
  • Define the non-functional requirements for the service

Using the change proposal for existing services:

  • Define requirements for changes needed
  • Define requirements changes due to contract or policy changes

Output

Service requirements

 

CHECKPOINT

Approve Service Requirements

Input

Service requirements

Activities

Ensure that the requirements were defined according to the service requirement guidelines

Output

Approval of service requirements

Used Guidelines

Service Requirement Guidelines

 

PROCESS

Service Realization Planning

Goal

This process defines the key activities of the analysis to build a service and the techniques required in design, assembly, testing, and deployment of services. Some of the variables may be predetermined by portfolio decisions and reference architectures.

Input

Service description

Service metrics

Service processes

Activities

Analyze the service requirements to detect if the service should:

  • Be a new implementation
  • Use existing legacy functionality
  • Be an external service
  • Be a composite of existing services
  • Be a change of existing service

Create a realization plan for the service development and deployment

Output

Service realization plan

Service techniques

 

CHECKPOINT

Approve Service Realization Plan

Input

Service realization plan

Service techniques

Activities

Ensure conformance to guidelines

Output

Approval of service realization plan

Used Guidelines

Information Exchange Guidelines

ESB Guidelines

Pattern Usage Guidelines

Security Guidelines

Service Development Guidelines

Service Interface Guidelines

Service Logging/Audit Guidelines

Service Project Management Guidelines

Service Taxonomy Guidelines

Service Versioning Guidelines

 

PROCESS

Service Modeling

Goal

The detailed design and specification of a service based upon design techniques, patterns, and standards.

Input

Service policy

Service realization plan

Service techniques

Service requirements

Activities

Create the service interface (contact first) or do the interface changes for an existing service:

  • Use the information exchange model to specify the parameters of the operations
  • Create a service description using the service taxonomy
  • For web services interfaces, create a WSDL definition file
  • For non-web services interfaces, create associated artifacts

Create the service implementation model:

  • Identify applicable service design patterns
  • Identify appropriate legacy integration patterns, if necessary
  • Identify possible external service usage
  • Use the local software development method to create the design

Output

Service model

Service policy

Service modeling metrics

 

CHECKPOINT

Approve Service Model

Input

Service model

Service policy

Service modeling metrics

Activities

Ensure conformance to guidelines

Ensure modeling metrics have been collected

Output

Approval of service modeling

Used Guidelines

External Service Usage Guidelines

Information Exchange Guidelines

ESB/Integration Guidelines

Pattern Usage Guidelines

Security Guidelines

Service Contract Guidelines

Service Development Guidelines

Service Interface Guidelines

Service Logging/Audit Guidelines

Service Modeling Guidelines

Service Policy Guidelines

Service Versioning Guidelines

Service Taxonomy Guidelines

Service Pattern Guidelines

Legacy Modernization Guidelines

 

PROCESS

Service Implementation, Assembly, or Acquisition

Goal

Service assembly allows developers to create new services that follow predefined rules and processes based upon defined architectural standards.

Input

Service model

Service policy

Activities

Implement the service using the implementation model

Output

Implemented service

Service implementation metrics

 

CHECKPOINT

Approve Service Implementation

Input

Implemented service

Service implementation metrics

Activities

Ensure compliance with guidelines

Output

Approval of service implementation

Approval of service implementation metrics

Used Guidelines

External Service Usage Guidelines

Information Exchange Guidelines

ESB/Integration Guidelines

Pattern Usage Guidelines

Security Guidelines

Service Contract Guidelines

Service Development Guidelines

Service Interface Guidelines

Service Interface Guidelines

Service Logging/Audit Guidelines

Service Policy Guidelines

Service Project Management Guidelines

Service Taxonomy Guidelines

Service Versioning Guidelines

Legacy Modernization Guidelines

 

PROCESS

Service Testing

Goal

Services must be tested at multiple levels to ensure they meet the stated functional and non-functional objectives according to the service contract criteria.

Input

Implemented service

Service description

Service processes

Service requirements

Activities

Development of service test plans including functional, performance, scalability, and security testing and fulfillment of guidelines

Execution of service test plans

Documentation of service test results

Output

Service test plans

Service test results

Service test metrics

 

CHECKPOINT

Approve Service Test

Input

Service test plans

Service test results

Service test metrics

Activities

Ensure compliance to guidelines

Ensure test metrics have been collected

Output

Approval of service testing

Used Guidelines

External Service Usage Guidelines

Information Exchange Guidelines

ESB/Integration Guidelines

Security Guidelines

Service Contract Guidelines

Service Development Guidelines

Service Interface Guidelines

Service Logging/Audit Guidelines

Service Policy Guidelines

Service Project Management Guidelines

Service Taxonomy Guidelines

Service Testing Guidelines

Service Versioning Guidelines

 

PROCESS

Service Deployment

Goal

The Service Deployment process manages the registration and configuration of services and release into production. Service release management is included in this process.

Input

Service description

The service itself

Service test results

Activities

Manage the deployment of the service to different staging environments (e.g., test, pre-production, production)

Register the service in the repository to ensure in can be discovered

Document specific deployment information

Certify deployed service

Define capacity and operational and virtualization plan based on load requirements

Ensure service approval from consumers

Output

Updated service description with deployment information

Updated service catalog

Report of certification for the deployed service:

  • Verification of test results for the final configuration and execution of tests that can only be done on final configuration due to variance from test configuration (such as confidentiality verification)

Report of capacity and operational and virtualization plan:

  • Document describing the IT environment configuration and virtualization techniques used (if any) to meet the service contracts
  • Should include a list of any shared infrastructure or other services used for service dependencies

Approvals/acceptance of the service from the service consumers (serves as approval of service contracts):

  • Should include monitoring/reporting requirements from each service consumer

 

CHECKPOINT

Approve Service Deployment

Input

Updated service description with deployment information

Updated service catalog

Activities

Ensure that the service is published

Ensure that service deployment information is maintained

Ensure that the service is deployed in a manner the fulfills the contracts and policies

Ensure that service monitoring and management have the correct information available

Ensure that the service follows the organization service naming taxonomy

Output

Approved service deployment

Used Guidelines

Service Deployment Guidelines

Service Publishing Guidelines

Service Taxonomy Guidelines

 

PROCESS

Service Management and Monitoring

Goal

This process is used to monitor workload and system events that could cause service outages/problems as well as security incidents.

Input

Service contract

Service deploy results

Service infrastructure

Service metrics

Service policy

Activities

Collect service metrics

Audit service

Manage service exceptions

Enforce service policy

Monitor service execution in relation to service contracts

Manage service problems

Manage rogue services

Output

Service audit reports

Service exceptions

Service performance feedback

Service performance reports

 

CHECKPOINT

Approval of Service Monitoring and Management

Input

Service audit reports

Service exceptions

Service performance feedback

Service performance reports

Activities

Ensure compliance to guidelines

Output

Approval of service monitoring and management

Used Guidelines

Security Guidelines

Service Contract Guidelines

Service Policy Guidelines

Service Logging/Audit Guidelines

Service Monitoring and Management Guidelines

 

PROCESS

Service Support

Goal

The service support process manages problems, incidents, and the interaction with service consumers.

Input

Service contract

Service infrastructure

Service policy

Service exception

Service description

Service requirement

Service consumers

Activities

Resolve service exceptions

Create service change proposals when needed

Manage interaction with service consumers

Output

Incident report

Problem report

Service consumer interaction report

 

CHECKPOINT

Approve Service Support

Input

Incident report

Problem report

Service consumer interaction report

Activities

Ensure compliance to guidelines

Output

Approval of service support

Used Guidelines

Service Retirement Guidelines

Service Change Management Guidelines

Service Support Guidelines

Service Policy Guidelines

Service Contract Guidelines

SOA Solution Portfolio Governance Activities

PROCESS

SOA Solution Portfolio Planning

Goal

Ensure that future business plans are appropriately supported by an up-to-date roadmap of planned development and integration activities.

Input

Business needs and related business cases from either enterprise architecture, business units, or other sources

Business objectives, strategies, principles, and budget constraints

Solution change proposals and their business cases

Activities

Using the current business objectives, strategies, principles, and budget constraints to:

  • Identify new initiatives defined since previous roadmap
  • Identify proposed solution changes
  • Create a prioritized list of solutions efforts planned for the upcoming two to three years, and map these to development projects
  • Analyze if SOA is the correct solution for proposed SOA projects

Output

Solution roadmap

 

CHECKPOINT

Approve SOA Solution

Input

Solution roadmap

Activities

Ensure that the solution roadmap has been created according to the guidelines

Ensure that SOA is the correct solution for the business needs

Output

Approval of SOA as a solution

Used Guidelines

Current IT Portfolio Management Process & Guidelines

SOA Initiative Guidelines

Solution Change Management Guidelines

 

PROCESS

SOA Solution Validity

Goal

Provide a mechanism to evaluate initiatives and/or projects with regard to the corporation’s desired degree of SOA focus based on overall SOA strategy and current maturity level. The Portfolio Management process may need to be updated to ensure the right mix of projects is selected that advance the ability of the business to be agile. This includes an assessment of services from a project to determine the value of those services beyond that of the project itself. SOA governance needs to ensure that the benefits of service re-use for a particular project are reflected in project selection and prioritization.

Input

Business case

Business, IT, & SOA principles

Solution requirements

Solution constraints

Solution process (the process performed by the solution)

SOA maturity

Activities

Analyze the validity of the SOA solution

Output

Solution roadmap

 

CHECKPOINT

Approve SOA Solution Validity

Input

Solution roadmap

Activities

Ensure that the analysis is compliant with the long-term goals of the organization

Output

Approval of SOA solution validity

Used Guidelines

SOA Solution Validity Guidelines

 

PROCESS

Solution Change Management

Goal

When an incident report is resolved by recommending a change to the solution, a record should be established which justifies the changes to the solution and the cost of revalidating and testing the solution conformance.

Input

Solution change proposal

Activities

Analyze the change request including the cost of redevelopment, revalidating the solution

Output

Updated solution roadmap with the approved solution change proposal

 

CHECKPOINT

Approve Solution Change Proposal

Input

Updated solution roadmap with the approved solution change proposal

Activities

Ensure compliance to guidelines

Output

Approval of change request

Used Guidelines

Solution Change Management Guidelines

Solution Lifecycle Governance Activities

PROCESS

Solution Definition

Goal

The process for creating a specification of the solution based on the business needs.

Important issues due to SOA are:

  • Define exact process steps and their relationships (used for the choreography and orchestration of the solution)
  • Define where agility and other SOA properties are needed in the solution

Input

Business needs

Business case

Activities

Define the business processes in scope

Define the information in scope

Define the business rules in scope

Define the IT functionality needed to support the business processes and information (including what should be automated and what should be manual)

Define agility levels for different parts of the solution

Define SOA prioritization for different parts of the solution

Output

Solution requirements including principles, processes, information, business rules, and IT functionality needs

SOA prioritization

SOA agility levels

 

CHECKPOINT

Approve Solution Requirements

Input

Solution requirements including principles, processes, information, business rules, and IT functionality needs

SOA prioritization

SOA agility levels

Activities

Ensure that the business processes, information, business rules, and automated functionality have been defined to appropriate level

Ensure that areas of importance for SOA have been defined

Output

Approval of solution requirements

Used Guidelines

Solution Requirement Guidelines

 

PROCESS

Solution Realization Planning

Goal

This process defines the key activities of the analysis to build the solution and the techniques required in design, assembly, testing, and deployment of the solution. Some of the variables may be predetermined by portfolio decisions and reference architectures.

Important changes due to SOA:

  • Define the relationship between the solution and service development (e.g., will the services be done in the same project or by different project groups)

Input

Business, IT, & SOA principles

Solution requirements

Activities

Plan how to develop the SOA solution

Output

Solution realization plan

 

CHECKPOINT

Approve Service Realization Plan

Input

Solution realization plan

Activities

Ensure compliance to guidelines

Output

Approval of service realization plan

Used Guidelines

BPM Guidelines

Portal Guidelines

Security Guidelines

Service Discovery Guidelines

Solution Development Guidelines

Solution Project Management Guidelines

 

PROCESS

Request a Dispensation

Goal

The process defined within the governance framework or contract to request a dispensation based upon a dispute of the compliance review results.

Input

Dispensation request

Disputed compliance review results

Activities

Analyze the impact of the dispute results

Determine if dispensation should be requested

Submit the dispensation request

Output

Dispensation request results

Service change proposal (possibly)

Service contract (possibly updated)

Service policy (possibly updated)

 

CHECKPOINT

Gain Dispensation Approval

Input

Dispensation request

Escalation contacts

Impact analysis of the disputed compliance results

Activities

Propose the dispensation plan for future compliance

Propose the plan for non-dispensation (for immediate corrective action/fix)

Obtain the dispensation approval or non-approval

Output

Dispensation request results

Trigger for vitality update (possible new condition or change in Dispensation Management Guidelines)

Used Guidelines

Service Contract Dispensation Management Guidelines

Service Contract Guidelines

Service Policy Guidelines

Security Guidelines

 

PROCESS

Solution Modeling

Goal

The detailed design and specification of the solution based upon design techniques, patterns, and standards.

Important changes due to SOA:

  • Modeling of processes should be done in a re-usable way.
  • Design techniques, standards, and patterns are often unique for SOA.

Input

Solution requirements

Solution realization plan

Activities

Model the business processes including business functionality

Model the user interfaces

Model the business rules

Identify service needs

Output

Service needs

Solution model

Solution modeling metrics

 

CHECKPOINT

Approve Service Model

Input

Service needs

Solution model

Solution modeling metrics

Activities

Ensure compliance to guidelines

Output

Approval of service model

Used Guidelines

BPM Guidelines

Portal Guidelines

Security Guidelines

Service Discovery Guidelines

Solution Modeling Guidelines

Business Rules Guidelines

 

PROCESS

Service Re-use Planning and Re-use Exceptions

Goal

The process of evaluating existing services identified from the service identification and services found in a more thorough service discovery process.

Input

SOA solution model

SOA solution requirements

Service characteristics

Activities

Identify services to be re-used

Identify existing services possible to re-use after some changes

Output

Service usage plan

Service change proposal

 

CHECKPOINT

Approve Service Usage Plan

Input

Service usage plan

Service change proposal

Activities

Ensure service re-use

Output

Approval of service usage plan

Used Guidelines

Security Guidelines

Service Change Management Guidelines

Service Portfolio Planning Guidelines

Service Policy Guidelines

 

PROCESS

Service Entitlement/Usage

Goal

The processes for requesting access to a service and determining who can use a service, how often they can use it, and what qualities of service can be expected by consumers of the service.

Input

Solution requirements

Service usage plan

Service characteristics

Service performance feedback

Service roadmap

Service funding model

Activities

Negotiate the contracts for the services used

Identify changes to existing services to fulfill business needs and define new contracts for them

Output

Service contract

Service policy

Service change proposal

 

CHECKPOINT

Approve Service Usage

Input

Service contract

Service policy

Service change proposal

Activities

Ensure contracts exist for all services

Ensure service change proposals are appropriate

Ensure compliance to guidelines

Output

Approval of service usage

Used Guidelines

Security Guidelines

Service Contract Guidelines

Service Policy Guidelines

Service Discovery Guidelines

Service Change Management Guidelines

Service Portfolio Planning Guidelines

 

PROCESS

Solution Assembly, Implementation, or Acquisition

Goal

Solution assembly allows developers to create new solutions that follow predefined rules and processes based upon defined architectural standards.

Important changes due to SOA:

  • New tools and techniques to implement and assemble SOA solutions
  • Acquisitions may require new tools and testing methods

Input

Solution model

Solution techniques (from reference architecture)

Solution architecture

Services from the Service Lifecycle

Activities

Implement workflows using BPM

Implement automatic workflows using orchestration

Implement user interfaces

Implement business rules

Output

SOA solution components and services

Solution implementation metrics

 

CHECKPOINT

Approve Solution Implementation

Input

SOA solution components and services

Solution implementation metrics

Activities

Ensure compliance to guidelines

Output

Approval of solution implementation

Used Guidelines

BPM Guidelines

Portal Guidelines

Security Guidelines

 

PROCESS

Solution Testing

Goal

The testing of the solution needs to include verification of solution adherence to service contracts.

Input

Solution requirements

Solution design

Solution

Solution test cases

Activities

Development of solution test plans including functional, performance, scalability, and security testing and fulfillment of guidelines

Plan for testing of SOA capabilities (agility)

Execution of solution test plans

Documentation of solution test results

Output

Solution test plan

Solution test results

Solution testing metrics

 

CHECKPOINT

Approve Solution Testing

Input

Solution test plan

Solution test results

Solution testing metrics

Activities

Ensure compliance to guidelines

Output

Approval of solution testing

Used Guidelines

Solution Testing Guidelines

Solution Development Guidelines

 

PROCESS

Solution Deployment

Goal

The Solution Deployment process manages the registration and configuration of the solution and release into production.

Important changes due to SOA are:

  • New and updated service contracts and service policies are deployed with the solution.
  • New ways of deploying processes are included in the solution.

Input

SOA solution components and services

Solution deployment architecture (staging environments)

Used services contracts and policies

New and updated services

Activities

Deploy solution into different staging environments (e.g., testing, pre-production, production)

Manage deployment information

Output

Deployed solution information

Version of solution in different staging environments

 

CHECKPOINT

Approve Solution Deployment

Input

Deployed solution information

Version of solution in different staging environments

Activities

Ensure that the solution is deployed correctly

Ensure that the tracking of the solution in the staging environments is up-to-date

Ensure that necessary production environment testing has been performed

Output

Approval of the solution deployment

Used Guidelines

Solution Deployment Guidelines

BPM Guidelines (deployment)

Portal Guidelines (deployment)

ESB Guidelines (deployment)

Service Guidelines (deployment)

Security Guidelines (deployment)

 

PROCESS

Solution Management and Monitoring

Goal

This process is used to monitor workload and system events that could cause solution outages/problems as well as security incidents.

Input

Service policy

Service contract

Solution deployment results

Solution requirements (non-functional metrics)

Activities

Monitor solution adherence to solution Quality of Service (QoS) attributes

Manage solution execution to ensure correct capacity

Create solution audit reports

Create solution performance reports

Output

Solution performance report

Solution audit reports

Solution exceptions

 

CHECKPOINT

Approve Solution Monitoring and Management

Input

Solution performance report

Solution audit reports

Solution exceptions

Activities

Ensure compliance to guidelines

Output

Approval of solution monitoring and management

Used Guidelines

BPM Guidelines (management & monitoring section)

Portal Guidelines (management & monitoring section)

Service Contract Guidelines

Service Policy Guidelines

Solution Support and Management Guidelines

 

PROCESS

Solution Support

Goal

The Solution Support process manages problems, incidents, and the interaction with solution users.

Input

Solution exception

Service contract

Service policy

Service performance reports

Activities

Resolve solution exceptions

Create solution change proposals when needed

Manage interaction with solution users

Output

Solution change proposals

Solution incident reports

Solution problem reports

Solution user interaction report

 

CHECKPOINT

Approve Solution Support

Input

Solution change proposals

Solution incident reports

Solution problem reports

Solution user interaction report

Activities

Ensure compliance to guidelines

Output

Approval of solution support

Used Guidelines

Service Contract Guidelines

Service Policy Guidelines

Solution Change Management Guidelines

 

 

 

 

The Open Group
Platinum Members
HP IBM Oracle Philips