A Theory of the Evolution of Technical Debt

Why Modernization Isn’t Solving the Problem, and What We’re Missing

By Terry Dorsey, Senior Data Architect and North America Evangelist at Denodo  

Ask most engineering leaders where technical debt comes from, and their answers will be predictable: legacy systems, rushed timelines, or architectures that didn’t age well. All of these are valid. They explain how complexity is introduced into systems and why systems become harder to change over time. But they don’t tell the whole story.

There is another form of technical debt that operates beneath these familiar causes, one that shows up even in brand-new systems, persists through modernization efforts, and amplifies complexity across the enterprise. 

Consider a simple example. 

An HR system keeps track of basic employee information, including where each person works. The “location” field is meant to answer a simple question: Where is this employee physically located? 

As more employees begin working remotely, the company faces a new requirement. For tax and compliance reasons, each employee still needs to be associated with a specific office or legal entity, even if they don’t work there. Instead of creating a new way to track this, the HR team makes a practical decision: they start using the existing location field to store the office the employee is aligned to for tax purposes. 

At first, this seems harmless. The system continues to work, and the requirement is met. 

But something important has changed. 

The location field no longer means just one thing. It now means two different things at the same time: where the employee physically works, and the office they are assigned to for tax and reporting purposes. 

Within the HR system, everything continues to function as expected. Nothing breaks

Semantic Debt

The problem shows up when other parts of the business use that data. Facilities use location to plan office space and assumes it reflects where employees actually work. So, they overestimate how many people are in certain offices. Security uses it to determine building access and grants permissions based on the assigned office, not the employee’s real location. Finance uses it for regional reporting and allocates costs based on where employees are “located,” even though that may not reflect reality. Now every team has to adjust. Some create their own rules. Others build workarounds. Reports start to disagree. People spend time explaining why the data doesn’t quite line up. 

Nothing is technically broken. But nothing is fully reliable either. Over time, this compensation accumulates into real technical debt, not just in appearance, but in the form of increased complexity, fragility, and cost. 

But it didn’t originate in the systems. It originated in the distortion of meaning. 

Most organizations view technical debt as a system problem. It is what happens when teams move quickly, take shortcuts, or inherit aging technology. Enterprise architecture addresses this through standardization, modernization, layered design, and governance. These practices are necessary and valuable. They reduce fragmentation, improve maintainability, and create more resilient systems. Yet even in well-architected environments, organizations continue to struggle with inconsistent data, duplicated logic, growing transformation layers, and constant reconciliation. This is the signal that something deeper is at play. 

That deeper issue is semantic debt. 

Semantic debt occurs when data no longer carries a consistent, stable meaning across systems. It is not the result of poor decisions, but of local decisions made in isolation. A field is repurposed to meet an immediate need. A concept is duplicated rather than aligned. A code set is extended “just this once.” Validation rules are relaxed to keep operations moving. Each decision is rational within its context. But over time, these decisions alter meaning at the source. Once meaning begins to drift, every system that consumes that data must interpret it, correct it, or work around it. 

This is what makes semantic debt so insidious. Nothing immediately breaks. Systems continue to run, data continues to flow, and outputs appear reasonable immediately. But beneath the surface, assumptions diverge and interpretations fragment. The cost does not show up as a failure, but as friction – more time to understand data, more effort to coordinate across teams, and more complexity in making even simple changes. Because this form of debt is not tied to any single system, it often goes unrecognized and unowned. 

More importantly, semantic debt does not just accumulate, it regenerates. Every new system, integration, or use case reinterprets the same ambiguous data. Logic is reimplemented in multiple places. Dependencies become harder to identify. Changes become more complex and error prone. Derived calculations break as underlying assumptions shift. Support costs increase, and reuse becomes unreliable. What should be a localized change turns into an enterprise-wide effort. Even after modernization — new platforms, new architectures, the same issues reappear. The platforms may be new, but the meaning is not stable. 

Most organizations attempt to manage this through governance, but governance is typically applied downstream. Data quality rules, transformation pipelines, reporting adjustments, and reconciliation processes are all used to detect and correct inconsistencies after they have already been introduced. This creates a continuous loop where data is implemented with local meaning, inconsistencies are discovered later, and fixes are layered on top. The underlying issue remains intact. 

