Strategic Reuse: Enterprise Unified Process

Table of Contents

1. Overview
2. Planning your reuse program
3. Harvesting existing assets
4. Obtaining external assets
5. Developing assets
6. Evolving assets
7. Publishing an asset
8. Retiring an asset
9. Supporting project teams
10. Measuring reuse programs
11. Summary
12. Translations

1. Overview of Strategic Reuse

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 more than 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. The detailed amalgamated 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. Strategic Reuse: 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 gain.

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 failbecause 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:

• 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 easily track?
• Growth strategy. How will you handle your program’s success?

3. Strategic Reuse: Harvesting Existing Assets

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 besomething 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.

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:

1. Harvest in-progress. You generalize an asset developed by a team before it has been released by working closely with the team.
2. Harvest at project end. You wait until the team has finished building the asset, and then you generalize and perhaps even redeploy it afterwards.
3. 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 asset.
4. 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. Strategic Reuse: 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
persistence framework, 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.

5. Strategic Reuse: Developing Assets

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 need it.

When it comes to building something to be reusable, four basic options are available to you:

1. Architected reuse. You develop assets called out by your enterprise architecture.
2. Single-use-build. You highly suspect that a specific asset will be needed by other teams, so you build it with reuse in mind.
3. Public open source. You start a normal OSS project hoping that others will do some “free work” for you.
4. Internal open source. You host an OSS project within your private intranet where only members of your organization are involved with the project.

6. Strategic Reuse: Evolving Assets

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:

1. 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.
2. 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.
3. 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.

7. Strategic Reuse: Publishing an 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.

8. Strategic Reuse: Retiring an Asset

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.

9. Strategic Reuse: Supporting Project Teams

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 Asset activity.

There are several strategies for effectively supporting reuse within your organization:

• 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. Strategic Reuse: 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 engineers.
• 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.

11. Summary

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.

12. Translations:

• Japanese

Recommended Reading

This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context. This book represents leading-edge thinking about enterprise agile, some of which originated in the EUP and RUP.

This book, The Enterprise Unified Process: Extending the Rational Unified Process, defines the Enterprise Unified Process® (EUP), which was first introduced by myself in 1999 and later enhanced to support a wider variety of clients. The EUP is an extension to the IBM Rational Unified Process (RUP).  The EUP extends the RUP to include the operation and support of a system after it is in production and its eventual retirement.  Furthermore, because all but the smallest organizations have more than one system, the EUP also handles cross-system enterprise issues such as portfolio management, enterprise architecture, and strategic reuse.