Software Architecture: From Features to Systems

Building software is not only implementing features. As an application grows, decisions about boundaries, dependencies, data, interfaces, deployment and maintainability start to determine how fast you can move — and those decisions are architecture, whether or not anyone made them deliberately.

Where does architecture start?

With the problem. Before choosing patterns or technologies, understand the users, the workflows, the requirements, the constraints, the data and the systems this has to integrate with.

Architecture chosen before the problem is understood tends to be the architecture its author most recently read about.

Why separate responsibilities?

A system divides into layers with distinct jobs: presentation, application, domain or business logic, and data.

The exact division varies by project. The principle does not: each part should be understandable on its own, and you should be able to say what belongs in it and what does not. When nobody can answer that, every change touches everything.

What does coupling cost?

When components depend heavily on each other, a change in one forces changes in others, and eventually a small feature requires understanding the whole system.

Some coupling is necessary — parts of a system do need to work together. Unnecessary coupling is the kind that exists because it was convenient at the time: a module reaching into another's internals, business logic in a query, a user interface built around the shape of a table.

Why do interfaces matter?

A clear interface says what a component promises and hides how it keeps the promise. That applies to interfaces between services, modules, databases and external systems.

The benefit is replaceability. If a component's contract is clear and narrow, it can be rewritten or swapped without the rest of the system noticing. If it is not, nothing can be replaced and every improvement is a rewrite.

Does architecture have to be decided up front?

No, and trying to is its own failure. A system serving a small team has genuinely different needs from a large distributed platform, and building the second when you need the first costs time you do not have and complexity you cannot maintain.

Avoid complexity adopted because a pattern is fashionable. Take on complexity when the problem demands it — and design so that the demand, when it comes, does not require starting again.

What is architecture really trading off?

There is rarely one correct answer. Every decision balances performance, reliability, complexity, cost, maintainability, security, what the team can actually operate, and what the business will plausibly need next.

Those pull against each other. The most reliable design is rarely the simplest; the cheapest to build is rarely the cheapest to run. Architecture is choosing which to favour and being explicit about what it costs.

What should an engineer consider?

• Write decisions down, with the reasoning and the alternatives rejected. The next person needs the why, not only the what.
• Design for the change you expect. Which part is most likely to be replaced, and is it isolated?
• Fit the team. An architecture nobody can operate is not an architecture.
• Make failure explicit. What happens when a dependency is unavailable?
• Keep the boundaries observable — if you cannot see what crosses them, you cannot debug or improve them.
• Revisit. The right structure for last year's system may not be right now, and noticing that early is cheaper than noticing it late.

The practical conclusion

Good architecture is not the most sophisticated technology available. It is a structure that fits the problem, that the team can work in, and that can change as the problem does.

---

Related reading: database design, API integration, and custom software versus off-the-shelf.