Know the Difference: Reusability vs. Reuse

The concept of reusability is of foremost importance within any Enterprise-wide IT Initiative. Its promotion is one of the principal means from which ROI is obtained, whether it is through direct re-use or indirect collateral factors such as increased logic centralization, reduced gross "architectural size" and infrastructure footprint, among others.

Although this might seem like a straightforward concept, many Enterprises have neither the governance nor standards required to truly transform reusability into reuse. Without governance and standards, all the effort put into increasing the reusability potential of a software solution is translated into sunken costs and ultimately leverage for taking traditional, tactical, and siloed solution endeavors.

This article aims to give guidance on differentiating reusability from reuse. It will recommend approaches and things to consider to ease the transition from one to the other, with aim on changing hope-driven reuse into proactive reuse.

Reusability and reuse within a single application are not usually costly endeavors. They come with a specific complexity from which no important or profound benefit to the whole enterprise (or a significant segment of one) is commonly attained.

This article will assume that both concepts are being considered within the scope of Enterprise IT initiatives, as mentioned earlier. These initiatives may involve several parts of an enterprise and not represent a single application or discrete application cluster.

That being said, several concepts and definitions within the article can be used in either case; but the scope, benefits, and implications related to each one of them are going to be considered in the wider scope described earlier.

What is Reusability?

Reusability is a concept taken from the ability of something to be used more than once and in different functional contexts than those for which it was initially designed for.

It is a simple concept that, when used within IT Initiatives, entails multiple, complex considerations and approaches. Many of these considerations relate to core concepts such as: functional context, purpose, agnosticism, and compatibility.

In the following paragraphs, all will be explained with the aim of increasing understanding of reusability and each concept's relation to it.

Considering the aforementioned definition of Reusability:

If X is MORE reusable > X can be used in MORE distinctive Functional Contexts.

If X is LESS reusable > X can be used in LESS distinctive Functional Contexts.

Keeping in mind that each distinct functional context has from one clear purpose* associated with its definition to many or an undetermined number of possible purposes, these two concepts can be finally related as the following:

*A purpose answers the question "what for?" whilst an objective relates to the question "what?" For example: what does the pen do? It writes; one might use it to write a poem while someone else might use it to stir coffee. The purpose changes between contexts and instances while the objective remains the same. The objective may be defined as the most primitive characteristic of a solution and the closest relative of the original problem that required it. For this reason, the objective of a particular solution may not be valid in every case where the solution is applied, for the purpose could completely change in each application.

If X is MORE reusable > X can be used to fulfill MORE purposes.

If X is LESS reusable > X can be used to fulfill LESS purposes.

From this, we can conclude:

• The amount of purposes a solution could be used to fulfill is directly proportional to its reusability potential.
• The reusability potential of a solution is directly proportional to the amount of purposes it's able to fulfill.

Following this line of thought, the question "How can a solution be designed in a way that it can be used to fulfill multiple purposes?" remains unanswered. The amount of purposes on which it could be used will not (in almost every case) remain clear during the early stages of its definition. A new factor should then be introduced to guide the solution's design towards increasing its reusability in case it is required and the resources for doing it effectively and responsible are available.**

** If something is comestible, it doesn't mean that it will feed any Qt. of people per ration if someone would eventually eat it or even if there are actually people who need to be fed. The same goes with IT solutions that balance several things other than design factors before deciding on the application of additional effort entailed by increasing reusability potential.

The concept of "agnosticism" will be introduced as the aforementioned factor. Agnosticism comes from Greek, and it literally means "without knowledge". The concept was mainly used for religion-driven philosophy, but in the last 50 years the scientific community has started to use it as a qualifier of compatibility:

The more agnostic X is to Y, the more compatible X is to the category or group to which Y belongs ***.

*** This statement has its origin from the idea on which the more something (generally speaking) "knows" the reason for its existence (answering the question "what for?" hence telling its purpose), the less useful could become on situations in which its reason to be used may be different from the one known beforehand. This relies on the presumption in which a solution is then specially designed as to comply with its known purpose, increasing the coupling to it, and becoming more effective in its fulfillment. This approach would entail adding details and features to the solution that could make it less effective or even useless in different functional contexts.

