Asset development and lifecycle in Rational Asset Manager

As an asset develops, it moves from planning to production to managed change. These stages are predefined by repository and community administrators to manage the requirements and standards every asset must meet.

To learn about developing assets by using lifecycles, see these sections:

Lifecycle phases and iterations
What you can do with asset lifecycles
When to use asset lifecycles
Additional roles for asset lifecycles
Lifecycle modification
Implicit asset lifecycles
Retirement lifecycles
Lifecycles and pre-V7.2 review processes
Example: Standard lifecycle workflow
Example: Asset development and lifecycle

Lifecycle phases and iterations

The development cycle includes phases and iterations. Across the phases and iterations, you can create and reuse development artifacts. Relationships can exist between development artifacts. You can also reference and use development artifacts that were created in other development cycles. These development artifacts might be on websites or in custom repositories.

Assets can contain development artifact files or references to them. For example, a remote artifact might be uploaded into the asset repository as an asset artifact. Alternatively, the asset artifact might be a reference to the remote artifact in the repository where it is stored. The appropriate set of artifacts and relationships are displayed in the asset repository. Teams can access the repository to govern, search for, and view usage scenarios about the assets.

What you can do with asset lifecycles

Custom lifecycles are flexible and can be used for several purposes:

Provide a workflow for assets to develop over time: All lifecycles use a workflow. Repository administrators define the workflow when a master lifecycle is created. A workflow consists of states and the transitions between states. For example, the Standard workflow has three states. Assets enter the Draft state and can then be moved to a Review state. After the asset is reviewed and approved, it can move to the Approved state. For each state, you can modify who can view, review, or vote on the asset, and you can configure policies to run.
You can use the workflows that are included in the product, or you can create additional workflows for the repository.
Specify which assets can enter a lifecycle: You can configure conditions to specify that assets of a particular asset type or categorization must enter a specific master or community lifecycle. For example, you can specify that assets of the Documentation type must enter one master lifecycle, and that assets of the Documentation type that are also categorized as a Presentation must enter a different master lifecycle. In a community-level lifecycle that uses the Presentation master lifecycle, you can add a condition that assets that are categorized as Slides must use this lifecycle.
Assign users to guide assets through lifecycles: For each lifecycle at the repository, community, and asset levels, you can assign a user to be a lifecycle manager. A lifecycle manager guides an asset through its lifecycle by adjusting the lifecycle and managing the reviewers of the asset. For more information about lifecycle managers, see Additional roles for lifecycles for assets. For more information about how to adjust the lifecycle for a single asset, see Modifying the lifecycles for individual assets.
Assign users to comment on, modify, or approve assets: For every state in the workflow of a lifecycle, you can assign subject matter experts or other interested parties to be reviewers. Reviewers can view, comment on, and, optionally, modify or vote on assets. For more information about reviewers, see Additional roles for lifecycles for assets.
Configure policies that test or modify assets: In every state of the asset, you can configure policies. Policies are scripts or macros that can test or modify an asset. For example, you might test an asset to ensure that it has a unique name. You can control when and how frequently a policy runs. You can use policies to enforce restrictions and programmatically govern assets. For more information about which policies are available and how to configure them, see Policies for lifecycles in Rational Asset Manager.
Configure requirements for assets to move between states: For every transition, you must configure exit conditions that must be met for the asset to move between states. For example, for an asset to move from the Review state to the Approved state, you might require that at least three reviewers approved the asset and that it has passed all of the test policies.

When to use asset lifecycles

Asset lifecycles are useful in these situations:

When an asset might benefit from a required workflow: Assets that might benefit from a required lifecycle workflow include business case documents, test plans, software components and services, product builds and baselines, and corporate branding components, such as logos, style sheets, and templates.
When you want to review assets: Lifecycle managers can invite reviewers to view, modify, or vote for assets in any state.
When you want to use policies for lifecycles: You can use policies for lifecycles to efficiently manage assets in your community. Policies for lifecycles are like many of the constraints that you can configure with asset types.
When you are using a service-oriented architecture (SOA) process: Rational® Asset Manager includes a package of lifecycles that support an SOA process. You can use the lifecycles to integrate that process with IBM® WebSphere® Service Registry and Repository.

Additional roles for asset lifecycles

