Part 6 · Navigating the Territory
Suppose it happens — you take an enterprise architecture role. The contribution you have been making without the title is now your job, and the organisation expects you to bring order to a landscape that took years to disorder. The first ninety days will shape whether you succeed, and they are easy to get wrong, because the instinct on arriving — to demonstrate value fast by producing analysis and asserting governance — is precisely the instinct that fails.
This chapter is the honest version of how an architecture function is built from one person with goodwill and no budget. It follows a Meridian contractor through her first ninety days, and it is organised around what to do first, second, and third — and what not to do at all.
The Mistake to Avoid
Before the plan, the trap. The newly-arrived architect’s strongest instinct is to prove their worth quickly by doing visible architecture — producing the heat map, asserting the principles, standing up the governance, telling the organisation what is wrong with its estate. This is the instinct that the Meridian EA herself followed early in this book, and it failed: she produced rigorous analysis for an organisation that had not asked for it and was not ready to act on it, and it sat inert.
The mistake has a shape. Arriving and immediately telling an organisation what is wrong — however correct — positions the architect as a critic before they are a colleague, asserts authority before earning standing, and produces answers to questions the organisation has not yet agreed to ask. It generates resistance, not change. The ninety-day plan is, in large part, the discipline of resisting this instinct and earning the right to govern before attempting to govern.
Days 1–30: Listen
The first phase is listening, and it is the phase most likely to be cut short by impatience. The goal is to understand the organisation — its real problems, its history, its politics, its language, and crucially what it already knows and feels about its own estate — before offering any conclusion.
Listening means talking to people across the organisation, at every altitude, and asking far more than telling. What hurts? What has been tried? What failed, and why do people think it failed? Who owns what? Where are the tensions? It means reading the history — the previous strategies, the abandoned initiatives, the post-mortems — because the architect who does not know what was tried before will propose it again and be rightly ignored. And it means learning the organisation’s language: the terms it uses, the things it is proud of, the things it is defensive about.
The output of the listening phase is not a document. It is understanding, and the relationships that understanding is built through. The architect who spends thirty days listening has made thirty days of deposits in the relationship account (Chapter 33) and has learned where the organisation actually is, which is the prerequisite for the baseline. The temptation to short-circuit this — “I can see the problems already, why wait?” — is the temptation to solve the wrong problem confidently.
Days 31–60: Baseline
The second phase establishes an honest baseline — the current state, scoped to the decisions the organisation is actually facing, not documented for its own sake. This is the disciplined baseline of Chapter 23: detailed enough to support the decisions in front of the organisation, and no more.
In this phase the architect produces the artefacts that make the estate visible — a capability view, an application portfolio, a sense of the data and integration reality — but produces them with the organisation rather than at it, validating findings with the people who own the systems rather than pronouncing on them. The difference is everything. A portfolio assessment delivered as a verdict generates defensiveness; the same assessment built collaboratively, with system owners confirming and correcting it, generates shared understanding and a sense of joint ownership of the problem.
The baseline phase also begins to surface the architect’s first real value: the connections and consequences that no single part-owner could see. This is where the architect earns early credibility — not by criticising, but by assembling the parts into a whole that helps everyone see their own piece differently. The first genuine deposit of architectural value is usually made here, when the architect shows the organisation something true about itself that it could not see from any single chair.
Days 61–90: The First Governance Conversation
The third phase begins to establish how decisions will be made differently — the first governance conversation, the first principle, the first test. Note the ordering: governance comes third, after listening and baselining, never first. The architect who has listened for thirty days and baselined for thirty has, by day sixty, the understanding and the standing to begin the governance conversation that would have generated only resistance on day one.
This phase is deliberately modest. It is not the imposition of a full governance regime. It is the first principle proposed and agreed (and the architect should expect it to be challenged — a principle nobody pushes on is a principle nobody will follow). It is perhaps the case for an Architecture Review Board made, not the board fully operational. It is the first decision taken in a new way, small enough to succeed, that demonstrates the value of deciding things coherently. Credibility for governance is built on small honoured decisions before it is tested on large contested ones — the same lesson the ARB itself learns in Chapter 28.
By day ninety, the architect should have understanding, an honest baseline, relationships across the organisation, early credibility from visible value, and the beginning of a governance conversation. What they should not have is a comprehensive architecture, a full governance regime, or a list of everything wrong with the estate delivered as a verdict. The ninety days build the foundation for architecture, not the architecture itself.
Meridian: The First Ninety Days
A contractor joins Meridian as enterprise architect — the role the book’s EA has been growing into is now formalised in a new arrival, and her first ninety days are the template.
Days 1–30, she listens. She resists the considerable pressure to immediately “do something about the VMware problem,” because she does not yet understand why previous attempts failed. She talks to the clinicians and learns that their defining fear is patient safety, not technology. She talks to the infrastructure team and learns they feel blamed for an estate they inherited. She reads the abandoned rationalisation initiatives and learns that every one of them failed for the same reason — no governance with the authority to make decisions stick. This single finding, available only through listening, shapes everything that follows: she now knows that the missing ingredient is not analysis but enforcement.
Days 31–60, she baselines — with the organisation. She builds the application portfolio by interviewing system owners rather than auditing them, which surfaces the shadow IT and the zombie systems through cooperation rather than confrontation. The community caseload spreadsheet emerges in these conversations, named by the nurses themselves rather than discovered as a gotcha. By day sixty she has an honest baseline and, more valuably, a set of system owners who feel they built it with her.
Days 61–90, she opens the governance conversation. She does not propose a full ARB on day sixty-one. She proposes one principle — single patient identity — and lets it be challenged, which it is, hard, and the argument itself surfaces the identity-master problem as the organisation’s shared concern rather than her imposition. Only once that principle is genuinely agreed does she make the case for an ARB as the body to uphold it. By day ninety, the principle is agreed, the ARB case is accepted, and she has the standing — earned through listening, baselining, and one honoured decision — to begin the work the rest of this book describes.
Her honest reflection is that the ninety days contained almost no architecture in the technical sense. They contained listening, relationship-building, collaborative baselining, and one carefully-chosen governance conversation. The architecture came later, and it came easily, because the ninety days had built the foundation that the organisation’s previous failed attempts had all skipped. The temptation she resisted — to arrive and fix things — was exactly the temptation that had defeated everyone before her.
Translator Panel
The new architect feels: “I need to show value fast — let me produce the analysis and fix the obvious problems.” > What that means: The instinct to prove worth through immediate visible architecture. It is the instinct that fails, because it positions the architect as a critic before a colleague and answers questions the organisation has not agreed to ask. Visible value comes faster, paradoxically, from listening first.
The effective architect does: listens for thirty days, baselines collaboratively for thirty, and opens one modest governance conversation in the last thirty. > What that means: They earn the right to govern before attempting to govern, build the relationships that make change possible, and establish credibility through small honoured decisions before testing it on large contested ones. The order — listen, baseline, govern — is the whole method.
The Key Idea
The first ninety days in an architecture role determine whether it succeeds, and the instinct that feels right — arriving and demonstrating value by producing analysis and asserting governance — is the instinct that fails, because it positions the architect as a critic before a colleague and answers questions the organisation has not agreed to ask. The method is an ordered sequence: listen for the first thirty days to understand the real problems, the history, the politics, and what the organisation already knows; build an honest, decision-scoped baseline collaboratively rather than deliver it as a verdict for the next thirty; and open one modest governance conversation in the last thirty, after the standing to do so has been earned. Governance comes third, never first. By day ninety the architect should have understanding, a baseline, relationships, early credibility, and the beginning of governance — the foundation for architecture, not the architecture itself, which comes later and comes easily once the foundation the organisation’s previous failures all skipped is finally in place.
Next: Part 7 gathers three practitioners’ arguments about what architecture is ultimately for. Chapter 51 begins with de Visscher’s case that architecture is connection, not control.
Further Reading
- Michael Watkins — The First 90 Days (Harvard Business Review Press, updated ed. 2013): The canonical guide to leadership transitions, and the direct source for the listen-before-acting discipline. Applies almost wholesale to the architecture role.
- Camille Fournier — The Manager’s Path (O’Reilly, 2017): On entering a role with influence but not yet authority, and building both — the transition challenge an enterprise architect shares with a new manager.
- Niek de Visscher — on connection over control (see Chapter 51): The argument that an architect’s first job is to connect rather than to govern is the philosophical foundation of a listen-first ninety-day plan.