Your As-Is Architecture Is an Interview Transcript. Agility Starts When It Becomes Telemetry.
Photo by Alina Grubnyak on Unsplash
Ask an enterprise architect for the as-is landscape and you will usually get a diagram that was accurate on the day someone finished interviewing the people who were available. It is not a lie, but it is testimony — filtered through what teams remember, what they want funded, and what they would rather not mention. Then a to-be target is drawn against that testimony, a three-year roadmap is sequenced, and eighteen months later the programme is renegotiating scope because the real landscape had integrations, consumers, and dependencies nobody declared. Business agility does not fail at the target state. It fails at the baseline.
The baseline decays faster than the governance cycle
The uncomfortable arithmetic: most large enterprises refresh their architecture repository annually or semi-annually, while the estate changes weekly through deployments, SaaS purchases, new integration flows, and quietly created service accounts. Gartner's 2025 enterprise architecture research notes that only 13% of leaders feel their organisations respond effectively to technology disruption — and a stale baseline is a direct cause. You cannot reroute quickly around a dependency you did not know existed. Application portfolio and CMDB practitioners have been saying the same thing from the operations side for years: the portfolio you think you have rarely matches the portfolio you actually run.
This is also why two-speed IT keeps reappearing as a coping mechanism. If nobody can prove what the slow core actually touches, the only safe move is to wrap it and build beside it. The second speed is not a strategy; it is the price of an unmeasured baseline.
Harvest the as-is from systems that cannot lie
A measured baseline is cheaper to build than most architects assume, because the evidence already exists in operational systems. Instead of a discovery workshop series, start with extraction:
- API gateway and integration middleware logs — who actually calls what, how often, and which declared interfaces have zero traffic. Dead endpoints are decommissioning candidates hiding in plain sight.
- Identity provider grants and service accounts — the most honest map of system-to-system coupling in any enterprise, and usually wider than the architecture repository shows.
- Database and table access patterns — the shadow integrations. Direct reads against a core schema are dependencies whether or not anyone modelled them.
- Deployment and change records — per-component change cadence, which tells you empirically which parts of the estate are fast and which are frozen.
- Spend and licence data — SaaS and cloud billing reveals the applications that never entered the portfolio in the first place.
None of this replaces architectural judgement. It replaces the guessing that currently precedes it.
Make the roadmap a diff, not a destination
Once the as-is is observed rather than recalled, the to-be stops being a poster and becomes a set of differences: these seventeen consumers must move off that interface, these four flows must be inverted, this schema must stop being read directly by anything outside its owning service. Each difference has a named owner, a measurable completion signal, and a cost. Progress is reported as consumers migrated and dependencies retired — not as phases completed. That reporting change alone kills most roadmap theatre, because a diff cannot be 70% green while nothing has actually moved.
Let the speed layers be an output, not an org chart
When change cadence is measured per component, you discover the estate already has more than two speeds — and the boundaries rarely match the ones drawn in the operating model. The useful design move is to align service and ownership boundaries to the cadences you observe, rather than declaring a digital unit and a core unit and hoping the dependency graph cooperates. This is where SAP-heavy landscapes are especially instructive: the core moves on quarterly release discipline, the engagement layer moves weekly, and the pain is always at the contracts between them.
The 2025 DORA research on AI-assisted development made a related point that generalises well: AI amplifies the capability an organisation already has. The same is true of architecture practice. Agents and copilots pointed at an accurate, machine-readable landscape accelerate planning; pointed at a Visio archive, they accelerate confident nonsense.
The next competitive step for most EA functions is not a better framework or a bigger modelling tool. It is treating the as-is as a continuously refreshed data product — queryable, versioned, and trusted enough that a reorganisation, an acquisition, or an AI initiative can be scoped in days rather than quarters. If you want to see how we approach baseline discovery alongside target-state design, our advisory practice starts there deliberately.
Frequently Asked Questions
How long does it take to build a telemetry-based as-is baseline?
For a mid-sized estate, a first usable version typically takes four to eight weeks, because the data already exists in gateways, identity systems, and billing. The slow part is agreeing ownership and reconciling extracted evidence with the existing repository, not the extraction itself.
Does this replace our enterprise architecture tool or CMDB?
No. It feeds them. The repository remains the place for intent, standards, and target states, while telemetry supplies the observed reality that keeps those models honest and flags drift between what was approved and what is actually running.
What if teams resist having their undeclared dependencies exposed?
Frame the exercise as risk reduction rather than audit, and publish findings to owners before leadership. In practice most undeclared integrations were pragmatic fixes under delivery pressure; teams cooperate once it is clear the output is a funded migration path rather than a blame list.

Comments (0)
No comments yet. Be the first to comment!