When you create custom lifecycles, additional roles are configured:

Lifecycle manager: You can assign the lifecycle manager role to users or user groups while you configure custom lifecycles for a community. If you are a lifecycle manager for an asset, you gain the following additional permissions:
- You can search for, view, and download the asset.
- You can modify the asset.
- You can view the asset on the My Dashboard page in the Assets to Manage section.
- You can leave a comment on the Review page of the asset.
- You can adjust the lifecycle for the asset by adding or removing reviewers, changing the permissions for reviewers, adding or removing policies, and changing the conditions for the transitions between lifecycle states.
Reviewer: For each state of a custom asset lifecycle, you can add users or user groups as reviewers. Community administrators can add and remove reviewers as they configure custom lifecycles for a community. Lifecycle administrators can add and remove reviewers as they modify the lifecycle for individual assets. If you are a reviewer for an asset, you gain the following additional permissions:
- You can search for, view, and download the asset.
- You can leave a comment on the Review page of the asset.
- If the Approver check box is selected, you can vote to approve or reject the asset on the Review page. Approvals and rejections are saved and can be used as conditions for changing states. For example, the asset can change from Review to Approved only if at least three reviewers have voted for Approve.

Lifecycle modification

At the asset level, requirements for master and community lifecycles are inherited by the asset lifecycle. Lifecycle managers can add requirements for the asset to supplement those requirements specified by repository and community administrators.

This tree diagram shows how master lifecycle requirements are inherited by community lifecycles. Then, community administrators can add requirements to the community lifecycle. Master and community lifecycle requirements are inherited by asset lifecycles. Then, the lifecycle manager can add requirements to the asset lifecycle.

For example, a lifecycle manager might decide to invite additional reviewers for a specific asset. They might also adjust how a policy is configured, in order to better match the requirements of a particular asset.

Any changes that you make to the lifecycle configuration of an asset apply to only that asset. Your changes do not apply to other assets in the community that are using the same master or community lifecycle. If you often make the same adjustments to assets, you might ask a community administrator to adjust the lifecycle at the community level.

Lifecycle managers can adjust the lifecycles for an individual asset in the following ways:

Add or remove lifecycle managers for the asset
Add or remove reviewers for each state
Change the permissions for reviewers for each state
Add or remove policies for each state
Reconfigure policies for each state
Reconfigure the transitions between states

At the individual asset level, you cannot change the following aspects of the lifecycle:

The workflow for the lifecycle
The conditions for the asset to enter the lifecycle

Implicit asset lifecycles

If an asset that is submitted to a community does not meet the requirements of a lifecycle or other custom review process, the asset enters a simple lifecycle that has two states: Submitted and Approved. The owner of the asset and any administrators are the lifecycle managers for the asset.

You can modify the lifecycle of an asset that enters the implicit lifecycle, but you cannot modify this lifecycle for all assets in a community.

Retirement lifecycles

For all assets that are in lifecycles, including the implicit lifecycle, you can send an asset to a separate retirement lifecycle, the Implicit Retire Asset Lifecycle, which consists of two states:

Pre-Retired: The Pre-Retired state copies the permissions, lifecycle managers, and reviewers from the state of the lifecycle that the asset was in before it entered the Pre-Retired state. All owners, lifecycle managers, reviewers, owners of related assets, and anyone that has downloaded the asset will receive an email that the asset has entered the Pre-Retired state.
Retired: When an asset is in the Retired state, only administrators and lifecycle managers can find or download the asset.

You can send an asset to the retirement lifecycle from any lifecycle state. While an asset is in the retirement lifecycle, its lifecycle managers can modify the retirement lifecycle for that asset. In either state of this lifecycle, you can restore the asset. When you restore the asset, it is resubmitted to the community. It enters the first state of the appropriate lifecycle based on the asset type or categories of the asset.

Lifecycles and pre-V7.2 review processes

In versions of the product earlier than 7.2, you can manage the development of assets over time by using review processes. In version 7.2 or later, you can use lifecycles to develop assets over time.

Although you can still access existing review processes, you cannot create new ones. Use lifecycles instead, which are more customizable and flexible. The following table shows how lifecycles differ from review processes.

