Software architecture is the set of decisions about a system’s overall structure and behavior: its software elements, the relationships among them, and the properties that matter. It gives teams a way to examine whether a proposed system can meet qualities such as modifiability, availability, and security while those decisions can still be changed.
Architecture includes the reasoning behind the structure. A component diagram without the decisions, trade-offs, and constraints that produced it is only part of the record.
What architecture covers
A software architecture describes the structures used to reason about a system. Those structures include software elements, their relationships, and the properties of both. Architecture concentrates on choices with broad or lasting effects, particularly choices that become costly to reverse once a system has grown around them.
Those choices involve trade-offs among system qualities. The Software Engineering Institute says architecture helps stakeholders analyze how a system will achieve qualities including modifiability, availability, and security. It also warns that failing to identify, prioritize, and manage significant trade-offs can lead to delays and costly rework.
Architecture and design overlap
There is no sharp boundary between architecture, design, and requirements engineering. They run from high-level intentions to low-level details. Architecture generally concerns the overall structure and behavior of the system, while application design can focus on the processes and data that support required functionality.
Martin Fowler describes architecture as the important aspects of a system’s internal design and, in one formulation, the shared understanding expert developers have of that design. That makes the rationale useful, not ceremonial: people working on the system need a common account of the intended structure.
Why teams keep working on it
Architecture supports analysis before implementation, integration, or deployment exposes a problem at greater cost. Fowler argues that accumulated internal cruft makes software harder to modify, which can slow feature work and increase defects.
The work continues after the initial structure is chosen. The SEI recommends documenting intended elements and interrelationships, repeatedly evaluating the architecture against business or mission goals, and analyzing whether the deployed system conforms to the intended architecture.
Styles are choices with costs
A layered structure divides an application into layers with different responsibilities. In the example described by vendor vFunction, a common three-layer arrangement separates presentation, business or application logic, and data persistence. Its described convention allows components to call within the same layer or into lower layers, rather than higher ones.
Microservices take a different structural approach. Fowler describes them as a single application built from small services that run in separate processes, communicate through lightweight mechanisms, are organized around business capabilities, and can be independently deployed through automated machinery. That approach also brings costs: increased distribution, weakened consistency, and a need for mature operational management.
A practical architecture loop
- Identify the system qualities that matter and the trade-offs among them.
- Compare structural options against those concerns rather than treating a named pattern as a default answer.
- Document the intended elements, relationships, decisions, and rationale.
- Re-evaluate the architecture as system goals change, including whether the deployed system still conforms to the intended structure.
That is software architecture in practice: making consequential structural choices explicit early enough to examine, then checking whether the system still reflects them.
Frequently asked questions
What is the difference between software architecture and software design?
There is no sharp universal boundary. Architecture concerns decisions about overall structure and behavior, while application design can focus on processes and data that support required functionality. Both sit on a chain from high-level intentions to low-level details.
What trade-offs do microservices introduce?
Fowler describes microservices as independently deployable services organized around business capabilities, but says they also increase distribution, weaken consistency, and require mature operational management.
How can a team keep architecture aligned with the deployed system?
The SEI recommends documenting intended elements and relationships, repeatedly evaluating fitness against business or mission goals, and analyzing whether the deployed system conforms to the intended architecture.
Sources
- Software architecture — en.wikipedia.org
- Software Architecture | CMU Software Engineering Institute — www.sei.cmu.edu
- Software Architecture Guide — martinfowler.com
- What is Software Architecture? A Comprehensive Guide — vfunction.com
