Practice 17. Actively Promote Reuse

Bruce MacIsaac

Reusing assets can save you time and money, while increasing overall quality.

Problem

Many organizations repeatedly build similar software and other assets that could have been reused. The problem is not only the cost of developing these assets but also the complexity and costs of maintaining the volume of unnecessary artifacts. Reuse promises a number of benefits:

• Reduced cost by building assets only once.

• Quicker delivery of new capabilities by assembling and configuring reusable components in new ways.

• Better quality through use of proven components.

• Reduced complexity through architected, standardized components.

Unfortunately, reuse at many organizations is ad hoc at best. This practice describes how to overcome barriers to reuse and how to foster a reuse culture in your organization.

Background

We start by defining an "asset" and discussing barriers to reuse and trends enabling greater reuse.

What Is an Asset?

When most people talk about reuse, they are usually thinking of reusing code. Reuse, however, is not limited to code. Patterns, requirements, guidelines, processes, and so forth are all candidates for reuse. For example, a reusable asset could be a collection of Java coding patterns or a set of requirements.

An asset has several desirable characteristics:

• It serves a clear purpose.

• It solves a recurring problem.

• It is relatively independent, portable, flexible, and extensible and can be reused in different contexts.

• It includes documentation of how and when it should be used, including instructions and guidance for customization.

Here are some examples of successful code assets:

• Large customizable, componentized commercial offerings like PeopleSoft and SAP.

• Middleware for integrating business systems, such as MQSeries.

• Smaller commercial components, available from retailers like ComponentSource.

• Component frameworks, such as J2EE and Microsoft .NET.

• Open source tools, frameworks, and components included in Linux, Eclipse, and Apache projects.

• Smaller open source components in repositories like SourceForge.

Here are some examples of reusable assets:

• Reusable patterns, such as IBM's e-business patterns and Microsoft's blueprints.

• Reusable requirements, such as standard requirements for globalization and supportability across an organization.^[17]

  ^[17] IBM has many products with many different technologies, but despite this, many requirements, such as globalization and supportability requirements, have been standardized for the organization.

• Reusable development processes, such as plug-ins to EPF or RUP.

Barriers to Reuse

Several years ago I needed a library of geometric services for lines and surfaces on the earth. My problem was that I was dealing with large distances, and two-dimensional geometry was inadequate given the earth's spheroid shape. Knowing little about spheroids, I was strongly motivated to find code that I could reuse or adapt. I spent a lot of time asking around the company, searching the Web, and consulting various literature sources. It was difficult to know if such a library existed at all, and even more frustrating to think that the perfect library might exist, but I lacked the tools to find it.

I did find something, but it was a poor fit, as it had few of the needed services and was written in another programming language. In the end we built our own library and designed it to be reusable by any application. However, it was built for our project, and if a future project ever needed such a library, I wonder how anyone would know that our library exists. There were no mechanisms in place to encourage cross-project reuse.

Reuse has such compelling benefits that you may wonder why it tends to be the exception rather than the rule. The answer is that there are significant barriers to reuse, including the following:^[18]

^[18] Summarized from Jacobson 1997.

• Lack of incentives to identify and produce suitable reusable assets.

• Difficulty finding, assessing, and using assets.

• Architectures do not enable new items to be added.

The rest of this chapter discusses how to overcome these barriers.

Trends Enabling Greater Reuse

Reuse is becoming easier with new technologies and approaches, including the following:

• The growth of Web-based communities sharing knowledge and assets, including both "interest groups" and open source communities. One of the newest such communities is one that inspired this book, the EPF community. This new community enables common representation and shared evolution of methodologies and methodology-related assets.

• Object Management Group (OMG) Reusable Asset Specification (RAS) effort, which standardizes the format of reusable asset libraries. Tools supporting this standard will make it easier to manage and access reusable assets.

• Rich platforms and component frameworks like Eclipse, Microsoft .NET, and J2EE make it easier to create components that integrate well with other components.

• Web services and middleware are making it easier to integrate components and existing systems in flexible ways.

