In week one of any architecture review, I ask the same 3 questions.
The answers decide where I focus next.
“Does leadership understand what your data team actually does?” If the answer is silence or vague gestures toward “dashboards,” I know the real problem. The data team is a service desk, not a strategic function. They build what’s loudest, not what matters.
“When was the last time you changed a core schema?” If the answer is nervous laughter or “we avoid that,” I know the real blocker. Fear of change. Nobody mapped the dependencies, so every change feels like defusing a bomb. That’s not stability. That’s losing velocity.
“Does the business trust your data?” If executives double-check reports in spreadsheets or ask “where did this number come from?” in every meeting, that’s the priority. A data platform nobody believes is just expensive infrastructure.
These questions don’t require code access. They tell me whether we’re solving a technical problem or an organizational one. Most architecture reviews start with code. Most architecture problems live in ownership, definitions, and communication.
These answers set the agenda. Architecture practice can’t exist without alignment. The answers tell me how much foundation work comes first.
When was your last production incident - and how did you find out about it?