Reuse Engineering


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?

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:

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

Reuse Terminology

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.


What is Potentially Reusable?

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.

Figure 1. Potential reuse types.

Reuse types

The reuse categories are:

  • Architected Reuse. The identification, development, and support of large-scale, reusable assets via enterprise architecture. Your enterprise architecture may define reusable domain components, collections of related domain/business classes that work together to support a cohesive set of responsibilities, or service domains which bundle a cohesive collection of services together.
  • Pattern Reuse. The use of documented approaches to solving common problems within a specified context. With pattern reuse you’re not reusing code, instead you are reusing the thinking that goes behind the code. Patterns can be a multiple levels – analysis, design, and architecture are the most common. Ward Cunningham’s site is a useful source of patterns on the web.
  • Framework Reuse. The use of collections of classes that together implement the basic functionality of a common technical or business domain. Horizontal frameworks, such as a security framework or user interface frameworks such as the Kendo or QuickUI. Vertical frameworks, such as a financial services framework, are common in some domains.
  • Artifact Reuse. The use of previously created development artifacts – use cases, standards documents, domain-specific models, procedures and guidelines, and even other applications such as a commercial off the shelf (COTS) package – to give you a kick start on a new project. Sometimes you take the artifact as is and other times you simply use it as an example to give you an idea about how to proceed.
  • Component Reuse. The use of pre-built, fully encapsulated “components” in the development of your solution. In this case a component is self sufficient and encapsulates only one concept. Component reuse differs from code reuse in that developers don’t have access to the source code.
  • Template Reuse. This is the practice of using a common set of layouts for development artifacts such as vision documents, training slide decks, or system overview wiki pages within your organization.
  • Code Reuse. The reuse of source code within sections of an application and potentially across multiple applications. At its best code reuse is accomplished through the sharing of common classes and/or collections of functions and procedures. At its worst code reuse is accomplished by copying, pasting, and then modifying existing code which adds to your organization’s technical debt and can potentially result in negative overall value.

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.

The Reuse Engineering Process

The following process goal diagram overviews the potential activities associated with disciplined agile reuse engineering.

Figure 2. The Reuse Engineering process goal diagram.

Goal - IT - Reuse Engineering 

The process factors that you need to consider for reuse engineering are:

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

The following diagram overviews the major workflows that a disciplined agile reuse engineering team is associated with. Note that feedback is implied in the diagram. For example, where you see the Technology Roadmap flow from Enterprise Architecture to Reuse Engineering there is an implied feedback loop from the reuse engineers to the enterprise architects. Also note that the workflows do not necessarily imply that artifacts exist. For example, the guidance workflow from IT Governance could be a conversation with a governance person, it could be a concise description of organizational standards, or it could be a combination of the two.

Figure 3. The external workflow of reuse engineering.

External workflow of a reuse engineering team

The following table summarizes the workflows depicted in the diagram.

Process Blade Process Blade Overview Workflow with Reuse Engineering
Continuous Improvement Addresses how to support process and organizational structure improvement across teams in a lightweight, collaborative manner; how to support improvement experiments within teams; and how to govern process improvement with your IT department.  
Enterprise architecture Addresses strategies for collaborative and evolutionary exploration, potential modelling, and support of an organization’s architectural ecosystem in a context-sensitive manner. The enterprise architects will produce a technology roadmap that delivery teams should follow and be a good source of development guidance (such as programming guidelines, user interface conventions, security guidelines, and so on). Delivery teams will provide development intelligence (metrics) and feedback pertaining to the usage of key architectural components and frameworks to help inform the decisions of the enterprise architects.
Solution Delivery Addresses how to develop solutions in a disciplined agile manner. This includes the four lifecycles – basis/agile, advanced/lean, continuous delivery, and exploratory – supported but DAD plus the program management blade (effectively a large team following one or more of the lifecycles).  
IT Governance Addresses strategies for consolidating various governance views, defining metrics, taking measurements, monitoring and reporting on measurements, developing and capturing guidance, defining roles and responsibilities, sharing knowledge within your organization, managing IT risk, and coordinating the various governance efforts (including EA governance). The IT governance team will provide guidance to all IT teams, including large delivery teams. This guidance typically focused on financial and quality goals as well as any regulatory constraints where appropriate. Delivery teams will provide development intelligence to the IT governance team to enable them to monitor your team and provide informed guidance to it.
Operations Addresses how to run systems, evolve the IT infrastructure, manage change within the operational ecosystem, mitigate disasters, and govern IT operations. Your operations group will provide operations intelligence (metrics) to IT delivery teams, in particular around the usage of systems and features that a team is responsible for. This enables the IT delivery teams to make informed decisions regarding the value of delivered features.
Portfolio Management Addresses how to identify potential business value that could be supported by IT endeavors, explore those potential endeavors to understand them in greater detail, prioritize those potential endeavours, initiate the endeavours, manage vendors, and govern the IT portfolio. Your organization’s portfolio management activities will provide the initial vision and funding required to initiate a program, as well as ongoing funding for the program. It will also provide guidance, often around management and governance conventions, to the team. IT delivery teams will make their development intelligence (metrics) available to the portfolio management team to help inform their decisions.
Product Management Addresses strategies for managing a product, including allocating features to a product, evolving the business vision for a product, managing functional dependencies, and marketing the product line. The Product Management team will provide a business roadmap and stakeholder priorities to all IT delivery teams, including programs.


