Every engagement starts the same way. A system exists. Documentation doesn't. A roadmap is coming. Nobody can tell you what the current state supports or what the future state requires.
That's not a problem. That's the job.
Decision makers don't hire architects when the path is clear. They hire them when it isn't.
The situation every organization faces
You have a production system built by people who are gone, documented by people who had other priorities, and now expected to support a roadmap nobody stress-tested against what actually exists.
The business is moving. The technology has to keep up. Somewhere in that gap are decisions that need to get made before the next phase breaks something.
How a senior architect approaches it
The instinct is to dive into the code. Don't.
Start with inventory. What exists today — every table, every pipeline, every data flow — mapped against what it actually does. Not what it was supposed to do. What it does.
Then map the roadmap. What is each upcoming phase asking of the system at the data and instrumentation level? What needs to be captured, logged, and queryable that isn't today?
Then build the matrix. Current state against future requirements. Where coverage exists. Where the gaps are. What decisions need to get made before the next phase lands.
Three layers. One framework. Every engagement, every domain.
Why it matters
The gap between current state and future requirements never announces itself. It surfaces mid-project, under deadline, when fixing it costs the most.
The architect's job is to find it before it finds you.
That's not a technical skill. That's a thinking pattern. The difference between an engagement that delivers and one that stalls because nobody mapped the foundation before building the next floor.
What you walk away with
A clear inventory of what you have. A clear map of what you need. A decision framework that lives in your documentation after the engagement ends — not in someone's head.
Clarity through the chaos.