Lifecycle management is of importance to every enterprise that wants to implement a process-driven SOA with emphasis on adaptability, service reuse, and improvement. The lifecycle management (LCM) system for CentraSite helps to:

A lifecycle model describes the distinct steps through which a particular type of SOA asset passes from conception to retirement. In other words, a lifecycle model enables you to classify assets according to the state they have reached in their lifecycle. It also provides the basis for CentraSite's lifecycle governance capabilities. Using these capabilities, you can steer assets through the different steps of their lifecycle and apply governance controls at significant stages of the lifecycle process.

A lifecycle model is composed of states and transitions.

A state represents a distinct step through which an asset passes on its way from conception to retirement. A very simple lifecycle model for an asset might include states such as Design, Development, Test, Operational, and Retired. It might also include the Canceled state for assets whose lifecycle is terminated prior to completion.

A transition represents the act of switching an asset from one state to another. When you define a lifecycle model, you specify both the states that make up the lifecycle and the transitions that can occur from each state. For example, the Test state might have possible transitions to the Operational, Development, and Canceled states. If these are the only three transitions that you define for the Test state, then these are the only states to which CentraSite allows an asset in the Test state to be switched.

When you apply a lifecycle model to an asset type, the lifecycle model itself is treated as a taxonomy by many of CentraSite's browse and search tools. For example, using the catalog browser in CentraSite Control, you can view the contents of your catalog according to a specified lifecycle model. This view enables you to quickly ascertain which assets are in a particular phase of their development lifecycle.

CentraSite's search tools and reporting features also allow you to query assets by lifecycle state. You can use the advanced search feature, for example, to filter assets by their lifecycle state. You can also use CentraSite's reporting facility to examine the lifecycle status of the assets in your catalog.

Lifecycle models enable you to govern your assets more effectively by allowing you to enforce governance controls at various points in an asset's lifecycle.

When you associate a lifecycle model with an asset type, you make it possible to impose design/change-time policies at each step of the asset's lifecycle. These policies enable you to control the transition of an asset from one step of its lifecycle to another by triggering review and approval processes, issuing email notifications, updating permission settings and generally verifying that an asset meets the requirements necessary to enter the next step in its lifecycle.

System-wide models, also called global models, apply to objects that can be owned by any organization. Global lifecycle models do not belong to any organization, but apply to all organizations. Global lifecycle models may have organization-specific policies attached to them.

System-wide models have precedence over organization-specific models, when a system-wide model for an object type (set of types) exists, it takes priority over all other models. However, if an organization-specific model already exists and a system-wide model is added, then the organization-specific model still exists and the objects that are in this model completes their lifecycle without effects. Only new objects is assigned to the new system-wide model.

Organization-specific models, also called organizational models, apply only to objects that are owned by a specific organization. Each organizational lifecycle model belongs to an organization. Organizational lifecycle models are technically hierarchical, as organizations may contain sub-organizations.

For a given object type (say Service), each organization can define and activate its own lifecycle model, so that there are several models that can control the Service type. However, per organization only one lifecycle model can be active. When a new Service instance is created, then the user creating the instance belongs to an organization and that organization's active lifecycle model is used to control the particular Service instance.

It is possible to define a lifecycle model which consists of multiple nodes (registries) to make up one overall model. Each node only knows the model for the current node. It also knows the nodes that make up the complete lifecycle model and where they are.

Sometimes an asset's overall lifecycle is split across two or more registries. The most common example of this occurs when assets that are in the development and test phases of their lifecycle are maintained in one registry (the creation CentraSite) and assets that are deployed (that is, in production) are maintained in a separate registry (the consumption CentraSite).

When a site splits an asset's lifecycle across multiple registries, each participating registry is referred to as a stage. Each stage knows about the other participating stages, but does not know the details of the lifecycle that takes place in those stages (that is, the registries that participate in the overall lifecycle are not aware of the specific states and transitions that occur in the other registries).

To model a lifecycle that extends across multiple registries, you must create a separate lifecycle model on each participating registry. Each model describes just the segment of the lifecycle that occurs within its own registry. For example, in the multi-stage lifecycle depicted above, the lifecycle model on the creation registry would consist of the Requested, Declined, Approve, Development, Revising, QA, and Promoted states. The lifecycle model on the consumption registry would consist of the Pre-Production, In Production, Deprecated, and Retired states.

To indicate that a lifecycle ends on one registry and continues on another, the state that represents the end of an asset's lifecycle on a particular registry includes a pointer to the registry that hosts the next stage of the lifecycle.

When an asset reaches the end of its lifecycle on one registry, you promote the asset to the next stage of its lifecycle by exporting the asset from the current registry and importing it to the next.

When you import the asset into the registry that hosts the next stage of its lifecycle, CentraSite verifies that the asset is being imported into the correct stage. It does this by checking the address specified in the stage parameter that is included in the archive file with the exported asset. If the address identified in the stage parameter in the archive file matches the registry's own address, CentraSite allows the asset to be imported.

The registry stages are broken down into states for lifecycle-enabled objects like services. This way the lifecycle process can be split into smaller steps, each supported and controlled by its responsible stage registry. States are connected to each other by allowable transitions. An approval process can define the conditions and activities to set a service from one state to another. CentraSite comes with the following:

By using stages and states, you ensure that the registry object always has one defined state, even if multiple registries exist. State transitions are restricted, this ensures that the registry object had passed the lifecycle process correctly and achieved the required quality.

When moving from one state to the next, the following situations can exist: