Page title:Why use lifecycles to govern assets with Rational Asset Manager?
Closed Captioning text:With Rational Asset Manager, you can create a lifecycle, which is a planned but customizable workflow to control and govern assets. In Rational Asset Manager, the simplest lifecycle (shown here) has two exclusive states for assets to be in: an initial state for when a new asset has been submitted to a repository, and an APPROVED state for when the asset has been, well, approved. The arrows represent TRANSITIONS between those states. Lifecycles can have many more states and transitions, which means you can govern and manage assets with more detail and complexity, depending on your needs.
Lifecycles are useful in the following circumstances:
HOW TO MAKE LIFECYCLES
Now, I'm going to show you how to create lifecycles in Rational Asset Manager. I'll start by customizing a master lifecycle for assets of the RELEASE asset type. I'm going to use the master lifecycle to enforce a few requirements at the repository level.
First, by the time a Release asset is in the REALIZED state, it has a relationship to a different asset that is of the IMPLEMENTATION type. Also, at the STAGED state, I want to always have one of our company's lawyers review and approve the asset. Finally, to make the lawyer's job a little easier, I want to automatically add a legal NOTICES file to the asset when it reaches the STAGED state.
Let's get started.
Repository administrators create the master lifecycles, and then community administrators can extend the master lifecycle to apply further requirements for their specific communities.
Our goal here is to create a lifecycle specifically for assets of the RELEASE type. Rational Asset Manager comes with several built-in workflows, with varying numbers of states and branches, including one specifically for release assets. Your repository administrator can make more, or edit the built-in ones to better match your group's needs.
On this initial page, you see the picture of the workflow again, and you can begin to configure the master lifecycle.
First, enter the NAME and a DESCRIPTION of the lifecycle. You can use these to describe and clarify the purpose of this lifecycle to others.
Next, the CONDITIONS section is very important. Here, you define which assets of certain TYPES or CATEGORIES enter the lifecycle that you are configuring.
Here, select asset type.
You use basic IS or IS NOT logic, so I'm selecting IS and I'm selecting the RELEASE asset type.
If you need to create more specific conditions, you can add additional ones by selecting AND or OR here and clicking the plus sign.
You can create very complex, nested conditions, but I don't need to get that specific here. I want to create something that can be used across multiple communities.
Next, add LIFECYCLE MANAGERS for this lifecycle. LIFECYCLE MANAGERS can invite other users to collaborate on assets that are using this lifecycle, and they can modify the lifecyle to fit the needs of an individual asset. You can add either individual users or user groups.
Here, I've added Pete, a project manager, as a lifecycle manager. For any assets that use this lifecycle, Pete is able to tweak the lifecycle and invite reviewers.
I'm leaving this checkbox selected; it automatically assigns any owners of an asset to be lifecycle managers. If that's something you want to avoid, for example if you intend to keep the original submitter of the asset out of its review and certification process, you can clear it.
Now, to configure a state. You can use the CURRENTLY CONFIGURING dropdown list to select a state or transition, or just click the box in the diagram.
When an asset in this lifecycle gets to the REALIZED state, I want the asset to have a relationship to one or more assets of the IMPLEMENTATION type, which are assets that have the actual application files for the release.
I can use a POLICY to enforce that. POLICIES let you apply a variety of restrictions or rules to an asset during specific states of a lifecycle.
Rational Asset Manager includes about a dozen standard policies. You can also create and install custom policies, but you must program them yourself. Here I'm using the RELATIONSHIP VALIDATION POLICY, which lets you define which relationships an asset must have.
After you add a policy, you must configure it to define the rules that you want.
Every policy has different options. For the RELATIONSHIP VALIDATION policy, set the number of relationships and what relationship type must exist for the policy to pass.
I'm configuring this to look for AT LEAST ONE relationship, that relationship is to an IMPLEMENTATION asset, and the relationship is of the IMPLEMENTATION type. You can make the configuration more specific by entering a lifecycle STATE that the related asset must be in, for example, APPROVED, but that's not necessary.
After you configure the options for the policy, you use these checkboxes to configure when the policy runs. This policy checks for the appropriate relationships when the asset is modified, when the asset enters this state, and when someone attempts to change the state of the asset.
Now I have that policy configured, but I'm not quite done. I must configure the TRANSITION between states to prevent the asset from changing from one state to the next unless the policy passes.
When you configure a transition, you are configuring what gets checked, what conditions must be met, in order to move from one lifecycle state to another. In other words, the transitions are where you enforce the policies and approvals that you just set up. By default, transitions always have the MANUAL ACTION condition, which means that a lifecycle manager must manually select that it is time for an asset to change states.
I'm keeping that, but also adding a condition that the policy I just added has to PASS.
So, from this drop-down you can see the policy from the previous state.
Now, for the asset to move to the next state, a lifecycle manager must request that change, AND the policy must pass. Only then does the asset change states.
Next, onto configuring another state that is slightly different. In the STAGED state, I want a lawyer to have to approve the asset, and, to make that lawyer's job a little easier, I want to AUTOMATICALLY grab some standard legal notices from a different asset and add them to any asset that enters this state.
First, use the Review section to add the lawyer as a reviewer.
I'm adding the lawyer, Kenneth, as an Approver. APPROVERS can view, comment on, and vote on assets.
So, for Kenneth here, select ALLOW EDITING to let him modify the asset if needed. And select APPROVER to let him APPROVE or REJECT the asset.
Next, the APPEND ARTIFACTS policy allows you to grab all the files from an existing asset and add those to any other asset that enters this state.
To configure this policy, you must enter a GUID and version number for the asset that has the files you want. I'm copying these values from the asset general details and pasting them into this configuration window.
This adds the label "Legal notices" to any files that get copied over and this option means that the notices file that I'm grabbing replaces any other file that has the same filename
Now, I want this file only to be added when an asset enters this state, so I'm selecting only the ENTRANCE TO STATE checkbox for when this policy runs.
Finally, to make sure that Kenneth has approved the asset before it can move to the final state, I'm editing the next transition. I'm adding an extra condition that Kenneth, our lawyer, must have approved the asset.
Now that the master lifecycle is complete, a community lifecycle can be customized.
Community administrators manage community lifecycles on the LIFECYCLES tab. Community lifecycles are extended versions of master lifecycles, where you can add conditions and policies like the ones I added here to the master lifecycle to use within only a specific community. In the Lifecycles section, you see a list of all the current lifecycles. The order of the lifecycles is important: an asset can only use ONE lifecycle; if an asset qualifies for more than one lifecycle, it enters the FIRST lifecycle, in top-to-bottom order here.
If you are seeing assets enter the wrong lifecycle, you can use the arrows here to change that order.
Asset lifecycles take on the properties of a community lifecycle and you can add conditions, policies, and reviewers here for the individual asset as well.
It takes some time to set up and some planning on the repository, community, and asset levels, but lifecycles give you very detailed control over how assets develop over time. Thanks for watching.