• Model-driven development approaches, including platform-independent models and domain-specific languages, raise the level of abstraction, allowing for more flexible implementations, including targeting different platforms and automated application of patterns.

Applying the Practice

The following are some strategies that can be used to foster reuse in your organization:

• Establish standards for representation.

• Capture examples.

• Promote sharing of good examples and reusable assets through communities.

• Create asset repositories.

• Foster consumption of reusable assets.

• Fund creation of reusable assets.

• Develop reusable assets incrementally.

These strategies are discussed in turn below.

Establish Standards for Representation

Whatever the asset, reuse is easier if the representation follows some standard. The following are some different kinds of standards:

• External standards. For example, standardize on UML as a modeling representation.

  Assets that use a standard representation are easier to reuse.

  
  

• Common tools. For example, choosing a standard tool to manage requirements allows sharing of examples and best practices for the use of the tool to manage requirements.

• Templates. For example, if you want to reuse requirements, a standard format for representing use cases will make them easier to reuse.

• Technologies. Choosing standard technologies such as .NET, and then building components that work in the resulting framework, will make it easier to mix and match components. Consider standards-based platforms such as J2EE and open platforms like Eclipse if you wish to avoid locking into a single vendor's solution.

• Guidelines. For example, standard coding guidelines result in code that is easier to use and understand across a broad community.

A standard methodology like RUP is a great facilitator for standardizing representation. Many companies have created plug-ins to RUP to deliver standard templates, notations, guidelines, and tool usage guidelines (tool mentors).

Capture Examples

Copying and modifying from examples are generally the most common forms of reuse. They don't have the visibility of large-scale systematic reuse, because you can't easily tell that the reuse happens; material reused this way is rarely cited. However, improving efficiency on lots of small tasks adds up, so this kind of reuse should be encouraged.^[19] How does it happen?

^[19] Note that this is about adapting examples to learn how to apply a pattern, not about duplication. Duplication of code is discouraged, because duplicated code is hard to maintain.

Let's say you need to produce a certain kind of document, code, or data, and you don't know what to do. You could thumb through some books, read through guidance in RUP or EPF, or work through guidance in a template, but after a while you become frustrated with trying to interpret the guidance. You cry out, "Don't tell meshow me!"

Many practitioners turn to the example grapevine; they ask their colleagues, post requests on forums, and if they are lucky they unearth an example. If they are very lucky, it is a good example.

A lot of time could be saved if good examples were made available. Sometimes there are confidentiality concerns, sometimes there is resistance just because the examples aren't "showcase quality." One way to start is to make a repository available for completed project artifacts and require these artifacts to be stored in the shared repository upon project completion.

Sharing good examples adds up to major savings.

Some companies have confidentiality concerns that prevent cross-company sharing of all artifacts, which limits the effectiveness of this simple approach. "Sanitizing"removing sensitive informationis a solution that can still allow many artifacts to be shared.

Sharing artifacts has many limitations: it doesn't scale, there is no way to assess quality, and each "reuser" has to make changes to take advantage of the assets. Defects in the original artifact multiply with each copy, and improvements in one copy don't easily flow to others. More systematic approaches to reuse are described in later sections.

Promote Sharing of Good Examples and Reusable Assets Through Communities

One way to promote good examples is to establish communities with a focus on excellence in a particular part of the software development process. For example, IBM has communities for visual modeling, testing, requirements, and so on. If you need to find a good example, you can post requests on the community forum, contact community experts directly, or search through a community's shared file area. This approach is one step up from the informal grapevine.

Communities can also provide feedback and encouragement to practitioners who create good examples or reusable assets. Additional incentives, either as recognition in annual appraisals or some financial incentive program, can also promote the creation of assets. Incentives should be based on actual reuse, to avoid collecting a lot of supposedly reusable assets that are never reused.

Communities provide a forum and incentives to share assets.

Some organizations go beyond simple communities by creating "community source" projects. The idea of "community source" is to mimic the successful practices of open source projects, but within the scope of an organization. As with open source projects, community source projects are successful only if there is a critical mass of individuals willing to participate.

Communities are easy to set up. Free services are offered by Yahoo!, MSN, and several other online services.^[20]

