The Dark Data Tax: What Enterprise Data Architecture Actually Builds

Part 1 of this series looked at why the conceptual-to-physical knowledge chain breaks before it ever reaches a system: It is funded as a project rather than a sustained practice, and it has no authority to bind the teams who build systems to follow it. Both are, at root, data governance failures: Nobody owns the decision, approves the definition, or pays for its upkeep once the project that produced it has closed.

But an organization can fix both. It can fund the discipline properly and give it real authority, and the chain can still fail, in two further ways: The models and standards it produces never reach the point where a project team makes a design decision, and the artifacts themselves quietly stop describing the systems they were built to govern. This article covers what enterprise data architecture actually provides once funding and authority are in place, those two further breaks, and what the daily evidence of a broken chain, the Excel workaround, the stalled AI project, the overrun migration, actually reveals about where the chain failed first.

What Enterprise Data Architecture Actually Provides

Part 1 introduced the three levels of this chain in brief. Here is what each level actually produces, and why the chain works only when all three stay connected.

The DAMA Data Management Body of Knowledge (DMBOK) defines enterprise data architecture as the discipline of identifying the data needs of the enterprise and designing and maintaining the master blueprints to meet them, per the DAMA-DMBOK. The key word is maintaining. Not producing once. Maintaining, as an ongoing operational responsibility, updated as the enterprise changes.

What EDA maintains is a structured chain of knowledge about data, spanning from the most abstract business concept to the most specific physical implementation, and back again.

At the conceptual level, EDA produces the conceptual data model: a business-language map of the organization’s core entities and their relationships (Customer, Product, Contract, Transaction) expressed independently of any technology. This model answers the question what does our data represent at the level of the business. It is the reference that makes “Customer” mean the same thing in finance as it does in sales as it does in operations. Without a current conceptual data model, every team develops its own interpretation, and every integration becomes a translation problem.

At the logical level, EDA produces the logical data model: the translation of business meaning into structured attributes, relationships, and business rules, independent of any specific system. This model answers the question how should our data be structured to represent what the business means. It is the bridge between the business concept and the physical implementation. Without a maintained logical data model, the gap between what the business means and what the system stores is never formally closed, and people fill that gap manually, in spreadsheets, every day.

At the physical level, EDA connects the conceptual and logical models to the physical data models of specific systems: the actual database structures built for specific technologies. A new system scoped and built without connecting its physical model to the enterprise conceptual and logical levels does not just introduce local technical debt. It widens the gap between the organization’s data and its knowledge of that data, because the new entities it introduces have no governed relationship to the canonical meaning the conceptual model is supposed to define, as EWSolutions notes.

Across levels, EDA maintains the enterprise data model (the canonical definition of entities and relationships across the organization) and the data lineage documentation that traces how data flows from its source, through every transformation, to the point of consumption. These are the instruments that make data traceable: They are what makes it possible to answer the question, “How did we arrive at this number?” for any business-critical metric.

As a value chain, EDA governs the sequence of steps through which raw data becomes actionable insight: acquisition, processing, storage, integration, analysis, and use. This is the data value chain: the map of what the data is worth at each stage of its journey, and the documentation of what governance is required to preserve that value as the data moves. When the data value chain is understood and maintained, the organization knows not only what data it has but what that data is capable of becoming and what it needs to travel safely from source to decision.

As a living roadmap, EDA maintains the implementation roadmap: a governance instrument that describes the current state of the data landscape, the target state the architecture is oriented toward, and the sequenced path between them. Not a project deliverable filed at close. A living document, reviewed and updated as the organization evolves.

This is what enterprise data architecture provides when it is functioning: not a set of diagrams produced at project close, but an active, maintained knowledge system that spans the full abstraction chain, from the business concept that defines what the data means, through the logical structure that translates meaning into form, to the physical reality of the systems that store and move it, and back again.

The movement in both directions matters. Going from abstract to physical is how architecture guides the design of new systems, ensuring that what gets built reflects what the business means, not just what the technology makes convenient. Going from physical to abstract is how architecture stays current: tracing what the systems actually do back to the conceptual level, identifying where the models have drifted, and closing the gap before it widens into contradiction. EDA is the discipline that maintains both directions of that chain.

When the chain is intact, the organization knows its data. When it breaks, at any level, for any reason, the data goes dark.

Where the Chain Breaks

Funding and authority, covered in Part 1, are the breaks that keep the chain from ever taking hold. An organization can fix both and still lose the chain at two further points: It can fail to reach the people making decisions, and its own artifacts can quietly stop describing reality.

