Architecture is the list of decisions that are expensive to change

Ask ten engineers what architecture is and you will get diagrams: boxes, arrows, a queue somewhere, a cache that everyone agrees is important. Diagrams are useful. They are not architecture.

The most useful definition I know is this: architecture is the set of decisions that are expensive to change. Everything else is implementation, and implementation can be fixed on a Tuesday afternoon.

Why the definition matters

It tells you where to spend your care.

Most of the choices in a system are cheap to reverse. Which UI library renders a button. How a function is named. Whether a list is sorted in the database or in the application. Getting these wrong costs a pull request. Agonising over them is a waste of the team's attention.

A small number of choices are the opposite. Getting them wrong costs a migration, a rewrite, or a promise to customers you can no longer keep. Those deserve slow, explicit, written-down thinking.

Where the expensive decisions usually hide

In my experience they cluster in a few places.

The data model. Data outlives code. A table shape chosen in week two will still be there in year three, with millions of rows depending on it. Whether a "project" can have one owner or many, whether a price is stored with its currency, whether a record is ever truly deleted — these are architecture.

Identity and ownership. Who a record belongs to, and how you know who is asking. Changing this later touches every query in the system.

Boundaries with the outside world. Anything a customer, partner or another system depends on: your public API, your URLs, your export formats, your webhook payloads. Other people's code is built against these. You cannot refactor it.

Money and time. How you represent currency, how you handle time zones, how you record when something happened versus when it was recorded. These are small to get right on day one and enormous to fix on day three hundred.

What the system refuses to do. A deliberate limitation can be lifted later. An accidental capability, once customers depend on it, usually cannot be removed.

How to treat an expensive decision

A few habits help.

• Write it down with the reason. Not just the choice — the constraint that drove it. When the constraint changes, the note tells you the decision is now open.
• Delay it if you can. If a decision can be made later with more information and no extra cost, make it later.
• Make it reversible if you cannot delay it. Put it behind an interface, keep the migration path in mind, avoid spreading the assumption across the codebase.
• Choose the boring option. For expensive decisions, the well-understood choice is usually right. Novelty belongs where mistakes are cheap.

The payoff

A team that knows which decisions are expensive can move quickly on everything else. That is the real value of architecture: not a perfect diagram, but the confidence to be fast where speed is safe, because you were careful where it was not.