Software architecture refers to the fundamental structural decisions about a software system—the decomposition into components, the relationships between those components, and the principles and guidelines governing their design and evolution over time. Architecture is not about getting everything right upfront; it is about making the decisions that are hardest to change later and creating a structure within which the system can evolve.
## What architecture defines
- **Component structure**: How the system is broken into modules, services, layers, or other units
- **Communication patterns**: How components interact (synchronous calls, events, messages, shared data)
- **Quality attributes**: How non-functional requirements (performance, scalability, security, maintainability) are addressed
- **Constraints and trade-offs**: What was deliberately sacrificed and why
- **Boundaries**: Where the system ends and external systems begin
## Architecture vs. design
Architecture and design exist on a continuum rather than being cleanly separable. A useful heuristic: architecture is the set of decisions that are **expensive to change**. Choosing between microservices and a monolith is architectural; choosing a variable name is design. The boundary shifts as technology evolves—containerization made some previously architectural decisions (deployment topology) easier to change.
Martin Fowler captures it well: architecture is "the shared understanding that the expert developers have of the system design." Ralph Johnson adds: it is "the decisions you wish you could get right early."
## Common architectural styles
| Style | Characteristics | Trade-offs |
|---|---|---|
| Monolithic | Single deployable unit | Simple to start; hard to scale independently |
| Microservices | Independently deployable services | Flexible scaling; operational complexity |
| Event-driven | Components communicate via events | Loose coupling; eventual consistency |
| Layered | Horizontal layers (UI, business, data) | Clear separation; can become rigid |
| Hexagonal | Ports and adapters isolate core logic | Testable, adaptable; more abstractions |
| Serverless | Functions triggered by events | Pay-per-use; cold starts, vendor lock-in |
## Architecture as decisions
Modern software architecture increasingly recognizes that architecture is not a blueprint but a collection of decisions. Architecture Decision Records (ADRs) capture these decisions explicitly, preserving the context and rationale that would otherwise be lost to context rot. The most important architectural knowledge is often not the structure itself but *why* the structure was chosen—what alternatives were rejected and what trade-offs were accepted.
## Architecture and Conway's Law
Conway's Law states that systems mirror the communication structures of the organizations that build them. This means architecture is not purely a technical concern—it is deeply intertwined with team structure, communication patterns, and organizational design. Effective architects understand that changing the architecture often requires changing the organization, and vice versa.
## Evolutionary architecture
Traditional architecture assumed requirements could be known upfront. Modern approaches embrace evolutionary architecture—building systems that support guided, incremental change across multiple dimensions. Instead of trying to predict the future, evolutionary architecture uses fitness functions and incremental change to guide the system toward desired quality attributes over time.
## The architect's role
The architect's primary job is not to draw diagrams but to:
- Make the hard decisions that cannot be easily reversed
- Communicate those decisions so the team understands and follows them
- Create guardrails that prevent accidental violation of architectural principles
- Evolve the architecture as requirements and context change
- Balance competing quality attributes (you can't optimize for everything simultaneously)