Model and assemble phases of the SOA lifecycle
You use the model and assemble phases of the SOA lifecycle to govern a capability version, process version, or service version, from being initially identified, through to its specification being proposed for review, through to it being realized.
The following table describes the states of the model
and assemble phases of the SOA lifecycle, and, for each state, names
the transition that moves an object forward to that state.
| Transition | State (and state ID) | Description |
|---|---|---|
| (Initial state) | Draft (Identified) | A new version of a capability has been requested or identified. The stakeholders identify the requirements for this version of the capability. |
| Send for Specification Review | Awaiting Specification Review (SpecificationReview) | The specification review must ensure that the specifications that are provided for this version of the capability will meet the stakeholder requirements. Any use of this version by other consumers, as defined by the service level definitions, will be based entirely on the specification, and costed accordingly. Any dependencies on other capability versions must be specified and agreed through a service level agreement and document of understanding (DOU). Any disagreement about functional specifications might require the specification to be revised and proposed again. Approval of the version specification determines a contract that allows both potential consumers and providers to proceed independently. |
| Send for Specification Revision | Draft (Identified) | Issues are found during the specification review which require rework, so the capability version is moved back to the Draft state, ready for a re-proposal into specification review. |
| Approve Specification | Specified (Specified) | In this state, the majority of the development or assembly of this version of the capability occurs. The details of activities undertaken during this state will be very specific to the development processes being used within the organization. The key exit criteria is when development (and development test) is complete, and a release is ready to be reviewed before being sent to operations for integration testing, configuration, and staging. On completion of the development, the version implementation is proposed for an implementation review. |
| Send for Implementation Review | Implementation Review (RealizationReview) | In this state, stakeholders agree that sufficient testing of the developed implementation has taken place, and the quality of the version is such that it can be sent to operations for deployment and configuration into the staging environments. |
| Send for Implementation Revision | Specified (Specified) | Issues are found during the implementation review which require rework, so the capability version is moved back to the specified state, ready for a re-proposal into implementation review. |
| Approve Implementation | Implemented (Realized) | The version is installed onto staging (integration, test, pre-production) environments and configured to operate with other deployed applications, processes and services. Testing is undertaken of the service level definitions that the capability offers, and if all service level definitions can be met, then the version is proposed as ready for staging. |
Diagram of the model and assemble phases of the SOA lifecycle
Note: In the lifecycle diagram, any transitions
that are highlighted in red represent a promotion step in the sample
promotion file.