Reuse Engineering: A Goal-Driven Approach

 

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:

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.

Related Postings

• Reuse Engineering 101
• What can you reuse on agile development teams?
• Disciplined Agile Reuse: Funding Strategies
• Disciplined Agile Reuse: Harvesting potentially reusable assets
• Disciplined Agile Reuse Engineering Teams (coming soon)
• Reuse Engineering: External Workflow (coming soon)