King’s Cross Station, London.

Reusability is not Reuse

The concept of reusability is of foremost importance in any company nowadays. Its promotion is one of the principal means of obtaining ROI, which may be directly through straight reuse or indirectly by collateral factors, such as increased logic centralization, reduced gross “architectural size,” and infrastructure footprint, amongst others.

Although this might seem straightforward, many companies don’t have the governance and standards required to truly transform reusability into reuse. Without reuse, all the effort invested in increasing the reusability of a solution is translated into sunken costs and ultimately into leverage for taking traditional, tactical, and siloed strategies.

This article aims to provide guidance on differentiating reusability from reuse and provides recommendations to increase the conversion rate from one to the other, changing hopeful reuse into effective reuse.

What is Reusability?

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

Although it is a simple concept, it entails many complex considerations, such as Functional Context, Purpose, Agnosticism, and Compatibility.

Considering the definition above of reusability →

• If a solution is MORE reusable, it can be used in MORE distinctive Functional Contexts.
• If a solution is LESS reusable, it can be used in FEWER distinctive Functional Contexts.

Having in mind that each distinctive Functional Context has at least one clear purpose (*) as part of its definition, to an undetermined number of possible purposes, these two concepts remain associated as follows:

• If a solution is MORE reusable, it can be used to fulfill MORE purposes.
• If a solution is LESS reusable, it can be used to fulfill FEWER purposes.

(*) “Purpose” answers the question “What for?” while “Objective” correlates to the question “What?” Example: What does the pen do? It writes. One can write a poem, while someone else might use it to open a container. The purpose changes between contexts and instances, while the objective remains the same. An objective could be defined as the most primitive characteristic of a solution and as the most enduring relationship with the original problem that required it. That is why the objective of a particular solution may not be valid in every case the solution is applied, as the purpose may change in each application.

From this, we can conclude:

• The number of purposes a solution could fulfill is directly proportional to its reusability potential and vice-versa.

Following this line of thought, the question, “How can a solution be designed, in a way, it can be used to fulfill different purposes?” arises.

How to drive reusability

The number of purposes for which a solution could be employed does not (in almost every case) remain evident in the early stages of its definition. A new factor is introduced to guide the design of a solution towards increasing its reusability. That is if the resources for doing it effectively and responsibly are available (*).

(*) If something is edible, it doesn’t mean that it can feed any number of people; if someone would eventually eat it, or even if there are people who need to be fed in the first place. The same goes for solutions; one must balance many things before investing the extra effort in increasing the reusability of a solution, and not just the technical aspects of it.

The concept of agnosticism comes from Greek: “Without Knowledge.” The idea was mainly used in religion-driven philosophy, but in the last 60 years, the scientific community started using it as a compatibility qualifier.

• The more agnostic X is to Y, the more compatible X is with the category or group Y belongs to (*).

(*) This statement originates in the idea that the more something (generally speaking) “knows” the reason for its existence, the less effective it could become in situations in which its reason to be used differs from the one known beforehand. The concept relies on the presumption that when a solution is specially designed to comply with a predefined purpose, increasing how coupled it is to it; it becomes more effective and efficient in its fulfillment. Consequently, the same idea entails that adding behavior and features to increase its reusability could make it less effective or useless for its original purpose.

Examples:

• JAVA is agnostic to its underlying OS. JAVA is compatible with many different OSs.
• The hammer is agnostic to the nail it hits. The hammer is compatible with hitting different nails.
• The calculator is agnostic to any mathematical operation. The Calculator is compatible with many operations.

An ancillary result of this idea is that something cannot be defined simply as agnostic. Instead, it must be defined as agnostic to a distinct category of things. It is common to use the “agnostic” classifier indiscriminately, thus increasing the inherent scope of its applicability. Nevertheless, there is always an intrinsic understanding of which category of things the agnostic property is related to.

The purpose is to create a relationship between a problem and a solution. The more agnostic a solution is to a problem, the more agnostic it would be to any linking purpose. As the original problem cannot be changed, the design and definition of a solution are the remaining factors responsible for reaching the desired level of agnosticism while remaining applicable to the purpose that initially motivated its creation. The initial association between a solution and its original problem is the solution’s objective. Essentially, the objective is the first and foremost purpose for which a solution was made in its pure form (*).

(*) Generally speaking, a glass's objective is to hold liquids. No matter the various purposes one could have for it, that objective is known implicitly. The logical divergence between a solution objective and any particular purpose could be employed to measure how well that solution would fulfill 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 with other purposes.
• The MORE compatible a solution is to any purpose, the MORE likely it can fulfill it.

