The architect looks ten years ahead

An engineer builds a house for the family moving in on Saturday. An architect asks: "And when they have a third child? When the mother moves in? When they want to rent out the ground floor?"

An engineer solves the problem as posed. An architect solves the problem as it will look in three years. That means designing in capabilities not yet needed, and deliberately leaving out the ones that sound elegant but will never be used.

The architect owns consequences, not code

A carpenter who drives a nail crooked fixes it in a day. An architect who puts a load-bearing wall in the wrong place can't fix the house — they have to live in it.

An engineer's mistake gets fixed in a week. An architect's mistake the company pays for for years — in technical debt, in lost teams, in missed opportunities. So the architect has to think before the first line is written, and have the courage to halt the build if the architecture doesn't survive real requirements.

The architect questions the task, not just the solution

A patient walks in asking for a prescription. A good doctor first asks what hurts — and may find the requested medicine would have been the wrong call.

When someone says "do X," the engineer asks "how do I do X." The architect asks "why do we need X, and would something else solve the actual problem". The task is often posed wrong — and the solution someone ordered becomes the problem a year later.

Every decision wins something and loses something

A bicycle is faster than walking but gets wet in the rain. A car doesn't get wet but stalls in traffic. The metro doesn't stall but doesn't take you to the door.

When an engineer picks a technology, they often look for "the best." That's an illusion. The architect knows: any choice is a compromise along several axes — development speed vs. maintainability, simplicity vs. flexibility, cost now vs. cost in three years. Naming the axes and choosing consciously is the architectural job.

The simple solution is almost always more right than the complex one

A Swiss Army knife does everything, badly. One good knife cuts better than all its siblings inside the Swiss Army version.

The engineer fears missing a requirement and packs the system with everything that might ever be needed. The architect knows: every capability nobody uses is a permanent tax on development. Complexity gets introduced consciously, when it's justified; by default — the simple solution that's easy to change.

Decisions that are hard to undo deserve more attention

You can return an order at a restaurant. You can't return a "yes" at a wedding.

Not all architectural decisions are equal in the cost of being wrong. Choosing a programming language or a database is nearly irreversible. Choosing a logging library is reversible in a day. The architect spends disproportionate time on irreversible decisions and moves fast on reversible ones.

Technical debt is a conscious choice, not laziness

A business loan is fine if you know when and how you'll pay it back. A loan with no repayment plan is the road to bankruptcy.

Sometimes the right move now is to ship something you'll have to rewrite later. That's normal. What's not normal is failing to admit it's a debt. The architect writes down which trade-offs were taken, why, and when they need to be revisited.

Decomposition is the architect's core skill

You can't eat a whale whole. You can — if you cut it into pieces that fit in your mouth.

A big system is incomprehensible. Good architecture is a set of small parts, each understandable in isolation. If explaining one component requires bringing in three others — the decomposition is bad.

High cohesion inside, low coupling outside

A good apartment: the kitchen is organised around one purpose (stove next to sink), and it shares only one wall with the neighbours.

Inside a module, everything should be about one thing. Between modules — minimum contact, through a clear interface. If you change something in one module and have to touch five others — the coupling between them is too high.

Layers are about the direction of dependencies

The floors of a house: the third floor stands on the second, the second on the first, the first on the foundation. You can't put the foundation on the third floor.

In good architecture, the business logic doesn't know about the database, the web UI, or the framework. Inner layers don't depend on outer ones. When you need to swap a database or a framework, the business logic stays untouched. That's Clean Architecture in one sentence.

The interface matters more than the implementation

You don't care what brand of elevator runs in the building. You care that the buttons work the same way, the doors open reliably, and it's quiet.

When one module talks to another, what matters is the contract between them, not how the other one is built inside. Design the boundary first (API, class interface, message schema), then the implementation. Change implementations freely; change contracts only with full awareness of the cost.

Monolith or microservices — a question of maturity, not fashion

One cook in a small kitchen makes a dish faster than ten cooks negotiating over Slack. A hundred dishes per hour, ten cooks do better.

Microservices solve problems of organisational scale and load, not code quality. A small team with microservices is complexity nobody asked for. The architect starts with a monolith and splits it when real pain shows up, not "because it's trendy."

The data model outlives everything else

The foundation of a house outlasts all the walls and roofs that get built on it over a century.

Languages will go, frameworks will change, the UI gets redrawn ten times. The data structure laid down at the start will live — because changing it on a running system is very expensive. It's the first thing the architect spends time on and the last thing they rush to fix.

Single source of truth — each fact lives in one place

If everyone in the family keeps their own shopping list, two will buy milk and nobody will buy bread.

The same information in two places is a guaranteed road to divergence. The architect determines where each fact in the system lives. If data is duplicated (for performance, say), it has to be explicit what is the source of truth and what is a cache or a projection.

State is complexity; the less of it, the better

A clean desk makes work easier. A cluttered one forces you to remember where things are and keeps distracting you.

Every piece of state stored somewhere is something that can fall out of sync, get lost, or contradict other state. Good architecture aims for memoryless functions and short-lived variables. State stays where it's truly needed — usually in the database.

Transactions are about the atomicity of intent

A money transfer is two actions but one intent. Either both writes happened, or neither did. Half is a catastrophe.

When several changes must happen as a single unit, you need transactions. The architect knows which operations in the system are atomic, which can fail partially, and how to live with that. In distributed systems this becomes a central problem (two-phase commit, sagas, idempotency).

A cache is a second truth, and it can lie

The calendar on the fridge is faster than checking your phone. But if someone changed the schedule on the phone — the fridge is already lying.

A cache gives speed but takes away the guarantee of freshness. The architect always understands: what is cached, for how long, and what happens if the cache lies. The hardest cache question isn't how to add one — it's how to invalidate it.

