What are the core responsibilities of a software architect, beyond drawing diagrams?
answer
- Richards & Ford: 8 expectations
- First law: everything is a trade-off; second: why > how
- Guide, don't specify
- Governance = automation over inspection
- Anti-patterns: ivory tower, frozen caveman, bottleneck
basics
~20 sMake and justify the hard-to-change decisions; define and continually re-check the technical boundaries and standards; make sure the built system actually matches them; understand the business domain and constraints; and communicate and mentor so that teams can make good local decisions themselves.
solid answer
~60 sRichards & Ford's *Fundamentals of Software Architecture* lists eight expectations, and they hold up well: 1. **Make architecture decisions** — guide rather than specify: define constraints and let teams choose within them. 2. **Continually analyse the architecture** — the system decays; you must keep assessing vitality and technical debt, not sign off once. 3. **Keep current with trends** — because architecture decisions are long-lived, being wrong about direction is expensive. 4. **Ensure compliance with decisions** — a decision nobody follows isn't a decision; enforce via reviews and automated fitness functions. 5. **Diverse exposure and experience** — breadth across many technologies matters more than depth in one. 6. **Have business domain knowledge** — you cannot judge trade-offs without knowing what the business values. 7. **Possess interpersonal skills** — leadership, facilitation, mentoring; most architecture failures are communication failures. 8. **Understand and navigate politics** — architectural decisions cross budgets and org charts, so they must be negotiated. Underneath all eight sits the real job: **owning the quality attributes nobody else owns and making the trade-offs explicit.**
go deeper
Name three or four concrete responsibilities — makes the big decisions and explains why, sets standards, checks the code matches, mentors the team — and show you understand the architect works through other people.
Recite the eight expectations with a sentence of substance on each, and stress that decisions come with rationale and with an enforcement mechanism, not just a document.
Frame everything around trade-offs and quality attributes: what does the architect own that no individual team owns? Discuss drift vs erosion, automated governance, and why architects should stay hands-on.
Talk about scale and organization: Conway's law and the inverse Conway manoeuvre, distributing decision authority via an advice process while keeping coherence, choosing which constraints are worth centralizing versus leaving to teams, and how you measure whether the architecture function is working at all.
## Framing: the architect's job is trade-offs, not answers Mark Richards and Neal Ford's "First Law of Software Architecture" is: **everything in software architecture is a trade-off.** The second law: **why is more important than how.** Every responsibility below is downstream of those two. An architect who produces answers without stating what was traded away has not done the job. ## The eight expectations, unpacked **1. Make architecture decisions.** The distinction that matters is *guiding* versus *specifying*. Saying "all teams will use this exact HTTP client version" is specifying a technical choice — usually the team's business. Saying "all inter-service calls must be through the platform's service mesh so we get uniform mTLS, retries and tracing" is guiding — it states the constraint and the reason, and leaves the implementation open. Good architectural decisions come with rationale attached (see ADRs) and with an explicit statement of what they cost. **2. Continually analyse the architecture.** Systems decay in two distinct ways worth naming precisely: - **Architecture drift** — the implementation gains structures the architecture never intended (a shortcut call that skips a layer, a direct read of another service's database). - **Architecture erosion** — the implementation actively violates the intended architecture, usually under delivery pressure. Both are invisible unless someone looks. Practices: periodic architecture reviews, dependency analysis, tracking hotspots and change-coupling in version control history, and — best — automated conformance checks that fail the build. **3. Keep current with trends.** Not fashion-chasing. The point is that architectural decisions have long half-lives, so a wrong bet about where the industry is going (a dying framework, a database with no future) compounds for years. Practical hygiene: read widely, prototype cheaply, and be more suspicious of the new thing than of your own boredom with the old thing. **4. Ensure compliance with decisions.** Also called governance. This is where most architecture programmes fail: the wiki says one thing, the code does another. The modern answer is **automation over inspection** — dependency rules enforced in the build (module boundary tests, layer checks), performance budgets asserted in CI, security policies enforced at the platform, licence and vulnerability gates. Manual review is a supplement, not the mechanism. **5. Diverse exposure and experience.** See the breadth-vs-depth discussion: the architect's value comes from knowing that many solutions exist and roughly what each costs, not from being the deepest expert on one. **6. Business domain knowledge.** You cannot rank quality attributes without knowing the business. Is a minute of downtime a nuisance or a regulatory incident? Is the constraint peak throughput on Black Friday, or per-tenant data isolation for a compliance audit? Architects who cannot hold a conversation in the domain's own vocabulary end up optimizing for the wrong attribute, elegantly. **7. Interpersonal skills.** An architect works mostly through other people. That means facilitating decisions rather than issuing them, mentoring so that teams grow the judgement to decide locally, writing clearly, and presenting trade-offs to non-technical stakeholders in terms of risk and cost rather than technology. The failure archetype here has a name: the **Ivory Tower Architect**, who designs without building, hands down decrees, and is never present when the decisions meet reality. **8. Navigating politics.** Architectural decisions redistribute budget, headcount, autonomy and blame. Almost any significant decision will be resisted by someone whose interests it touches. Navigating this means understanding the org chart, building coalitions early, framing proposals in stakeholders' own success metrics, and choosing which battles are worth spending credibility on. ## What the architect owns that nobody else does Teams naturally own their features and their code quality. Nobody naturally owns: - **Cross-cutting quality attributes** — end-to-end latency, system-wide availability, aggregate cloud cost, uniform security posture. Each team can be locally optimal and the system globally terrible. - **The consequences of Conway's law** — that a system's structure mirrors the communication structure of the organization that builds it. This means org design *is* architecture work; if you want a different system shape, you often have to change team boundaries first (the "inverse Conway manoeuvre"). - **The long horizon** — decisions whose cost lands after the current roadmap and the current team have moved on. ## Common shapes of the role - **Hands-on / team architect** — a senior engineer on the team who also holds the cross-cutting view. Highest feedback fidelity; risk of tunnel vision within one team. - **Enterprise / domain architect** — spans many teams, sets standards and reference architectures. Higher leverage; risk of ivory tower. - **Architecture guild / advisory forum** — no dedicated title; decisions are made by whoever is doing the work, after seeking advice from affected parties and experts. Scales well, requires strong recording discipline (ADRs) to avoid amnesia. - **Solution architect** (customer/vendor-facing) and **infrastructure/platform architect** are common specializations. The key point for interviews: the responsibilities are constant across shapes; only who carries them varies. ## Should architects code? The strong consensus in modern practice is: **yes, at least some.** Fowler distinguishes *Architectus Reloadus* (the decision-maker apart from the team) from *Architectus Oryzus* — the architect who works alongside developers, whose main value is raising everyone else's level. Coding provides the feedback loop that keeps decisions honest; without it, decisions are made on how the system is *believed* to behave. Practical compromises: pair regularly, build proof-of-concept spikes, own cross-cutting or tooling work that isn't on the critical path (so you don't become a bottleneck), and take on production support rotations. ## Anti-patterns to be able to name - **Ivory tower** — decisions without contact with implementation. - **Frozen caveman** — every decision refracted through one traumatic past incident ("we must handle a total datacentre loss" for an internal tool with ten users). - **Résumé-driven architecture** — technology selected for career value rather than fit. - **Diagram-only architecture** — beautiful documents, no enforcement, immediate drift. - **Bottleneck architect** — all decisions must route through one person, so teams either stall or route around them.
- Should an architect still write production code?At least some, yes. Fowler's Architectus Oryzus is the architect embedded with the team whose main value is raising everyone else's level; the feedback loop keeps decisions grounded in how the system actually behaves rather than how it's believed to behave. The practical constraint is not becoming a delivery bottleneck — so architects typically take cross-cutting, tooling, or spike work rather than critical-path features, plus pairing and on-call rotations.
- How does an architect enforce decisions without becoming a gatekeeper?Automate the enforcement. Encode dependency and layering rules as build-failing tests, put performance and cost budgets in CI, enforce security at the platform level, and provide golden paths that make the compliant option the easiest one. Reserve human review for genuinely novel decisions. This converts governance from 'ask permission' into 'the pipeline tells you', which scales and removes the architect from the critical path.
- What is Conway's law and why is it an architect's concern?Conway's law observes that a system's structure tends to mirror the communication structure of the organization building it. It matters because you cannot impose a decoupled architecture on a tightly-coupled organization and expect it to hold — the boundaries will erode along the lines of who talks to whom. Architects therefore treat team topology as an architectural lever (the 'inverse Conway manoeuvre': shape the teams to get the system shape you want).
A city planner, not a house designer. They don't choose your kitchen tiles; they decide where the roads, water mains and zoning boundaries go, then check that what got built matches the plan — and they have to negotiate with residents, budgets and politicians the whole time. A planner who never walks the streets ends up with a plan that looks great on paper and floods every spring.
saying these in an interview costs you the question
- Describing the role as producing diagrams and documents, with no mention of trade-offs, enforcement, or people.
- Believing architects should specify technology choices down to library versions rather than setting constraints and rationale.
- Assuming architecture is signed off once at project start rather than continually re-analysed.
- Ignoring the business domain — treating architecture as a purely technical optimization problem.
- 'The architect decides, developers implement' — the ivory tower model, which produces decisions that don't survive contact with the code.
- No mechanism for compliance, so the documented architecture and the real one silently diverge.
- Dismissing organizational politics as 'not engineering' when most significant decisions cross budgets and org boundaries.