Software Architecture: The Hard Parts teaches FDEs to weigh trade-offs when splitting and connecting customer systems

“There are no easy decisions in software architecture.” The publisher’s description opens with that near-confession, for a book with a refreshingly honest title: Software Architecture: The Hard Parts, subtitled modern trade-off analyses for distributed architectures, by Neal Ford, Mark Richards, Pramod Sadalage and Zhamak Dehghani.

For a Forward Deployed Engineer, that sentence describes an ordinary working day. You arrive at a customer site and find a legacy system, a shared database, and several teams who would rather nobody touched their part. Then you have to connect your company’s product to all of it within a few weeks.

This book does not teach you which technology is best. It teaches something harder: weighing what each option gains and what it costs, then explaining that to the customer with clear reasoning.

Where does the book come from?

O’Reilly released the print edition on 5 November 2021. It runs to about 450 pages, ISBN 978-1-4920-8689-5. It was not written in one go. According to Neal Ford’s training page, the authors taught workshops and training classes for several years, gradually refining both the content and the way they told it before it became a book.

Because it grew out of the classroom, the book reads like a course with characters. Instead of cataloguing patterns, it follows a fictional team called the Sysops Squad through a chain of decisions: whether to make services large or small, what the contracts between services should look like, how to handle distributed transactions, and how operational characteristics are affected.

The book’s promise is direct: to help you sharpen critical thinking about the trade-offs in distributed architecture. Ford also stresses that every architect benefits from learning trade-off analysis, not only specialists.

FDEs are often the ones who must stand in front of the customer and explain decisions like these, so this is a skill you will use almost every week.

First idea: strict or loose contracts are a decision, not a habit

Ford’s course outline has a dedicated section called “Strict Versus Loose Contracts”. For FDEs this is probably the topic you can use tomorrow, because almost every deployment begins with reading data from the customer’s systems.

Imagine the customer’s orders API returns a 40-field payload, and your agent needs only 3: order ID, status and last-updated time.

If you strictly validate all 40 fields, a team on the customer’s side only has to rename a field you never use for your pipeline to break at midnight. If you read only the 3 fields you need and ignore the rest, your system survives those changes.

But loose contracts have a price too. Errors can slip through unnoticed, for instance when the status field changes its values without warning. Strict contracts catch errors early but bind the two sides tightly to each other; loose contracts tolerate change, but in return you have to monitor the data yourself.

At a customer site, the first thing to do is ask the team that owns the API how often they change the schema, and how serious the consequences of bad data would be. Those two answers decide which way you lean.

A small exercise: take a real response from an API you are using and count the fields your code actually reads. For each field, write one line: if this field were renamed or changed its values, would you want the system to break immediately, or keep running and raise an alert?

Second idea: how small is small enough?

The outline also has a section on “Service Granularity”, the question of how large the pieces of a system should be. When a customer has a monolith and wants to modernise, the common reflex is to propose microservices straight away. The book forces you to pause.

Take a hypothetical example: the ordering flow is split into three separate services for orders, payments and inventory. In the monolith, these three steps sat neatly inside one database transaction. After the split, if payment succeeds but the inventory deduction fails, there is no longer a single rollback that covers all three.

That is the distributed transactions problem, one of the topics the book covers. You gain independence but pay for it in network calls, coordination, compensating logic when a step fails, and harder debugging.

Before drawing a decomposition diagram for the customer, ask which parts genuinely change at different speeds and which must be consistent at the same moment. If three parts always change together and must be correct together, splitting them only adds work.

A small exercise: pick one of the customer’s business flows, list each step, and mark the steps that must be correct at the same time. Groups that always move together stay in one service; only the boundaries between groups are worth considering as split points.

Third idea: data is the hardest thing to split

One section of the outline is called “Pulling Apart Operational Data”. Splitting code is relatively easy. Splitting a database that billing, logistics and reporting all read and write is much harder, and this is usually where integration projects stall longest.

Suppose you need your agent to read order status. Reading directly from the shared database is fast, but it ties you to an internal schema that nobody has promised to keep stable. Asking the customer to expose an API is a few weeks slower, but gives you a clear boundary. Neither option is wrong, and the book teaches you to state plainly what each one costs.

A small exercise: for each table your agent reads, note which team owns it and who else writes to it. The table with the most writers is where you should ask for an API first, rather than reading it directly.

Who should read it, and in what order?

The book suits engineers with a few years of experience, who are comfortable with services, APIs and databases and are starting to make architectural decisions themselves. If you are fresh out of university, 450 pages on trade-offs will feel rather abstract before you have personally paid for a decision.

The effective way to read it is to follow the Sysops Squad storyline from the start, to see how the decisions connect. Then go back and study the passages on pulling apart operational data and on contracts, the two topics FDEs meet most often. Save service granularity and distributed transactions for when the customer asks about modernisation.

For your career, this skill is visible to others. When a job description says “integrate with customer systems”, read it as weighing trade-offs like these every week.

On your CV, don’t just write “integrated with ERP systems”. Spell out that you chose to read through an API rather than directly from the database, and accepted a two-week delay in exchange for a stable boundary.

When practising system design, get into the habit of saying out loud what your option costs, not just naming technologies. The book will not give you the answers, but it helps you ask those questions yourself before the customer does.