Deciding the shape before writing the code

Architecture is the set of decisions that are expensive to change later. Everything else is implementation, and confusing the two is why teams spend weeks arguing about things that do not matter and minutes on things that do.

What is expensive to change. How the system is split into parts and how those parts communicate. Where the data lives and how it is structured. What runs where. How the system is deployed. What you depend on that you do not control.

What is cheap to change. Almost everything inside a well bounded component. A function, a class, an algorithm, a library used in one place.

So the architectural question is not which framework, which is usually a cheap decision, but where the boundaries are.

Architecture serves the qualities the system needs, and those differ. A system needing high availability is built differently from one needing low cost. One needing to change frequently is built differently from one that must not fail. Naming which two or three qualities matter most for this system is the first real decision, and doing it explicitly prevents optimising for something nobody asked for.

Every choice is a trade. More components means more flexibility and more operational complexity. Caching means speed and staleness. Redundancy means availability and cost. There is no architecture without a cost, and an architect who presents one without naming its cost has not finished thinking.

And architecture is not a document produced once. It is a set of decisions revisited as the system and its requirements change.