Software architecture is the set of significant decisions about how a system is structured: its components, how they interact, how data flows between them and how the system meets its business and technical requirements. A useful test is cost: if a decision would be expensive to change later, it is probably architectural.
Why it matters
Architecture is not about elaborate diagrams. Its value is practical:
- It determines whether the system can grow and be maintained.
- It lets components developed separately work together.
- It gives developers a shared frame for consistent decisions.
The elements of an architecture
- Structure. The components, such as services, modules and databases, and how they are organized.
- Behaviour. How the system responds to inputs and how its parts communicate.
- Quality attributes. Measurable properties such as performance, reliability, security and maintainability.
- Trade-offs. Every design gains something by giving something up. Flexibility, for instance, often costs simplicity.
Core principles
- Separation of concerns. Each part of the system has one clear responsibility.
- Encapsulation. A component hides its internals and exposes only what others need.
- Loose coupling and high cohesion. Components depend little on each other, while the contents of each belong together.
- Designing for change. Requirements will change, so put boundaries where change is likely.
Quality attributes need numbers
"The system must be fast and secure" cannot be designed against. "95% of searches return within 500 ms at 200 concurrent users" can. Turning vague needs into measurable targets is among the most valuable things an architect does.
What an architect does
- Defines the system's structure and main components.
- Confirms the design meets business and technical requirements.
- Makes decisions affecting scalability, flexibility and maintainability, and records the reasons.
- Bridges the engineering team and other stakeholders.
Thinking architecturally
Architectural thinking goes beyond writing code. It means considering components, their interactions and long-term consequences. Start by asking what must stay true as the system grows. Then design the simplest thing that keeps it true.
To see what happens when structure erodes, read about system entropy. To find out how we approach this for clients, see technical architecture consultancy.
