Asset Management Scenarios

With many workproducts created across many delivery cycles from many teams using multiple tools and repositories, it is difficult for the business to preserve its investment in workproducts and leverage them as a strategic business asset and provide the trace-ability back to where and from whom the original workproducts came from. Having the right set of workproducts and relationships exposed in an asset repository for governance, search, and usage scenarios across teams and projects is central to the value proposition for asset management repositories.

Roles

In these scenarios there are two major roles, asset submitter and asset consumer. These roles overlap functional roles like developer, architect, tester and so forth. For example, this means a person in the role of developer can also take on the roles of asset submitter and asset consumer. These roles are briefly introduced.

• Asset Submitter: performs asset preparation activities outlined in the publish scenario.
• Asset Consumer: performs asset searching and retrieval activities outlined in the search and retrieve scenarios.

Security / Access Rights

In these scenarios it is assumed the asset submitter and the asset consumer have already provided user authentication. This means they are not providing user information as they publish an asset or as they search or retrieve assets. It is expected that the asset repository will determine that context from previous information provided by the respective user.

Scenarios Overview

Asset management plays an important role across the software delivery cycle. Here we will focus on the following scenarios:

• Publish
  • Submit asset information and files to repository for governance, review and approval, search and retrieval, measurement and reporting.
• Search
  • Find and browse asset information and files, metrics, comments, related assets and other relevant information on the asset.
• Retrieve
  • Pull a local copy of the asset information and possibly files for the asset.

More detail below on each of the scenarios.

Publish

Publish Scenario Example

A developer has been creating a service specification (WSDL file and several XSD files), checking them into and out of a source control system. The developer has determined the service specification is mature enough to be governed and shared with other teams. The developer prepares to publish these workproducts as a service specification asset and fills in the relevant asset information (version, classification, ...) and selects the WSDL and XSD files (workproducts) and performs the publish. The developer examines the resulting message, indicating the service specification asset, with the WSDL and XSD files, has been successfully published to the asset repository.

The published service specification asset is part of an approval process and various groups collaborate, iterate, and vote on the specification moving it through its states until it is approved.

Background

An asset is published for one of many reasons, including:

• for approval purposes to be used by others
• to declare relationships to other assets, which may already be approved
• to submit the asset to a lifecycle so the appropriate teams may evaluate and refine it
• to declare the asset's type

An asset may contain zero or more workproducts (artifact, files). When the workproducts are of sufficient quality and represent a completion of work which is ready to be governed and shared, then the asset information is created and the workproducts, if any, are selected.

In the publish scenario the Asset Submitter describes the asset's information (or metadata) including, but not limited to, items such as:

• name
• version (asset version, not workproduct version)
• asset type (describing the asset's expected content, constraints, lifecycle, relationships, categorization)
• description
• relationships/dependencies to other assets
• workproducts, contained directly, or referenced
• published location (server, community)

Other information about the asset can also be determined by the asset repository, although it may not be directly provided by the asset submitter, such as:

• date submitted
• submitter's roles and permissions
• permissions of potential users
• asset's unique identifier

The asset submitter may be human or a system. When the publish scenario is completed the submitter has a description of the result.

Search

Search Scenario Example

A developer is building an application and needs to find an existing, approved service to use. To find the service the developer provides service information to search such as the service name, description, classification, relationships, attributes, artifact information, and other metadata (such as preferred sort). The developer also provides keywords, wildcards and variant keyword phrases. The developer also indicates the scope of the search, indicating what level of the metadata to search, such as the service's artifact information - such as the WSDL operation name.

The developer issues the search, viewing the service information on the result list such as service name, version description, asset type, ratings, attributes, artifacts, and related assets. The result list includes information on each asset about its position and relevance in the result list. The developer sorts the result list by the approved date.

The developer pages through the result list examining the service's artifact names (such as the WSDL artifact in the service, and the operation name that was found), the service description, and so forth. After reviewing the result list, the developer shares it with another developer, who examines the service information on the result list.

The search could be performed by a human or by a system.

Search Scenario Example 2

In this scenario a developer searches using asset relationships in addition to the other service information. In this case the developer is looking for service specifications which have associated implementations which have been deployed.

Background

The asset information and workproducts provided in the Publish scenario provide the basis for searching and browsing.

In the search scenario the Asset Consumer uses asset information to search for the asset. The search allows the asset consumer to perform structured searching using classification, asset type, and other structured elements. The search also allows unstructured searching using keywords, wildcards, and variant phrase searching. Any given search may have any given number of structured and unstructured searching parameters.

The set of searchable assets are constrained by the access rights of the asset consumer; which means that another asset consumer with different access rights while using the same search parameters may have a different result set.

The search returns the search result for the provided search parameters and user access rights. The Developer browses the asset information on the search result (i.e., browses the asset meta data). The service artifacts are NOT downloaded during this scenario; but are downloaded as part of the Retrieve scenario.

Retrieve

Retrieve Scenario Example

A developer is building an application and has found a service specification to use. The service specification may have been found through the Search use case described above, or a reference to the service specification may have been given to the developer.

The developer examines the service specification more closely, browsing its information and artifact lists. When the developer is satisfied the developer downloads the service specification's artifacts, which are retrieved to a local workspace.

If the service specification has dependencies to other assets, the developer is given an option to retrieve those assets, if selected, the related assets artifacts are downloaded as well.

Background

Upon browsing the asset information, the asset's artifacts provided in the Publish scenario are then browsed and eventually retrieved into a target location.

The set of retrievable assets are constrained by the access rights of the asset consumer; which means that another asset consumer with different access rights may be not be able to retrieve the asset.

Other

The Powerpoint file with the images for these scenarios can be retrieved from here.