Software architecture · Level 0: The architect · Module 01 of 46

What software architecture is

Ask ten architects to define software architecture and you'll get ten answers. The useful one is practical: architecture is the set of decisions about a system that are expensive to change later. It decides which qualities the system has, how it's split into parts, where those parts run and how they share data. Get those right and features are cheap to add; get them wrong and every change ripples across teams.

1. The idea

Renovating a house. Repainting a room is a weekend job. Moving a load-bearing wall, the staircase or the main drain means engineers, permits and months of work, because everything else rests on them. Nobody notices a good foundation, but every later change depends on it. Software architecture is the foundation, load-bearing walls and plumbing: the parts you want to get roughly right before people move in.

Four things make up an architecture. They come up in every module of this track, so it's worth knowing them by name:

Part	What it is	Example
Architecture characteristics	The qualities the system needs beyond its features	"Must survive a data-centre outage", "must handle Black Friday"
Structure	The parts (components) and the overall shape (the style) that connects them	Five services communicating through events
Architecture decisions	Rules the team must follow, with their reasons	"Only the order service writes to the orders table"
Design principles	Guidelines that leave room for judgement	"Prefer asynchronous messages between services"

Two ideas hold everything together. First, everything in architecture is a trade-off: there are no best practices, only the least bad option for this situation. Second, why matters more than how: anyone can read how a system is built from the code, but only a recorded reason tells the next person whether a decision still makes sense.

One more distinction you'll use constantly: the logical architecture is the parts and how they relate (ordering, payment, inventory); the physical architecture is how those parts are deployed (one application, or five services, with which databases and which network between them). The same logical architecture can be deployed in very different ways, and that choice changes speed, failure behaviour and cost.

2. How it works

Press Play. The same four logical parts of an online shop are deployed two ways. Watch what each arrow turns into, and what can go wrong on it.

Architecture has to agree with everything around it

An architecture doesn't live alone. It has to match the data topology, the team structure, the deployment tooling and the business's plans. When two of these disagree, the system pays for it. The classic case: services that are deployed separately but share one database.

The intersections to checkFor any architecture, ask whether it agrees with: how the data is stored and owned, how teams are organised (who owns which part), how the code is built and deployed, the infrastructure it runs on, and what the business plans to change next. A mismatch in any of them shows up as slow releases, outages or teams blocking each other.

3. Try it yourself

Where does a change ripple?

Pick an architecture and a change request. The lab shows which parts must change (red), which must scale (blue), how many separate releases it takes and how many teams must coordinate. The logical parts are the same every time: only the deployment boundaries (dashed) and the data ownership change.

Illustrative model of a small shop. Orders, Payments, Inventory and Notifications are owned by four teams. In the shared-database versions, Payments and Notifications read the orders table directly; with private databases they get order data from the Orders API or its events.

4. Trade-offs

Decide early vs decide late

Deciding structure early gives teams a stable shape to build in. Deciding too early, before you know the real load or domain, locks in guesses. Make the expensive decisions at the last responsible moment: as late as you can without blocking the work that depends on them.

One deployment vs many

One deployment means simple calls, one transaction and one release, but everything scales and fails together. Many deployments let parts change and scale alone, at the price of network calls, partial failures and harder data consistency.

Rules vs principles

A rule ("never call the payments database directly") is easy to check and enforce, but rigid. A principle ("prefer asynchronous calls") trusts the team's judgement, but drifts more easily. Use rules for things that would be expensive to get wrong.

Upfront design vs evolving it

Big upfront design misses what you learn while building. No design at all lets accidental structure appear. Most teams sketch enough architecture to start, then evolve it with checks that keep the important decisions true (Module 26).

5. In real projects

Architecture shows up as the cost of change. When a team says "that's a two-line change, but it needs three teams and a coordinated release", that's an architecture problem, not a coding one. The lab above is that conversation in miniature.

"Shared database, separate services" is one of the most common real-world mismatches. Teams split the code into services to release independently, keep one database for convenience, and discover that every schema change needs a synchronised release. Modules 13 and 23 show the ways out.

