Module 11 · Practice
Standing up EA in a scaling organization
Your first 90 days, a minimum viable architecture practice, choosing an operating model, and showing value.
By the end of this module you should be able to
- Plan your first 90 days as an organization's first enterprise architect
- Define a minimum viable set of EA artifacts and forums
- Choose an EA operating model, engagement model, and decision rights
- Build and sustain a federated architecture community
- Measure and communicate the value of EA
Builds skills: Architecture review & governance , Building an EA practice
Starting from nothing
If you’re a scaling organization’s first enterprise architect, nobody will hand you a playbook. There’s no repository, no board, no principles. There are a lot of decisions already in flight, a few people who’ve been informally doing architecture, and probably some skepticism about what “EA” means.
The aim of this module is a practice that is small, useful, and trusted, built in about 90 days.
The first 90 days
Days 1–30: Listen and map
- Meet everyone who matters: every executive, every engineering director and EM, key product leaders, and the informal architects. Ask each one:
- What are you trying to achieve this year?
- What gets in your way?
- What decisions are coming up that you’re worried about?
- What do you expect from EA? What are you worried EA will do?
- Build a stakeholder map (module 10) and a pain-point list.
- Find decisions already in flight. Get involved in one or two where you can genuinely help.
- Sketch the level-1 capability map (module 4). Don’t publish it yet; use it to organize what you hear.
- Hand over your old responsibilities properly (module 3).
Deliverable: a short “what I heard” memo to your manager: the top themes, the top risks, and where you think EA can help first.
Days 31–60: Quick wins and foundations
- Solve one visible problem. Pick something from the pain-point list that’s cross-team, matters to a senior stakeholder, and can be moved in a few weeks. Make sure it moves.
- Publish a first set of principles: five or six, drafted with the informal architects, not handed down.
- Start the ADR habit. Write the first few enterprise ADRs for decisions you were involved in.
- Start the application inventory (module 9).
- Agree how EA will work with your manager: scope, engagement model, decision rights.
Days 61–90: Direction and rhythm
- Publish the capability map, heat-mapped, co-owned with business leaders.
- Publish a first roadmap for the most important strategic initiative.
- Launch an architecture forum (see below).
- Present back to the leadership team: what EA has done, what’s next, and what you need from them.
Minimum viable EA
The five artifacts worth having first:
| Artifact | Why first |
|---|---|
| Architecture principles | Let teams make consistent decisions without you |
| Enterprise ADR log | Builds the governance log and shows your reasoning publicly |
| Capability map | Gives business and technology a shared language |
| Application inventory | You can’t rationalize what you can’t see |
| One initiative roadmap | Shows EA turning strategy into a plan |
One forum, not a board:
- Architecture forum: fortnightly, 45–60 minutes, open to anyone. Its agenda is ADRs and design questions brought by teams. It’s advisory by default. Enterprise-level decisions are made by named decision-makers, not by committee vote.
What not to do yet:
- Adopt a framework publicly (“we’re doing TOGAF now”)
- Buy an EA tool
- Mandate design reviews for everything
- Build a complete current-state model
- Write long standards documents
Operating model and decision rights
Write a one-page “how architecture works here” that answers:
- Scope: what EA covers, and what it doesn’t
- Engagement model: federated, almost certainly (module 2)
- Decision rights: which decisions are made by teams, which by domain or platform owners, and which at enterprise level, and who makes each
- How to engage EA: how teams bring a question or decision; expected turnaround
- Forums: when they meet and what they’re for
A simple decision-rights table resolves a surprising amount of friction:
| Decision type | Decides | Consulted | Informed |
|---|---|---|---|
| Within one team, reversible | Team | — | — |
| Within one team, hard to reverse | Team (with ADR) | Forum | EA |
| Crosses teams or domains | Domain / platform owners | EA, forum | Affected teams |
| Enterprise-wide, strategic, or exception to principles | CTO, advised by EA | Affected leaders | Everyone (ADR) |
Building the architect community
In a federated model, your community of tech leads and embedded architects is the EA capability. Invest in it:
- Name it. Give the group a name and a channel. Membership is by contribution, not title.
- Give it real work: the technology radar, principles reviews, reference architectures.
- Grow people. Pair with tech leads on their hardest decisions. This is where your EM coaching skills pay off.
- Make it visible. Credit community members by name when their work shapes enterprise decisions.
Measuring value
EA is notoriously hard to measure, and if you can’t show value, the function gets cut at the next budget review. Distinguish:
| Activity metrics (necessary but not sufficient) | Outcome metrics (what leadership cares about) |
|---|---|
| ADRs written | Time from proposal to decision on cross-team questions |
| Forum sessions held | Run cost reduced through retirement and consolidation |
| Applications inventoried | Duplicate capabilities eliminated |
| Principles published | Strategic initiatives delivered on the roadmap |
| Radar editions | Audit or due-diligence questions answered in days, not weeks |
Pick three outcome metrics that matter to your executives and report on them quarterly with a short narrative. Include one story of a decision EA improved; stories persuade more than dashboards.
Maturity models, with care
EA maturity models (TOGAF describes one, and there are others) can be useful for a periodic self-assessment, or to explain to leadership what “more mature” would look like. They become harmful when maturity becomes the goal. A highly “mature” EA practice that doesn’t change decisions is worthless.
At Quillfeather
Your first 90 days, in summary:
- Days 1–30: 34 one-to-ones. Top themes: EU expansion anxiety, identity, “nobody knows who decides.” The CTO’s main worry was becoming the bottleneck, and the Head of Payments’ was losing PayNest’s autonomy.
- Quick win: You noticed that two teams were about to sign separate contracts with SMS vendors. One conversation consolidated the contracts, saved money, and became the first evidence for notification consolidation.
- Principles: Six, drafted with eight tech leads in two workshops, including “One customer, one identity.”
- Day 75: First architecture forum. Twelve people attended. Two ADRs were discussed and one decided.
- Day 90: Presented to the leadership team: capability map, EU expansion roadmap (T1/T2), six principles, nine ADRs, and three proposed outcome metrics. These were time-to-decision on cross-team questions, application run cost, and progress against T1.
The CTO’s feedback: “The first time I’ve felt like we have a plan rather than a list.” That’s what success looks like at day 90.
Reflection
- If you started as your organization’s first EA on Monday, who would be your first five one-to-ones?
- Which quick win could you deliver in your first 60 days?
- Which three outcome metrics would your executives care about most?