The Reuse Engineering process blade addresses the purposeful creation (or rescue), management, support, and governance of reusable assets. Reuse engineering is often led by your organization’s enterprise architecture team, although as you will see disciplined agile IT organizations will fund a specific reuse engineering team.
This article is organized into the following sections:
- Why reuse engineering?
- Reuse terminology
- The reuse engineering process
- Workflow with other IT teams
- Workflow within a reuse engineering team
- Funding reuse engineering
- Why is reuse engineering difficult?
Why Reuse Engineering?
The vast majority of developers, agile or otherwise, take an ad-hoc approach to reuse. Although this is a good start, we have the opportunity to do much better. There are several reasons why your organization should consider investing in explicit reuse engineering:
- Quicker time to market. The more reusable assets that a team has at its disposal then the less the team will have to build, thereby enabling them to release quicker.
- Improved return on investment (ROI). Reuse engineering enables IT delivery teams to avoid building something that your organization already has. This leads to greater ROI for your IT investment which in turn leads to greater value being delivered to your stakeholders.
- Improved consistency. When all of your systems use the same implementation of a service, or component, or function, or framework then that functionality by definition is implemented consistently across those systems. This makes them more predictable and easier to understand.
- Easier updates to common functionality. When functionality is implemented in one place and then reused where needed it is very easy to update that functionality and then deploy the updated version.
We use the following definitions for common reuse terminology:
- Asset. An artifact that is retained after its initial purpose is fulfilled. For example, working source code is an asset because it is retained and potentially updated in the future to address new stakeholder needs. A user story that is discarded once the functionality it describes is implemented is not considered an asset.
- Robust asset. An asset that is appropriately documented, generalized beyond the needs of a single team, thoroughly tested, is of high quality, 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.
- Reusable asset. A robust asset that has been used at least three separate times by at least three separate teams. 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.
- Ad-hoc reuse. An informal approach to reuse where individuals or teams reuse whatever they can find on their own. Ad-hoc reuse is often a good start.
- Engineered reuse. A formalized approach to reuse where an organization actively supports a reuse engineering strategy.
- Reuse engineering. The purposeful creation (or rescue), management, support, and governance of reusable assets.
The Reuse Engineering Process
The following process goal diagram overviews the potential activities associated with disciplined agile reuse engineering.
Figure 1. The Reuse Engineering process goal diagram.
The process factors that you need to consider for reuse engineering are:
- Obtain assets. There are several ways that you can obtain potentially reusable assets. The least effective is to try to build them to be reusable from the very beginning but this strategy often proves problematic in practice because it’s hard to predict what other teams will actually want and as a result you tend to overbuild the asset. A better approach is to obtain an asset from external sources, either free (as in the case of open source assets) or through purchase. In this case the assets are often both under and over built – some features you want are missing and many that you do not want are there. The most effective strategy, in general, is to harvest an existing asset that is already in use within your organization and to generalize it so that others will want to reuse it.
- Publish assets. An asset won’t be reused if people don’t know that it exists. When a new reusable asset is made available it must put into your organizational reuse repository, described appropriately, and announced to any interested parties.
- Support delivery teams. There are many ways for a reuse engineering team, if it exists, to support IT delivery teams. Training, educating, coaching, and mentoring team members in reuse are fairly straightforward to understand. Some of the more interesting strategies include working with a delivery team to configure and even integrate an asset into their work. Reuse engineers, often working with a team’s architecture owner, will identify potentially reusable assets that can be harvested and generalized for reuse.
- Evolve assets. Reusable assets, like all other assets, will need to be evolved over time. This includes any work required to generalize the asset to make it reusable, configuration management of the asset’s constituent parts, to update an existing asset to support its evolving purpose, to tailor an asset so that it can be reused in a new situation, and to eventually retire the asset when it is no longer needed.
- Fund reuse. There are several ways to fund your reuse engineering efforts. The least effective, and often debilitating, strategy is to put a chargeback strategy in place. The basic idea is that if someone reuses an asset then they should pay for it (some organizations will even charge a team for downloading something from their reuse repository, regardless of whether they use it or not). The problem with this approach is that it in effect punishes teams for reusing things, thereby motivating them to build things from scratch in the future. In some organizations it proves better to not fund the reuse effort at all, which typically results in ad-hoc reuse at best, than it is to put a chargeback scheme in place. The most effective approach that we’ve seen is to directly fund the reuse team, thereby taking cost considerations out of the equation when people choose to reuse an asset.
- Govern reuse. The reuse engineering effort, as with all other efforts, should be governed in a lightweight, collaborative manner. This is part of your overall IT governance efforts.
Workflow With Other IT Teams
This section is a work in progress.
Workflow Within the Reuse Engineering Team
This section is a work in progress.
How to Fund Reuse
Your approach to funding is a critical success factor for your reuse engineering strategy. As you saw in Figure 1, the funding strategies, from most to least desirable, are:
- Funded reuse-engineering team. A team of one or more people in the role of reuse engineer is provided explicit funding to support and enhance the reuse efforts within your IT department.
- Asset-level funding. Funding for a specific reusable asset, such as a security framework or collection of micro services, is explicitly budgeted for. This funding should cover the development, enhancement, and long-term support of the asset.
- Development team-based funding. Funding for the use, development, and enhancement of reusable assets is included in the budget for development teams. Such funding is often accompanied by mandates along the lines of “The team will achieve X% levels of reuse” (although teams are rarely measured against these mandates in practice).
- No explicit funding. With this approach reuse occurs on an ad-hoc basis within delivery teams, often driven by tactical decisions at the team level as opposed to strategic decisions at the organizational level.
- Chargeback funding. Delivery teams are charged for usage of an asset. In some extreme cases development teams are charged to download an asset from the reuse repository, typically because that’s easier to charge them at this point in time over charging for actual usage.
Table 1 compares and contrasts these funding strategies.
Table 1. Comparing the reuse funding strategies.
|Funded reuse engineering team||
|Development team based funding||
|No explicit funding||
Combinations of these strategies can of course be implemented.
Why is Reuse Engineering Difficult?
Unfortunately reuse is a lot easier to talk about than it is to implement in practice, at least beyond the ad-hoc level. There are several reasons why reuse engineering is difficult to achieve:
- There is a greater impact when reusable assets break. When an asset is used in only one place and it breaks, then the impact of that breakage is limited to that one place. When an asset is reused in dozens or hundreds of places, and it breaks, then the impact is significantly larger. This is reusable assets need to be of high quality.
- Teams must go beyond the reuse of source code. Reuse is often described as not “reinventing the wheel,” and an important step for succeeding at reuse is to understand that you have more than one option at your disposal. For example, in addition to source code you can reuse components, services, patterns, and templates to name a few. More on this in a future post.
- Reuse requires enterprise awareness on IT delivery teams. For reuse to succeed IT delivery teams must understand that reusable assets exist, how these assets fit into your overall IT ecosystem, and what the benefits of reusing them are for your organization. In Disciplined Agile we promote the philosophy that IT delivery teams should work closely with enterprise architects and reuse engineers, if any exist, so that they will better understand and appreciate these issues.
- Reuse requires investment. To get beyond ad-hoc reuse your organization will need to invest in a reuse program. This may include investment in a reuse engineering team, in a reuse repository, in the development/rescue of potentially reusable assets, and the long-term maintenance and support of those assets.
- Your approach to funding will make or break reuse. As you saw earlier, a critical success factor for reuse programs is your approach to funding it. We cannot say this enough: Chargeback schemes put your reuse program at risk.
Having said all of this, it is in fact possible for your organization to succeed at reuse and many companies do so. Follow the advice in this article and you will be well on your way.