@emgsilva Sociotechnical Architecture: co-designing technical & organizational architecture to maximize impact Eduardo da Silva @emgsilva | [email protected] | esilva.net 

@emgsilva @emgsilva LEt’s talk about Restaurants... 

@emgsilva @emgsilva Important ”traits” to look for when setting up a Restaurant for success* * Success ⇒ defined clear business goal & mission (the direction for our developments) Please do not “blindly” follow my recommendations to open your restaurant 

@emgsilva @emgsilva Trait 1: Your staff defines your cooking and experiences If you want an amazing French food and drink experience you need to have French chefs and French wine experts; and they have to work together to come up with great combinations 

@emgsilva @emgsilva Trait 2: Chefs cannot cook, serve and do the dishes at the same time... If you want to run your restaurant smoothly and have a strong team for a long time, you need to have enough people and skill to support the different tasks without having people “burning out” (or leaving) 

@emgsilva @emgsilva Trait 3: Kitchen + Serving + Wine + ... = Restaurant Your restaurant has different parts and people working on them (in parallel); however, you want to understand and optimize how it all comes together in order to maximize your “product” (value to customer) 

@emgsilva @emgsilva Trait 4: don’t hand recipes to your chefs… Empower them to discover new recipes Do you want to achieve unique experiences (and value exchange) for your customers? Then enable your crew to "experiment & discover" how to maximize that! 

@emgsilva @emgsilva Trait 5: because #1 restaurant does something it does not mean it will work for you and your crew Your restaurant will have specific constraints, context, mission, etc. Understand those elements and design your restaurant from there! 

@emgsilva @emgsilva Trait 1: Your staff defines your cooking and experiences Trait 2: Chefs cannot cook, serve and do the dishes at the same time... Trait 3: Kitchen + Serving + Wine + ... = Restaurant Trait 4: don’t hand recipes to your chefs… Empower them to discover new recipes Trait 5: because #1 restaurant does something it does not mean it will work for you and your crew 

@emgsilva @emgsilva Trait 1: Your staff defines your cooking and experiences Trait 2: Chefs cannot cook, serve and do the dishes at the same time... Trait 3: Kitchen + Serving + Wine + ... = Restaurant Trait 4: don’t handle recipes to your chefs… Empower them to discover new recipes Trait 5: because #1 restaurant does something it does not mean it will work for you and your crew These traits revolve a lot around “people” and “organization”... and how to have an holistic approach to design 

@emgsilva @emgsilva This is Sociotechnical Architecture! Credit: Nick Tune, KanDDDinsky 2018 

@emgsilva @emgsilva Definition: Sociotechnical architecture “Sociotechnical Architecture is about taking an holistic co-design approach to technical and organizational systems, given the inherent impact they have on each other.” --Eduardo da Silva Source: Sociotechnical Architecture Definition thread “When we are architecting a software system, we must consider the impact on the teams in the organisation and vice-versa.” --Nick Tune 

@emgsilva @emgsilva Nick Tune’s Sociotechnical Evolution (Loop) Credits: Primary Sociotechnical Design Heuristics, Nick Tune 

@emgsilva @emgsilva STOP to just focus on the systems of software; teams are equally important, they listen to the customer and build product 

@emgsilva @emgsilva “why” are Sociotechnical traits important And “How” to address them (...to build software products & teams who build them) 

@emgsilva @emgsilva Trait 1: Your staff defines your cooking and experiences >> Conway’s Law Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. -- Melvin E. Conway In a nutshell: “Software systems architecture always follows organization systems architecture” 

@emgsilva @emgsilva Trait 1: Your staff defines your cooking and experiences >> Conway’s Law Conway's Law is unavoidable! If you don't explicitly address it, it will organically reveal itself… …and (in many cases) HR (as org designers) become the accidental architects of our software systems Credit: Accidental Architects - how HR designs software systems, Team Topologies 

@emgsilva @emgsilva Trait 1: Your staff defines your cooking and experiences >> Conway’s Law Design an organization that mirrors your desired system architecture. How? => Inverse Conway Maneuver* - What system Architecture we want? (think business/product mission/goals; enable high velocity and autonomy for team; etc.) - What is the team/org arrangement we need to make it happen? * Credit: James Lewis 

@emgsilva @emgsilva Trait 2: Chefs cannot cook, serve and do the dishes at the same time… >> Team Cognitive Load “Software that fits in your (team) head(s)” --Daniel Terhorst-North “We should be thinking about limiting the size of software, services, and products to the cognitive load that the team can handle…” --Team Topologies Credits: Team Topologies 

@emgsilva @emgsilva Trait 2: Chefs cannot cook, serve and do the dishes at the same time… >> Team Cognitive Load Goal: Maximize capacity for “Germane” Cognitive Load! Credits: Team Topologies 

@emgsilva @emgsilva Trait 2: Chefs cannot cook, serve and do the dishes at the same time… >> Team Cognitive Load Team Topologies’ “Team-first” approach: - Before jump into implementing the “dream technical architecture”, check the team(s) can successfully build & own it - Namely: do they have enough cognitive load available?* If the answer is “No” and you do nothing, YOU will fail! Credits: Team Topologies | * Team Topologies provides tools for assessing Cognitive Load on team 

@emgsilva @emgsilva Trait 3: Kitchen + Serving + Wine + ... = Restaurant >> Teams Boundaries & Interrelations Effective Teams cannot have “a lot people”*: - ~5: close personal relationship & working memory (~> team) - ~15: can experience deep trust (~> closely related teams) - ~50: can have mutual trust (~> directly related teams or product) - ~150: can remember (~> department/domain) * From Team Topologies, based on Dunbar’s number & observations from typical team < family < department sizes 

