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.
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.

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.
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.
|