Among the items a Reuse Strategy should consider, there are four major categories that should be
described:
-
Process
-
Standards
-
Tools
-
Assets
These items typically go into the Reuse Strategy document's section called Reuse Environment.
Process
There are two process categories to consider: organizational-level processes and project-level processes. The strategy
needs to describe the organization-level process for setting up asset governance. This includes describing who should
be involved in the planning, definition, enablement, and measurement activities as outlined in the image below.
The strategy also needs to describe for project-level processes how assets should be manufactured, who will do it, who
will own the assets, what are the responsibilities of the teams using the assets, how long should an asset be supported
by the asset submitter, how will assets be versioned, and so on.
Standards
The Reuse Strategy should describe what standards the asset program will adhere to, and
which ones it will ignore. There are several standards to consider in the reuse space. One is the Reusable Asset
Specification from the OMG: http://www.omg.org/. This standard describes the basic
metadata that assets should have. Other standards in the reuse space are described on the SEI site: http://www.sei.cmu.edu/.
Tools
The Reuse Strategy should outline the major tools that need to be identified
and whether the organization will align on a common toolset or support various ones. There are many repositories
in a software development organization. The nature of these repositories and development environments should be
described.
If there are multiple existing asset repositories filling similar needs, then the strategy should address whether these
should be federated. For example, you may have multiple development-time asset repositories, and the federation or
migration strategy should be outlined.
You should also address the federation of metadata between development-time and runtime repositories, such as service
registries. Each red dot on the image below identifies a candidate point of governance. This means that, for the action
being performed, who can do it, how it is measured, and how does it impacts a related repository or registry.
The tools for asset-based development need to intersect naturally into the way the users perform their work on a daily
basis. To do this analysis, consider the intersection of the user's role, the assets that they will be working with,
and the asset-related scenario that they are performing.
For example, a developer conducting the search asset scenario will likely be looking for an asset such as code, or
perhaps a test, and will likely be in an integrated development environment. A business analyst conducting the
search asset scenario, on the other hand, will likely be looking for an asset such as a business process model, or
perhaps a requirement, and will likely be in a modeling tool, or perhaps using a Web browser.
A table or matrix to organize this can be helpful.
|
Analyst
|
Architect
|
Developer
|
Search for Asset
|
Asset: Business Model
Tool: Web Browser
|
Asset: Design Model
Tool: Eclipse IDE
|
Assets: Service Interface, Service Implementation
Tool: Eclipse IDE
|
Create Asset
|
Asset: Business Model
Tool: Modeler tool
|
Asset: Design Model
Tool: Eclipse IDE
|
Assets: Service Interface, Service Implementation
Tool: Eclipse IDE
|
Assets
The reuse strategy document should outline the significant assets that the organization should
create/govern/manage/reuse. Asset size, structure, and granularity are left to the organization to determine. The reuse
strategy should identify the key assets which are beneficial to the business and which potential assets should be
ignored.
As part of the strategy, the scope of the assets should be discussed. Will assets be shared across the entire
enterprise, or just within teams? In general, the best practice is to begin with a small reuse scope for the assets,
and then increase the scope over time.
Major sections of the Reuse Strategy document
The Reuse Strategy should address the following items:
-
Introduction of key concepts: describe the key terms and concepts of asset management and asset-based development.
-
Reuse vision and risks: describe the motivation and benefits being sought (quality, productivity, etc.). Describe
the business drivers and IT drivers.
-
Reuse environment: introduce the organizational structure and tooling support necessary to conduct reuse.
-
Funding strategy: describe the funding model and sponsors to support the reuse effort.
-
Reuse implementation strategy: describe the approach for introducing the reuse program to the organization.
-
Resource and training strategy: outline the approach to training the teams creating assets, using assets, and
managing the repository.
-
Metrics for measuring progress: describe the significant metrics that will be tracked for technical and
business management.
The Template: Reuse Strategy provides a sample for getting started.
|