@emgsilva @emgsilva Trait 3: Kitchen + Serving + Wine + ... = Restaurant >> Teams Boundaries & Interactions Goal: maximize Stream Aligned Teams available Cognitive Load Credits: Team Topologies 

@emgsilva @emgsilva Trait 3: Kitchen + Serving + Wine + ... = Restaurant >> Teams Boundaries & Interactions Team Topologies “team + interaction types” don’t necessarily address the “discovery of proper team boundaries” This can be done in different manners, Domain-Driven Design (DDD) provides excellent mechanisms for these activities. 

@emgsilva @emgsilva Trait 4: don’t hand recipes to your chefs… >> Continuous Discovery & Delivery in team Product team should be empowered to continuously discover (brainstorm) new ways to make the product better (bottom-up / emergent) …while aligning with overarching org strategies (top-down, multi-product/team) Credits: 2020 Product Management Insights Report, Alpha 

@emgsilva @emgsilva Trait 4: don’t hand recipes to your chefs… >> Continuous Discovery & Delivery in team Enable your team to be continuously on Discovery & Delivery mode* (a.k.a.: “Dual-Track Agile”) This is a capability/skill that should exist in the team * “Dual-Track Agile” | Image credit: Nick Tune 

@emgsilva @emgsilva Trait 5: because #1 restaurant does something it does not mean it will work for you and your crew >> Understand your context & design based on that Credits: Tweet Thread Your organization has a particular context that need to be taken into account when designing your Sociotechnical Architecture Don’t just copy Spotify! 

@emgsilva @emgsilva Trait 5: because #1 restaurant does something it does not mean it will work for you and your crew >> Understand your context & design based on that Don’t (just) do Analogy (copy Spotify). Apply First Principles Thinking: boil things down to their “fundamental truths” and from there design solutions for your specific challenge 

@emgsilva @emgsilva Trait 5: because #1 restaurant does something it does not mean it will work for you and your crew >> Understand your context & design based on that Fact: organizations are continuously changing… so should your sociotechnical architecture Listen for the signals and act Create an Operating Model that embraces change and improvement (Continuous Change / Continuous Improvement => CC/CI) 

@emgsilva @emgsilva Sociotechnical Architecture >> (small) Howto / State-of-the-art* * Work-In-Progress (WIP) 

@emgsilva @emgsilva typical phases of (sociotechnical) architecture 

@emgsilva @emgsilva Design (sub-domains and their relations) the “to-be architecture”; to best realize the business goals Define sub-domains/parts do you want to invest on; and the most suitable org design / teams setup Go into tactical mode in each part of your architecture (and their teams) and get clarity about their relation and how to implement it Align the business priorities and mission and get a clear understanding of your domain (where are you; and where you want to go) typical phases of (sociotechnical) architecture Remarks: greenfield, brownfield, etc., products/orgs will require different flows & emphasis per phase You will go back and forth; 2 <-> 3 is particularly interesting for sociotechnical optimization (tech + org arch) 1: Align & Understand 2: Strategic Architecture 3: Strategy & Org Design 4: Tactical Architecture 

@emgsilva @emgsilva “Domain-Driven Design Starter Modelling Process” github.com/ddd-crew/ddd-starter-modelling-process Domain-Driven Design (DDD) mixed with several other elements (Team Topologies, Wardley Maps, product thinking, etc) Great start for Sociotechnical Architecture design 1: Align & Understand 2: Strategic Architecture 3: Strategy & Org Design 4: Tactical Architecture 

@emgsilva @emgsilva 1: Align & Understand / Event-Storming Focus: collaboratively (no technical barriers) discover & create “big picture” shared understanding of the domain; involve “everyone with knowledge” Image from: https://medium.com/@springdo/a-facilitators-recipe-for-event-storming-941dcb38db0d Event Storming, Alberto Brandolini 

@emgsilva @emgsilva 2: Strategic Architecture / Context Maps Focus: understand the parts (bounded contexts) we have and how they relate with each other Credits: https://github.com/ddd-crew/context-mapping - Michael Plod 

@emgsilva @emgsilva Focus: visualize perform all sorts of analysis and strategy: portfolio overview, dependencies, team setup, etc. 3: Strategy & Org Design / Core Domain Chart Credits: https://github.com/ddd-crew/core-domain-charts - Nick Tune Core, Supporting and Generic are types of domains in DDD 

@emgsilva @emgsilva 4: Tactical Architecture / Bounded-Context Canvas Focus: provide a clear template to design and document the design of a each bounded context. This enables to have a clear overview of the main aspects relevant to a bounded context. Credits: https://github.com/ddd-crew/bounded-context-canvas - Nick Tune 

@emgsilva @emgsilva Books (the team organizational - topologies/interrelations aspects) (the metrics to track and optimize for when building and scaling tech org) (the foundations to strategically arrange our org domains, sub-domains and their relations) (collaborative discovery and understanding of your domain and its parts) 

@emgsilva @emgsilva Thank you! More on this in: http://esilva.net/sociotechnical @emgsilva | esilva.net | [email protected] 

@emgsilva @emgsilva Other great resources (https://github.com/ddd-crew: a lot of resources for Strategic DDD and Sociotechnical Architecture) (Nick Tune’s overview of resources and how to use them to develop your Sociotechnical Architecture [link]) (Michael Plod’s overview on the use of Context Maps to visualize Sociotechenical Architectures [link]) (Patterns for teams topologies, especially DevOps teams [link])