Architect roles

7 units, 18 lessons and 34 questions on Architect roles. Every question is scored on submit with an explanation. Free, and open without an account.

What is in it

The difference from being a very senior engineer.

Deciding what is hard to change — The useful working definition: architecture is the set of decisions that are expensive to reverse. Choosing a queue is architecture. Choosing a variable name is not.
Trade-offs, not best practices — Every architectural choice buys something and costs something. An architect who answers "what is the best X" without asking "for what" is not doing the job.
Writing the decision down — An Architecture Decision Record states the context, the decision and the consequences. Its value is a year later, when nobody remembers why and the alternatives look obviously better in hindsight.

One system, one problem, end to end.

The scope of the role — A solution architect owns the shape of one system: how it is structured, how it integrates, whether it meets its quality requirements. Deep, not wide.
Quality attributes are the requirements — Availability, latency, throughput, security, cost. They are what actually determine the design — and stated without a number they are decoration.
How the role fails — The recognisable failure is the architect who produces diagrams the team cannot implement, is not there when it goes wrong, and treats every deviation as a defect in the team.

The whole estate, and the horizon.

Wide rather than deep — The enterprise architect works across systems: capabilities, the landscape, the target state and how to get there without stopping. Far more of the job is people than technology.
Standards that survive contact — A standard nobody follows is worse than none: it teaches everyone that governance is theatre. Fewer standards, chosen for real consequence, and a recorded exception process.
Influence without authority — Enterprise architects rarely command the teams whose work they shape. The lever is being useful early, not being right afterwards.

Where the job stops being about technology.

The shift — A CTO is accountable for whether technology serves the company: hiring, structure, budget, risk and what the company can promise customers. Technical judgment remains necessary and stops being sufficient.
Technical debt as a business argument — Nobody outside engineering funds "paying down debt". They fund shorter lead times, fewer incidents and the feature that is currently impossible.
Betting, and being wrong in public — Some decisions cannot wait for certainty. The job is to make the bet explicit, state what would prove it wrong, and change course without pretending you always thought so.

The job is not picking the best technology; it is choosing which quality attribute to sacrifice, and leaving a record of why.

Architecture decision records — An ADR states the context, the decision and the consequences. Its value is not documentation — it is that a future team can tell whether the reason still holds.
Quality attributes in conflict — Availability, consistency, latency, cost, security and changeability pull against one another. A requirement is only real once it is a number someone will be held to.

How the parts talk, who owns which data, and what happens when one of them stops answering.

Synchronous and asynchronous integration — A synchronous call couples availability: the caller is only as available as everything it calls. Events decouple it and pay in eventual consistency and harder debugging.
Data ownership and shared databases — Two services writing one table are one service with extra steps. Ownership means one writer, a published contract, and copies that are explicitly derived.

Where an enterprise architect or CTO decides more by structure than by design: build or buy, debt, and the shape of the teams.

Build, buy, and the cost of a decision — Buying trades control for time. The questions are whether the capability differentiates you, and what the exit looks like if the vendor changes direction or price.
Team shape and the systems they produce — Conway's law says a system mirrors the communication structure that built it. Organising teams to produce the architecture you want is one of the few levers an architect genuinely controls.