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.
Reuse types

Figure 1. Potential reuse types.

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.


Related Reading