Blog
Footprints before maps
Architecture work matters when it gives teams a path from strategy to implementation rather than another target-state diagram.
I still remember a conference room with a wall-sized target architecture printed on foam board.
It looked excellent. Clean lanes, crisp labels, a future everyone could point to. For a few weeks, the diagram did what good diagrams often do: it created a feeling of progress before any real progress existed.
Then the useful questions arrived.
Who would own the landing zone? How would identity work across old and new systems? Which platform capability had to exist before the first product team could move? The room became less elegant and more honest.
That is usually the moment transformation begins.
I have learned to look for execution shape before I look for architectural beauty. Execution shape is the order in which capabilities appear, decisions get made, and ownership becomes clear enough for teams to move.
Without that shape, a transformation is just aspiration with diagrams.
Most organizations do not struggle because they lack a destination. They struggle because the path is made of hidden dependencies. The platform team is waiting on security. Security is waiting on standards. Product teams are waiting on tooling. Everyone is working. Nothing is moving.
Good architecture should reduce that ambiguity.
That means asking a different set of questions earlier than people expect. Which constraints are real and which are inherited habits? Which shared capabilities must exist first so other teams can build safely? Which governance decisions are creating delay without buying much risk reduction? Which new burden are we introducing in the name of modernization?
These are not glamorous questions. They are the ones that matter.
If I could give a younger version of myself one rule for transformation work, it would be this: trust the plan that tells a team what to do on Monday, not the one that describes 2028 in perfect detail.
I have become skeptical of architecture that only describes the end state. End states are cheap. They are necessary, but they are cheap. The expensive part is deciding what to build first, what to defer, and what trade-offs a team can live with for twelve months while the organization catches up.
That is why I trust roadmaps more than renderings.
A strong architecture gives teams a way to start. It tells them what must be true now, what can become true later, and where they can move without waiting for universal alignment. It creates momentum by making the next decision easier than the last one.
The real job is not drawing the future. It is shaping the first few steps so the future can happen.
A target state is only useful when it leaves footprints.