Architecture is also a set of decisions people remember differently. Without written reasons, a decision like "Payments only talks to Orders through events" gets undone by someone who doesn't know why it was made. That's why architecture decision records (Module 27) exist.

Say it in the interview

Two-sentence answers

"What is software architecture?" The decisions that are expensive to change: the qualities the system needs, its structure and style, the rules for building it, and the reasons behind them. It shows up as how much a change costs and how many teams it involves.
"What's the difference between architecture and design?" It's a spectrum: the longer a decision lasts, the more people it affects and the more effort it takes to make, the more it's architecture. Choosing services and data ownership is architecture; choosing a class pattern inside one service is design.
"Logical vs physical architecture?" Logical is the parts and their relationships; physical is how they're deployed and connected. I decide the logical parts first, then choose a deployment that gives the characteristics we need.

Red flags interviewers notice

Describing architecture only as a list of technologies ("React, Kafka, Postgres").
Claiming a "best practice" without naming what it costs.
Splitting into services while keeping one shared database, and not mentioning the coupling.

6. Remember it

Memory hook: "Load-bearing walls, with a note taped on"Architecture is the parts that everything else rests on, and the note says why each wall is there.

How this hook works: what "load-bearing walls, with a note taped on" means

What the slogan means, phrase by phrase

"Load-bearing walls": The decisions that are expensive to move: structure, deployment boundaries, data ownership, communication style.
"with a note taped on": Every one of those decisions carries its reason and its trade-off, written down where the next person will find it.

Why this picture fits: nobody can tell a load-bearing wall from a partition just by looking, and nobody can tell an important architecture decision from an accident just by reading code. The note is what protects it.

The story → the concept

The house	The software
Foundation and load-bearing walls	Structure, style, deployment and data boundaries
Paint, furniture, fittings	Design and code inside one part
The note taped to the wall	The architecture decision record
The building inspector	Automated fitness functions (Module 26)

The trap it saves you from

Treating every decision as equally important: either agonising over trivia, or making a load-bearing decision in a code review without noticing.

7. Common mistakes

Architecture as a technology list"We use microservices on Kubernetes with Kafka" describes tools, not an architecture. Say which characteristics they serve and what they cost.

Splitting code but not dataSeparately deployed services over one shared database release together anyway. Decide data ownership together with deployment boundaries.

No recorded reasonsDecisions without reasons get reversed by the next person, often re-creating the problem they solved.

Freezing the architectureRequirements, load and teams change. An architecture that isn't checked and adjusted drifts into whatever the code happens to be.

8. Design exercise (30 minutes)

Name the four parts (10 min). For a system you work on, write its top three characteristics, its style, one architecture decision and one design principle. If you can't name them, that's the finding.
Logical vs physical (10 min). Draw its logical components, then draw how they're actually deployed. Mark every arrow that crosses a network.
Find a mismatch (10 min). Check the intersections: data, teams, deployment, infrastructure, business plans. Write down one place where two of them disagree and what it costs today.

9. Self-check quiz

Which definition of software architecture is the most useful in practice?

Tools and diagrams follow from the decisions; the cost of changing them is what makes them architecture.

Four services share one database, and Orders renames a column that two others read. What happens?

The deployment boundaries say "independent", the data says "shared". The data wins, and three releases must be coordinated.

What does the physical architecture describe?

Logical = the parts and relations; physical = deployment units, databases and networks.

Why is "why" more important than "how" in architecture?

Without the reason, nobody can tell whether a decision still holds or can safely change.

To let the Orders team change its schema without coordinating with others, Orders needs:

Private data turns a schema change into a local change; the contract (API or event shape) is what others depend on.

10. Go deeper

Resource	Time	Why
Who needs an architect? (Martin Fowler, IEEE Software)	15 min	The classic short essay: architecture as "the important stuff, whatever that is".
Software Architecture Guide (Martin Fowler)	browse	Why architecture matters economically, with links to the key articles.
Fundamentals of Software Architecture, 2nd edition (Mark Richards and Neal Ford)	book	The standard textbook for this track's topics, chapters 1–2 for this module.