Today's post presents a Governance Case Study; in this case the introduction of SOA Governance within an enterprise environment.
 |
| The larger context for SOA Governance |
Process Context
The process depicted in the figure above represents one of
several related processes. We've referred to this
process as the SOA Service Approval and Governance process. This is used to help document to provide oversight
for SOA service development and management. The other processes that this will become integrated to will
include a modified project and portfolio management process, an engineering
design process and an application lifecycle management process. Each of those
processes will have hooks into and out of the governance process. Both the governance
and design-related processes will definitely involve collaborative small group
involvement (and that involvement will include collaboration between both
technical and business representatives). The eventual goal would be to further
integrate the related processes and to provide automation for all of them.
Process Overview
The SOA Approval and Governance Process is at its
heart both a requirements management process as well as a configuration control
process. We've also included some elements of design review within the process
in order to provide the most flexible approach and least
number of processes possible. The primary objective of this process is to help
provide a documentation baseline of all potential service opportunities within
the enterprise. The primary role within the process is that of
the SARB - this could be translated to either Services Architecture Review
Board or Software Architecture Review Board. At first the focus will primarily
be directed to SOA services but eventually the board can extend governance
across all business logic . The other roles presented in
this process include:
- Stakeholder - stakeholders represent business analysts, management and possibly even customers.
- Developer - developer represents any technical resource that would be involved in either constructing a service or utilizing a service as a system-level consumer. Developers and stakeholders are the primary participants in both design process activities as well as design review activities within the governance process.
- CM - CM stands for configuration management and in this context would represent one person designated as the point of contact and responsible for documenting specific configuration information within the SOA Center of Excellence (COE) wiki.
- Manager - this is self-explanatory and of course the management role is responsible for integration of governance with project portfolio management.
Prerequisites
There are several prerequisites for the governance process;
these include a Center
of Excellence
Goals
There are several critical goals associated with this
process:
- Standardization of requirements capture, documentation and management.
- Standardization of SOA services design through enforcement and oversight.
- The ability to reconcile requirements and designs across the retail enterprise.
Service Level Versus Enterprise
One of the key concepts associated with this particular
process is the separation of design and design review as well as the separation
of discrete design from enterprise design. All these considerations are managed
through the first and second level analyses within the process. In other words,
we are viewing the SOA designs at two different stages in the governance
process – stage I allows us to ensure that the granular service is constructed
according to agreed upon standards. Stage II allows us to ensure that services
fit within the enterprise in the most efficient way possible.
part 2 of the post will examine the process steps...
Copyright 2012 - Technovation Talks, Semantech Inc
0 comments:
Post a Comment