Task: Prepare Reuse Strategy
The Reuse Strategy describes how the enterprise, or some other scoped entity, will conduct the activities of the reuse program.
Disciplines: Asset Governance
Purpose
Organize the approach for the reuse effort.
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
    • None
    Outputs
      Main Description

      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.

      Organizational-level processes and project-level processes.

      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.

      Tools used by an asset-based development process.

      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.

      Candidate points of governance.

      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.

      Reuse scope of an asset. 

      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.

      Steps
      Document the Reuse Strategy
      The major point here is to iterate through the sections of the document to create it. Often there may be more than one person working on the document. Dividing the various sections among those writing the strategy has some value for making the process easier.
      Share and Validate
      The initial goal is to share the Reuse Strategy with the appropriate stakeholders and collect feedback. Eventually the goal is to achieve sign off from key stakeholders to proceed with resource planning, pilot project planning, reuse adoption and rollout planning.
      Refine the Reuse Strategy
      Make adjustments based on the feedback.
      Key Considerations