^[20] For Yahoo! groups, see http://groups.yahoo.com. For MSN groups, see http://groups.msn.com.

Create Asset Repositories

As the number and diversity of reusable assets grow, some method of managing these assets becomes necessary. The keys to managing large reusable asset repositories are an effective categorization scheme, search mechanism, and feedback mechanism. Consider the Amazon online bookstore as a model for reuse, except that "asset" replaces "book." You can browse or search by categories such as subject or author. More important, it is easy for individuals to post comments and provide a rating so that a potential buyer can benefit from the experience of others.

Asset repositories need categorization, search, and feedback mechanisms.

Note that the OMG has recently adopted a reusable asset specification (RAS). This specification provides a set of guidelines and recommendations about the structure, content, and descriptions of reusable software assets. There are some advantages to standardizing asset repositories on such a standard:

• You can migrate easily to other tools and environments that support the standard.

• It becomes possible to search across repositories, even repositories produced by third parties (a virtual super-repository).

• It fosters good documentation of assets, including categorization, examples, feedback, and so on.

Foster Consumption of Reusable Assets

If you have taken the time to produce reusable assets, you should take the following steps to foster their use:

• Advertise the existence of assets to end users.

• Train end users in how to find and assess assets.

• Use a development process that encourages reuse.

Fund Creation of Reusable Assets

The biggest benefits of reuse accrue when substantial assets are reused many times. Creating such assets can be a valuable investment, but they need to be identified, produced, managed, and made available for consumption (see Figure 6.9).

Figure 6.9. Reuse Program Management.

Reuse of significant assets across the enterprise requires a dedicated reuse program that enables assets to be identified, produced, managed, and consumed.

Reuse of significant assets across an enterprise requires a dedicated reuse program.

Reuse of significant assets across an enterprise requires a dedicated reuse program.

As with every project, an enterprise-level reuse program should have the following:

• A vision that defines objectives and sets the direction.

• A business case that justifies the required expenditures.

• Adequate funding to realize the objectives.

• An architecture that enables reuse.

• A software development process that covers the following:

  - Management of requirements and change requests from clients

  - Management of different versions of assets and dependencies between assets

  - Measurement of success/return on investment

In addition, an enterprise-level reuse program benefits from the following:

• An enterprise business model that defines the goals and processes that drive the business.

• An enterprise architecture that allows for improved integration between systems, coordinated adoption of new technologies, and ensured effectiveness of overall business processes.^[21]

  ^[21] See the Additional Information section for references on these topics.

You also need a governance process to manage dependencies and priorities as you evolve assets. Users of an asset may have competing needs that drive the asset in different directions. Which changes should be included? Should everybody update to the latest version? If not, how will you maintain multiple versions? The references listed in the Additional Information section can help you address these and other management, cultural, and technical challenges facing enterprise reuse efforts.

Develop Reusable Assets Incrementally

Building a successful reuse program is a challenging endeavor, and failures are common. Many programs result in repositories full of "reuseless"^[22] assets, that is, assets that are potentially reusable but are nevertheless not reused. Why does this happen?

^[22] The term "reuseless" comes from Ambler 2005.

If you build an asset to meet the needs of future projects, you are assuming that you can predict the needs of those projects. Unfortunately, it is very difficult to predict future needs, because needs change and technologies evolve. Assets built for the "future" clutter repositories waiting for a future that never comes.

Instead of focusing on reuse for an unknown future, consider the reuse needs of existing projects. Identify two projects that have a common need, and evaluate the likelihood that additional projects will have a similar need. If you have a family of related systems, the benefits of reuse can be obvious.^[23] But sometimes there is simply not enough commonality to justify a reuse effort.

^[23] Glass 2003 points out that most reuse success stories come from families of related systems.

A rule of thumb is that unless you expect to reuse an asset more than three times,^[24] it is not worth trying to make it reusable.

^[24] Glass 2003 and Ambler 2005 make reference to this rule of 3.

Once you have a business case for creating an asset, focus on the needs of the immediate projects that plan to use it, and evolve the asset over time to support additional projects. Generalizing a few assets of proven value to meet the needs of specific projects builds early success, and avoids building assets that don't get reused.

