Guideline: Selecting Asset-Based Development Tools
These guidelines provide recommendations for selecting tools that support asset-based development.
Relationships
Main Description

Introduction

It is important to select tools that support the asset-based development activities, so that these activities do not reduce the productivity of the team in any way. Also, the availability of tools that provide value and are easy to use will increase the probability that the asset-based development activities will be performed..

The selected tools should support the asset-based development activities and meet the needs of your organization. The type of tooling that is provided is highly dependent on the types of assets that your organization will be working with. The possible asset types should be considered when selecting the tooling.

There are several kinds of tools to consider when setting up the asset-based development and management environment. In the image below, the Reusable Asset repository (referred to as repository) and the IDE are critical ones for the Development time environment.

Critical tools for development-time environment: the Reusable Asset repository and the IDE.

In the image above, reusable asset repository may include design, code, or anything that is reusable; configuration management repository may include versioned artifacts and views; change management repository may include activities and tasks; portfolio data ware house includes project summary data, financial data, and resource data; project repositories/workspaces may include requirements, code, tests, assigned tasks, build results, defects, etc.; configuration management database includes machines, operating systems, databases, and applications; service registry include descriptions of deployed services and composite applications.

These guidelines provide recommendations for selecting tools that support asset-based development. The project-specific guidelines and process may need to be modified to reflect the selected tools.

Selecting Asset Production Tools

Tasks specific to asset production include creating (or harvesting) the Artifact: Asset Artifacts that will make up the asset, and packaging the asset.

Some tools to consider for each of the asset consumption tasks are as follows:

  • Asset Artifact Development. The tools that support the development and harvesting of the Asset Artifacts are dependent on the type of artifacts being created. In most cases, such tools already exist, as they are usually the same tools as those used for developing other projects in the organization.
  • Asset Packaging. The tools that support packaging the asset should understand and support the semantics of the standard format in which the asset is to be packaged in (that is, it embodies and supports the format's well-formedness rules). In that way, it reduces (ideally eliminates) the possibility of an improperly formed asset. Also, the tool should make it easy to locate, browse, and include in the asset package, the individual artifacts. The tool should highlight what remaining documentation is needed to complete the asset, as well as provide validation checks for completeness.

Selecting Asset Consumption Tools

Asset consumers locate assets, evaluate assets, apply assets, and provide feedback on the assets and the asset library.

Some tools to consider for each of the asset consumption tasks are as follows:

  • Asset Location. The Asset Consumer needs tools to search for assets, browse them and conduct fit analysis, and ultimately choose to acquire the asset. The supporting tooling can include Web browsers for searching and browsing assets. Depending on the size and complexity of the asset a Web browser may be sufficient for conducting fit analysis. Or, an evaluation version of the asset may need to be secured and used in point tools to conduct fit analysis. Acquiring the asset also takes multiple paths as some assets may be downloaded online whereas others may require significant financial transactions and other media to acquire the asset.
  • Asset Application. The Asset Consumer needs tools to install and customize the asset. This tooling varies widely depending on the types of asset. Applying an asset may be as simple as opening a requirements document and customizing it for your needs. Or, it may be more complex, such as installing and extending an application framework.
  • Asset Rating. In many cases the way in which an asset is rated may be less dependent on the type of the asset and more dependent on the asset library. Rating an asset provides feedback and change requests, and is often implemented as part of the asset library.

Understanding Target Environment, Topology and Hardware

A critical part of selecting tools for asset-based development is to understand the target environment where the asset repository will be hosted. There are several topologies to consider for the asset repository, with two simple ones presented here.

In the first topology, shown below, the asset repository server is on a clustered application server at a central site. There is one database with which the asset repository server communicates, along with source configuration management (SCM) support and other necessary integrations. The remote sites deploy just the clients to the asset repository server, but replicate SCM locally on each site. This topology has the benefit of lower technical support staff in remote locations, but requires higher bandwidth for asset-based development scenarios between the remote site and the central site.

Topology where the asset repository server is on a clustered application server at a central site.

Another topology to consider is shown below. This topology has the benefit of distributing the computing for asset-based development scenarios to the remote sites with replicated SCM support. Asset searching and asset retrieval will perform faster in remote sites, while asset browsing of the metadata, which requires asset repository DB support still requires decent network bandwidth. This topology requires more administrative support in the remote sites as well.

Distributed topology with replicted SCM support.

There are certainly many other topologies to consider. In short the enterprise needs to determine the level of replication of indexes, metadata, and asset artifacts to promote across the remote sites to support performant asset-based development scenarios, balanced with the cost of delivering that capability.