Introduction
Ask any data architect what they’re optimizing for, and you’ll hear the same word:
Reusability.
Reusable entities.
Reusable dimensions.
Reusable canonical models.
And yet—many of the most reusable models are the least usable.
This isn’t because reuse is bad.
It’s because reuse is often misunderstood.
The Reuse Trap
Reusability is usually interpreted as:
- One model for many use cases
- One definition for all contexts
- One structure to rule them all
In practice, this leads to:
- Overloaded entities
- Vague attributes
- Endless conditional logic
- Confusing metrics
A model that tries to serve everyone usually serves no one well.
Reuse Without Purpose Creates Abstraction Debt
Abstract models feel elegant early on.
But abstraction debt accumulates when:
- Business rules differ slightly across domains
- Timing semantics aren’t the same
- Aggregation logic changes by audience
- Regulatory requirements diverge
Each “small exception” chips away at trust.
Eventually, the reusable model becomes a liability.
Reusability Is Not the Same as Standardization
This is the most common mistake.
Standardization means:
- Shared definitions
- Consistent naming
- Agreed semantics
Reusability means:
- Shared structures
- Shared tables
- Shared logic
You can (and often should) standardize without reusing physical structures.
Context Is Not Reusable
Business context is almost never reusable.
Examples:
- “Customer” means different things in sales vs billing
- “Active” varies by reporting purpose
- “Revenue” changes by accounting treatment
- “Member” differs across healthcare lines
Trying to reuse context collapses meaning.
Instead, context must be explicit and scoped.
The Cost of Over-Generalized Entities
Over-generalized entities usually contain:
- Dozens of nullable columns
- Polymorphic identifiers
- Type flags to explain meaning
- Conditional joins everywhere
These models:
- Slow down queries
- Confuse analysts
- Increase error rates
- Hide business rules in SQL
They look reusable but behave unpredictably.
Reuse at the Wrong Layer
The most successful architectures reuse at higher layers, not lower ones.
Good reuse targets:
- [[Naming conventions](/tools/naming-auditor)](/tools/naming-auditor)
- Definitions
- Calculation logic
- Reference vocabularies
- Metric specifications
Poor reuse targets:
- Transaction tables
- Event semantics
- Grain definitions
- Temporal rules
Reuse meaning, not mechanics.
Versioning Is a Reusability Requirement
If something is truly reusable, it must be versioned.
Without versioning:
- Changes break downstream consumers
- Metrics shift silently
- Historical reports change
- Trust erodes
Most “reusable” models fail because they assume stability that never exists.
Reusability That Actually Works
High-performing teams design reuse intentionally:
- Reuse definitions, not raw tables
- Reuse patterns, not full schemas
- Reuse logic via views or semantic layers
- Reuse governance artifacts
- Allow divergence where context demands it
They optimize for clarity first, reuse second.
Reuse Is an Outcome, Not a Goal
The best reusable models weren’t designed to be reused.
They were designed to:
- Be explicit
- Be understandable
- Be verifiable
- Be aligned with the business
Reuse followed naturally.
Final Thoughts
Reusability isn’t about fewer tables.
It’s about fewer misunderstandings.
If reuse makes your model harder to explain, you’re reusing the wrong thing.
Design for meaning. Standardize definitions. Let reuse emerge—not dominate.
Explore standardized terms and definitions at
/definitions and /abbreviations
mdatool Team
Data modeling experts helping enterprises build better databases and data architectures.
More in Data Architecture
TEFCA and Data Architecture: What Health Systems Need to Build Now
TEFCA is now operational. Qualified Health Information Networks are live. If your health system or payer is not actively planning TEFCA participation, you are behind. Here is what the architecture requires.
Read moreHealthcare Data Lakehouse Architecture: Building on Delta Lake for Payers
The data lakehouse pattern — combining the scalability of a data lake with the ACID guarantees of a warehouse — is a natural fit for payer data. Here is how to build it on Delta Lake, layer by layer.
Read moreReal-Time vs Batch Processing for Healthcare Claims: Architecture Decision Guide
Not every healthcare claims use case requires real-time processing — and treating them all the same wastes resources and adds complexity. Here is the decision framework for choosing the right architecture.
Read moreReady to improve your data architecture?
Free tools for DDL conversion, SQL analysis, naming standards, and more.