On August 1st, 2012, a trading firm called Knight Capital pushed new code to its servers and lost $440 million in about 45 minutes. Nothing crashed. The software ran exactly as written, placing thousands of bad trades every second, while nobody could figure out how to stop it in time. One server out of eight never got the update. It still had a piece of old, unused logic that wasn’t supposed to run anymore, and a flag meant for something else turned it back on. That leftover code started firing off trades nobody wanted, faster than anyone could react.
This isn’t really a story about a bug. A bug gets fixed with a patch and a coffee. This problem was decided long before anyone touched that day’s code, in how the system was built, deployed, and monitored. That leads to the question everyone eventually faces: what is software architecture, and why does it matter enough to sink a company before lunch?
Ask Five Engineers, Get Five Answers
If you look for a clear definition of software architecture, you’ll find a dozen different answers from a dozen smart people. Even the main textbook in the field, Software Architecture in Practice, has changed its definition over time. The current version calls it “the set of structures needed to reason about the system”, meaning the pieces, how they relate, and what stays true about both. There’s also an international standard (ISO/IEC/IEEE 42010, if you want to sound official at a dinner party), and it says something similar: the basic parts of a system, found in its elements, their relationships, and the principles behind how it’s built and how it changes.
None of those definitions are exactly wrong. They’re just abstract enough to be easy to miss. Programmer Ralph Johnson put it better: architecture is “the decisions you wish you could get right early in a project.” Grady Booch offered a practical test: architecture is whatever is expensive to change later. If you swap a button’s color, nobody notices. But if you change how your services talk to each other after building fifty of them that way, you could have a very bad quarter. That’s the whole Knight Capital story in one sentence: A small, reasonable-sounding shortcut, which involved leaving the old code on one machine for the time being, ended up being an architectural issue. Fixing it later cost $440 million.
Software Architecture Basics
If you ignore the debates, the basics of software architecture come down to three things. Every definition above agrees on them, even if it doesn’t say so directly:
- The elements are the actual pieces the system is made of. These include services, databases, modules, and anything else that’s really there.
- The relationships describe how those pieces communicate, depend on each other, or even cause problems for each other.
- The properties are the rules that should remain true as the system grows, not just when it is first built.
Think of it like how a building architect uses a blueprint. The blueprint decides where the load-bearing walls go, where the plumbing runs, and how many floors the foundation can support. Paint color and where the couch goes? That’s interior design, and you can change it whenever you want. But if you move a load-bearing wall, you need engineers, permits, and maybe some luck. Software is similar: some decisions are easy to change, while others can’t be touched without affecting everything built on top of them.
Not the Same Thing as Design
People often confuse architecture and design, and it’s an easy mistake to make since both involve decisions about how code fits together. The difference is in the level of detail. Architecture is the big-picture view: what the main parts are and how they work together. Design is one level down, inside a single part, like which pattern you use, how a class is structured, or what a function does. Booch explained it well: architecture is design, but not all design is architecture. Choosing microservices instead of one big application? That’s architecture. Deciding how one service stores its data internally? That’s design. If you get the first one wrong, you’ll feel it for years. If you miss on the second, you can fix it in the next sprint.
The Shapes It Usually Takes
Once you start paying attention, you’ll see the same few patterns appear over and over:
- Monolithic means everything is built and shipped as one unit. It’s simple to start but harder to separate later.
- Microservices are the opposite approach. These are small, independent services, each handling one job and communicating over the network.
- Layered means the system is split into layers, like the interface, business logic, and database, where each layer only communicates with the ones next to it.
- Event-driven means that instead of calling each other directly, parts of the system send out events and let any listeners react.
There’s no single “right” choice in that list. Each one is a trade-off, and picking between them is a big part of the job.
Who Actually Owns These Decisions
So who makes these decisions? “Software architect” might sound like a fancy title, but in reality, it’s more about influence than rank. A senior engineer might be responsible for one service, inside and out. An architect’s choices influence various services, teams, and can span years of effort. In smaller companies, the role often isn’t officially filled, so a senior team member typically handles it in addition to their other responsibilities.
Martin Fowler makes a good point here: the best people in this role aren’t the ones making decisions alone. They’re the ones who help everyone else make good choices, so the whole team shares an understanding of how the system should work. Ralph Johnson’s other quote also resonates: he said architecture is all about focusing on what truly matters, whatever that may be. This is a way of admitting there’s no fixed checklist. It’s just judgment, used early, before it becomes costly to change your mind.
This doesn’t make the decisions any easier. It just means they’re worth identifying, so you can spot the expensive ones while they’re still easy to fix. Knight Capital’s engineers weren’t careless; they were moving fast, like everyone does, and one small shortcut turned out to be critical. It’s rarely clear which decisions matter most until you’re already dealing with the results. The best thing you can do is ask a little earlier than feels necessary: is this the kind of thing we’ll wish we’d gotten right from the start?
