Definition: Software architecture is the fundamental structure of a system that defines its components, the relationships between them, and the principles that guide its design and evolution. It's the "blueprint" that determines how software is organised and behaves.
— Source: NERVICO, Software Development Consultancy
What is Software Architecture
If code is what makes software work, architecture is what makes software keep working as it grows, changes and evolves. It's the set of structural decisions that affect the entire system.
Good architecture goes unnoticed. Bad architecture is noticed every time you try to make a change.
Components of an Architecture
Components
The "blocks" that form the system: services, modules, databases, APIs, user interfaces. Each component has a specific responsibility.
Connectors
How components communicate: REST APIs, message queues, events, direct calls. The choice of connector affects coupling and scalability.
Constraints
The rules that limit how components can interact. For example: "the frontend never accesses the database directly" or "all services must authenticate".
Common Architectural Patterns
Monolith
All code in a single application. Simple to start, can become difficult to maintain as it grows. Not bad by default — many successful projects are well-structured monoliths.
Microservices
System divided into small, independent services. Each service deploys separately. Greater operational complexity, but better scalability and team autonomy.
Serverless
Functions that execute on demand without managing servers. Ideal for variable loads. Can generate vendor lock-in and is hard to debug.
Event-Driven
Components that communicate via events. High decoupling, but harder to reason about data flow.
Why Architecture Matters
- Scalability: Thoughtful architecture allows growth without rewriting everything.
- Maintainability: Organised code is code that can be changed without fear.
- Performance: Architectural decisions directly affect speed.
- Costs: Bad architecture generates extra work on every change.
- Onboarding: New teams understand a well-structured system faster.
When to Think About Architecture
Always, but proportionally. An MVP doesn't need microservices. A system with millions of users can't be a 500-line script.
Architecture should evolve with the product. What matters is making conscious decisions and documenting them, not getting it right the first time.
Signs of Architectural Problems
- "Every small change breaks something unexpected"
- "We can't deploy without stopping the whole system"
- "We need 3 months to add a simple feature"
- "Nobody understands how this part works"
- "We can't scale without rewriting everything"