Architecture: The Hard Parts

Architecture: The Hard Parts

Architecture: The Hard Parts logo

Architecture: The Hard Parts?

Why do authors write technical books about topics like software architecture? They write them when then have figured something out, a “best practice” that is general enough and has matured enough to tell the rest of the world. In fact, architects rely on the current (but always shifting) notion of “best practices” for guidance in solving tough problems.

But what happens where there are no best practices? What if no one has ever solved this particular problem before? What if there are no good answers, just varying degrees of awfulness?

When you’re a software developer, you build outstanding skills in searching online for solutions to your current problem. For example, if you need to figure out how to configure a particular tool in your environment, expert use of Google finds the answer.

But that’s not true for architects.

For architects, many problems present unique challenges because they conflate the exact environment and circumstances of your organization–what are the chances that someone has encountered exactly this scenario and blogged it or posted it on Stack Overflow?

Welcome to Architecture: The Hard Parts

When architects encounter novel problems (by the way, they’re all novel when you become an architect), how do they make decisions if no “best practices” exist and no one has ever solved this problem before?

The real job of an architect is, when presented with a novel situation, how well can they delineate and understand the tradeoffs on either side of the decision, so that the organization can make the best informed decision.

Software Architecture: The Hard Parts book cover

That’s what this book does–start teaching architects how to make informed decisions about tough problems in architecture.

One tried and true way to become an experienced architect is…experience. However, we can accelerate that process a bit by providing two critical things: context and scenarios.


To understand something, you must have enough knowledge and vocabulary to contextualize it–it would be difficult to understand snow if you didn’t understand precipitation. To that end, the Architecture: The Hard Parts book is organized in two parts:

Pulling Things Apart…

To make decisions about architecture, you must understand architecture, particuarly how the pieces fit together. This part describes how architects define coupling in architecture, how to analyse architecture, and how to use that knowledge to pull the pieces apart, for architecture restructuring, migration, or disintegration. We talk about the issues in architecture that drive from monolithic architectures towards distributed systems, including data architecture.

…and Putting Them Back Together

Building distributed architectures is hard, yet many applications end up here because of differing degrees of architecture characteristics. The second part of Architecture: The Hard Parts describes common strategies for granularity for microservices, communication, contract management, and a host of other difficult problems in architecture.

We don’t provide silver bullets–rather, we inform readers on how to make informed decisions within different contexts. To that end…


Interspersed within the context of Architecture: The Hard Parts, we have scenarios: case studies and exercises that present real-world scenarios, to help simulate similar problems in the wild. We have many different scenarios, highlighting both single tradeoffs and also complex, multi-dimensional tradeoffs.

By studying the context and scenarios, amplified by exercises, burgeoning architects can build a faster path towards enough context to understand that everything in software architecture is a tradeoff, and get down to the business of figuring out what those are.

A Work in Progress…

Join us as we build this brand-new intellectual property iteratively. We discovered years ago that the best technical books don’t fall from the sky but, like all good design, emerge from iterative, incremental improvement. We discovered that a terrific way to hone material comes from presenting it to engaged audiences–their questions lead to better versions of exposition, and the more instructors explain things, the more they understand them.

To that end, we have three distinct versions of this IP that we’re currently iterating on; each offers a different dimension/perspective on the material that we’re melding into the final book.

Architecture: The Hard Parts–Scenarios, a 3-hour Hands-on Class on the O’Reilly Online Learning Platform

A scenario-based approach the Hard Parts problems, this class takes a sequence of questions about difficult parts of architecture (“How to choose the correct granularity for microservices”, “How can I achieve high semantic coupling with low syntactic coupling”) and provides the sets of tradeoffs an architecture must consider when confronting these decisions in the wild.

One-day Hands-on Workshop (in person or online)

A one-day, Hands-on workshop that splits the day into two parts: Pulling Things Apart and Putting Them Back Together, which highlights the content of our book.

Two-day Intensive Hands-on Workshop (in person or online)

A two-day, intensive workshop that takes a full day for each part, delving into all the various measurements, metrics, techniques, tradeoffs, and pitfalls for a wide variety of difficult problems in architecture.

More details on each soon, but to give you a flavor of the work in progress, here is the mind-map that we used to organized the in-person two-day workshop at the end of February 2020.

Mind map of Architecture: The Hard Parts work in progress

More to come soon! Stay tuned…