Break 3: The Chain Doesn’t Reach the Delivery Process

Even when the abstraction chain is funded, maintained, and backed by genuine authority, it breaks if it never reaches the moment that matters: the point at which a project team makes the design decisions that will either respect or contradict the enterprise model.

This failure has two components. The first is format. EDA documentation is produced for architects, in the language of architects, using modeling notations (UML, ArchiMate, TOGAF-compliant repository structures) that require specialist training to read. The project manager scoping an integration requirement will not open an ArchiMate diagram to check whether the proposed data flow aligns with the governed lineage. The business analyst writing functional specifications will not navigate an enterprise architecture repository to verify that the new entity they are defining is consistent with the conceptual data model. Architecture that lives in specialist tooling and repositories that the people making consequential daily decisions do not visit functions as a knowledge system for the architecture team and an invisible constraint for everyone else, a pattern explored by Ryan Aminollahi and in a LinkedIn collaborative article on storing architecture artifacts.

The second component is process. Even when the artifacts are accessible, they fail to influence outcomes if the project delivery methodology contains no structured checkpoint at which alignment with the enterprise data model must be demonstrated before design is finalized. The EA operating model (the formal integration of EDA into how projects are initiated, funded, approved, and delivered) is what makes this alignment mandatory rather than voluntary. In most organizations it was never built. In organizations where the EA operating model is not formally integrated with project governance, 73% treat it as an afterthought, per Intelance’s analysis of 50+ EA implementations. In one documented case from that same analysis, standards compliance was running at 34%, not because the architecture was wrong, but because the delivery process never required checking it.

Every project that goes live without an EDA alignment review adds a break: physical models with no connection to the conceptual level, entity definitions that diverge from the business glossary, integrations that bypass governed data flows. The chain accumulates breaks with every release cycle.

Immediate: Audit your current project delivery methodology for every mandatory approval gate. At each gate: Is there a checkpoint at which the project’s data model is verified against the enterprise conceptual and logical data models, and its integration points checked against governed integration standards? If a system went to production last quarter without that verification, the audit will confirm it in a day.

Tactical: Introduce an EDA alignment gate into the existing project intake and phase-gate process, not as a parallel process, but as a mandatory step inside the one that already governs project approval. Three minimum requirements: a named enterprise data architect or data steward as reviewer; a structured question set (does this system’s entity definition align with the conceptual model? does it conflict with the business glossary? are its integration paths governed?); and a recorded outcome that enters the project risk register.

Structural: Track EDA compliance as a portfolio-level governance metric: what proportion of active projects have passed an EDA alignment review, what proportion of live systems have a current architecture record, what the aggregate EDA risk exposure of the project portfolio is. When that metric is visible to the investment committee, the chain’s integrity becomes a governance concern, not just an architecture one.

Break 4: The Artifacts Have Decayed

The deepest break is in the state of the artifacts themselves. A conceptual data model that was accurate three years ago and has not been maintained since is not a current map of the organization’s data; it is a historical record of a past state, presented as if it were current. A business glossary populated during an implementation project and not updated as definitions evolved is not an authoritative reference; it is the documented understanding of what the data meant at a point in time that may no longer apply. Lineage maps that describe the flows that were designed when an integration was built, not the flows that exist after four new systems were added and two decommissioned, do not describe reality.

This matters because the entire chain depends on the artifacts at its base being reliable. The logical model translates the conceptual model into structure, but if the conceptual model no longer reflects the business entities as they exist, the translation is wrong. The physical implementation follows the logical model, but if the logical model describes business rules that were superseded two system generations ago, the implementation embeds outdated logic. Decayed artifacts do not just fail to provide knowledge. They actively misdirect the organizations that continue to treat them as reliable.

The most dangerous state is not the absence of artifacts. It is the presence of artifacts believed to be current that are not. The EDA deliverables in most organizations are not wrong in the sense of having been incorrectly produced. They are wrong in the sense of no longer describing the enterprise they were built to govern, and the organization does not know this, because nobody is maintaining the discipline of checking.

Immediate: Run a currency check across every core EDA artifact: enterprise data model, conceptual data model, business glossary, data dictionary, integration standards, lineage maps, implementation roadmap. For each: When was it last verified against current systems? When was the last system change that should have triggered an update? The gap between those dates is the decay exposure. Most organizations running this check for the first time find their most critical artifacts are two to four years behind current reality.

Tactical: Assign named maintenance ownership for each artifact, not a shared responsibility, but a specific person accountable for keeping the artifact current as systems change, triggering reviews when changes are detected, and confirming currency on a defined cycle.

