Reusability is frequently promoted as a best practice in architecture. The logic seems obvious: build something once and use it many times. In theory, this reduces effort, improves consistency, and accelerates future delivery.

 

In practice, however, reusability is more complicated.

 

Throughout my ServiceNow career, I have seen organisations invest significant effort creating highly reusable frameworks, integrations, and configuration structures that ultimately see very limited adoption. The problem is not that reusability is flawed. The problem is that future use cases are often assumed rather than validated.

 

Creating a reusable solution introduces additional complexity. Developers need to accommodate multiple scenarios. Configuration options increase. Documentation requirements expand. Testing becomes more extensive. As a result, the solution often becomes more complex than the original requirement justified.

 

Good architects evaluate reusability pragmatically. They distinguish between proven enterprise capabilities that are likely to be reused and speculative capabilities that may never be needed again.

 

This does not mean reusability should be avoided. Shared integrations, common data models, platform utilities, and standardised services can deliver enormous value. However, reuse should emerge from genuine organisational needs rather than theoretical possibilities.

 

Every reusable component introduces a long-term ownership responsibility. Someone must maintain it, support it, and govern future changes.

 

Successful architects understand that the goal is not maximum reuse. The goal is appropriate reuse. Sometimes the simplest solution for a specific requirement creates more value than investing heavily in a framework designed for an uncertain future.