What is software architecture, and what makes something "architectural" rather than just design?

## The problem this question is really testing Interviewers ask this to see whether you treat "architecture" as a job title and a box-and-arrow picture, or as a decision-making discipline with an economic basis. Answers that just recite "architecture is the high-level structure of a system" are true but hollow — the follow-up is always "high-level according to whom?" ## Two standard definitions, and why you should know both **1. The formal / standards definition.** ISO/IEC/IEEE 42010 (the international standard for architecture description, successor to IEEE 1471) defines architecture roughly as: the *fundamental concepts or properties of a system in its environment, embodied in its elements, their relationships, and the principles of its design and evolution*. Unpacking each term: - **element / component**: an identifiable part of the system — a service, a module, a database, a queue. - **relationship**: how elements are connected — calls, messages, shared data, deployment co-location. - **environment**: everything outside the system that it must live with — users, regulators, other systems, the organization, budgets. - **principles of design and evolution**: the rules that constrain future change ("no module may reach into another module's database", "every write goes through the domain layer"). The key insight buried in this definition is *constraint*. Architecture is largely the set of constraints you deliberately accept so that the rest of the work becomes predictable. **2. The pragmatic definition.** Martin Fowler, in "Who Needs an Architect?" (IEEE Software, 2003), reports Ralph Johnson's formulation: *architecture is the shared understanding that expert developers have of the system design*, and it is *the stuff that's hard to change*. Fowler adds the memorable phrasing: **"Architecture is the decisions that you wish you could get right early in a project."** He is careful to note this is a *social* definition — architecture is whatever the experienced people on the project consider important, and it changes as the project matures. Both definitions point at the same core: **architecture = the decisions whose cost of reversal is high.** ## The dividing line: cost of change, not size A useful mental test for any decision: | Question | If yes, it leans architectural | |---|---| | Does reversing it require coordinating multiple teams? | ✔ | | Does it change contracts other people depend on? | ✔ | | Does it require a data migration or a deployment-topology change? | ✔ | | Does it constrain future decisions (a "one-way door")? | ✔ | | Does it materially affect a quality attribute (latency, availability, security, cost)? | ✔ | | Can one developer change it in one merge request without telling anyone? | ✘ — that's design | Examples that are almost always architectural: - **Decomposition style**: one deployable unit (monolith) vs. many (services); layered vs. hexagonal vs. modular monolith. - **Communication style**: synchronous request/response vs. asynchronous messaging/events; this determines coupling and failure modes across the whole system. - **Data ownership and consistency model**: one shared database vs. database-per-service; strong vs. eventual consistency. Data is famously the hardest thing to un-decide because it has *state* — code can be rewritten, terabytes must be migrated. - **Security and trust boundaries**: where authentication happens, what is inside vs. outside the trust perimeter. - **Deployment/runtime platform** and any framework that inverts control over your code (a framework calls you; a library you call — frameworks are far harder to remove). Examples that are usually design: - Which collection type or algorithm to use inside a function. - Whether to use inheritance or composition inside one module. - Applying a pattern such as Strategy or Factory within a single component. - Naming, formatting, local refactoring. ## Structure vs. design — the relationship The cleanest way to phrase it: **architecture is design, but not all design is architecture.** Grady Booch's line — *"All architecture is design, but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significance is measured by cost of change."* Architecture sets the boundaries and rules; design fills in the inside of each box. They are a continuum, not two disjoint activities, and the same person often does both. In practice the two interact: a poor internal design can force an architectural change (a module so tangled it must be split), and an architectural constraint can dictate designs (an event-driven boundary forces idempotent handlers everywhere). ## "Architecture" is contextual and time-varying The same decision can be architectural or not depending on: - **Organization size.** Choosing a logging library in a 3-person startup is a 20-minute change. In a 2,000-engineer company with 400 services it is a year-long migration — architectural. - **Maturity.** Early in a project the language runtime choice is architectural; ten years later it is simply a fact of life, and the architectural questions have moved to "how do we carve the legacy core apart?" - **Investment in changeability.** Fowler's important corollary: if you get good at change — automated tests, continuous delivery, decoupled modules, abstraction layers — *fewer* decisions remain architectural. The best architects actively shrink the set of irreversible decisions rather than trying to be clairvoyant about them. ## What architecture is NOT - **Not a phase.** It is not "the six weeks before coding". Decisions are made continuously. - **Not a diagram.** Diagrams are *descriptions* of architecture (42010 calls them views/viewpoints); the architecture is the decisions and the resulting properties. A system has an architecture whether or not anyone drew it — often called the *implicit* or *accidental* architecture. - **Not only about structure.** Architecture is primarily how you deliver **quality attributes** (also called non-functional requirements or "-ilities": performance, scalability, availability, security, modifiability, testability, operability, cost). Functional requirements can usually be met by many architectures; quality attributes are what discriminates between them. - **Not the exclusive property of a person titled "Architect".** Every team that makes a hard-to-reverse decision is doing architecture. ## How to answer in an interview Give both definitions in two sentences, then immediately ground it: state the cost-of-change test, give one architectural example and one design example from a system you actually built, and close with the contextual caveat ("the line moves with team size and with how good we are at changing things"). That sequence — definition, test, example, nuance — signals seniority far more than any single definition.