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?
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.
This session consists of lecture mixed with group-based hands-on exercises. Attendees won't need technology beyond the ability to reference web sites. The exercises illustrate the tradeoffs illustrated in the lecture, where groups design architectures to solve particular problems.
The target audience is existing architects, aspiring architects interesting in learning about fundamental tradeoffs, and developers working within complex architectures.
No laptop is required, but access to a browser on some device is necessary as the exercises are online.
Outline & Agenda
- What Happens When There Are No Best Practices?
- Discerning Coupling in Software Architecture
- Architecture Quantum
- Static Coupling
- Dynamic Coupling
- Architecture Modularity
- Architectural Decomposition
- Is the Codebase Decomposable?
- Analysis metrics
- Component-Based Decomposition
- Tactical Forking
- Pulling Apart Operational Data
- Data Decomposition Drivers
- Data Integrators
- Data Decomposition
- 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
- 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 Versus Loose Contracts
- Stamp Coupling
- Managing Analytical Data
- 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 Versus Quantative Analysis
- MECE Lists
- The “Out-of-Context” Trap
- Model Relevant Domain Cases
- Prefer Bottom Line over Overwhelming Evidence
- Avoiding Snake Oil and Evangelism
This workshop helps me to back up my architectural decisions with measurements and proofs rather than just by gut feeling.
The workshop reinforces my learning in distributed systems and helps me to consider important aspects when designing the architecture in my business.
Excellent concepts were introduced that I can use to evaluate and discuss architectural choices with colleagues. The workshop provided a vocabulary that makes these discussions easier.