Visualizing Sociotechnical Architectures MICHAEL PLÖD FELLOW

Michael Plöd Fellow at INNOQ Mastodon (or Twitter): @[email protected] LinkedIn: https://www.linkedin.com/in/michael-ploed/ Current consulting topics: • Domain-Driven Design • Team Topologies • Transformation from IT Delivery to digital product orgs Regular speaker at (inter-)national conferences and author of a book + various articles

“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 https:/ /esilva.net

Sociotechnical Architectures are a lot about Systems Thinking as well To manage a system effectively, you might focus on the interactions of the parts rather than their behavior taken separately

Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into

There are many great visualization approaches for software architectures

4+1 Model by Kruchten

8 I will mainly focus on arc42 4+1 Model by Kruchten

Arc42 Building Block View C4 Model Level 2: Container Diagram (in parts) Source: https://c4model.com/ Source: https://arc42.org/overview

Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into Arc42 - Building Block View

Arc42 Deployment View Source: https://arc42.org/overview

Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into Arc42 - Deployment View

There are some approaches that can be used for organizational aspects

No content

15 Fundamental Team Topologies Complicated Subsystem Enabling Platform Stream-aligned Image taken from the Team Topologies book

Complicated Subsystem Team • Responsible for building and maintaining a part of the system that is highly dependent on specialist expertise • Team manages the complexity of the subsystem using speci f ic skills and expertise that are usually dif f icult to f ind or recruit. Enabling Team • Work alongside the stream-aligned teams and support them in the area of knowledge building and empowerment. • Have a strong collaborative nature and strive to understand the problems and shortcomings of the other teams • Inhouse consulting team Platform Team • Should give stream-aligned teams the possibility to do their work with a high degree of autonomy, • Platform provides self-service APIs, tools and services as an internal product Stream-aligned Team • Tailored to a business area or organizational capability (Bounded Context) • Is intended to create customer value quickly, safely and autonomously without having to delegate parts of the work to other teams.

A team can have attributes of several fundamental topologies but should be attracted to one of them Enabling Platform Complicated Subsystem Stream- aligned

Team Interaction Modes Collaboration X-as-a-Service Facilitating Image taken from the Team Topologies book

Team Interaction Modes Image taken from the Team Topologies book

Platforms Image taken from the Team Topologies book

Team Topologies is not just 4 Team Types + 3 Interaction Modes

No content

It’s about the f low of work

Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into Team Topologies + Flow + Interactions

https://un f ix.com A pattern and model collection for versatile organizational design

🤔 😝 😩 😬 😇 🥳 😅 😆 😉 😋 😎 🙄 😣 😮 🤐 😆 😉 😊 😋 🙄 😏 😣 😥 😮 M I A D 9 5 Governance Crew Partnership Crew Experience Crew Facilitation Crew Capability Crew Platform Crew Value Stream Crew Forum Base Turf 😌 😛 Chiefs Captain Captain Captain Captain Captain Chair Chair Captain Captain

Crews aka Team, Squad, Cell, Pod Small group of 3-7 people Exists for (at least) the duration of a de f ined mission The Crew is mostly self- organizing There is no manager on the Crew

• Evolutionary • Simple • Hints for identifying team boundaries • Team Interaction Modes • „Opinionated“ / Promotes best practices • Talks about Platforms, and not just Platform teams • Evolutionary • Very f lexible / adjustable • More holistic for complete org design • No Team Interaction Modes! • Not so opinionated, promotes some good advices • It’s easy to get lost with all the options

Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into unFIX NO Flow NO Interactions

There is one approach which bridges the gaps of the other approaches a bit

Strategic Domain Driven Design also has a technique which can be used to visualize sociotechnical relationships: CONTEXT MAPS

Context Maps in Domain Driven Design address relationships between Bounded Contexts and teams. They start „bounded context f irst“.

33 Dependencies between teams Team Dependencies Mutually Dependent • Two software artifacts or systems in two bounded contexts need to be delivered together to be successful and work. • There is often a close, reciprocal link between data and functions between the two systems. Free • Changes in one bounded context do not in f luence success or failure in other bounded contexts. • There is, therefore, no organizational or technical link of any kind between the teams. Upstream / Downstream • An upstream context will in f luence the downstream counterpart while the opposite might not be true. • This might apply to code but also on less technical factors such as schedule or responsiveness to external requests.

