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

Systems Thinking by combining Team Topologies with Context Maps

Michael Plöd
November 18, 2022

Systems Thinking by combining Team Topologies with Context Maps

Team Topologies and Context Maps are two interesting approaches to visualize sociotechnical architectures. However, using each method on its own you will not be able to capture a truly holistic view of the system as a whole, but you can use both in combination and this is what this talk is about.

This talk will introduce a Systems Thinking perspective on those two approaches and explain how both can be leveraged in combination to get a deep dive on many interactions in a system of teams and software. Those interactions include:
- team relationships
- team dependencies
- propagation of domain models
- governance related communication
- provisioning of APIs / services

However we will also look at the components of the system with Team Topologies being team centric and Context Maps being bounded context centric.

I will finally explain how you can use both methods to visualize alignments between domains, bounded contexts and teams.

This talk assumes that you have a basic understanding of strategic Domain Driven Design (esp. Bounded Contexts and Context Maps)

Michael Plöd

November 18, 2022


  1. Michael Plöd Fellow at INNOQ Follow me on Twitter under

    @bitboss 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. Get my DDD book cheaper Book Voucher: 7.99 instead of

    (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
  3. How can we maximize the value exchange with the customer

    in a continuous fashion at high velocity? Customers Product Organization (digital) Product Money (or maybe data?) Value
  4. “A loosely coupled software architecture and org structure to match”

    is a key predictor of: •Continuous Delivery Performance •Ability to scale organization and increase performance linearly
  5. Some basic ideas… Teams Software Business 
 Domain Should be

 a model of Should be 
 aligned with the team(s) we need the architecture we want
  6. “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
  7. „Team assignments are the f irst draft of the architecture”

    Michael Nygard Author of „Release It“ 8
  8. There are two boundaries to this and we should align

    them Team 
 Boundaries Software 
  9. Bounded Context A Bounded Context is a boundary for a

    model expressed in a consistent language tailored around a speci f ic purpose
  10. What we want to achieve in a Bounded Context Learning

    and mastering domain complexity Conducting experiments / Learning Delivering high 
 value software
  11. 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
  12. Isn’t it about (maybe a reduction / lack of) interactions?

    Autonomy To manage a system effectively, you might focus on the interactions of the parts rather than their behavior taken separately
  13. “An architect should be thinking: 
 Which team interaction

    modes are appropriate for these two teams? 
 What kind of communication do we need between these two parts of the system, between these two teams?“
  14. 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.
  15. Mind the COGNITIVE LOAD of the teams. We need a

    boundary for this! Learning and mastering domain complexity Conducting experiments / Learning Delivering high 
 value software
  16. Teams Team 
 Topologies Services & 
 Interfaces Team Classi

    f ications Enabling Collaboration Team Boundaries 
 „ f irst“
  17. Strategic Domain Driven Design 
 also has a technique which

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

    Contexts and teams. They start „bounded context f irst“.
  19. 29 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.
  20. These patterns address a diverse variety of perspectives 30 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
  21. 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
  22. I’ll just mention a few of the patterns here which

    we will later pick up for the combination with Team Topologies.
  23. Schufa OHS 33 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
  24. 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 
  25. 35 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 
  26. 36 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
  27. Scoring Credit 
 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
  28. 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
  29. 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
  30. 40 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 ✅
  31. 41 Some of the patterns map to team dependencies Team

    Relationships Mutually Dependent • Partnership • Shared Kernel Free • Separate Ways • Published Language Upstream / Downstream • Customer-Supplier • Anticorruption Layer • Conformist • Open-host Service
  32. Teams Team 
 Topologies Context 
 Maps Domain Models Services

 Interfaces Governance Team Dependencies Team Classi f ications Enabling Collaboration „Organizational 
 Solutions“ Team Boundaries 
 „ f irst“ Context Boundaries 
 „ f irst“
  33. Learning with context maps we can dig into the boundaries

    of teams in order to see how they are mapped to their internal responsibilities / software boundaries and if this suits the type of team (stream-aligned, …)
  34. From a Systems Thinking perspective which aims at understanding a

    system as a whole combining Team Topologies with Context Maps makes sense •Team Topologies give us a great starting point by focussing on teams and their core relationships •Context Maps allow us to dig deeper into the interactions of those relationships and add another perspective with their focus on Bounded Contexts •Combining both allows us to really understand a system as a whole
  35. Value Exchange with Customer What enables maximum Value Exchange (Product)

    How are we doing it (Tech / Arch) Who is doing this (Teams) Collaborative 
 Modeling Bounded 
 Contexts Team Topologies 
 Context Maps
  36. 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 Thanks! Michael Plöd Twitter: @bitboss LinkedIn: https://www.linkedin.com/in/michael-ploed/ Book Voucher: 7.99 instead of (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck