Software Architecture:
The Hard Parts

What is it?

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. Not even modern AI will help. 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 the Software Architecture: The Hard Parts

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.

The material represents both the source and derivative of the book architecturethehardparts.com: 

The authors conducted workshops and training classes for several years, refining the material and the narrative, distilling the difficult problems facing modern architects. Because each software architecture is unique, generic advice doesn’t help (which is why not many advanced software architecture books exist). However, every architect can benefit from learning how to perform trade-off analysis, which is what this material does, using common problems in microservices architectures

Who is it for?

This class is for both existing architects who want to hone their skills in understanding and deriving trade-offs, especially in modern distributed architectures like microservices.

This class is also for architects at the beginning of their career, including "accidental architects"–developers and tech leads who make architecture level decisions but don't have the title yet. All architects must learn how to evaluate trade-offs, and this class helps new architects understand the scope and nuance of the variety of problems.

What background should the participants have?

Participants should have experience with software development and exposure to several software architectures, either as a creator or implementer. Experience with modern distributed architectures such as microservices is a plus but not required (this class will provide a fast-track to understanding the most difficult problems in these architectures.)

What will the participants learn?

This hands-on class focuses on two broad topics in software architecture, static and dynamic coupling in distributed architectures. The first part of the class focuses on static coupling, covering how to determine the appropriate granularity for microservices, how to incorporate data dependencies into architecture design, architecture reuse patterns, and patterns for migration from monoliths to microservices. The second part of the course focuses on dynamic coupling–how to services communicate and participate in workflows with the best trade-offs. It covers patterns in communication (sync/async), consistency (atomic/eventual), and coordination (orchestration/choreography). Then, we cover transactional sagas, combining all the prior forces, and describe how to perform trade-off analysis to achieve the least-worst architecture.

How will it be delivered?

This class is a combination of lecture and group-based, hands-on exercises. The overall group members will be randomly assigned to architecture teams to solve exercises based on the previous exposition.