Structural: Integrate artifact maintenance into the project delivery lifecycle as a required deliverable at project close and a required input at project initiation. Every project that changes a system closes with a model update. Every project that initiates a new system begins with a review against current artifacts. When maintenance is a project requirement, the chain stays current by design.

What the Excel Trap Is Actually Telling You

The Excel trap is so universal in organizational data life that it is worth reading as a diagnostic. A team needs data. The governed path is too slow, too complex, or too inaccessible. Someone exports to a spreadsheet, applies their own interpretation of what the fields mean, calculates derived metrics based on their own understanding of what the business rule should be, and shares the file. Within weeks, that file is the reference.

PwC found that over 90% of finance professionals use Excel for financial modeling; Deloitte found that nearly 70% of companies use it for budgeting and forecasting, both cited by Orkestra Data. These are not rogue behaviors. They are rational responses to a broken knowledge chain. The person who built the spreadsheet was not circumventing the architecture. They were filling a vacuum left by architecture that could not reach them.

Reading the Excel trap means identifying which break produced it:

If there is no working conceptual data model, or if the one that exists is outdated or inaccessible, every team develops its own interpretation of what the core entities mean. The Excel file is the conceptual model that EDA failed to maintain.

If there is no maintained logical data model, if the bridge between business concept and system structure was never built or was left to decay, the gap between what the business means and what the system stores is never formally closed. The spreadsheet formula is the logical model that EDA failed to provide.

If physical models were designed in isolation, if each system’s database structure was scoped without connection to the enterprise conceptual level, then data carries no governed relationship to the canonical meaning the organization is supposed to share, as EWSolutions notes. The VLOOKUP that joins two exports is the integration architecture that EDA failed to govern.

The spreadsheet is not the problem. It is the evidence. It appears wherever the conceptual-to-physical chain has a break that the organization’s daily work needs to route around.

When the Chain Is Missing at Scale

The Excel trap is the daily evidence of a broken chain. The failed AI project and the overrun migration are the delayed invoice: the large, visible, expensive moment when years of accumulated breaks become impossible to ignore.

Fifty percent of generative AI projects were abandoned after proof of concept, per Gartner, exceeding the firm’s own 2024 prediction that at least 30% would be abandoned by the end of 2025. Forty percent of ERP implementations exceed their budgets, and nearly 30% fail to deliver expected benefits, in both cases due primarily to data quality issues and missing data foundations, per a Gartner study cited by Threadgold Consulting.

A generative AI application that fails at proof of concept because the data it was trained or grounded on is inconsistent, untraced, and ungoverned is a Break 4 problem. The lineage was not maintained, the entity definitions were not consistent, the integration paths were not governed. The model was fed data that looked like knowledge and was actually accumulated contradiction.

An ERP migration that overruns its budget because nobody can produce a complete, current map of what data exists, what it means, and what depends on it is the delayed invoice for every project that went live without an EDA alignment review (Break 3), in an organization where no one had authority to require physical models connect to the conceptual level (Break 2), funded as a series of projects with no operating budget for maintenance between them (Break 1).

The project that reveals the broken chain is never the project that broke it.

What a Functioning Chain Looks Like

Enterprise data architecture, when the chain is intact and maintained, produces five observable properties, not in documentation, but in the organization’s daily data work.

Traceable. Any authorized person can follow a number from the report it appears in back through every transformation to the system where the underlying data was created. The lineage is maintained as systems change. The trace remains current.

Governed. The canonical definition of every core business entity is documented, current, and enforced. When two departments produce different numbers from the same source, there is an authoritative model to resolve the discrepancy. Someone has the authority to require that the resolution align with the model.

Integrated. Flows between systems were designed against the enterprise data model, not improvised at each project’s convenience. New system integrations are assessed against the governed architecture before design is finalized. The connections between physical systems can be traced to the logical and conceptual levels that govern what the connected data means.

Understood. The metadata is current. Any authorized user can interpret what a field means today, not what it meant when the data dictionary was last updated. Ownership assignments reflect the people who are actually accountable now.

Aligned to business outcomes. The architecture describes what the organization needs to do, not what the technology makes easy to store. The data model reflects business entities as the business currently understands them. When the business changes, the architecture changes with it. There is a maintained chain connecting the business concept to the physical system, and the people responsible for it are watching both ends.

These five properties are operational conditions, not aspirations. They exist when the chain is funded as a discipline, backed by genuine authority, connected to the delivery process, and maintained in the artifacts. They disappear when any of those conditions fails. Which is why the four breaks are not four separate problems. They are four ways the same chain can stop holding.