Workflow Within a Reuse Engineering Team

Figure 4 overviews the internal workflow performed by a reuse engineering team. A lot, but not all, of their work is focused on working with and supporting delivery teams.

Figure 4. The internal workflow of a reuse engineering team.

Goal - IT - Reuse Engineering Internal Workflow

Let’s work through the primary activities performed by a reuse engineering team:

  1. Guide teams in reuse. An important activity for reuse engineers is to provide guidance to delivery teams regarding what is available for reuse, how to go about accessing and applying the reusable artifacts, and educating teams in why reuse is important to both the team and to your organization. Very often a team’s architecture owner will collaborate with the reuse engineering team to bring a reuse engineer into the team at the right time.
  2. Obtain assets. Reuse engineers will obtain reusable assets from a variety of sources, including from the marketplace and from internal delivery teams. Based on the various organizational roadmaps, and the needs of the delivery teams that they’re working with, the reuse engineering team will often work with delivery teams to identify and obtain the appropriate assets from the marketplace. The goal is to find assets that fit the needs of individual teams in a way that aligns with the direction of the organization. Furthermore, reuse engineers tend to monitor what delivery teams are doing, often by working closely with the organization’s enterprise architecture team and the architecture owners on delivery teams, to help them identify potentially reusable assets. When a team believes it has built something that is potentially reusable by others, or when the reuse engineers believe they have done so, then the reuse engineers will work with the team to understand and harvest that asset.
  3. Publish reusable assets. An asset is potentially reusable when it is of high quality, it is appropriately documented, one or more examples exist of how to use it, and it is findable by others. The publishing process ensures that all of these criteria are true. The reuse engineers will do the work to publish the asset, refactoring and documenting it as needed and harvesting any usage examples if available (and creating some when not). After doing so, they will save the asset and its related supporting artifacts into your organization’s reuse repository, announcing the availability of the new asset after doing so. Note that reuse repositories, also called asset managers, have fallen out of favor in the past few years due to the complexity of the available products on the market and the propensity of organizations to use products like Git or Microsoft SharePoint as repositories.
  4. Configure asset for specific use. Reuse engineers will often work with a team to help them to configure an asset for specific use. The goal is to make it as easy as possible for others to reuse existing assets, thereby increasing the chance of rate of successful reuse within your organization.
  5. Integrate reusable assets into a solution. Reuse engineers will often work with delivery teams to integrate a reusable asset into their solution, once again to make it as easy as possible for teams to reuse existing assets. Interestingly, an important aspect of harvesting an asset for reuse is to help the source team to integrate the improved version of the asset back into their solution. This helps to increase the likelihood that teams will offer up potential assets for harvesting and publishing.
  6. Evolve reusable assets. Assets need to evolve over time to reflect changing requirements and implementation technologies. The implication is that the owners of the assets, often the reuse engineering team, will need to evolve their assets, publish new versions, and deprecate old versions. This is work that must be funded and supported properly.


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:

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

Strategy Advantages Disadvantages Considerations
Funded reuse engineering team
  • Reuse is actively supported across all IT
  • Long-term support activities, such as evolution of assets and reuse repository, are directly funded
  • Cost of reuse engineering is easily measured
  • Value provided by reuse engineering team must be measured to justify continued, year-over-year funding
  • Reuse engineering team becomes a target for financial cuts because the cost is easily measured but the value provided is difficult to measure
  • Supports a robust, organization-wide, reuse engineering strategy
  • Significant discipline required: IT executives must understand and be prepared to execute an explicit reuse engineering team strategy
Asset-level funding
  • Development of potentially reusable assets are funded in a targeted manner
  • Cost of individual assets easily measured
  • Typically used for initial development of an asset, but long-term support and enhancement is often neglected
  • Can result in development of similar assets by disparate teams
  • Useful first-step towards the funding of a reuse-engineering team
  • Can be made to work in organizations with a project-based IT funding, although long-term support and enhancement of the asset can be a struggle in such situations
Development team based funding
  • Development of potentially reusable assets are funded
  • Difficult to fund ongoing enhancement and support of your reusable assets with this strategy, unless the team is stable over the long term and willing to support the assets that they create
  • Funds earmarked for reuse often diverted for development of non-reuable functionality
  • Many “potentially reusable assets” are created yet few are reused by other teams due to lack of infrastructure to support wide-scale reuse
  • This strategy may be your only option in IT departments with strict project-based IT funding
No explicit funding
  • Some delivery teams, particularly very disciplined ones, will still choose to have high levels of reuse even when no organizational support is provided
  • Reuse will be inconsistent at the organization level
  • The only way reuse will happen in this situation is through the maturity and enterprise awareness of the delivery teams
Chargeback funding
  • Potential exists to fund ongoing support and enhancement of reusable assets
  • Development teams are punished for reusing assets, motivating them to create their own versions
  • Complexity of chargeback added to overall organizational bureaucracy, effectively adding waste to your IT processes
  • Chargeback strategies will undermine if not destroy your reuse engineering endeavour
  • There is no situation where we would recommend this strategy

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:

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