Introducing the Enterprise Semantic Integrity Framework (ESIF)

Breaking this cycle requires a different approach — one that treats meaning as something to be defined, preserved, and governed deliberately across the enterprise. To address this gap, I’d like to introduce what I call the enterprise semantic integrity framework (ESIF). ESIF is not a product, or even another layer of technology; it is a disciplined approach to stabilizing meaning at its source so that systems no longer have to compensate for it. 

First, enterprise data modeling establishes the foundation of meaning. Core concepts such as “employee,” “location,” and “organizational structure” must be defined independently of any individual system or process. These definitions must be stable, unambiguous, and free from process-specific assumptions. This includes not only structural definitions, such as the formal representation of entities and their relationships, but also standardized code sets and value domains, so meaning is consistent at both the attribute and the value level. 

Second, a universal semantic layer standardizes consumption. It provides a consistent interface through which data is accessed and interpreted, enabling consumers to rely on a shared semantic understanding. Crucially, this layer also serves as a buffer between imperfect source systems and downstream consumers. It enables organizations to correct meaning at consumption, even when source systems cannot be immediately changed. This introduces a critical capability: decoupling data access from the pace of change. Production systems, which are often slow to evolve due to operational and regulatory constraints, can be modernized over time, while consumers, such as analytics, applications, and AI systems, can operate on stable, consistent meaning immediately. 

Third, implementation methodology must align with enterprise meaning. Local teams must avoid repurposing fields, duplicating concepts, or introducing process-specific distortions into shared data. Instead, implementations should preserve semantic integrity, with contextual needs handled through governed mechanisms whether in the semantic layer, application logic, or other controlled patterns based on what is most appropriate for the use case. 

Fourth, cross-domain governance ensures that meaning evolves in a controlled manner. This includes ownership of core concepts, disciplined management of code sets and value domains, impact analysis across systems, and alignment with security policies. Most importantly, governance operates across domains, so the meaning of these entities remains consistent at the core, enabling flexibility of use downstream without redefining or fragmenting what the data represents. 

This approach aligns directly with established enterprise data architecture best practices. Enterprise data architecture has long emphasized defining core entities, creating canonical models, separating logical and physical layers, and governing data across domains. ESIF builds on these principles and makes them actionable. Where traditional approaches often stop at defining models, ESIF consistently enforces and operationalizes those definitions. It extends the principle of separation of concerns by separating meaning from implementation, enabling systems to evolve without destabilizing the data they depend on. 

This shift will have a significant impact. Logic can be built once and reused. Changes can be localized instead of cascading across systems. Dependencies become easier to understand and manage. Systems consume meaning rather than reconstructing it. Most importantly, the regenerative cycle of semantic debt is broken. 

Why This Matters Now

Historically, organizations relied on specialized individuals to reconcile inconsistencies in meaning. Analysts and engineers acted as the interpretation layer, absorbing ambiguity through experience and context and acting as SMEs for technical projects. They knew what the data really meant, even when systems didn’t agree. 

That model no longer scales. 

As AI systems and autonomous agents become embedded in enterprise processes, the tolerance for ambiguity collapses. Machines do not reconcile inconsistent meaning — they amplify it. What was once inefficiency becomes systemic risk, producing incorrect outcomes at scale. 

In this environment, ambiguity is no longer manageable. It is operationally dangerous. 

The Implication

Technical debt is not confined to systems or code. It propagates through every system that consumes shared data. Most organizations do not suffer from a lack of data, or even a lack of alignment in principle. They suffer from the absence of a disciplined method for preserving meaning at the source. 

Without that discipline, distinct concepts become conflated, code sets diverge, validation breaks down, and downstream systems are forced to interpret rather than rely on data. Each new system inherits these conditions and reintroduces the same forms of debt. 

This is why technical debt continues to return, even after significant investment in modernization. It is not just accumulated. It is regenerated. 

Technical debt is not just a system problem. It is also a meaning problem. And semantic debt is the most insidious form, because it hides in plain sight and regenerates every time something new is built. 

Organizations are not solving the wrong problem. They are solving only part of it. 

Stabilize semantic integrity at the source, and the systems follow. Ignore it, and every system becomes just another workaround.