These patterns address a diverse variety of perspectives 34 The context map uses patterns to describe the contact between bounded contexts and teams Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Partnership Big Ball Of Mud

Check out DDD Crew on GitHub https://github.com/ddd-crew/context-mapping •Cheat Sheet for all of the patterns and Team Relationships •Context Mapping Starter Kit for Miro (as a downloadable Board Backup) •Creative Commons

I’ll just mention a few of the patterns here to give you a taste

Schufa OHS 37 Open-host Service WebService The Open-host Service is a public API •One API for several consumers •No point-to-point API •Has a common, general purpose model and functionality •The team providing the Open-host Service is an upstream team Bank A Bank B U D D

Anticorruption Layer The Anticorruption Layer translates one model to another one •Transforms an external model from another team / bounded context / system to another internal one •Reduces the amount of coupling to a single layer •The team implementing an Anticorruption Layer is always downstream Credit Sales Funnel Scoring OHS ACL U D Credit Application Person Scoring Credit Scoring Security Scoring

39 Conformist The Conformist slavishly adheres to the upstream model •There is no model-to-model transformation •Motivation: Simplicity, contracts, force or delight (for the upstream model) •The team implementing a Conformist is always downstream Credit Sales Funnel Scoring OHS CF U D Credit Application

40 Shared Kernel Shared Kernel is a subset of a domain model that two teams share •„Physically“ shared artifact between two teams •Examples: shared JARs or database •High degree of coupling requires a high amount of coordination between the involved teams •Shared Kernel is no Anti-Pattern but use with caution Credit Sales Funnel Scoring Credit Application SK

Scoring Credit Sales Funnel Partnership Partnership is about cooperative relationships between teams •Establishes a process for coordinated planning of development and joint management of integration •Not technical at all, Partnership is plain organizational •Recommended for teams which depend on a Shared Kernel We want to adjust something Ok, let’s coordinate our efforts

Customer-Supplier A Customer-Supplier development gives the downstream team some in f luence •Downstream requirements factor into upstream planning. Therefore, the downstream team gains some in f luence over the priorities and tasks of the upstream team •Customer-Supplier is organizational •Mind „vetoing customer“ and customer against an OHS as anti-patterns Credit Sales Funnel Scoring CUS SUP U D We need more f ields in the application Ok

System ABC Upstream Downstream System Y Open Host Service Anticorruption Layer You can visualize different perspectives Customer Supplier • Call Relationship • Team Relationship - Level 1 • API Level • Model Propagation • Team Relationship - Level 2

44 The patterns address various aspects Team Relationships Model Propagation API / „technical“ Open-host Service (✅) ✅ Anticorruption Layer ✅ Conformist ✅ Shared Kernel ✅ (✅) Partnership ✅ Customer-Supplier ✅ Separate Ways ✅ (✅) Published Language ✅ (✅) Big Ball Of Mud ✅

Context Mapping Quiz

Chain of Conformists

High Utilization Open Host Service

OHS + Customer / Supplier CUS SUP

In demand supplier

Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into Context Maps + Governance + Dependencies + Coupling

“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 https:/ /esilva.net

All of these approaches don’t have an holistic approach. We need to combine and improvise.

Introducing STA-Maps

https:/ /github.com/sta-maps/ STA-Maps is currently work in progress

Key Principles Flexibility - there are no f ixed views Open for extension - You are missing something? No problem: just add your building block, team dependency or -relationship. Trade-Offs instead of templates - STA-Maps don't tell you what is right or wrong. Instead they help you to visualize trade-offs in order to better discuss them. Collaborative - STA-Maps are there for modeling and reasoning about sociotechnical systems in a collaborative fashion.

Building Blocks

No content

Alignments

No content

No content

No content

Relationships

No content

No content

No content

Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into STA-Maps + Interactions + Flow + Dependencies + Coupling

Krischerstr. 100 40789 Monheim +49 2173 3366-0 Ohlauer Str. 43 10999 Berlin Ludwigstr. 180E 63067 Offenbach Kreuzstr. 16 80331 München Hermannstrasse 13 20095 Hamburg Erftstr. 15-17 50672 Köln Königstorgraben 11 90402 Nürnberg innoQ Deutschland GmbH www.innoq.com Thank you! Michael Plöd E-Mail: [email protected] LinkedIn: https://www.linkedin.com/in/michael-ploed/ German version of Team Topologies incl. the Remote Team Interactions Workbook Translated by me Released through O’Reilly Germany