Why Software Architecture Is Hard: 8 Core Trade-offs from 'The Hard Parts'

Overview

This article summarizes key insights from the book Software Architecture: The Hard Parts , focusing on the "hard parts" of architecture—those complex trade-offs with no universal best practices.

1. Architecture Definition: Foundations That Are Hard to Change

The term "Hard" carries dual meaning: difficult (the daily trade-offs architects face) and solidity (the underlying structures that become extremely difficult to change later). These hard-to-change decisions constitute the core hard parts of software architecture.

While the steps are simple, the hard parts lurk in the details.

2. Tensions Between Data Concerns and Functional Architecture

Many of the thorniest problems in modern distributed architectures stem from the tug-of-war between data and architecture concerns. In distributed systems, merely splitting code is insufficient; data ownership and consistency must be intertwined with architectural design.

Many of the hard parts of modern architecture derive from tensions between data and architecture concerns, which we untangle in both Part I and Part II.

3. Determining Service Granularity

Deciding the right level of service granularity—how large or small a service should be—is a persistent struggle. Overly fine-grained services introduce distributed transaction and orchestration pain; overly coarse-grained services sacrifice scalability and independent deployment agility.

“Determining the right level of service granularity—the size of a service—is one of the many hard parts of software architecture that architects and development teams continually struggle with.”

4. Breaking Apart a Monolithic Database

“Splitting the database is hard; in fact, it is far more difficult than splitting application functionality.” Data is an enterprise's core asset, and tables are often highly coupled via foreign keys and views, making decomposition fraught with high business disruption risk and technical challenges.

5. Distributed Data Access and Read Patterns

In a monolith, cross-table joins are trivial. Once data is split across independent databases or schemas owned by different microservices, cross-service read-only data access becomes extremely difficult. Architects must make painful trade-offs among performance, latency, data consistency, and service coupling.

After breaking apart data within a distributed architecture, an architect must determine which services own what data. Unfortunately, assigning data ownership to a service is not as easy as it sounds, and becomes yet another hard part of software architecture.

6. Designing Service Contracts

Contracts themselves are an architectural hard part. The formats used to pass information or dependencies between architectural components are defined as "hard part contracts." There is tension between strict contracts (e.g., gRPC) and loose contracts (e.g., REST, GraphQL) regarding strong typing precision versus interface volatility and brittleness.

Thus, contracts are an architecture hard part ; we cover coupling issues involving all types of contracts, including how to choose appropriate ones, in Chapter 13.

7. Code Reuse in Distributed Environments

In a monolith, code reuse is as simple as importing a package or class. In distributed architecture, code reuse becomes a major hard part . Over-pursuing DRY (Don't Repeat Yourself) leads to compile-time or runtime coupling, creating a fragile "distributed monolith"; avoiding sharing entirely causes wasteful duplication.

Code reuse is a hard part of distributed architecture.

8. Handling Errors and Exception Paths

If the world consisted only of perfect "happy paths," software architecture would be simple. However, one of the primary hard parts of software architecture is dealing with complex error conditions and remediation paths . In distributed transactions (Saga pattern), designing compensating updates to roll back failed transactions is an exceptionally complex engineering challenge.

"However, one of the primary hard parts of software architecture is error conditions and pathways."

Applying ADR and Trade-off Analysis

The book's examples of Architecture Decision Records (ADRs) and trade-off analyses are worth studying. The article closes with a reflective question: how can we perform similar trade-off analyses for our own projects?