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 the Software Architecture: The Hard Parts workshop
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.
The material represents both the source and derivative of the book http://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.
Each workshop features both exposition and hands-on, group-based (for in-person classes) exercises to apply the concepts to realistic scenarios.
Outline:
Architecture Modularity
Structural Design
Architectural Decomposition
Component-Based Decomposition Patterns
Service Granularity
Pulling Apart Operational Data
Creating Bounded Contexts
Data Ownership and Data Access
Managing Contracts
Managing Distributed Workflows
Orchestration versus Choreography
Distributed Transactions
Transactional Sagas
Managing Analytical Data using a Data Mesh
Build Your Own Trade-Off Analysis
Neal is Director, Software Architect, and Meme Wrangler at Thoughtworks, a software company and a community of passionate, purpose-led individuals, who thinks disruptively to deliver technology to address the toughest challenges, all while seeking to revolutionize the IT industry and create positive social change. He is an internationally recognized expert on software development and delivery, esp...
Mark Richards is an experienced, hands-on software architect involved in the architecture, design, and implementation of microservices architectures and other distributed systems in a variety of technologies. He has been in the software industry since 1983 and has significant experience and expertise in application, integration, and enterprise architecture. Mark is the founder of DeveloperToArchit...