SOA Governance Framework – 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

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

⇒ SOA Governance Process Information Entities

SOA Work Group

SOA Standards Discussion Forum

SOA Work Group Members Page