Software Design · 1/3
What a software architect does: architecture vs design, the three laws and eight expectations
Architecture vs design, the three laws of software architecture, architecture characteristics, recording decisions, and what is expected of an architect.
On this page
This series follows the course Software Design in my MSc in Software Engineering at FCUL, taught by Prof. António Pedro Ribeiro. It covers a short history of software engineering and the concepts, representation techniques, methods and tools of software design, and then its core: software architecture. The goals are to know the main architectural styles and their properties, to design alternative architectures for a system and evaluate them against its requirements, and to recognise whether an implementation conforms to its architecture.
It draws on three books:
| Book | Authors | What it’s for |
|---|---|---|
| Fundamentals of Software Architecture, 2nd ed. (O’Reilly) | Mark Richards, Neal Ford | The modern practice: the role of the architect, architecture characteristics, trade-offs, and today’s styles. |
| Software Architecture in Practice, 3rd ed. (Addison-Wesley, 2012) | Len Bass, Paul Clements, Rick Kazman | The foundations: what architecture is, quality attributes, tactics, and evaluation methods like ATAM. |
| Documenting Software Architectures: Views and Beyond, 2nd ed. (Addison-Wesley, 2010) | Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford | How to write an architecture down: views, styles, interfaces, behaviour and rationale. |
The course starts where Richards and Ford start: before diagrams and styles, with what architecture is and what the job involves.
Architecture and design
The two words get used interchangeably, but they aren’t the same thing, and the usual way to put it is: all architecture is design, but not all design is architecture. Architecture is the subset of design decisions that shape the system as a whole.
What makes a decision architectural? Richards and Ford suggest treating it as a spectrum rather than a line, and asking where a decision falls on a few scales:
| More architectural | More design | |
|---|---|---|
| Scope | Strategic: affects the whole system, many teams | Tactical: affects one module or feature |
| Effort to change | Expensive, slow, risky to reverse | Cheap to change later |
| Trade-offs | Significant, across qualities | Small and local |
| Examples | Monolith or services, sync or async communication, where data lives | A class hierarchy, a design pattern, a component’s API |
Choosing a message queue between services is architecture: it changes how the whole system behaves and is costly to undo. Choosing how to name the handler classes that consume from it is design. Most decisions sit somewhere between, which is itself one of the laws below.
The three laws
1. Everything in software architecture is a trade-off
There are no free wins. Every decision buys something by giving something else up: more services buy independent deployment and cost you network calls, data consistency and operational overhead. A cache buys speed and costs freshness.
The book adds a corollary worth remembering: if you think you’ve found a decision with no trade-off, you probably just haven’t found the trade-off yet.
I’ve seen both directions of this. On a healthcare platform, splitting 30 overloaded endpoints into 46 focused ones made screens roughly twenty times faster, and the price was more endpoints to maintain, a coordinated migration, and screens that make several calls instead of one. At my current job the same judgement went the other way: a search modal making one request per filter became a single call, cutting requests by 90%, at the price of a bigger response. Neither choice is “right” in general. Each is right for its trade-offs.
2. Why is more important than how
Anyone can see how a system is built by reading the code. What gets lost is why: which alternatives were considered, which constraints ruled them out, which trade-offs were accepted on purpose.
Without the why, the next person can’t tell a deliberate decision from an accident, so they either preserve mistakes out of fear or undo good decisions out of ignorance. That’s why architects write down decisions with their context and consequences, for example as architecture decision records (ADRs), and why Documenting Software Architectures insists on recording rationale alongside the design itself.
When I proposed replacing a form-field pattern at work, the document that got it accepted wasn’t the new component’s API. It was the comparison of what the old pattern cost, with numbers, and why the new one removed that cost.
3. Most decisions aren’t binary
The second edition of the book adds this one: architecture decisions rarely come down to one option or the other. They sit on a spectrum between two extremes.
- Not “monolith or microservices”, but anywhere from a layered monolith, through a modular monolith, to service-based architecture and fine-grained microservices.
- Not “synchronous or asynchronous”, but which interactions need an immediate answer and which can be eventual.
- Not “consistent or available”, but how much staleness each piece of data can tolerate.
Framing a decision as a switch hides the options in between, and the best answer is often one of them. The marketplace I work on is a good example: a twenty-year-old PHP codebase that grew into a Laravel modular monolith, with clear domain boundaries inside one deployable. It’s neither of the two poles people usually argue about.
Architecture characteristics
Functional requirements say what a system does. Architecture needs a second list: the qualities it must have. Software Architecture in Practice calls them quality attributes; Richards and Ford call them architecture characteristics, and a characteristic qualifies when it’s about something other than the domain logic, it influences the structure, and it’s critical to the system’s success.
They group them roughly like this:
| Group | Characteristics |
|---|---|
| Operational | availability, performance, scalability, elasticity, reliability, safety, recoverability, robustness |
| Structural | maintainability, extensibility, configurability, portability, upgradeability, localisation |
| Cross-cutting | security, privacy, accessibility, usability, legal and compliance, supportability |
A few are easy to confuse:
- Scalability is handling more load as it grows: more users, more data, more requests, without falling over.
- Elasticity is handling bursts: scaling up quickly for a spike and back down afterwards. A ticket shop on release day needs elasticity; a system that grows steadily needs scalability.
- Availability is being up when needed, often stated as a percentage of time. Reliability is working correctly when it’s up. Safety is not causing harm when things go wrong, which matters most where software touches people or physical systems, like the healthcare platform I worked on.
The trap is wanting all of them. Every characteristic costs complexity, and many pull against each other: security against usability, consistency against availability, performance against maintainability. The book’s advice is to pick the handful that really matter for this system and aim for the least worst architecture, not a perfect one, because a perfect one doesn’t exist.
Deciding: write down the why, leave room to change
Architecture is, in the end, a series of decisions, and the second law says their reasons matter more than their shape. A common format is the architecture decision record (ADR), one short document per decision:
| Section | What goes in it |
|---|---|
| Title | A short name: “Use a message queue between orders and notifications”. |
| Status | Proposed, accepted, superseded (and by which ADR). |
| Context | The forces at play: requirements, constraints, what’s known and what isn’t. |
| Decision | What was decided, stated plainly. |
| Consequences | The trade-offs accepted, good and bad, and what now becomes easier or harder. |
Written this way, the record survives the people who made it, and a later “why on earth did we do this?” has an answer.
The other half is knowing what not to decide yet. Not everything needs to be closed at the start. A decision taken too early is taken with the least information you’ll ever have, so it’s worth leaving the ones that can wait open until the last responsible moment: the point after which not deciding starts to cost more than deciding. Architectures that keep those options open, with clear boundaries and replaceable parts, can adapt when requirements change, which they always do. Ford and his co-authors call this evolutionary architecture, and it’s why the eighth expectation below (keep checking the architecture) matters: an architecture that’s allowed to evolve needs guardrails, not a frozen blueprint.
The eight expectations of an architect
Richards and Ford list what’s expected of an architect, whatever their title. My summary, in the order the course presented them:
1. Navigate politics
Almost every architecture decision affects someone else’s work, budget or plans, so it will be challenged, and the challenge is often not technical. An architect has to negotiate, build agreement, and sometimes accept a compromise. The book’s point is that this isn’t a distraction from the job: it is part of the job.
2. Soft skills
Explaining a decision to engineers, product owners and executives, each in their own terms. Listening. Mentoring. Much of an architect’s impact comes through other people: at WebMD Ignite a lot of mine went through code reviews and one to three pair-programming sessions a day, not through diagrams.
3. Business domain knowledge
An architect who doesn’t understand the domain designs the wrong system very well. Knowing the business is what turns vague requests into the right architecture characteristics: in a healthcare product, what “critical data” means for availability and security; in a marketplace, why search and SEO drive so many decisions.
4. Keep up with trends
Not to chase every new tool, but because an architect’s decisions last years and have to take into account where the technology is going. Knowing what exists, and what it trades off, is what lets you pick well.
5. Breadth over depth
A developer’s value grows with depth in a few technologies. An architect’s grows with breadth: knowing that many options exist and what each one is good for, even without being an expert in all of them. Richards and Ford picture knowledge as a pyramid, from what you know, through what you know you don’t know, to what you don’t know you don’t know, and the architect’s job is to widen the middle layer. Being the deepest expert on one framework is less useful to an architect than knowing five alternatives well enough to compare them.
6. Leadership: make the decisions
An architect decides, but the decision is about the architecture, not every technology choice. The book’s guidance is to guide rather than dictate: set the constraints and principles, and let teams make the choices that fall within them. Leadership is also owning a decision when it turns out to be wrong.
7. Keep the architecture healthy: technical debt and observability
Architectures decay. Shortcuts pile up, structure erodes, and a system that was fine at launch struggles two years later. An architect keeps analysing the architecture as it lives: tracking technical debt, and watching it in production through observability. On the healthcare platform, we retired old endpoints only after watching Datadog and Sentry at every step; that’s the same habit applied to a single change.
8. Consistency: make sure decisions are followed
A decision nobody follows isn’t a decision. Architects check that the implementation conforms to the architecture, ideally automatically. Richards and Ford call these checks fitness functions: tests that fail when a structural rule is broken, like a module importing from a layer it shouldn’t. This is also the last goal of the course: recognising conformance between implementation and architecture.
What I’m taking from this
- Architecture is the part of design that’s expensive to change. That’s what makes it worth the extra care.
- Look for the trade-off in every decision, and if you can’t find one, look harder.
- Pick a few characteristics, not all of them. Aim for the least worst architecture.
- Write down the why, and leave room. The code already says how; not every decision needs making on day one.
- Question binary framings. The answer is often in between.
- Most of the job is people. Politics, soft skills and leadership are half the list, and they decide whether good architecture gets built at all.