A company built thorough BDAT models three years ago during a major transformation program. Today, engineers say the models are "basically fiction." What causes enterprise architecture models to drift out of sync with reality like this, and how would you decide whether it's worth the cost to refresh them versus retiring them?

## Where the models come from, and why reality moves on Enterprise architecture models are typically produced during concentrated, well-funded programs — a core-system replacement, a major reorg, a cloud migration — where a dedicated team has the time and mandate to interview stakeholders, catalog systems, and produce detailed business, data, application, and technology diagrams. Once the program closes, that dedicated capacity usually disappears, but the underlying reality doesn't stop changing: applications get patched and re-platformed, infrastructure gets resized or migrated, teams reorganize, and business processes get tweaked in the ordinary course of operating the company. Each of the four layers changes at a different natural pace: | Layer | Natural pace | |---|---| | **Technology** | Fastest — servers, cloud resources, and configurations can change daily. | | **Applications** | Next — releases, integrations, retirements happen over weeks to months. | | **Data** | More slowly — core entity definitions change less often, though data flows and ownership shift as systems are added or removed. | | **Business architecture** | Slowest of all — capabilities and high-level processes are comparatively stable. | A model produced once and left alone therefore drifts fastest and worst at the technology and application layers, even if the business-layer diagrams remain roughly accurate for years. ## The root cause of the drift The root cause of the drift is almost never that the original documentation was low quality — it's that no ongoing process ties routine changes back to the model. Engineers making a normal infrastructure change or decommissioning a system have no required step that updates the architecture diagram; documentation upkeep isn't what they're measured on, and the program team that owned the models has been reassigned or disbanded, so ownership of "keeping this current" diffuses into nobody's job in particular. Hand-maintained diagrams compound the problem: unlike a database schema or a service catalog entry, a diagram doesn't break or throw an error when it becomes wrong, so there's no forcing function that surfaces the staleness until someone relies on it and gets burned. ## The options, and what each one trades The trade-off in deciding what to do about it runs across several options. - **Fully re-syncing all four layers** by hand on an ongoing basis is the most thorough option but also the most expensive, and tends to recreate the same problem a few years later once attention moves elsewhere again. - **Partial automation** — deriving the technology and application layers' current state from systems that already update themselves, such as cloud resource tags, service meshes, API gateways, and configuration management databases — is far cheaper to keep current because it piggybacks on data that's already being maintained for other operational reasons, though it only works where such systems of record actually exist and are trustworthy. - **Just-in-time modeling** — refreshing only the specific slice of BDAT needed for an active decision, like an upcoming audit or migration, and explicitly labeling everything else as a stale, point-in-time snapshot — trades comprehensiveness for honesty about what's actually known. - **Retiring the models entirely** is the right call when nobody has been consulting them for real decisions anyway, since continuing to maintain unused documentation is pure cost with no offsetting benefit. ## What unmanaged drift costs When the drift isn't managed, the failure shows up concretely and often expensively. - A due-diligence or audit team pulls the three-year-old model, finds that it says system X owns capability Y, and makes a decision based on that — only to discover X was decommissioned eighteen months earlier and the capability quietly moved elsewhere, which can derail a merger valuation, a security assessment, or a compliance filing. - Regulatory or compliance audits frequently surface a gap between "as documented" and "as deployed" architecture, which is itself a finding auditors flag regardless of whether the underlying systems are actually fine. - There's a longer-term cultural cost: once a team gets burned relying on a stale model, they tend to distrust all architecture documentation afterward, including parts that are still accurate, and fall back on tribal knowledge instead — which is itself fragile and walks out the door when people leave. ## What the drift looked like at one bank A representative scenario: a bank built full BDAT documentation, including detailed data-flow diagrams, during a multi-year core-banking replacement program. Two years after the program closed, a regulator's audit requests the current-state data flow diagrams, and the architecture team discovers the diagrams still reference a data warehouse that was decommissioned and replaced the prior year — an easy, embarrassing finding in an audit context where accuracy of documentation is itself being assessed. The bank's remediation is not to go back to fully hand-maintaining all four layers at equal fidelity; instead, it shifts to auto-generating the technology and application inventories directly from its cloud tagging and configuration management systems — which are already updated as a side effect of normal operational change control — while keeping only the business and data layer models hand-curated, since those change more slowly, under a lightweight quarterly review cadence rather than a one-time program-driven effort that's left to decay again.