A true reuse environment is far more ambitious than Web developers using common components in an object library or a Webmaster using another Webmaster’s code. The purpose of a reuse initiative is to establish an environment where structured and unstructured components are shared between teams, between departments, and within an entire worldwide organization. The focus is on reusing business logic, not on the reuse of utility functions.

As a result, it’s important to think about a reuse model in broad organizational terms. If you are asked to develop a solution for your customer, you may well be building components that could be used in other solutions that might arise later—in other departments and locations. Consider the following:

  • How do you know if the component can be reused?
  • Should you build the component in a way that will allow it to be reused by others, even if that means it will take longer to develop for your particular application?
  • Once you create the component and it’s used in multiple applications, how does it get changed if a problem is found or an enhancement is needed?

Creating a reuse environment requires balanced attention to people, processes, and technology. More specifically, you need to address reuse processes, training, roles and responsibilities, incentives, metrics, and a repository. This article will discuss the role of reuse processes and training in making the environment successful. Although both structured data (models, code, etc.) and unstructured data (documents, video, etc.) can be shared in a reuse model, our focus here and in subsequent articles will be on structured data reuse.

The need for reuse processes arises because of the logistical difficulty in managing components that can be shared by many developers in many applications. Let’s assume for a minute that a particular group manages the reusable component library. Two broad sets of processes need to be defined. First, you need processes for determining how a component is identified as being reusable and how it is elevated to the reuse library. Second, and most important, you must have processes associated with managing the components in the library.

Component identification and submission
If you develop a component that you think has wider reuse applicability, how do you let the rest of the organization know? In most organizations, no process exists to make this happen. You can share components on your team, but wider reuse is difficult. You must have processes in place that allow people to volunteer certain components they are building as candidates for broader reuse. The request needs to be evaluated to see if the component does, in fact, have wider use opportunities. Once that determination is made, the business rules need to be defined precisely and the component must be built, tested rigorously, and documented clearly. This work may be done by the original developer or by a team that develops and supports the library of reusable components.

Ongoing component management
Once you identify, build, and document a reusable component, you have something people can reuse. However, the component must then be supported, just as a normally developed application needs to be supported until it is retired. This component management is not as difficult if a component never changes. However, management becomes more complex if the component needs to be modified.

A component may require modification because of a necessary enhancement or because an error was found. Or perhaps a component is close to what a new application needs, but it’s not exactly right. You may create a new, related component or modify the first one to allow it to be reused more generally. When that happens, you need to keep track of component versions. The people who are currently using the component need to be notified that the component is changing, and they must decide whether they want to continue using the older version or make the change to a newer version. If everyone using the old component can migrate to a newer version, the older component can be retired.

Other specific processes need to be established in the following areas:

  • Testing and quality processes—To ensure that the components are tested rigorously and do not break the host application. Testing must also verify that changes to a component will not break older systems using an earlier version of the component, which might happen if the old system ever needs to be recompiled.
  • Communication processes—To keep developers informed of the components available for reuse
  • Error and enhancement reporting processes—To make sure that the appropriate people make decisions on when and how component changes occur

Training is key
A successful reuse environment also requires specific techniques and skill sets for building components for reuse. You obviously can’t cut and paste sections of code and expect them to be reusable by other applications. There are programming paradigms that need to be understood and followed in terms of encapsulating the code, building the proper parameters, etc.

Most developers probably think that they write pretty solid and stable code. But how many developers actually have the skills to develop nontrivial encapsulated components that can be used by independent developers all over the company without breaking or providing inconsistent results?

Computer languages accomplish reuse in various ways—some of which are more difficult than others. The developers building the reusable components must have the right level of training and mentoring to ensure that the components are reliable, understandable, and stable.

More than just copying code
Reuse, as we mean it here, is more than copying and modifying an existing program. Reusing business logic, code, and processes across an entire organization can be a challenge. Here are a few points to keep in mind:

  • Reusing components on a team or between two people who know each other can be relatively painless. Building and managing an environment where components are shared within a large organization requires much more structure and rigor.
  • You need to set up processes to make the reuse environment run smoothly. In general, these processes will focus on how components get nominated and added to the reuse library and how they are managed over their lifetime.
  • The people who build the reusable components may require a different set of skills than typical developers. These reuse developers typically need a combination of training and mentoring to be successful.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.

Missing out on the promise of reuse?

Have you been a part of an effort to create a reuse environment in your shop? What problems did you encounter? How did the effort turn out? Send us an e-mail with your experiences and stories or post a comment below.