Core Laws of Software Architecture

1. Everything in software architecture is a trade-off
2. Why is more important than how
3. Most decisions exist on a spectrum, not binary choices

– Mark Richards & Neal Ford, Fundamentals of Software Architecture (2020)

These three laws form the foundation of architectural thinking. The first law reminds us that every decision involves compromise; choosing one quality attribute often means sacrificing another. The second emphasizes that understanding the reasoning behind decisions matters more than memorizing implementation details. The third challenges binary thinking and encourages viewing decisions as contextual choices along a continuum.

What Is Software Architecture?

Software architecture encompasses five interconnected dimensions:

Structure defines how the system is organized: the components and their relationships. Think of this as the blueprint showing what pieces exist and how they connect.

Characteristics specify the non-functional capabilities the system must deliver, such as scalability, performance, security, and maintainability. These drive architectural decisions more than functional requirements do.

Components are the behavioral building blocks of the system. Each component has a defined responsibility and encapsulates related functionality.

Style describes the overall implementation pattern and topology, such as layered, microservices, or event-driven architecture. The style determines how components interact and deploy.

Decisions establish the rules and constraints that guide how the system is constructed. These include technology choices, coding standards, and governance policies.

Together, these five dimensions create a complete picture of the system’s architecture. Neglecting any dimension leads to incomplete architectural thinking.

Characteristics drive architectural decisions more than functional requirements do.

Architectural Thinking

Architecture vs Design

Understanding the boundary between architecture and design helps clarify responsibility and scope. Architecture deals with strategic, long-term decisions that are hard to change and involve significant trade-offs. Design focuses on tactical, short-term decisions that are easier to change and involve fewer trade-offs.

When evaluating whether a decision is architectural or design-level, ask yourself: How much planning does this require? How many people are affected by this choice? Does this serve a long-term vision or solve an immediate problem?

Consider database selection. Choosing between a relational database and a document store is architectural because it affects how the entire system stores and retrieves data, influences team skills required, and is expensive to reverse. Deciding on specific table indexes is design because it’s localized, easier to change, and affects fewer people.

The distinction isn’t always clear-cut, but recognizing the difference helps architects focus their energy on decisions with lasting impact.

Technical Breadth vs Depth

Architects must develop technical breadth rather than depth. Breadth means knowing a little about many technologies, patterns, and domains. Depth means expert-level knowledge in a narrow area. While developers benefit from deep expertise in specific technologies, architects need broad awareness across the technology landscape.

The goal is to move technologies and concepts from “unknown unknowns” (things you don’t know you don’t know) into “known unknowns” (things you know exist but don’t deeply understand). When a decision requires deep knowledge, you can then invest time to move that specific area into “knowns.”

Breadth means knowing a little about many technologies, patterns, and domains. Depth means expert-level knowledge in a narrow area.

Core Architectural Skills

Trade-Off Analysis

“Programmers know the benefits of everything and the trade-offs of nothing. Architects need to understand both.” – Rich Hickey

Every architectural decision involves trade-offs. Choosing microservices over a monolith trades simplicity for scalability. Choosing eventual consistency over strong consistency trades immediate correctness for availability. There is no universally correct answer; the right choice depends on context.

When evaluating trade-offs, consider the environment, business drivers, organizational culture, budget constraints, delivery timelines, and team skills. What works for Netflix may not work for a ten-person startup. What works in finance may not work in e-commerce.

Business Translation

Architects must translate business requirements into architecture characteristics. When stakeholders say “the system must be reliable,” that translates into specific architectural decisions about redundancy, failover, monitoring, and recovery procedures. When they say “we need to scale rapidly,” that informs decisions about horizontal scalability, stateless design, and distributed architecture.

Common business justifications map to architectural priorities:

• Cost concerns drive decisions about cloud vs. on-premises, serverless vs. containers, and build vs. buy
• Time to market pressures favor simpler architectures, existing platforms, and reduced customization
• User satisfaction translates to performance, availability, and user experience characteristics
• Strategic positioning influences decisions about vendor lock-in, open standards, and long-term flexibility

Hands-On Coding Balance

Architects must stay technically current through hands-on coding, but they must avoid the Bottleneck Trap. When architects own critical-path code, they become blockers. Every feature waits for the architect’s availability, and delivery velocity drops.

---

Partitioning Strategies

When organizing system components, architects face a fundamental choice: partition by technical capabilities or by business domains. This decision profoundly affects team structure, communication patterns, and long-term maintainability.

Conway’s Law

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

– Melvin Conway (1967)

Conway’s Law observes that team structure directly influences system architecture. If you organize teams by technical specialty (frontend team, backend team, database team), you’ll likely build a technically-partitioned, layered architecture. If you organize teams by business domain (checkout team, inventory team, payments team), you’ll likely build a domain-partitioned architecture.

This happens because people design systems that reflect their communication patterns. Frontend and backend developers who rarely talk will build systems with rigid boundaries between presentation and business logic. Cross-functional teams that collaborate daily will build more integrated vertical slices.

People design systems that reflect their communication patterns.

The Inverse Conway Maneuver deliberately structures teams to encourage the desired architecture. If you want a domain-partitioned architecture, organize cross-functional teams around business domains first. The architecture will follow naturally.

---

Team Topologies

Framework by Matthew Skelton and Manuel Pais from “Team Topologies” (2019)

Team organization directly affects architecture through Conway’s Law, but not all team structures are equal. Matthew Skelton and Manuel Pais identified four fundamental team types that optimize software delivery: