On Reuse

As long as I have been in IT - since I coded my first subroutine library 35 years ago - the debate on reuse has been ongoing. At times, it has seemed like a ‘Holy Grail’ for software delivery and like the Holy Grail it also seems to give rise to endless opportunities to debate whether it is exists or not, if it is good or bad, or even what it actually is.

Now entering into another, I thought it worth putting down some observations [1].

Why Reuse?

I am not going to enter into a long discussion about the economics of reuse. Enough has already been written on that.  I see three simple reasons to consider reuse. Every justification to reuse or not boils down eventually to one of more of the following,

1. Productivity. Improve productivity by reusing what has already been developed and tested.
2. Consistency. Improve consistency of process and information by ensuring that common functions are always performed in the same way
3.  Best Practice. Improve the execution of common activities by codifying best practice and algorithms.

Of course all manner of politics and personal bias come into decision making process, but that is a cultural issue, and enough has already been written on that too.

Forms of Reuse 

The assumption is normally that the debate is about software reuse. Ultimately it is, in that the end product of what is being reused is a software artifact. But there are many points in the SDLC at which reuse may occur, and there are many forms in which reuse may take place. For example;

•  Software Reuse. A unit of software is reused. There are many ways this can be achieved, which doesn’t always involve copying. Instances might be duplicated, or an instance might be shared somehow, but either way developers are aware of the software they are reusing.
• Service-based Reuse. Software is ultimately reused, but only via its service interface which helps to decouple the consumer from the provider, and better encapsulates the software being reused. Developers are less aware of the software they are reusing, and should only be aware of the service that encapsulates it.
• Specification or Model Reuse. The specification is reused, but different instances of software are produced from it. Providing the transformation is correct in each instance, this enables consistency but would allow delivery in different technologies for example
• Pattern-based Reuse. A higher form of abstraction, but a common form of ‘reuse’. More a way of reusing knowledge or ‘best practice’ than software itself.
• Architecture or Blueprint Reuse. Similarly, an architecture may establish a blueprint that is reused

So a key task is to determine what form of use is most appropriate to achieve the intended goal.

Scope of Reuse 

Establishing the intended scope of reuse of some asset is also key. Often for example, people attempt to reuse of an asset on an ‘enterprise’ basis whereas there is not actually an enterprise-wide requirement. Consequently trying to then ‘force’ the asset on projects (in order to realize the ROI for its development) only leads to conflict.

Rather, the scope of reuse should be set at an appropriate level and the investment in its delivery commensurate with that. The scope could be,

• For an enterprise, establishing its reuse boundaries
• Global. Or enterprise-wide.
• Common. Or domain or division wide, or for a product line.
• Local. Or project, product or business unit wide.
• For an Industry, or domain. More applicable to standards organizations, and to commercial software vendors or service providers
• Ecosystem. Intended to be reused or shared by many ecosystem participants

Where to Reuse  

Besides the issue of scope, clearly not everything needs to be built with reuse in mind. Hence there needs to be additional means by which you can distinguish reusable assets from the non-reusable. For example, using a layered architecture as a way of classifying assets into different layers and then facilitating reuse in and between appropriate layers.

For example, separate assets into different types based on

• Rate of Change. Things that are more stable in nature are better candidates for reuse than those that frequently change. I would like to thank my friend and colleague Richard Veryard for introducing me to the concept of ‘Shearing Layers’ as a valuable construct in IT architecture
• Core or Context. As well as stable vs unstable, you might also classify assets using core or context analysis [2], where context would be most suitable for reuse.
• Separation of Concerns. The traditional separation of presentation, process and data also helps to determine reuse.  Data assets can be reused in many processes. Processes (or parts of) can be reused in many solutions. Utilities can be reused everywhere.

One of the above classifications may not be sufficient to determine whether an asset should be reusable or not, but used together, along with scope, they can certainly help to narrow down whether or not an asset should delivered with reuse in mind.

Designing for Reuse 

Having determined that an asset should be reusable, it is essential that it should be designed for reuse. A full discussion is beyond the scope of this short note, but key factors will be

• Granularity. Finer grained, tightly focused assets will more likely to be reusable in a wider spectrum of different contexts. However, that doesn’t mean that coarse-grained software deliverables are not widely reused in term of the number of instances deployed. Rather, that they are less likely to be reused in different contexts to the one for which they were originally designed.
• Generalization. The more generalized an asset it, the broader applicability it will have
• Configuration. The greater number of ways an asset can be configured to suit different purposes will make it more reusable in different solutions.

Summary  

I am not suggesting these are the only ways by which to determine reuse. More, it a suggestion that only by developing such a framework within your organization can you make rational reuse decisions, and perhaps more importantly govern reuse with effective policies that codify such rules.

[1] I have documented much of this before, but it is mainly behind our pay-wall.

[2] Dealing with Darwin. Geoffrey A. Moore. 2005 http://www.dealingwithdarwin.com/index.php