A system boundary is a contract, not code

The boundary between countries isn't a fence — it's the rules: what you can carry across, who gets in, which passport you need.

An API, a message schema, a file format — these are a promise to everyone using them. Changing the contract means changing the promise, and that costs a lot. A good architect designs contracts so they can be extended without breaking existing clients (add fields, never remove).

Synchronous or asynchronous — a choice of coupling

A phone call: both sides have to be online at the same time. A letter: the recipient reads it when convenient.

A synchronous call couples two services in time: if the receiver is down, the sender is stuck too. A message queue breaks that coupling: the sender drops a letter and moves on. That gives you resilience but adds complexity — delay, duplicates, ordering.

Idempotency — an operation can be safely repeated

An elevator is called to the third floor. If ten people press the same button again, the elevator still goes to the third floor and nothing breaks.

In real systems, calls get retried — because of timeouts, network failures, restarts. An operation that's dangerous to retry is a time bomb. The architect makes critical operations (payments, message handling) idempotent by default.

External dependencies are always a risk

If dinner depends on the pizzeria across the street — no big deal, there are backups. If it depends on the only meat supplier in town — critical.

Every external system (API, service, library) can go down, get slow, or change its contract. The architect decides what will happen when that occurs: does the whole system fall, or does it continue with degradation? Often it's worth isolating the external dependency behind your own layer — so it can be swapped later.

Security isn't a feature, it's a way of life for the system

In a museum, security isn't one camera at the door — it's layers: turnstiles, guards, cameras in every room, locks on the display cases.

You can't bolt security on at the end. It gets built in at every layer: authentication, authorisation, encryption, isolation, audit, least privilege. The architect thinks about it from day one and asks at every decision: "What if an attacker gets in here?"

A taxi for three people shouldn't travel like a bullet train. A bullet train won't fit down a side street.

"Make it fast" is a meaningless requirement. The architect formulates: how many requests per second, what latency is tolerable, how does the system behave at peak, what happens past the limit. Optimising too early is waste; not thinking at all is catastrophe.

Scalability is the ability to grow without rewriting

A house designed with the option to add a second floor can be extended without demolition. A house without that option — only by rebuilding from scratch.

The system has to grow in two directions: more users (horizontally — add servers) and more features (modularly — add modules without breaking the old ones). That gets baked into the design, not bolted on after.

Reliability is the system's behaviour when something breaks

A good ship isn't one that doesn't sink (those don't exist) — it's one with ten compartments, where if one is breached, the rest keep floating.

Every part of a system eventually breaks. The architect doesn't try to prevent it — they design how the system survives the failure. Failure isolation, retries, graceful degradation, fallbacks. The main rule: the failure of one component must not kill the whole system.

Observability — you can't fix what you can't see

A car with no fuel gauge, no thermometer, no oil-pressure indicator. It drives until it dies for good.

The system has to tell you about its own state: logs, metrics, traces. When something goes wrong at three in the morning, you have minutes to find the problem. If observability isn't designed in from the start, it's too late to add it — you don't even know where to look.

Readiness for change matters more than being right today

In a new city, roads are built wider than they need to be today. Ten years later there are more cars, and narrow roads would have to be torn up.

The architect doesn't try to predict every future feature (impossible). They leave the option to add features without breaking what exists. That means: clear boundaries, extensible contracts, separating "what" from "how."

Moving from an old house to a new one is a months-long process. You can't just throw everything out and buy it all again.

When a system needs to change (new database, new protocol, new data model) — that's not "rewrite from scratch," that's "carry the system through a transition". Real systems run during changes. The architect thinks about the migration path from the start, otherwise the transition becomes impossible.

Deleting matters more than adding

You can't expand a closet forever. Sometimes you have to throw out the old to make room for the new.

Any successful system accumulates dead code, unused features, stale integrations. It's a tax every developer pays every day. The architect regularly asks: "What can we delete?" — and sometimes that's the most useful architectural decision of the year.

The best architecture is the one that wasn't needed

The strongest wall is the one that never had to be torn down, because nothing extraneous was wedged behind it.

Sometimes the right architectural decision is not to make an architectural decision. Don't introduce an abstraction layer "for the future." Don't split the monolith "because someday." Don't build a plugin system "in case." A good architect knows when to say "not yet" or "we don't need this."

An architectural decision is written down, otherwise it's lost

An oral will dies with the author. A written one outlasts generations.

Every significant architectural decision needs to be recorded: what was chosen, what the alternatives were, why they were rejected, what compromises were accepted. The document isn't needed now — it's needed a year from now, when a new person joins and asks "why is this done so strangely?" The standard format is an ADR (Architecture Decision Record).

A diagram is worth a thousand words

Describing how to get to a house with words is long and often useless. Showing a map takes a second.

The architect always has a diagram of the system: which components exist, how they connect, where the boundaries are. Not perfect — working. It's there to explain things quickly to a new person and to let you see the system whole. The C4 model (Context, Container, Component, Code) is simple and sufficient for most cases.

The architect explains so a non-engineer understands

A good doctor explains the diagnosis to the patient in words the patient understands. A bad one uses medical terms after which the patient nods and understands nothing.

If the architect can only explain a decision to other engineers, they've missed half the job. Business stakeholders, product, legal, security — all of them need to understand the consequences. Translating a technical decision into business language (cost, risk, time) is one of the architect's central skills.

A surgeon who agrees to every request loses patients. A good one refuses when the operation would kill.

The team often asks for decisions that sound reasonable but create long-term problems. The architect has to be able to push back, explain the risk, and sometimes hold the line — even when it's unpopular. And also — be able to admit when they're wrong and change the decision when the counter-argument is stronger.