Generalize assets for specific projects to ensure good return on investment.

Other Methods

While XP doesn't directly say much about reuse, its principles and practices affect how reuse is applied on XP projects. Let's discuss some examples.

The high level of communication on XP teams, along with shared development, enables the team to share knowledge of potential assets and reuse opportunities. The XP search for "the simplest thing that could possibly work" encourages reuse when this is the simplest solution. The incremental design approach discourages big up-front design of reusable components, but continuous testing and continuous improvement through refactoring can result in quality components with potential for reuse.

These principles and practices are compatible with the Unified Process. However, the Unified Process explicitly addresses reuse as one of many architectural decisions, including guidance for making build versus buy versus reuse decisions, as well as advice on the benefits and pitfalls inherent in reusing existing assets. In particular, the Unified Process recommends integrating reused components in early iterations to ensure that they work as expected.

Integrate reused components in early iterations to ensure that they work as expected.

Creation of reusable assets is not part of OpenUP/Basic, but is included in RUP. Partner extensions to RUP provide additional depth (see the Additional Information section on page 299).

Scrum doesn't directly address reuse.

Levels of Adoption

This practice can be adopted at three different levels:

• Basic. Establish a common representation for each kind of artifact that you want to reuse.

  Promote sharing of examples and reusable assets through communities that have a shared file area and forum.

  All reuse efforts involve some investment, and they pay off in increased ability to deliver more and deliver more quickly. This basic approach requires a minimum of investment, yet generates good results.

• Intermediate. Promote education and use of open standards, reference architectures, patterns, common and shared processes, component frameworks, component architectures, and service-oriented architectures.

  Investing in your organizations' technical knowledge in these areas increases their ability to create better-quality assets that are potentially reusable.

• Advanced. Fund the creation of reusable assets through a dedicated reuse program.

  Dedicated reuse programs involve substantial investment and risk. However, in cases where the organization has substantially overlapping development work, there can be significant payoffs.

Related Practices

• Practice 16: Architect with Components and Services and Practice 15: Leverage Patterns describes components, services, and patterns. These practices encourage reuse and aid in the creation of reusable assets, because they define systems in terms of reused and potentially reusable parts.

• Practice 18: Model Key Perspectives describes how modeling aids understanding and communication. Modeling is an effective way to document reusable software assets. Model-driven development approaches can also raise the level of abstraction, resulting in more flexible components. For example, a component can be expressed using a platform-independent model that is transformed into different platform-specific models.

• Other practices: Reusable assets are created following the same principles as nonreusable assets. In this sense all the practices in this book are applicable.

Additional Information

Information in the Unified Process

OpenUP/Basic recommends that projects reuse existing assets, but it doesn't go into the details of organizational reuse efforts. OpenUP/Basic, however, can be applied to projects that produce or improve reusable assets.

RUP provides specific guidance for asset production, consumption, and management in the Asset-Based Development plug-in. In addition, the Systems Engineering plug-in to RUP covers how systems of systems can be constructed, and the Business Modeling plug-in to RUP describes how to model business processes to identify opportunities for automation and reuse.

Flashline is a company that specializes in software reuse consulting and has produced a RUP plug-in for managing software asset portfolios. This plug-in is available from the company's Web site at http://www.flashline.com.

Additional Reading

For guidance on setting up and running a dedicated reuse program:

Jacobson, Griss, and Jonsson. Software Reuse: Architecture, Process, and Organization for Business Success. Addison-Wesley, 1997.

Hafedh Mili. Reuse-Based Software Engineering: Techniques, Organizations, and Controls. John Wiley & Sons, 2002.

For guidance on enterprise-level reuse as an extension to RUP, including enterprise business models and enterprise architecture:

Scott Ambler et al. The Enterprise Unified Process: Extending the Rational Unified Process. Prentice Hall, 2005.

For guidance on reuse as part of product line development:

Paul Clements. Software Product Lines: Practices and Patterns. Addison-Wesley, 2002.

Jack Greenfield et al. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. John Wiley & Sons, 2004.