What Is Software Architecture?
Meet DabbaGo, a Pune startup that delivers home-cooked lunch tiffins to office workers. Customers order by 10:30 am, home kitchens cook, and riders deliver by 1 pm. Its first version was built in a hurry by three engineers. Two years later, one early choice, a single database shared by every part of the app, is the reason every release takes a week. That choice was architecture, even though nobody called it that at the time.
The rule
Architecture is the set of decisions that are expensive to change.
Every system is full of decisions. Most are cheap: the colour of a button, the name of a variable, the wording of an error. A few are expensive: what the main parts of the system are, how they talk to each other, where the data lives, and which qualities matter most. Those few are the architecture.
Unpack the rule in three parts:
- Structure. The big parts of the system. For DabbaGo: a customer app, a kitchen dashboard, a rider app, and the server and database behind them.
- Relationships. How those parts depend on each other. Do the kitchen dashboard and the rider app read the same tables, or do they send each other messages?
- Reasons. Why each big choice was made. A decision without its reason is a trap for the next team, who cannot tell whether it is safe to change.
So architecture is not a diagram. A diagram is a picture of the architecture. The architecture is the set of choices, and it exists whether anyone drew it or not. DabbaGo had an architecture from day one; it just was not a deliberate one.
The shortcut
Use the reversal test. For any decision, ask: "If we got this wrong, what would it cost to undo in six months?"
- Minutes or hours, one person → a design detail. Decide quickly and move on.
- Weeks or months, several teams, data to migrate → architecture. Slow down, compare options, write the reason down.
The order button's colour
One line in a stylesheet undoes it. Minutes. Design detail.
The trap is judging by how big a decision feels today. Picking a database takes one meeting and feels small. The reversal test looks at the future cost instead, and that is what makes something architectural. The opposite trap is treating every choice as architecture and holding a meeting about button colours. Save the care for the decisions that deserve it.
A good architect also works to move decisions out of the expensive column. If DabbaGo wraps its SMS provider behind one small interface, switching provider becomes cheap, and the choice stops being architectural.
Drills
Answer fast — trust the rule.
Which DabbaGo decision is most clearly architectural?
What does the reversal test ask about a decision?
DabbaGo never drew a diagram of its first version. Did it have an architecture?
DabbaGo calls its SMS provider only through one small Notifier interface. What does that do to the choice of provider?
Remember
- Architecture is the set of decisions that are expensive to change: structure, relationships and the reasons behind them.
- Reversal test: "what would it cost to undo this in six months?" Weeks and many teams means architecture.
- Traps: judging by how big a choice feels today, and forgetting to record why a costly decision was made.