Software 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 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 trade-offs on either side of the decision, so that the organization can make the best-informed decision.
The material in this intensive workshop represents both the source and derivative of the book https://architecturethehardparts.com: the authors have 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.
This workshop features both exposition and hands-on, group-based exercises to apply the concepts to realistic scenarios.
If you'd like to see Neal Ford in action, you can view the full video of the following session at our main conference held in May 2022.
(1 hour 29 mins)
- What happens when there are no best practices?
- The importance of data in architecture
- Architecture fitness functions
- Sysops squad: architecture components
- Sysops squad: data model
- Discerning coupling in software architecture
- Architecture quantum
- Static coupling
- Dynamic coupling
- Architecture modularity
- Modularity drivers
- Sysops squad saga: creating a business case
- Architectural decomposition
- Is the codebase decomposable?
- Analysis metrics
- Component-based decomposition
- Tactical forking
- Component-based decomposition patterns
- Identify and size components pattern
- Gather common domain components pattern
- Flatten components pattern
- Determine component dependencies pattern
- Create component domains pattern
- Create domain services pattern
- Pulling apart operational data
- Data decomposition drivers
- Data integrators
- Data decomposition
- Step 1: Analyze database and create data domains
- Step 2: Assign tables to data domains
- Step 3: Separate database connections to data domains
- Step 4: Move schemas to separate database servers
- Step 5: Switch over to independent database servers
- Selecting a database type
- Service granularity
- Granularity disintegrators
- Granularity integrators
- Reuse patterns
- Code replication
- Shared library
- Shared service
- Sidecars and service mesh
- Data ownership and distributed transactions
- Assigning data ownership
- Common ownership scenario
- Service consolidation technique
- Distributed transactions
- Eventual consistency patterns
- Distributed data access
- Interservice communication pattern
- Column schema replication pattern
- Replicated caching pattern
- Data domain pattern
- Managing distributed workflows
- Orchestration communication style
- Choreography communication style
- Trade-offs between orchestration and choreography
- Transactional sagas
- Primal forces in dynamic quantum coupling
- Eight transaction saga patterns
- Strict vs loose contracts
- Stamp coupling
- Managing analytical data
- Previous approaches
- The data warehouse
- The data lake
- The data mesh
- Definition of data mesh
- Data product quantum
- Data mesh, coupling, and architecture quantum
- When to use data mesh
- Build your own trade-off analysis
- Qualitative vs quantitative analysis
- MECE lists
- The “out-of-context” trap
- Model relevant domain cases
- Prefer bottom line over overwhelming evidence
- Avoiding snake oil and evangelism
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 revolutionise the IT industry and create positive social change. He is an internationally recognised expert on software development and delivery, especially in the intersection of Agile engineering techniques and software architecture. Neal has authored magazine articles, seven books (and counting), dozens of video presentations, and spoken at hundreds of developer conferences worldwide. His topics include software architecture, continuous delivery, functional programming, and cutting-edge software innovations.
Interested in registering for this workshop?
Click here for details of the current price, which includes a substantial early-bird discount.