Table 1. How lifecycles in V7.2 or later differ from review processes in V7.1.1.1 or earlier
Functionality	Review processes (V7.1.1.1 or earlier)	Lifecycles (V7.2 or later)
Number of states and transitions	One workflow is included.	You can choose from various built-in workflows that have different numbers of states and transitions. Alternatively, you can use IBM Rational Team Concert™ to make more states and transitions.
Flexibility of states	Each state has an associated limitation on permissions that you cannot modify. For example, only the owners of the asset and administrators can view the asset in Draft state.	For every state, you can customize permissions, reviewers, and policies.
Transitions	Users must manually request that an asset changes states.	You can create complex conditions that control when an asset can move from one state to another. Transitions can also happen automatically if the asset meets conditions that you specify.
Who guides assets through the lifecycle	When you create a review process, you create a review board, or a list of users that have final approval over the review of the asset. You can modify the permissions of the review board by modifying the built-in Review Board role for your community.	When you create a lifecycle, you assign lifecycle managers who can adjust the lifecycle for individual assets and invite more reviewers. Lifecycle managers have a pre-defined set of permissions that you cannot modify.
Who reviews assets	In the Review state, reviewers can view and vote on assets and can access the forums for an asset. You can select reviewers when you configure the review process. The review board for an asset can select reviewers while the asset is in the Plan Review state.	For any state in a lifecycle, you can add reviewers who can view and comment on assets, and optionally modify and vote on assets.
How policies work	Policy processes must be configured separately from review processes. Generally, you configure a policy to run just before an action on the asset is attempted. When a policy fails, you cannot take that action. For example, a policy can run before an asset is approved, submitted for review, deleted, retired, or archived.	Policies are a major component of lifecycles. You can configure policies to run in any state at various times. For example, a policy might run every time an asset is modified while it is in a specific state. Or, a policy might run at a specified time after the asset enters a certain state. You can use the results of policies to control when assets can change from one state to another.
Limiting access to outdated or out-of-use assets	The Retire and Archived states are accessible only from assets in the Approved and As-is states.	Assets in any state of any lifecycle can enter a retirement lifecycle at any time.

When an asset can enter either a lifecycle or a review process

An asset can be governed only by a single lifecycle or review process. When you submit an asset to a community, the asset enters a lifecycle or workflow in this order:

First, the asset is checked to determine if it can be part of any master lifecycles in the repository.
Then, the asset is checked to determine if it can be part of any community lifecycles.
If no lifecycles apply to the asset, it is checked to determine if it can be part of any review processes that are created in the repository or community.
If no review processes apply, the asset enters a simple, implicit lifecycle process.

Example: Standard lifecycle workflow

The following figure shows an example of a workflow for an asset lifecycle. A workflow contains the states and actions for an asset type and can be configured as part of an asset lifecycle for governance. You can apply policies to specific actions in the workflow and specify who is authorized to complete each action or can be part of a review process.

The image shows the Standard workflow type.

Example: Asset development and lifecycle

Asset development is cyclic: as part of an asset workflow, an asset can move through states in its lifecycle. For a given asset type, you set up a governance model to control the users and groups that can submit, review, approve or reject, and publish assets. As people change an asset and make iterations, the development cycle moves through these stages:

Someone identifies gaps or problems in a current solution.
An architect or project lead searches the assets in the Rational Asset Manager repository to find a solution to the problem. If a solution or part of a solution is available, it is included in the architecture for the new proposed solution.
An architect or project lead creates the formal requirements for the solution. The formal requirements might include assets that were found during the search, or the previous defects, requests for enhancements, or task lists from past projects.
An architect creates the specification for the asset.
An architect submits the specification to an asset governance board. All of the major stakeholders for the solution complete a formal review. In this review, stakeholders ensure that the solution design is complete and that it addresses the gaps or problems in the previous solution.
A development team develops the solution and submits that solution as an asset. In the review of the developed solution, the reviewers ensure that the submitted asset is a complete solution or implementation and that it solves the gaps or problems in the previous solution.
If the developed asset is approved, the asset for the solution moves to the next state in the lifecycle workflow. In that state, a governance board reviews the asset and votes to decide whether to make the asset available. All of the major stakeholders might be required to review the asset and vote.
If the review board votes to accept the asset, it is published so that other people in the company can use and deploy the asset.

Asset development and lifecycles