Sociotechnical Architecture - Designing Systems and Teams Together

You can distinguish between a code problem and a structural problem - and explain why repairing the code without changing the structure will reproduce the same symptoms at the next release.

You recognize when an architecture initiative requires a governance decision before any technical one - and you can describe what a valid mandate looks like versus a conversation that will stall the moment it hits organizational resistance.

You recognize the moment when an architectural decision is blocked by an unresolved product strategy question - and you can explain why every boundary drawn without a shared answer to that question is politically vulnerable the moment it becomes inconvenient.

You can explain Conway's Law from its original source - including the architectural corollary that most practitioners have never read - and identify where it is silently shaping a system you know.

You can explain the Inverse Conway Maneuver as a design stance - not a process - and describe why it requires designing the target architecture before restructuring teams, and what the AWG commits to by adopting it.

You can identify the three prerequisites that must be answered before any architectural boundary can be drawn under the Inverse Conway Maneuver - and explain why skipping any one of them makes every subsequent design decision politically vulnerable.

You can read a Wardley Map as an architectural diagnostic - and explain why it reveals something no architecture diagram can: not how components connect today, but how appropriate your current architectural decisions will remain over time.

You can identify evolutionary mismatch in a software system - and explain why coupling capabilities at different evolutionary stages in the same deployment unit structurally enforces the quality standards of the most critical component on every other component, regardless of intent.

You can decompose a single performance complaint into its capability-specific components, and explain why the same symptom ("we're too slow") requires fundamentally different architectural responses, different quality investments, and different engineering personalities, depending on which capability it refers to.

You can use a Wardley Map's value chain as a first heuristic for DDD subdomain classification - and identify where the heuristic breaks down and why the breakdown is the most important part of the exercise.

You can facilitate a cross-role conversation that surfaces genuine strategic disagreement about Core Domain - and produce a documented decision with explicit reasoning and dissent, rather than a consensus that papers over the disagreement.

You can resolve Make-or-Buy decisions by combining DDD subdomain classification with Wardley evolutionary stage - and produce an investment priority recommendation that translates architectural reasoning into leadership language.

You can identify the architectural precondition that makes investment in a Core Domain capability effective - and explain why adding engineering capacity to a capability locked in a shared deployment unit will not produce the velocity the investment intends.

You can set up a Big Picture EventStorming session for domain discovery - and explain what architects derive from the output that they cannot derive from reading the codebase.

You can read a Big Picture EventStorming output to distinguish clear boundary signals from hotspots and contested language areas - and explain what each type of signal tells an architect about where to look next, without prematurely drawing an architectural boundary.

You can apply cross-process analysis to a Big Picture EventStorming output - reading vertically across horizontal process timelines - to generate Bounded Context candidates grounded in shared responsibility rather than shared vocabulary.

You can define the interfaces between Bounded Context candidates by identifying and classifying the events that cross candidate boundaries - and distinguish between necessary coupling that reflects genuine domain interaction and accidental coupling that reflects historical implementation decisions.

You can apply Ubiquitous Language as a validation criterion for Bounded Context candidates - and explain why language coherence is a necessary but not sufficient condition for a durable boundary.

You can select the fracture plane axes relevant to your architectural context, apply them systematically to a BC candidate set, and produce confirmed or adjusted verdicts for candidates that show consistent signals across multiple axes.

You can recognize when a BC candidate fails under operational fracture plane criteria despite passing language coherence tests - and explain why the failure strengthens rather than undermines the validation methodology.

You can reconstruct the implicit communication of a legacy monolith into named, explicit domain interfaces between validated Bounded Contexts - distinguishing accidental coupling that disappears with the split from genuine domain interaction that requires an explicit contract.

You can determine the upstream/downstream direction for each relationship in a validated BC set - and explain why the direction decision precedes any pattern assignment.

You can assign DDD Context Map patterns to BC relationships with explicit reasoning - distinguishing Customer/Supplier from Partnership, and identifying where an Anti-Corruption Layer protects a Core Domain's autonomy from dependencies it cannot control or negotiate with.

You can read a completed Context Map as an organizational signal - identifying the dominant pattern type, naming the team relationship each pattern implies, and explaining why a Core Domain downstream from all its dependencies is a structural problem no architectural decision alone can resolve.

You can explain why Team Topologies requires an architectural foundation to work, and identify the sequencing error at the root of many failed TT implementations.

You can assign Team Topologies team types and interaction modes to a validated BC set, and explain when a Complicated-Subsystem Team is the permanent right answer rather than a temporary migration vehicle.

You can identify where a Team Topologies formula produces a correct but operationally insufficient answer, and explain why Cognitive Load applies one level deeper than BC boundaries.

You can apply UL and Actor analysis as Fracture Planes to discover ownership areas within a Bounded Context - and explain why team formation must follow internal architecture, not precede it.

You can apply Wardley Mapping at cluster level to identify evolutionary mismatch within a Bounded Context - and use proximity criteria, checked against Cognitive Load headcount, to group clusters into Stream-Aligned Team hypotheses.

You can validate Stream-Aligned Team assignments against Cognitive Load criteria, define intra-BC interfaces between ownership areas, and read the complete result as a fully executed Inverse Conway Maneuver from Design Intent to Modulith structure.

You can identify where an architecturally correct plan collides with organizational commitments - and explain why the collision doesn't mean the architecture was wrong.

You can classify a proposed architectural compromise as a sequencing decision or as a revision of a prior architectural decision - using an explicit satisficing criterion - and produce a documented compromise decision with reasoning and dissent.

You can score candidate first moves for the next increment against value, friction, and reversibility - and select the one that builds real momentum toward the target architecture without colliding with committed work.

You can define a named sequence of intermediate architectures - each declared explicitly stable, with a concrete time horizon and non-negotiables - so that teams know how they will work next sprint, next year, and beyond, rather than experiencing the transition as an indefinite construction site.

You can apply the Strangler Fig pattern behind an existing Anti-Corruption Layer to migrate a live dependency concept by concept - without a cutover event, and with an explicit fallback per concept.

You can design a fitness function that automatically enforces a specific ownership boundary from the Modulith Plan - turning a documented intent into a continuously verified constraint.

You can use sustained fitness function evidence to justify extracting a team's ownership area into its own deployment unit - treating extraction as a consequence of proven stability, not a fresh architectural bet.