Asset Management Scenarios - Architect

These scenarios focus on ways that an Architect can specify & publish assets, and also how other users, Architects, Designers, or Developers, can consume those assets.

Roles

In these scenarios there are two major roles, asset submitter and asset consumer.

• Asset Submitter: performs asset preparation activities outlined in the publish scenario. For these scenarios, the submitter will be an Architect.
• Asset Consumer: performs asset searching and retrieval activities outlined in the search and retrieve scenarios. For these scenarios the consumer can be anyone consuming Architecture assets.

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.

Publish

Publish Scenario Example

An Architect has been developing

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

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

Background