Architecture and design

The architecture and design of an IT system is primarily driven by its non-functional requirements, which determine the system’s quality attributes such as its availability, performance, scalability, and security. Functional requirements describe what the system must do; non-functional requirements describe the qualities it must exhibit while doing it, and those qualities are what the architecture has to deliver.

Architecture versus design

"Architecture" and "design" are often used interchangeably, but they mark different points on the same spectrum. Architecture concerns the high-level structure of a system: its major components, the responsibilities assigned to each, and the relationships and interfaces between them. Design – in particular software design – covers the decisions made within and across those components, down to the design patterns and constructs used to implement them. The boundary is not sharp – what counts as an architectural decision in one system is a routine design choice in another – but the distinction is useful because architectural decisions are typically the most expensive to change once a system is built around them.

A common heuristic is that architecture is the set of design decisions that are hard to reverse. Choosing an architectural pattern such as microservices or a monolith, or deciding how a system partitions its data, shapes almost every later decision and is costly to undo. Selecting a design pattern for a single class, by contrast, is usually local and recoverable. The high-level design captures the architectural view, while the low-level design fills in the implementation detail of individual components.

Trade-offs are the work

Most of architecture and design is about making trade-offs between competing quality attributes, because those attributes are frequently in tension. Hardening security often costs performance. Maximizing availability tends to add complexity that hurts conceptual integrity and maintainability. Strong consistency across a distributed system works against latency and partition tolerance. As Richards and Ford put it, everything in software architecture is a trade-off (see system design).

These trade-offs are not abstract. They are made against the system’s non-functional requirements, which is why measurable NFRs matter. A target such as "reads must respond within 500ms" turns a vague quality into a constraint the architecture can be evaluated against, and makes the trade-offs explicit.

What shapes an architecture

Non-functional requirements are the primary driver, but they are not the only force. An architecture is also shaped by the constraints around it.

Organization. Conway’s law observes that systems mirror the communication structures of the organizations that build them. Team and reporting boundaries leave their mark on the design, and teams are sometimes deliberately reshaped to steer a desired architecture.
Existing systems. Most architectures are not greenfield. Legacy systems, shared platforms, and accumulated technical debt constrain what is feasible and push designs toward evolutionary change, eg. the strangler fig pattern.
Technology and people. The available platforms, the team’s skills, and organizational norms all bias the design, for better or worse.

How architectures evolve

An architecture is not fixed at the start of a project. How much up-front design is appropriate depends on the cost of change and the stability of requirements. Big design up-front suits high-cost, stable-requirement environments, while evolvability – building the capacity for change into the design – suits uncertain ones. Top-down and bottom-up design describe where the structure comes from, and most real systems blend the two.

Whatever the approach, the decisions and their rationale are themselves a deliverable. Architectural knowledge management – capturing decisions, trade-offs, and assumptions in artifacts such as C4 models and architecture decision records – keeps the design legible to future maintainers, and conceptual integrity is what keeps the result coherent as it grows.

References

Mark Richards and Neal Ford (2020). Fundamentals of Software Architecture. O’Reilly.