Software Architecture: The Hard Parts
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 Software 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.
That’s what this book and related material 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.
Context
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:
Part 1: 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.
Chapter 1: What Happens When There are no “Best Practices”?
Chapter 2: Discerning Coupling in Software Architecture
Chapter 3: Architectural Modularity
Chapter 4: Architectural Decomposition
Chapter 5: Component-based Decomposition Patterns
Chapter 6: Pulling Apart Operational Data
Chapter 7: Service Granularity
Part 2: …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.
Chapter 8: Reuse Patterns
Chapter 9: Data Ownership and Distributed Transactions
Chapter 10: Distributed Data Access
Chapter 11: Managing Distributed Workflows
Chapter 12: Transactional Sagas
Chapter 13: Contracts
Chapter 14: Managing Analytical Data
Chapter 15: Build Your Own Trade-off Analysis
We don’t provide silver bullets–rather, we inform readers on how to make informed decisions within different contexts. To that end…