Three Steps to Launching Reusable Software Assets

Software development teams are under intense pressure these days on a number of fronts.

They are asked to reduce costs, achieve earlier returns on investment, respond with agility to market forces, collaborate with other departments to integrate end-to-end business processes, leverage scarce resources and align technology with the needs of the business.

These forces can be dealt with through proper organization and reuse of assets contained in the business's software portfolio.

Making the decision to systematically reuse software-related artifacts requires support at the organizational level and the commitment to put reuse-related activities in practice at lower levels of the organization. The organization must realize from the start that reuse efforts are providing value to its development challenges and assignments.

A reuse strategy that delays benefits until some future time will generally fail. Therefore, assets must be identified early that have high value for application development teams.

First, I define the term software asset as a collection of artifacts that provide a solution to a problem. An artifact is a product from your software development activities, such as requirements, models, source code and tests.

With this definition in mind, and with the context of the forces we are seeking to mitigate, the costs to reuse the assets must be sufficiently low to support the business case for using them. The lower the reuse costs, the earlier you obtain a return on your investment in the assets. The business value may be described in terms of decreased production time, lower development and maintenance costs or improved ROI, for example.

Asset-based development is an organizational and software development strategy that organizes software investments around the software assets that will deliver high value to the business and decrease future development costs. To be successful, the business needs best practices and tooling to find, package and reuse software assets, as well as a standard approach for describing and cataloging assets.

There are four elements to consider before applying asset-based development within your organization:

1. Management support for asset-based development.
2. High-quality, relevant assets that are critically needed by the targeted asset consumers and have the highest probability for early ROI.
3. Policies to identify, understand and control reinvention in the organization.
4. Dedication to recognize and encourage all forms of software assets that have net benefits for the organization, which includes reusing document templates and procedures.

With these elements in mind, how does a business get started in applying asset-based development?

I recommend the following three steps:

1. Establish policies and procedures for measuring success. There should be a collection of policies created that include items such as measuring reuse activities and governance issues. The policies should be used consistently to enable the organization to know when the asset-based development activities are successful or need modification.

   For example, some of these policies should state how and when to measure reuse activities. Will an asset be counted as being reused multiple times on the same project? Or will the asset be counted when it's used only the first time by a team on a specific project? What are the costs for producing the asset? How do we quantify the value to the team or project, if any, of the asset's usage?

   Avoid the practice of measuring success as having a certain number of assets within a repository. Rather, the value derived from reusing the assets should be the measurement criterion. Increasing the number of assets in a repository for the sake of achieving some prescribed quantity generally increases the searching, evaluation and reuse costs, which lowers the benefit to the business and extends the time frame for achieving ROI.

Grant Larsen is the model-driven development strategist at IBM Rational Software, responsible for driving the asset-based development strategy, including development process definition, pattern content development and tooling features. He has more than 17 years of experience in software development. He is currently writing a book on reusable assets, their organization and usage for Addison-Wesley.

2. Understand the software-asset consumer and refine strategy accordingly. First, you must understand the skill set of the target consumers. Developing overly complex solutions that are a mismatch for them will certainly add to the reuse costs.

   Second, the packaging must provide sufficient information to help the asset consumer evaluate and make a decision. Some assets are small enough or convenient enough to allow a trial run with little packaging, whereas others need supporting material to provide this guidance.

   What's needed is predictable organization and packaging of assets to ensure that the right amount and kinds of information is presented for the asset consumers to evaluate and ultimately reuse the right assets for their context. The Reusable Asset Specification defines the structure and organization of software assets to provide a consistent, predictable experience for asset consumers.

3. Start small. As previously mentioned, organizational costs tend to increase as the level and scope of reuse increase.

   To get started, an organization should start small. Identify a narrow scope, perhaps for one team on one project, where it has been established that there are some recurring problems for which some recurring solutions are known. Then establish the policies for that scope and implement some asset-based development activities within that small scope. Measure. Revise. And implement again.

In summary, there clearly are more activities involved to conducting asset-based development, but these initial steps will help organizations establish a successful reuse program -- one that will help deliver software assets that provide timely value.