Reuse engineering is an important, and arguably advanced, aspect of the Disciplined Agile toolkit. The challenge is that reuse engineering requires significant discipline and organizational maturity to be successful, hence we tend to run into far more talk about reuse than action. Having said that, many organizations have been very successful with reuse. The following diagram overviews the internal workflow of a reuse engineering team, capturing key activities (the blue bubbles) that the team performs. This blog posting explores what reuse engineers do in practice.
Let’s work through the primary activities performed by reuse engineers:
If your organization is serious about reuse engineering then they will explicitly fund a reuse engineering team and enable them to work in the manner that we’ve described here. For more information, you will find the article Reuse Engineering to be of value.
Reuse isn’t free. Without funding, either implicit or explicit, meaningful reuse simply doesn’t happen. In short, your approach to funding is a critical success factor for your reuse engineering strategy.
In this blog posting we explore several strategies for funding reuse within your organization. The funding strategies, from most to least desirable, are:
Table 1 compares and contrasts these funding strategies.
Table 1. Comparing the reuse funding strategies.
Combinations of these strategies can of course be implemented.
Agile 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 micro services, or the first few agile teams to write personas will develop a potentially reusable template. 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 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 or technique and discover if there is actually a need for the asset on other teams.
One of the key activities performed by a reuse engineering team is to harvest potentially reusable assets so that they may be generalized for reuse on other teams. There are five steps to the harvesting process:
There are four basic timing strategies for when to harvest an asset:
This posting, the latest in a series focused on a disciplined agile approach to reuse engineering, overviews the activities associated with it. The Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy. The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique. In this blog we present the goal diagram for the Reuse Engineering process blade and overview its process factors.
The following process goal diagram overviews the potential activities associated with disciplined agile reuse engineering.
The process factors that you need to consider for reuse engineering are:
An important philosophy for succeeding at reuse engineering in the information technology (IT) space is to understand that you have more than one option at your disposal. You can reuse source code, components, development artifacts, patterns, and templates. The following diagram summarizes the types, or categories, of reuse available to you. The left-hand arrow indicates the relative effectiveness of each category – pattern reuse is generally more productive than artifact and framework reuse for example. Similarly, the right hand arrow indicates the relative difficulty of succeeding at each type of reuse. Code and template reuse are relatively easy to achieve because you simply need to find the asset and work with it. Other forms of reuse become hard to achieve; with framework reuse you need to learn the toolkits, with pattern reuse you must learn when to (and when not to) apply various patterns, and with architected reuse you need an effective approach to enterprise architecture in place.
The reuse categories are:
You can address these reuse categories simultaneously. Framework reuse often locks you into the architecture of that framework, as well as the standards and guidelines used by the toolkit, but you can still take advantages of the other approaches to reuse in combination with framework reuse. Artifact and component reuse are the easiest places to start, with a little bit of research you can find reusable items quickly. However, if your organization doesn’t have a common development process that it follows you may get little benefit from templates. Pattern reuse is typically the domain of developers with good modeling skills and your enterprise architects should be publishing and providing pattern-oriented guidance to them.
It is important to note that although the diagram indicates that pattern reuse is generally more effective than artifact reuse you may discover that within your organization the opposite holds true. This may occur because you have a comprehensive collection of reusable artifacts in place, because your organization culture is conducive to artifact reuse, or simply because your developers have little experience with patterns.