📣 Really enjoyed reading Software Architecture: The Hard Parts by Neal Ford, Mark Richards, Pramod S. and Zhamak Dehghani (O’Reilly 2022) as a natural follow-up to Fundamentals of Software Architecture. While Fundamentals introduces core concepts and laws of software architecture, The Hard Parts dives into the messy, trade-off-heavy situations that don’t have clean answers, especially in modern distributed systems.
Many topics that were too deep for Fundamentals effectively became the focus here: modern trade-off analysis for distributed architectures and the tough decisions that Fundamentals could only briefly touch. I finished Fundamentals over the summer break and wrapped up The Hard Parts during the autumn break – safe to say my time off was put to very productive (and nerdy) use! 🙂
What ‘Hard Parts’ mean
Software architecture is full of hard parts: problems that have no clear solution and require difficult trade-offs and careful judgment instead of best practices. What makes them ‘hard’ is that every approach involves trade-offs. Improving one aspect of your system often means compromising another. You might gain performance but lose consistency, or increase security at the cost of convenience.
The key is realizing there is no magic answer 🤔. Instead, the architect’s job is to analyze trade-offs for a given context and pick what fits the business and technical constraints best, documenting the “why” behind each decision. There are no silver bullets in software architecture; there is only systematic, repeatable trade-off analysis.
Example: service granularity
Service granularity is a prime example of a hard part. It is not about counting classes or lines of code, but about deciding what a service is responsible for, which is inherently fuzzy and context-dependent.
Relying solely on the Single Responsibility Principle is not enough, because what counts as ‘one responsibility’ can be interpreted in many ways, ranging from very broad to very narrow. The book’s ‘secret’ 🧠 is to understand granularity disintegrators (forces that push you to split services) and granularity integrators (forces that push you to merge them) and then reason carefully through the trade-offs. Architects are encouraged to use the book’s catalog as a starting set and add their own organization- and domain-specific disintegrators and integrators.
Example: synchronous vs asynchronous
You might have heard statements like: always use asynchronuos communication in distributed architecture. Well, ‘always’ or ‘never’ does not exist in software architecture. Relevant forces include responsiveness, coupling, scalability, fault tolerance, consistency guarantees, and the additional complexity introduced in design, testing, and operations. Rather than treating async as a universal best practice, architects should decide which communication style matches their business goals and operational constraints, knowing exactly what they are giving up in return.
❄️Every problem is a snowflake
The book states: for architects, every problem is a snowflake. Each situation has its own unique context, constraints, and trade-offs, just like snowflakes, where no two are exactly alike. What works for one problem might fail for another, even if they seem similar. This is why there are no one-size-fits-all solutions – architects must analyze each situation individually and tailor their solution to that specific ‘snowflake’.
Takeaways and highlights:
- 💡iterative design: create a canidate architecture and iterate on that design to refine it and make it better. Software Architecture must be developed and improved continuously rather than treated as a one-time effort;
- 💡transactional sagas: The book provides a clear overview of saga patterns for distributed transactions and evaluates them against forces such as consistency, coordination, and communication overhead. If you are interested in different saga types and when to use them, this book is a very useful guide;
- 💡business language: It is important for architects to learn to speak the language of the business. Every trade-off analysis should have a clear business translation, so architectural decisions can be guided by business priorities. Architects should be able to discuss these analyses with stakeholders using terms and concepts they understand;
- 💡‘always’ & ‘never’: Always remember to never say ‘always’ or ‘never’ in software architecture
- 💡it depends: is the common answer from architects. This book gives you the tools to answer the inevitable follow-up question: ‘depends on what’?
- 💡fitness functions: mechanism that provides an objective integrity check for architectural characteristics. Architects can think of fitness functions sort of like unit tests, but for architectural concerns (unit tests for architecture)
👏In short, this book is a catalog of the kinds of architectural decisions you face in modern distributed systems, along with clear explanations of the pros and cons of each direction you can take. I’d definitely recommend it to anyone involved in designing or evolving complex systems, as it pushes you to truly drill into the hard parts (like a very determined woodpecker 😊) and apply structured thinking to real-world trade-offs – which, of course, is where the real architectural challenge (and value) lives.
Originally published on: https://www.linkedin.com/pulse/software-architecture-hard-parts-ton-donker-ryoge/