Taking all this into consideration, we can assert that:

The reusability potential of a solution is directly proportional to the agnosticism of its design. The more Agnostic, the more Reusable.

What is Reuse?

Reuse is the action of using a solution in a different functional context from the one for which it was initially designed (*).

(*) This definition may only be effectively used within the conceptual context of this article, and the same could be considered for the concept of reusability, as it could be broken by semantics. If something is used again, then it’s reused. Plain simple. Although this is semantically correct, it is not the actual reuse that companies could benefit more significantly. The definition chosen for this article does not allow us to define a solution as being reused when it is executed in the same functional context. Example: A glass wouldn’t be considered reused just because it was used to hold two different liquids.

With this description in mind, it is essential to notice the leading and most crucial difference between Reuse and Reusability:

• Reusability → “… the ability of a solution to be used …”
• Reuse → “…the action of using a solution …”

Reusability promotes and enables reuse, but it does not guarantee its execution.

Although it is the semantic difference between ability and action, it’s a core factor to consider since neglecting it leads to several negative implications of unquestioningly promoting reusability:

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 their complexity.

Every one of the implications above remains valid with or without truly reusing the solutions from that context. The main difference relies on the ROI and other collateral benefits expected from them, which 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 in the initiative, slowing it down, stalling it, or even accelerating its early termination.

From Reusability to Reuse

In this final section, some different approaches to promoting reuse from a reusable solution are presented. The scenarios used to support these approaches are of the most generic nature to increase their applicability and understandability.

Take into consideration the following scenario:

There is a person (John Doe) sitting in a room with a desk in front of him and a pen sitting on top. A second person enters the room and asks John, “Can you sign this document here?” John takes the pen, signs the document, and hands the paper to him. One hour later, a third person asks for John to sign a different document. After due revision, John complied.

John started playing with the desk drawers and found the personal seal his boss gave him when he took the job so he could quickly sign corporate papers. He smirked and left it visible on the desk.

With this in mind, compelling questions arise:

• Why didn’t John use the Seal in the first place?
• Did he know it was there?
• Could he have used it?
• Should he have used it?
• Would he have used it?

All these relate to the fundamental steps to drive reuse from reusable solutions and should be considered in the same order presented above. Next, each question is elaborated on, adding reasons for its validity, examples, problems entailed by them, and finally, proposed ways to solve them.

Did he know it was there?

“…He smirked and left it visible on the desk…”

Before arguing if it’s right, wrong, possible, or impossible to use something, one must know if it exists, where and how to find it, what it does, and how it can be used.

• If team members do not know there are reusable solutions already been made, they are not using them.
• If team members do not know where or how to search for reusable solutions, they are not doing it.
• If team members don’t clearly understand a reusable solution’s functional characteristics, they will not know if it would satisfy current requirements.
• If team members don’t know how to use or access a reusable solution, they most certainly won’t do so.

The proposed actions to resolve these issues are the following:

1. Standardize functional & technical documentation templates and where they should be formally placed.
2. Standardize the meta-data required to discover and understand different types of existing solutions models effectively.
3. Establish a Repository to upload the meta-data and execute queries against it. When needed, each record should give a link to its related standard documentation.
4. Establish a formal Discovery Process to search for existing solutions and analyze their applicability, employing the repository to do so.

These actions ensure the addition of a formal analysis process of the existing solutions within project lifecycles, the standardization of their metadata, and the tools required to make a helpful discovery process are in place.

There is no need to rely on any specific product or vendor offers. The repository could be represented with a well-made spreadsheet or custom-made database, which, in most scenarios, is the most cost-effective way to do so. The important thing is to correctly define the meta-data required for the discovery process and promote the execution of such a process within existing project lifecycles.

Could he have used it?

One of the most dangerous things to do within an initiative that actively promotes reusability amongst its solutions (service-oriented initiatives, for example) is disregarding the fact that those solutions may need to be prepared for the expected demand entailed by their reuse.

Although having demand is considered positive, meaning those solutions have been identified as candidates for reuse, it does not ensure that they can continuously work as expected while subjecting to more significant or different types of loads along their lifespan.

Although many of the methods detailed next might seem fundamental, they are mostly neglected:

