الدرس 1 من 4
What an Architect Actually Does All Day
The job is mostly not drawing. It is defining constraints, resolving conflicts between teams, and being accountable for decisions whose consequences arrive long after you made them.
The most common misconception about the architect role is that it is a promotion from writing code to drawing diagrams. It is not a promotion at all — it is a change of unit. A developer is measured in features delivered. An architect is measured in expensive mistakes not made, which is a far less satisfying thing to put on a performance review and a far more valuable thing for the organisation.
Where the time actually goes
| Activity | Share of time | What it produces |
|---|---|---|
| Understanding the problem | ~25% | Quality attribute requirements with numbers attached, and the constraints nobody wrote down |
| Deciding and recording | ~15% | ADRs, options papers, and the explicit rejection of alternatives |
| Communicating and persuading | ~30% | Shared understanding across teams who will never read a document in full |
| Building and reviewing | ~20% | Reference implementations, spikes, pull-request reviews on the critical paths |
| Validating against reality | ~10% | Fitness functions, load tests, production evidence that the design holds |
The five things nobody puts in the job description
- 1Finding the constraint nobody mentioned. The compliance rule, the contractual SLA, the legacy system that cannot be touched until a supplier contract expires in eighteen months. These decide designs more often than any technical consideration, and they are never in the requirements document.
- 2Saying no with a reason and an alternative. "No" on its own is how architects lose influence; "no, because it costs us the availability target we committed to, and here is a cheaper way to get most of what you want" is how they keep it.
- 3Deciding what not to decide yet. Most decisions should be pushed down into teams and most of the rest should be deferred until the information improves. An architect who decides everything becomes a bottleneck and is wrong more often, because they are furthest from the detail.
- 4Making the invisible visible. Coupling, latency budgets, failure modes, and the cost of an outage are all invisible until someone draws them. A large part of the job is turning something everyone half-knows into something everyone can point at.
- 5Being present when it goes wrong. Architects who disappear during incidents lose the standing to make decisions afterwards. The incident is where you find out which of your assumptions were fiction.
A production incident at 2am
As a developer
Fix the failing thing. Find the bug, ship the patch, restore service, write the post-mortem action item. Success is the graph going green, and it is a genuinely satisfying kind of success.
As an architect
Ask what class of failure this was and whether the design permits it to happen again. Was this a bug, or did the architecture make this failure inevitable and we got unlucky about the timing? The patch is the team's job. Deciding whether this failure mode was accepted deliberately — and whether that acceptance is still the right call — is yours.
In practice
The constraint nobody mentioned
An architect joined a payments programme three weeks before design sign-off. The proposed design routed all card transactions through a single regional processor for simplicity, and every engineer in the room agreed it was the cleanest option.
Constraints
- Six-month delivery deadline
- Team had already prototyped the single-processor design
- Nobody in engineering had read the acquiring bank contract
- The programme sponsor was on holiday
Decision
Delay sign-off by nine days to read the acquiring bank contract and the internal card-scheme compliance memo before committing.
Why
The architect had no technical objection to the design. They had noticed that nobody could answer "what does our acquirer contract actually require about processor redundancy?", and that the entire design rested on the answer being "nothing".
What it cost
Nine days of delay, and visible friction with a team that felt second-guessed. The contract required a documented failover to a secondary processor within four hours, which the design could not do. Discovering it at sign-off cost nine days; discovering it at the pre-launch audit would have cost the launch window and roughly four months. The friction was real and was the correct price.
A team asks you to decide which testing framework they should use. What is the right answer?RevealHide
Almost certainly "that is yours to decide" — unless there is a specific cross-team reason it is not, such as a shared CI reporting pipeline that only parses one format. Pulling a decision like this upward makes you a bottleneck, removes the team's ownership, and means the decision is made by the person with the least context. The instinct to answer every question asked of you is one of the harder habits to unlearn in the transition, because answering feels like being useful.
Key takeaways
- The architect is measured in expensive mistakes avoided, not features shipped.
- Communication is the single largest block of the job, and it is the work rather than overhead.
- Finding unstated constraints changes designs more often than technical analysis does.
- Deciding what not to decide — and pushing decisions down — is a core skill, not an abdication.
- An architect who stops touching the system keeps their confidence and loses their accuracy.