Software architecture fundamentals

What software architecture is

“The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution” (IEEE 1471, now ISO/IEC/IEEE 42010).

In practice, architecture is the set of decisions that are hard to change later: how the system is split, how the parts talk, where the data lives. And almost every architecture decision is a trade-off: gaining scalability usually costs simplicity, gaining consistency usually costs availability. That is why an architect’s most honest answer is “it depends”, as long as it is followed by on what.

Types of architect

The software architect:

• Turns business requirements into application architecture.
• Orchestrates developers and domain experts.
• Masters architectural concepts and models and reinforces good practices, including in code reviews.
• Helps in times of crisis.
• Affects the organizational structure, such as how teams are formed (see Conway’s Law).

It can be a role, a department or a job title; what matters is that someone does it.

Why learn architecture

• Understand the macro and micro view of the company’s systems.
• Know more ways to solve a problem.
• Think long term and about the software’s sustainability.
• Better understand why good practices exist.
• Have clarity about the software’s impact on the organization.
• Decide with more confidence.

Architecture × design

• Architecture: global, high-level scope. How components interact and which abstractions exist between them.
• Design: local scope. Design patterns and good practices inside each component.

The boundary isn’t rigid: a design decision that spreads across every service (such as the event format) becomes an architecture decision.

Software sustainability

• Building software is expensive: development and infrastructure teams cost money.
• Software solves a pain: if it doesn’t solve a problem, it has no reason to exist.
• Software must pay for itself: the value generated over time has to exceed the project’s cost.
• It must keep up with the business: accommodate the strategic changes to come.
• The longer it runs, the more it returns: and the more sustainable it is, the later it will need a rewrite.
• The solution must be architected: poorly planned software soon needs to be redone.

Pillars of architecture

• Structure: a solid foundation that makes evolution easy.
• Componentization: components that reflect the business’s needs.
• Relationships between systems: protocols, security and resilience.
• Governance: standards, rules, documentation and clear definitions, so the system doesn’t depend on specific people (see Software documentation).

Architectural requirements

Non-functional requirements that change the architecture. Two systems with the same features can have very different architectures because of them.

Architectural characteristics

These are the “-ilities” the system needs. No system maximizes all of them: pick the few that matter most to the business and accept the trade-offs. Many of them show up in The Twelve-Factor App.

Operational

• Availability: defined by SLA, SLO and SLI (see the glossary); SRE is the engineering practice that ensures it.
• Disaster recovery: data redundancy, backup tests and an action plan for failures of any kind.
• Performance: tools and structure chosen to meet demand.
• Reliability and security: data validation, controlled database access and plans against attacks (e.g. DDoS).
• Scalability: vertical or horizontal, as needed.

Structural

• Configurable: environment variables, environment-agnostic.
• Extensible: easy to swap libraries and vendors.
• Easy installation: standardized environments, pipelines, managed configuration of external tools.
• Reuse: internal libraries and developer tools.
• Internationalization: texts, error messages, currencies.
• Maintainability: SOLID, design patterns, clear structure and tests.
• Portability: switch databases or cloud providers without rewriting.
• Supportability: logs, debugging and observability.

Cross-cutting

• Accessibility: good practices and screen design standards.
• Data retention: old data in cheaper storage.
• Authentication and authorization: identity provider or API gateway, service-to-service authentication, security policies.
• Legal and privacy: compliance with local laws and data leak prevention policies.
• Security: firewall, request validation, vulnerability monitoring.
• Usability: APIs designed for the user journey, not only for the application’s domain.

References

• Fundamentals of Software Architecture (Mark Richards and Neal Ford, O’Reilly): the main reference for architectural characteristics and for the idea that everything is a trade-off.
• ISO/IEC/IEEE 42010: the standard that succeeded IEEE 1471.