CentraSite User's Guide : Lifecycle Management : Customizing Lifecycle Models
Customizing Lifecycle Models
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 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.
When a lifecycle model is stored in CentraSite, it must be a valid state machine. This specifically means that all of the following semantic rules must be checked by CentraSite:
*There is an initial state. All objects under the control of the lifecycle model are initially in this state.
*Each state must be reachable from at least one other state.
*A default next state can be defined for each state.
*There must be at least one end state. An end state is one that it does not have any next state.
*There may be a preferred transition from one state to the next (for the UIs to use).
Lifecycle models can be applied to:
*Assets
*Policies
*Lifecycle models
CentraSite does not require you to apply lifecycle models to the assets in your registry. You can create and maintain an asset catalog without them. However, most of CentraSite's policy-based governance controls (for example, enforcing approval processes, validating attribute settings) can only be applied to assets that have an associated lifecycle model. The use of lifecycle models also makes it easier to manage the assignment of permissions (for example, granting View permissions to additional organizations) as an asset moves through its lifecycle.
If you want to use design/change-time policies to impose governance controls on a particular type of asset or you want to automate routine management tasks at certain points in the asset's lifecycle (such as setting permission assignments), associate a lifecycle model with the asset type.
Note:  
For your convenience, CentraSite provides predefined lifecycle models for several types of assets. You can use these lifecycle models as-is or customize them to suit your needs.
Applying Lifecycle Models to Asset Types
When you define a lifecycle model, you specify the asset types to which the model applies. Because different types of assets usually have different development paths, you generally create models that are specific to a single asset type (that is, one model for Service assets, one model for XML Schema assets, one model for Business Processes, and so on). However, if multiple asset types have the same lifecycle path, you can apply the same lifecycle model to them all.
You can model different lifecycle models for different assets types
When you apply the same lifecycle model to multiple asset types, you do not necessarily have to apply the same state-change policies to those types. You can trigger different policies depending on the type of asset whose state is changed. If you were using the lifecycle model for XML Schema and DTDs shown in the figure above, you might create one policy that executes when an XML Schema switches to the Available state and another policy that executes when a DTD switches to the Available state.
If an active lifecycle model is already associated with a particular type within an organization, you cannot assign another lifecycle model to that type. In other words, a particular object type can be associated with one and only one lifecycle model within a particular organization. If you want to switch an object type to a different lifecycle model, you must disassociate it with the current model and then assign it to the new model.
Applying Lifecycle Models to Asset Types
You can associate a lifecycle model with virtual asset type. When you apply lifecycle model to a virtual asset type, you do not necessarily have to apply the same lifecycle model as its base type. You can create a lifecycle model specific to the virtual asset type.
You can configure a virtual type to follow the same lifecycle model as its base type or you can give the virtual type its own lifecycle model to follow. Whether a virtual type follows the lifecycle model of its base type is determined by the type's Inherit Base Type LCM setting.
When the Inherit Base Type LCM option is selected for a virtual type, the virtual type automatically inherits its lifecycle model from the base type if the virtual type does not have an assigned lifecycle model of its own. (In other words, the lifecycle model for the base type serves as the default lifecycle model for the virtual type. CentraSite applies the lifecycle model of the base type to the virtual type only when the virtual type has no other lifecycle model assigned to it.)
If the Inherit Base Type LCM option is disabled, the lifecycle of the virtual type is completely independent of the lifecycle of the base type. The virtual type will only have lifecycle model if you explicitly assign one to it.
The following table summarizes how lifecycle model is applied to a virtual type depending on the state of the Inherit Base Type LCM option.
If the Inherit Base Type LCM option is...
And the Base Type...
And the Virtual Type...
Instances of the Virtual Type...
ENABLED
HAS an assigned lifecycle model
DOES NOT HAVE an assigned lifecycle model
Follows the lifecycle model assigned to the Base Type
ENABLED
HAS an assigned lifecycle model
HAS an assigned lifecycle model
Follows the lifecycle model assigned to the Virtual Type
ENABLED
DOES NOT HAVE an assigned lifecycle model
DOES NOT HAVE an assigned lifecycle model
does not have an assigned lifecycle model
ENABLED
DOES NOT HAVE an assigned lifecycle model
HAS an assigned lifecycle model
Follows the lifecycle model assigned to the Virtual Type
DISABLED
HAS an assigned lifecycle model
DOES NOT HAVE an assigned lifecycle model
does not have an assigned lifecycle model
DISABLED
HAS an assigned lifecycle model
HAS an assigned lifecycle model
Follows the lifecycle model assigned to the Virtual Type
DISABLED
DOES NOT HAVE an assigned lifecycle model
DOES NOT HAVE an assigned lifecycle model
does not have an assigned lifecycle model
DISABLED
DOES NOT HAVE an assigned lifecycle model
HAS an assigned lifecycle model
Follows the lifecycle model assigned to the Virtual Type
Note:  
If a virtual type initially inherits its lifecycle model from the base type and later it is assigned its own lifecycle model, instances of the virtual type that were created while the type was following the lifecycle model of the base type continues following that model. Only instances of the virtual type that are created after the new lifecycle model is assigned to the virtual type complies with the virtual type's newly assigned lifecycle model.
Assigning Permissions to Lifecycle Model States
Each state that you define in a lifecycle model includes a set of optional state permissions. State permissions enable you to restrict who can transition assets to a specified state. You can assign state permissions to individual users or to groups.
If you do not explicitly assign permissions to a state, any user with Modify permission on an object can switch the object to that state.
You can optionally assign permissions to the states in a lifecycle
When you assign permissions to a state, two sets of users are allowed to switch an asset to that state: the set of users to which you explicitly grant state permission and users who have implicit permission to switch lifecycle states. The set of users who have implicit permission to switch lifecycle states are:
*Users with Manage System-Wide Lifecycle Models permission (on objects managed by a system-wide lifecycle model).
*Users with Manage Lifecycle Models permission (on objects managed by an organization-specific lifecycle model).
*The owner of the Lifecycle Model.
Note that the group of users with implicit permission to switch states does not include the owner of the asset itself. If you want to give asset owners the ability to switch their assets to a particular state, you must explicitly include them using the state permission settings.
Also note that granting state permission to a user does not, in itself, give the user the ability to switch an asset to that state. The user must also have Modify permission on the asset itself. For example, let's say you give the Users group for organization ABC permission to switch assets to the Development state. Doing this does not mean that any user in organization ABC can switch the assets in organization ABC to the Development state. It means that any user in organization ABC with Modify permission on an asset can switch that asset to the Development state.
Note:  
CentraSite does not allow you to modify a lifecycle model, including its state permissions, after you activate the model. If you assign state permissions to a lifecycle model, consider assigning the permissions to groups instead of individual users. Doing this enables you to make simple adjustments to the permission settings by simply modifying the membership of the assigned groups. You does not have to deactivate the model to make these kinds of changes.
Triggering Policies during Lifecycle Model Transitions
You can configure design/change-time policies to execute during the transition points in an asset's lifecycle. For example, you might apply a policy that gives View permission to a specified group of users when an asset enters the Operational state, or you might apply a policy that obtains approvals from a review group before an asset enters the Development state.
CentraSite triggers polices when specified state transitions occur
When you create a policy that executes on a state change event, you specify whether the policy should execute immediately before CentraSite actually modifies the asset's state (which is called a PreStateChange event) or immediately after CentraSite modifies the asset's state (a PostStateChange event).
Generally, you execute policies that perform approval and validation actions on the PreStateChange event. In other words, you use PreStateChange policies to ensure that an asset satisfies the entry criteria for a given state.
On a PostStateChange event, you typically execute policies that update the asset (for example, granting instance-level permissions to the users who need to work with the asset in the next phase of its lifecycle) or issue notifications (for example, sending an email). In short, you use PostStateChange policies to execute actions that are to be carried out only if the asset's state is switched successfully.
There are, exceptions to the generalizations above. Under some circumstances you might want to set an asset's instance-level permissions or update its attributes in a PreStateChange policy. That is you want to perform approval and validation actions in a PreStateChange policy, and issue notifications and perform state-certain actions (that is, actions that should occur only after an object's state has been successfully switched) in a PostStateChange policy.
Copyright © 2015- 2017 Software AG, Darmstadt, Germany. (Innovation Release)

Product LogoContact Support   |   Community   |   Feedback