• The definition of SLA Policies applied to each reusable solution. With a clear SLA, it can be known whether a new consumer could add a definite amount of load to a particular reusable solution or if the solution could comply with its requirements. This is an oversimplification of the different implications of not having an SLA. Still, in this case, having them not only helps avoid unexpected behavior from the solution but also increases the confidence of every consumer with access to it throughout their lifespan. The latter approach massively increases the odds of success of such initiatives, as it promotes additional political support towards its execution.
• The active Monitoring of each reusable solution load and performance to act proactively towards the growth or modification of its underlying infrastructure if needed. The approach relates primarily to the abovementioned SLA, the core thresholds considered within this process. Additionally, the monitoring of reusable solutions gives constant feedback towards the vitality of its SLAs in a way that verifies its validity and effectiveness throughout its lifespan and amongst different kinds of direct or contextual stress.
• The practical applications of Security Mechanisms to avoid unauthorized executions. Although this might seem an expected approach towards any solution, especially the ones accessible by consumers residing on a different network level or even outside the company, it is vital to allow the reuse of that solution only to authorized consumers. In this case, authorization entails the functional rights to do so and the reserved capacity for that solution for that single consumer. It is not only a matter of technical consideration but also of governance and management.
• The definition of Reuse Policies to drive the analysis required to know if a specific consumer can effectively use an existing reusable solution. As the last question explains, it differs from establishing a formal discovery process. The Reuse Policies occur once the reusable solution has been found and aim to balance the consumer’s needs versus the solution's capabilities and SLAs. Applying these policies should establish an explicit contract between each part to balance these effectively or determine that a consumer should not reuse that particular solution and should find another way to do whatever it was thought to be done with it.

These last four approaches determine that promoting reuse from a reusable solution is not just a matter of design or technical consideration. A reusable solution has measurable vitality, as it is a continuously and collectively available IT resource that needs to be taken care of, measured, evolved, and audited. Promoting reusability without taking care of what it entails for it to work appropriately and consistently is irresponsible and counter-productive.

Many of the required skills to do so cannot be found in one particular Role or, better said, should not be taken from one role alone. It entails the need for collaboration between multiple roles involved, in one way or the other, with these solutions. The political power to enforce rules and procedures to increase compliance with these terms on teams that make or use reusable solutions is also a core and fundamental requirement.

Should he have used it?

After all, it was “…given by its boss when he took the job, so he could…” use it. There is a vital concept there: “could.” John didn’t have the moral, professional, technical, or functional obligation to use the seal, so he relied on the tools at hand when he needed to execute the task from which its original purpose was defined.

These are reasons why qualified consumers may not use (reuse) potentially reusable solutions, more so if they do not need to comply with any policy that drives them to do so or restrictions that would force them to justify other means.

On the other hand, if those customers have policies and restrictions defined so reusable solutions are used when compatible with new requirements, they need to look for existing solutions every time they need to design new solutions for them.

These rules pertain, in one way or another, to all three fundamental components from which an enterprise can be divided: Methodology, Management, & Governance.

The Governance →

• Should define policies and restrictions that enforce the discovery of existing solutions before the definition of new ones
• Should name actors and roles specialized in supporting the execution of these policies
• Should establish governance processes that aim to relate those roles and policies within predefined task flows
• Should introduce governance metrics to estimate and measure reuse, amongst others, adequately.

The extent and scope the government would have regarding this matter depend entirely on the enterprise governance scheme and cultural attributions.

The Methodology →

• Should add stages to IT Solution Life-Cycle processes to look after existing solutions that could be reused in each case.

The place where these stages should be inserted within the lifecycle may vary according to each enterprise methodology. However, as a common denominator, at least one of these stages should be inserted before the solution design takes place.

The Management →

• It should provide the means for auditing and executing the related processes, policies, and restrictions defined by the Governance and Methodology, as well as defining new processes aimed to measure their effectiveness.

It is crucial to notice that “Should” is not the same as “Would,” and with this kind of enforcement, strong political support is needed to drive compliance.

If the story had gone “…given by its boss when he took the job, to sign the papers with it…” it’s probable that John would have searched for that seal when he needed to sign those papers.

The most crucial problem found while fostering reuse profoundly influences these suggestions: Organizational Cultural Resistance. It increases the difficulties associated with every action mentioned above. The concept is further explained in the question “Would,” which is the last step in driving concrete reuse.

Would he have used it?

Why would John not use the Seal if its predetermined and explicitly communicated purpose was to”… sign corporative papers with ease…”?

Assuming that these three considerations are true

1. It exists
2. It can be used
3. It should be used

What factors could still prevent a reusable solution from being reused?

This question remains the farthest from technical or architectural considerations but one of the hardest to work on.

To do something, it is a matter of choice. John could choose not to use the seal, and no policy, restriction, process, or tool could change that decision. It is a personal and sometimes passional decision. However, these assertions do not only pertain to the context of this article but to a constant number of initiatives that change enterprise methodology, management, and governance: Organizational Cultural Resistance.

