Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Visualizing Sociotechnical Architectures

Michael Plöd
February 12, 2025
9

Visualizing Sociotechnical Architectures

Michael Plöd

February 12, 2025
Tweet

Transcript

  1. 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
  2. “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
  3. 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
  4. Teams Modules Business Domain Should be a model of Should

    be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into
  5. Arc42 Building Block View C4 Model Level 2: Container Diagram

    (in parts) Source: https://c4model.com/ Source: https://arc42.org/overview
  6. 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
  7. 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
  8. 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.
  9. A team can have attributes of several fundamental topologies but

    should be attracted to one of them Enabling Platform Complicated Subsystem Stream- aligned
  10. 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
  11. 🤔 😝 😩 😬 😇 🥳 😅 😆 😉 😋

    😎 🙄 😣 😮 🤐 😆 😉 😊 😋 🙄 😏 😣 😥 😮 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
  12. 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
  13. • 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
  14. 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
  15. Strategic Domain Driven Design also has a technique which can

    be used to visualize sociotechnical relationships: CONTEXT MAPS
  16. Context Maps in Domain Driven Design address relationships between Bounded

    Contexts and teams. They start „bounded context f irst“.
  17. 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.
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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 ✅
  28. 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
  29. “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
  30. 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.
  31. 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
  32. 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