NOTE: This article will soon be updated to reflect the evolution of EUP to be based on
Disciplined Agile Delivery (DAD). Please stay tuned.
Reusability is one of the "holy grails" of the
information technology (IT) industry, one that is seldom achieved. Many
organizations fail at reuse because they don't understand its scope; reuse
between projects is where you get your payback, not reuse within a single
project. Many organizations prematurely give up on reuse when they don't see
positive returns on their first few projects or even on their very first one.
Strategic reuse is a long-term endeavor that has strategic returns instead of
tactical ones. This is why it is critical to look beyond the needs of a single
project to the needs of your entire organization: hence
Strategic Reuse is an Enterprise
discipline, the goal of which is to define how organizations can succeed at
reuse, ideally in a manner that is as streamlined and agile as possible. It is possible to succeed at reuse if you've adopted an
iterative/agile process such as the
Disciplined Agile Delivery (DAD),
Extreme Programming (XP), or Scrum, you just need to look at the entire enterprise picture.
Table of Contents
- Planning your reuse program
- Harvesting existing assets
- Obtaining external assets
- Developing assets
- Evolving assets
- Publishing an asset
- Retiring an asset
- Supporting project teams
- Measuring reuse programs
Let's start with some definitions. An asset is a project
artifact that is retained at the end of a project. A robust asset is well
documented, generalized beyond the needs of a single project, thoroughly tested,
and ideally has several examples to show how to work with it. Robust assets are
much more likely to be reused than items without these characteristics. A
reusable asset is a robust asset that has been used on three separate projects
by three separate project teams (at a minimum). You can claim that something is
reusable, but it isn't truly reusable until it's actually been reused;
reusability is in the eye of the reuser, not in the eye of the creator.
Reuse is often described as not "reinventing the wheel," and the
first step for succeeding at reuse is to understand that you have
one option at your disposal. You can reuse source code, components,
development artifacts, patterns, and templates.
A key component
to reuse is open communication within your organization: this is usually the
major point of failure in implementing any reuse program in our experience.
It's plausible that the greater levels of communication and collaboration on
agile teams, and their greater focus on quality, seems to increase the odds that
agile teams will increase their chances of success.
Reuse isn't free; it isn't something that happens simply
because you're using certain tools or working with certain technologies.
Instead, reuse is something that you have to work at very hard, as you can see
in the high-level workflow for the Strategic Reuse discipline in Figure 1.
workflow is depicted in Figure 2. An
important message of this discipline is that in order for it to succeed your
organization must be as agile as possible: it is possible for
enterprise-level professionals to work in an agile manner, but they must
choose to do so and be allowed to do so.
Figure 1. The workflow of the
Strategic Reuse Discipline.
Figure 2. The amalgamated workflow of the
Strategic Reuse discipline.
2. Planning Your Reuse Program
You must actively plan and budget for reuse: you need to allocate the time
and resources necessary to make reuse a success. You must invest the time to
generalize or harvest your work, otherwise project pressures will motivate you
to put that work aside. The bottom line is that you need to plan for and then
operate a reuse program within your organization. This is often difficult for
some organizations to do. There is an upfront cost to reuse that may impact
early projects. You must be willing to tolerate short-term pain for long-term
Your reuse program must reflect both the goals of your organization, which
are reflected in your enterprise architecture and your portfolio specification,
and your willingness to fund and follow a reuse program. I can't overstate how
difficult it is to succeed at strategic reuse. Most organizations fail because
they make their programs too complicated, because they assign the wrong people
to the reuse team, or because they starve the team of resources. Important
issues that your plan should encompass:
Development teams build new things every day, and some of these things can be
generalized into robust assets for reuse by other teams. This is particularly
true for teams that are working with new technologies and techniques: for
example, your first few C# teams are likely to develop useful utility classes,
or the first few project teams to write use cases will develop use case
templates. The downside is that the first people to work with a technique or
technology are most likely to make "beginner mistakes," so their work may not be
something you want to share with others. The implication is that you either need
to wait to harvest a higher quality asset later on or be willing to invest more
effort into generalizing the asset; we've found that it's usually best to wait,
giving you more time to gain experience with the technology and discover if
there is actually a need for the asset on other teams. It takes much more effort
to generalize an asset to make it reusable than it does to develop it for
single-purpose usage. For example, studies showing that development of reusable
code costs 111% to 480% of the development cost of single-purpose code.
- Goals. What are you trying to achieve?
- Staffing. Who will be the reuse engineers?
- Initial startup strategy.
- Tool strategy. Will you have a reuse repository? Shared
directories? Hope for the best?
- Reuse potential. What is the potential benefit to your
organization of a strategic reuse effort?
- Communication strategy. How will people learn about the program?
- Team organization. How will the reuse engineers work together?
Support project teams?
- Defined support limits. What is your strategy for supporting
reusable assets? Who owns them?
- Asset evolution strategy. Your assets must evolve, so how will you
support that? How many versions of an asset will you support?
- Measurement strategy. How will you know that your reuse program is
successful? What simple metrics can you
- Growth strategy. How will you handle your program's success?
Generalizing an asset requires great skill: the reuse engineer needs to be
familiar with not only the technology or technique behind the asset but also
with how it will potentially be used in practice. Part of generalization
ensuring that it conforms to appropriate guidance (see Supporting Project Teams), and making it easy to understand by its intended
audience. You also want to validate the asset. You'll need to unit test
code-based assets and review templates and non-code artifacts with their target
audiences. Concise overview documentation is important, but far more important
are one or two good examples showing how to use the robust artifact properly. In
the case of code, your unit tests may be sufficient. For templates, you should
capture an actual example of the document for which it is a template (for
example, to support a use case template, you should harvest one or two
well-written use cases from a project team). Figure 3 depicts the workflow
details diagram for harvesting existing assets.
Figure 3. Harvesting existing assets.
There are four basic harvesting strategies that you can follow:
- Harvest in-progress. You generalize an asset developed by a team
before it has been released by working closely with the team.
- Harvest at project end. You wait until the team has finished
building the asset, and then you generalize and perhaps even redeploy it
- Harvest a legacy asset. In addition to reworking/generalizing the
asset, you can also wrap access to it using several technologies:
application programming interfaces (APIs) written in Java or C, Common
Object Request Broker Architecture (CORBA) interface definition language (IDL),
or even something as mundane as screen scraping software, which simulates
keystrokes that are submitted to the user interface (UI) of the legacy
- Harvest for a new project. You wait until a project team needs an
asset previously developed by another team and then decide to either reuse
it as-is or to generalize the asset.
4. Obtaining External Assets
A significant number of assets developed outside of your organization may be
available to you. Years ago, our advice would have been to "buy before you
build," but with the rise of open source software (OSS) and other forms of free
software, our advice is now "download and evaluate before you buy, and buy
before you build." There are three basic sources of external assets that
you should consider: OSS, Other freeware, and commercial off the shelf (COTS)
products. Much of the effort is similar to harvesting an existing asset
because you're likely to find that you need to tailor the external asset to meet
your exact needs.
You need a "shopping list" of requirements against which to assess candidate
assets. For example, if you're searching for a
you'll discover that you have many options to choose from, some of which will
meet your needs and some of which won't. Without these requirements, you run the
risk of being unable to determine which candidate assets meet your
needs; we've seen searches that should have taken hours or days last for
months because the people evaluating the candidates kept getting distracted by
"really cool" features that they didn't even need.
It is good advice to rarely, if ever, to start building an asset specifically
to be reusable because you run the risk of building something that you don't
need. How many projects have you seen where the team spent the first six months
building the infrastructure that they "required" for the rest of the project,
only to see the project get cancelled before delivery? How many times have you
seen a potentially reusable asset be built but never actually be used in
practice? How many times have you seen an asset be built and then reused, only
to discover that the reuse consumers only needed a small portion of that asset?
The bottom line is that when you build something to be reused before you have
clear evidence of actual need, you run the risk of wasting resources by
overbuilding: in the vast majority of cases, you are better advised to build
something for specific use and then generalize it for reuse when you actually
When it comes to building something to be reusable, four basic options are
available to you:
- Architected reuse. You develop assets called out by your
- Single-use-build. You highly suspect that a specific asset will
be needed by other teams, so you build it with reuse in mind.
- Public open source. You start a normal OSS project hoping that
others will do some "free work" for you.
- Internal open source. You host an OSS project within your private
intranet where only members of your organization are involved with the
An often-overlooked issue in reuse programs is how you'll evolve your robust
assets over time. When an asset is available for reuse, you will discover that
you need to evolve it to meet new requirements, to fix bugs, or simply to port
it to new platform versions. You need to consider three fundamental issues:
- Ownership. Who owns a reused asset? The original team that
built/bought it? The reuse team? The reuse consumer(s)? Ownership will help
determine who is responsible for evolving the asset.
- Configuration management. Two basic strategies are available to
you: insist that a single version of an asset be deployed into production,
or allow multiple versions to be deployed.
- Change management. The owners of an asset must put a change
management process in place to accept defect reports and new feature
requests applicable to the asset.
After you have obtained a robust asset, you need to make it available to
reuse consumers. If your robust assets are hard to find, then they likely won't
be reused. Your Reuse Registrar is responsible for maintaining and supporting
your reuse repository and registers the robust asset into your repository. The
role of the Reuse Registrar is typically filled by a senior staff member such as
the reuse manager, reuse engineer, enterprise architect, or project architect.
Your reuse repository could take several forms, such as a shared directory, a
version control tool, or a full-fledged reuse repository tool. Your registration procedure
will vary depending on the tool; our advice is to keep it as simple as possible.
After the robust asset is registered, the next step is to communicate, and
even actively market, its availability: it isn't enough to simply be able to
search for assets. This can be done via mailing lists or web pages, although our
experience is that word of mouth from successful project teams using the asset
is often the key to your success. Just as some things get done through
"official channels" and some get done through your informal network of contacts,
sometimes you find reusable assets by looking in the repository and sometimes
you get them from your friends. Your reuse engineers should become the people
that everyone trusts.
One of the activities of a reuse registrar is to retire older versions of
assets. As newer versions of assets are published into your reuse repository,
you must decide whether older versions should be removed because you can't
support everything. The retirement of a reusable asset can be as simple as
assigning it a "deprecation date", after which your team will no longer support
it, the implication being that anyone who continues working with the older
version is on their own because the reuse team can only do so much. The
retirement of an asset can also be as complicated as the retirement of a
full-fledged system: this is particularly true of large-scale assets such as
frameworks or common application architectures.
The primary goal of your reuse team is to support and enhance reuse within
your organization. To do this, you want to make it as easy as possible to reuse
the robust assets within your reuse repository. A critical success factor is to
be flexible; remember that each reuse consumer has his or her own unique needs
-- a Java developer will be interested in Java code and frameworks, a business
analyst in documentation templates and existing domain models, an architect in
candidate architectures, and a project manager in project plan templates.
An important part of a reuse engineer's job is to work with project teams to
modify an asset so that it can be reused effectively by them. Ideally this
modification is nothing more than configuring the asset properly. However, sometimes the asset needs to be evolved to
meet the needs of the team, which is the goal of the Evolve
There are several strategies for effectively supporting reuse within your
- Foster communities
- Adopt simple tools
- Adopt simple procedures to submit/develop/harvest/reuse assets
- Provide effective guidance
- Communicate with the project teams
- Reward a reuse mindset
- Get actively involved with the project teams
- Support the reuse repository
10. Measuring Reuse Programs
When you put your reuse program in place, you define your goals for it, such
as improving quality, reducing cost, and/or reducing time to market. It's very
easy to set these grandiose goals, but it's not so easy to prove that you've
achieved them in practice; any good senior management team will certainly want
evidence that their investment in your reuse program is effective. Your team
will also want to collect metrics to determine how effective their efforts are
so that they can redirect their energies accordingly. I suggest that you
consider collecting the following metrics:
- Net hours saved (asset metric). The net hours saved is the
estimated time to build the asset for single usage minus the time it takes
to reuse the robust asset (you need to find it, learn about it, deploy it,
and so on).
- Base asset cost (asset metric). This is the cost to obtain a
robust asset and make it available within your repository. It is calculated
by multiplying the time required by the full charge out rate for reuse
- Net asset benefit (asset metric). The summary of the net hours
saved across all instances of reuse minus the base asset cost.
- Total benefit (program metric). The total benefit of your reuse
program. It is calculated by summarizing the net asset benefits for all
robust assets obtained for potential reuse.
It is possible to reuse a wide range of assets, from source code to
templates to frameworks to entire architectures, but to succeed you need to
look beyond the scope of a single project. The Strategic Reuse discipline
describes how to increase the levels of reuse with disciplined agile projects by taking a
cross-system approach. To succeed, you need to plan for, operate, and
monitor a reuse program within your organization. There are several ways to
obtain robust assets for potential reuse, including harvesting internal
assets, downloading or purchasing external assets, and developing assets
from scratch. Your reuse efforts must be supported; the easier you make it
to reuse things, the greater the chance that people will do so. You should
also measure the success of your efforts to ensure continual funding and
management support for your project.