Promoting reusability does not only change the definition and design of solutions. When an initial investment is made to increase the reusability of a particular solution, the governance and ownership of that solution may be determined differently from traditional project-funded solutions.

A solution may not be wholly owned and governed by the project (and its managers) that initially required it or even those who worked on its implementation. Instead, it can be installed as an enterprise resource (another strategy for increasing reusable potential). Thus, its funding, governance, management, maintenance, and underlying infrastructure would fall under a different administration.

The statement above exemplifies a significant component of the cultural resistance in the following ways:

• Reduced freedom in analysis, design & development procedures.

Analysts, Architects, and Developers have less liberty to apply their criteria to new requirements that may use existing reusable solutions, as they don’t need to work on them (ideally). This means less work, time, and costs associated with that requirement. Still, at the same time, they are considering many possibilities on which they might think they are being replaced, their job is being taken, or their abilities are underrated.

Reduced ownership and political power.

It relates to each company's internal social, economic, and political structure as it relates to professional drive and insecurity projected on those levels. When a department or business line owns a critical solution for the company, it automatically gains leverage. When an enterprise initiative drives reuse (which, in most cases, is a single part of an elaborate goal scheme) and threatens to take that leverage away, a strong opposition is usually brought in place.

Many cultural considerations must be considered; these are just the ones that mainly affect the reuse of already-made reusable solutions. Other considerations affect how to drive reusability (which would have to be taken before), but that is not the focus of this article.

Nontechnical factors must be considered before and during the promotion of reusability and reuse. Next, some fundamental guidelines for treating these considerations are described.

• A healthy Educational Promotion and Knowledge Common Ground should be set to increase understanding of the technologies, methodologies, goals, and considerations. Knowledge is required as actions require strong teamwork and effective communication, in which a common language is necessary to transmit and understand a single piece of information in the same way. An entailed (but in no way less important) effect of robust educational promotion is the reduction of cultural resistance brought by fear of the unknown and the misunderstanding of the consequences and their effects.
• Promoting Multidisciplinary Teamwork and Cross-Department Collaboration reduces the logical distance between the different roles involved in the initiative, reduces bureaucracy, increases the trust between parties, and discourages non-positive competition (some “healthy” competitions drive improvement). The difficulty and effort required to make these steps effective depend on each company's organizational structure, governance, methodology, management, geographical distribution, communicational frameworks, and maturity. It must be taken before expecting any cultural resistance, as it gets challenging to succeed once resentment, mistrust, and other harmful ideas and emotions occur amongst the different people involved.

Any of these factors must be applied before problems and implications arise. These are the first considerations when considering the execution of an enterprise initiative that might provoke cultural resistance, require the redistribution of ownership, and require complex and more substantial cooperation and teamwork.

More so, the execution of preliminary processes like these can give a clear insight into how effective an initiative would be at a certain point in time, as they could act as an assessment to decide whether to do it, wait, change its scope, or even terminate it.

Conclusion

Promoting reusability is just one of the considerations required to drive effective and constant reuse.

Defining and implementing that framework is not a standardized “out-of-the-box” solution that can be immediately incorporated into a company or bought like a product or tool. It entails a profound transformation that ranges from low-level technical factors to high-level political concerns that could (and often do) reshape a company's structure.

The effectiveness of defining the extent and effort applied to initiatives of this kind measures the maturity of the company in “knowing itself,” to know its limitations, political characteristics, people, economic and funding models, and how all of them relate and depend on each other.

Not all companies have the maturity level to succeed in initiatives of this kind, but that should not be taken as a final determination. If those initiatives have been thought to be applied for particular reasons, the enterprise should work on increasing its maturity to a point at which it feels confident to execute them successfully.

Then again, as a final thought, promoting reusability and reuse should not be considered an “all or nothing” concept. Taking care of the small things that make the required framework work helps to increase the enterprise's maturity and sharpen the tools needed once a full-fledged initiative takes place. These may be installing a registry and changing the way solutions are designed.

The last paragraph was intentionally placed at the end of the article because of its message depicting a double-sided blade. Most companies expect these “small things” to provide all the benefits expected from a reuse-driven initiative without considering the concepts presented here. Finally, When those benefits are not delivered, the initiative that never formally existed failed before even starting.

As a final note, this article was originally written years ago, when microservices were starting to be the next-gen distributed architectures and traditional SOA-like architectures were still going strong. Regardless, most concepts here relate inherently to how reuse and reusability are involved with any architecture. I hope the ideas presented here help others to think around them further and avoid many of the negative implications that I’ve tried to introduce.