Software Architecture explained: the decisions that are costly to change
A practical definition, popularized by Martin Fowler: architecture is what a team's experienced people consider hard to change. It's not a pretty diagram or a list of technologies — it's the set of structural decisions that shape everything that comes after.
What's the difference between architecture and programming
Programming answers 'how do I make this behavior work'. Architecture answers 'how do I organize the system so ten future behaviors remain possible'. The first decision is local and reversible; the second is global and expensive.
An everyday example: in a house, changing the wall color is programming; moving structural walls is architecture. Both are necessary, but they require different decision timelines.
When should I think about my system's architecture?
Before writing the first feature that depends on an irreversible decision: data model, identity and permission strategy, isolation between customers, integration with external systems, and sensitive-data policy.
The opposite is also a mistake. Designing for a scale that never arrives burns budget and adds permanent complexity. The practical rule is to architect for the next realistic tier, keeping boundaries that allow the system to be split later if needed.
- Decide early: identity, authorization, data model, multi-tenancy, auditing.
- Postpone: queue choice, distributed cache, service separation.
- Leave a trail: clear internal boundaries make future separation cheap.
Monolith or microservices: which makes more sense?
Sam Newman is emphatic that microservices are an organizational choice before a technical one: they solve the problem of multiple teams needing to ship independently. If there's only one team, that benefit doesn't apply — only the cost remains.
A well-modularized monolith, with explicit internal boundaries, delivers almost all the clarity of microservices without the operational cost of networking, distributed deployment, eventual consistency, and fragmented observability.
- Modular monolith: lower operational cost, simple transactions, single deployment.
- Microservices: team independence, selective scaling, failure isolation.
- The cost of microservices: network latency, distributed data, debugging complexity.
- A common, healthy path: start modular and extract services when the pain shows up.
Does architecture affect security and performance?
Directly. Where authorization is enforced determines whether a screen bug turns into a data leak. Where sensitive data travels determines the size of the attack surface. How queries are modeled determines whether the system handles the tenth customer or chokes on the third.
Len Bass and co-authors treat these aspects as quality attributes: performance, security, availability, and modifiability aren't features added later — they're properties that emerge from the chosen structure.
The architect's role: reducing regret
Good architectural decisions are the ones that preserve options. Eric Evans, proposing domain-driven design, argues that software structure should reflect the language and boundaries of the business, so that when the business changes, the impact stays contained in one region of the system.
Not every project needs someone with the title of architect. Every project needs someone to consciously own these decisions and record them.
In short
Architecture is the management of future regret. Decide early what's expensive to change, postpone the rest, and keep boundaries that allow evolution without rewrites.
Use cases
Multi-tenant SaaS
Isolation by organization needs to live in the database and access policies, not just the interface.
Integration with a legacy ERP
An anti-corruption layer keeps the external system's model from contaminating the internal domain.
Seasonal traffic spike
Separating heavy reads from writes usually pays off more than splitting the system into services.
Common mistakes
- Adopting microservices with a single team and no infrastructure automation.
- Leaving authorization only in the interface layer.
- Modeling the database after the screens instead of the domain.
- Choosing technology by trend rather than a real constraint of the problem.
- Not recording decisions: six months later, nobody remembers why.
Best practices
- Write short architectural decision records (context, option, consequence).
- Keep explicit module boundaries inside the monolith.
- Apply authorization as close to the data as possible.
- Define quality attributes with numbers (latency, availability, retention).
- Review the architecture at every relevant product milestone.
Recommended books
Software Architecture in Practice — Len Bass, Paul Clements and Rick Kazman
Formalizes quality attributes and how structure enables them.
Building Microservices — Sam Newman
Shows the benefits, and especially the real costs, of distributing a system.
Domain-Driven Design — Eric Evans
Teaches how to align software boundaries with business boundaries.
Patterns of Enterprise Application Architecture — Martin Fowler
A catalog of recurring patterns in enterprise applications.
Go deeper
Frequently asked questions
- What is Software Architecture?
- It's the set of structural decisions that are hard to reverse: boundaries, data model, communication between parts, and required quality attributes.
- When should I think about my system's architecture?
- Before the first features that depend on irreversible decisions, such as identity, permissions, and data model.
- Does every application need a software architect?
- Not always the title, but it always needs someone to own and record the structural decisions.
- Monolith or microservices: which makes more sense?
- With a single team, a modular monolith almost always wins. Microservices pay off when multiple teams need to ship independently.
- Does architecture affect security and performance?
- Yes. Where authorization is enforced and how data is modeled largely determine risk and the ability to scale.
- What architecture mistakes are most common in early-stage projects?
- Distributing too early, modeling the database from the screens, leaving access rules in the interface, and not documenting decisions.
References
- Martin Fowler — architecture as the set of decisions that are hard to change
- Sam Newman, Building Microservices — microservices as an organizational decision
- Len Bass et al., Software Architecture in Practice — quality attributes
- Eric Evans, Domain-Driven Design — ubiquitous language and bounded contexts
Original content by the i9 Conecty team. Classic concepts are explained in our own words and credited to their authors.