Examples:

• JAVA is agnostic to its underlying OS. > JAVA is compatible for usage on different OS's.
• This hammer is agnostic to the nail it hits. > This hammer is effective at hitting different nails.
• This calculator is agnostic to any equation. > This calculator is compatible to multiple equations.

A collateral consequence of this definition is that nothing can be defined as solely agnostic. It must be defined as agnostic to a particular category of things. This is not the most common case within IT initiatives, in which the modifier "agnostic" is used alone for simplicity's sake or even to increase the scope of its applicability. There is always an implicit accord with this, and there is usually no doubt about to which category of things that attribution is being related.

The purpose is what relates a problem to its solution. The more agnostic a solution is to its problem, the more agnostic it is to its linking purpose. The original problem cannot be changed but can only be replaced; therefore, the design and definition of its solution are responsible for the increasing the level of agnosticism associated with its purpose. They must at the same time remain effective for the problem that initially connected them. This last attribution is represented by the solution's objective which maintains the descriptive information required to understand the first or original purposes that solution was intended to fulfill.*

*A glass will always be considered to have been made to hold liquids. Despite the number of purposes that could be given to it, its objective will be maintained until is no longer contextually meaningful. This means that the objective remains implicit, for it should be interpreted from the original solution's context, known by that solution's owner. It makes a clear distinction between the original and/or fundamental purpose of a solution and all those following. The logical distance and the particular contextual differences between a solution objective and a particular purpose given to it are a measure of how effective that solution is at fulfilling that purpose.

• The MORE agnostic the design of a solution, the MORE agnostic the solution is to its initial purpose.
• The MORE agnostic a solution is to its initial purpose, the MORE compatible it is to other purposes.
• The MORE compatible a solution is to any purpose, the MORE likely it is that that solution will be able to fulfill those purposes.

Taking all this into consideration, we can assert that:

• The reusability potential of a solution is directly proportional to the agnosticism of its design.

In conclusion: The more agnostic, the more reusable.

What is Reuse?

Reuse is the action of using something more than once, in a different functional context from the one for which it was initially designed.

*This definition may not be effectively used outside the conceptual context of this article. The same could be considered for the aforementioned concept of reusability because it is broken down by semantics. If something is used for a second time, it is reused. Plain and simple. Although this is semantically correct, it is not true reuse from which IT initiatives benefit the most. The definition chosen for this article does not allow a solution to be defined as something that has been reused if it is executed in the same functional context. For example, a glass wouldn't be considered reused if it were used simply to hold two different liquids.

With this description in mind, it is important to notice the main and most important difference between the words reuse and reusability:

Reusability: "... the ability of something to be used more than once ..."

Reuse: "... the action of using something more than once ..."

The difference is simple:

Reusability promotes and enables reuse but does not ensure it.

This semantic difference between ability and action is a key factor to consider within Enterprise IT Initiatives. The consequences of blindly promoting reusability are negative:

Analysis & design overhead

• Increased participation of Users and Business Analysts.
• Increased complexity of IT solutions.
• Increased platform and infrastructure requirements.
• Increased costs and implementation times.

Governance complexity

• Increased bureaucracy and cultural resistance
• Increased IT solution life-cycle length and complexity.
• Increased requirement of management tools.
• Increased SCM & CM processes and complexity.

Every single one of the aforementioned implications remains true with or without truly reusing the solutions made from that context. The main difference relies on the ROI and other collateral benefits expected from them and should balance the equation when concrete reuse has taken place.

On the other hand, if concrete reuse is not promoted and applied, all those negative implications remain as sunken costs and reduced trust for the initiative. This in turn may slow down and stall that initiative and even drive it to early termination.This in turn may slow down and stall a system and even drive it to early termination.

This article will continue in Part II.

- Part I Published: September 20, 2015 • Service Technology Magazine Issue XCII

Imagen: Luis Zafra, Creative Commons.