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

Bounded Contexts for Team Organization

Bounded Contexts for Team Organization

Since Conway's Law was discovered in the sixties, we know that the organisation structure and the system design it produces are closely linked. Bounded Contexts can help us create better team autonomy, resulting in more effective software designs.

Let's explore how the coordination cost doesn't scale, introduce the concept of work bandwidth and how it informs the clustering, and contrast that to the traditional ideas of component team vs. feature teams.

51dec3feb906404b8564a3c31d1050f3?s=128

Cyrille Martraire

February 05, 2020
Tweet

More Decks by Cyrille Martraire

Other Decks in Programming

Transcript

  1. @cyriux Cyrille Martraire Bounded Contexts for team organisation

  2. Nick Tune

  3. He usually talks about the socio-technical

  4. I’m his Stunt Double

  5. Don’t worry

  6. I know socio-technical

  7. I used to be a DJ

  8. cyrille martraire PARIS Since 1999 @cyriux Cyrille Martraire

  9. arolla.fr @arollafr crafting architecture

  10. Transformations

  11. @cyriux

  12. so what about this socio-technical stuff?

  13. code is the easy part, collaboration is the hard part

    - Indu.
  14. imagine.

  15. what if we didn’t bother organising teams?

  16. @cyriux Photo by Dimitar Belchev Just people together

  17. @cyriux Photo by Dimitar Belchev Please collaborate!

  18. What does it mean to collaborate?

  19. discussing & agreeing on: goals solutions words & their meaning

    ways to collaborate better where to go out for lunch…
  20. @cyriux Photo by Ethan Hoover

  21. @cyriux Photo by Ethan Hoover

  22. @cyriux Photo by Ethan Hoover coordination cost

  23. @cyriux Photo by Ethan Hoover

  24. @cyriux Photo by Ethan Hoover

  25. @cyriux Photo by Ethan Hoover

  26. @cyriux Photo by Ethan Hoover

  27. @cyriux Photo by Ethan Hoover

  28. @cyriux Photo by Ethan Hoover

  29. @cyriux lots of talking!

  30. @cyriux meetings!

  31. @cyriux miscommunication!

  32. @cyriux frustration

  33. @cyriux Photo by Taylor Vick

  34. @cyriux Photo by Taylor Vick runtime & co-evolution

  35. @cyriux Photo by Taylor Vick

  36. @cyriux Photo by Taylor Vick

  37. @cyriux Photo by Taylor Vick

  38. @cyriux Photo by Taylor Vick

  39. @cyriux Photo by Taylor Vick

  40. @cyriux Photo by Taylor Vick LATENCY!

  41. @cyriux Photo by Taylor Vick DOWNTIME!

  42. @cyriux Photo by Taylor Vick BIG BANG DEPLOYMENTS!

  43. so what do we do?

  44. we want to reduce the coordination cost

  45. we create smaller groups of people

  46. tribes.

  47. @cyriux the obligatory reference to Spotify

  48. tribes.

  49. @cyriux Photo by Ethan Hoover members know each other

  50. tribes. <100 - 150 people ”Dunbar number” max size of

    tribes
  51. @cyriux

  52. @cyriux for all primates like us

  53. we create smaller groups of people

  54. teams.

  55. @cyriux Photo by Ethan Hoover members know each other

  56. @cyriux Photo by Ethan Hoover they also know what each

    other thinks about any other
  57. @cyriux Photo by Ethan Hoover trust! speed!

  58. @cyriux “There is a high cost associated with work that

    leaves your team” — James Lewis, Thoughtworks
  59. @cyriux

  60. teams. <5-9 people ”2-pizza team”

  61. teams. <5-9 people ”2-pizza team” max size of teams

  62. tribes. teams. <5-9 people <100 - 150 people ”2-pizza team”

    ”Dunbar number” max size
  63. Max size of teams / tribes: you just can’t beat

    that
  64. who deserves to be in?

  65. anyone who can make a difference in the outcome

  66. @cyriux Photo by Hemant Latawa

  67. (3+ amigos) dev product testing UX ops …

  68. only the 5-9 MOST differentiating contributors IN the team

  69. whole teams cross-functional teams

  70. anyone else? outside the team!

  71. anyone else? outside the team! Other team Support group External

  72. ok.

  73. ok. no controversy so far.

  74. @cyriux

  75. whole teams cross-functional teams

  76. so beyond the skills, how do we organise teams?

  77. @cyriux @cyriux the answer to any question is always…

  78. BOUNDED Contexts

  79. @cyriux @cyriux ”it depends”

  80. BOUNDED Contexts

  81. @cyriux “There is a high cost associated with work that

    leaves your team” — James Lewis, Thoughtworks
  82. @cyriux

  83. we want to encapsulate the work within the team

  84. @cyriux Photo by Ethan Hoover work bandwidth

  85. @cyriux Photo by Ethan Hoover work bandwidth

  86. @cyriux Photo by Ethan Hoover

  87. @cyriux Photo by Ethan Hoover

  88. @cyriux Photo by Ethan Hoover

  89. @cyriux Photo by Ethan Hoover

  90. @cyriux Photo by Taylor Vick runtime bandwidth

  91. @cyriux Photo by Taylor Vick ”chatty” communication

  92. @cyriux Photo by Ethan Hoover better clusters

  93. @cyriux Photo by Ethan Hoover better clusters

  94. @cyriux Photo by Ethan Hoover better clusters

  95. keep the bandwidth inside

  96. @cyriux Photo by Ethan Hoover better clusters

  97. @cyriux Photo by Ethan Hoover Bounded Contexts

  98. BOUNDED Contexts

  99. BOUNDED Contexts

  100. BOUNDED Contexts

  101. None
  102. in isolation

  103. keep the work inside

  104. keep the work inside full

  105. @cyriux Photo by Ethan Hoover

  106. heuristics: Bounded Contexts by business sub-domains

  107. heuristics: Bounded Contexts by business sub-domains area of purpose areas

    of expertise
  108. DESIGN DECISION BUSINESS PERSPECTIVE

  109. @cyriux Event Storming PRACTICE

  110. @cyriux e-commerce • SEO, Traffic Acquisition • Marketing & Targeting

    • PIM (Product Identification Management) • Catalogue • Categorization • Search • Recommendation • Pricing, Promotions • Basket • Discount, Loyalties • Shipping Cost Estimation • Payment • (Fraud Detection) • Order Management • Billing • Stock / Overbooking • Shipping • Return • CRM
  111. heuristics: Bounded Contexts by audience experience crafting the optimal experience

    by persona
  112. heuristics: Bounded Contexts by domain-agnostic (generic) stuff areas of expertise

    (for someone else)
  113. Mapping the Potential Bounded Contexts Sub-Domain A sub-sub domain A1

    sub-sub domain B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X1 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4 Very specific Generic Specific audience Domain- Specific Domain- Agnostic Volatile Stable
  114. Mapping the Potential Bounded Contexts Sub-Domain A sub-sub domain A1

    sub-sub domain B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X1 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4 Very specific Generic Specific audience Domain- Specific Domain- Agnostic Volatile Stable by audience
  115. Mapping the Potential Bounded Contexts Sub-Domain A sub-sub domain A1

    sub-sub domain B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X1 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4 Very specific Generic Specific audience Domain- Specific Domain- Agnostic Volatile Stable by sub-domains
  116. Mapping the Potential Bounded Contexts Sub-Domain A sub-sub domain A1

    sub-sub domain B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X1 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4 Very specific Generic Specific audience Domain- Specific Domain- Agnostic Volatile Stable generic sub-domains
  117. Mapping the Potential Bounded Contexts Sub-Domain A sub-sub domain A1

    sub-sub domain B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X1 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4 Very specific Generic Specific audience Domain- Specific Domain- Agnostic Volatile Stable can delegate / SaaS / offshore
  118. Need fewer people! Downscale! #WIN

  119. Mapping the Potential Bounded Contexts Sub-Domain A sub-sub domain A1

    sub-sub domain B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X1 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4 Very specific Generic Specific audience Domain- Specific Domain- Agnostic Volatile Stable you never quite achieve that perfection
  120. Mapping the Target Architecture Sub-Domain A sub-sub domain A1 sub-sub

    domain B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X1 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4 Very specific Generic Specific audience Domain- Specific Domain- Agnostic Volatile Stable SpringBoot Postgres / Elastic Search RabbitMQ Microservice
  121. Mapping the Target Architecture Sub-Domain A sub-sub domain A1 sub-sub

    domain B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X1 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4 Very specific Generic Specific audience Domain- Specific Domain- Agnostic Volatile Stable Modular Monolith
  122. Mapping the Potential Bounded Contexts Sub-Domain A sub-sub domain A1

    sub-sub domain B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X1 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4 Very specific Generic Specific audience Domain- Specific Domain- Agnostic Volatile Stable legacy components not aligned (at all)
  123. Mapping the Potential Bounded Contexts Sub-Domain A sub-sub domain A1

    sub-sub domain B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X1 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4 Very specific Generic Specific audience Domain- Specific Domain- Agnostic Volatile Stable you never quite achieve that perfection c’est la vie!
  124. how did we do before Bounded Contexts ?

  125. Traditionally…

  126. @cyriux

  127. @cyriux Component Component Component Feature Feature Feature

  128. @cyriux Component Component Component Feature Feature Feature Component team

  129. @cyriux Component Component Component Feature Feature Feature Feature team

  130. @cyriux Component Component Component Feature Feature Feature Component teams X

    X X Cross-Component coordination to deliver a feature :(
  131. @cyriux Component Component Component Feature Feature Feature Feature team X

    X X System owners to protect integrity of components :(
  132. @cyriux Feature teams are better!

  133. @cyriux http://www.bebetterleader.com/know-how/how-do-i-form-teams.html Feature teams are better!

  134. but components & features are not independent…

  135. @cyriux https://www.adapttransformation.com/devops-journey/foundations/conways-law/

  136. Any organization that designs a system (…) will inevitably produce

    a design whose structure is a copy of the organization's communication structure ~ Mel Conway
  137. If you have four groups working on a compiler, you'll

    get a 4-pass compiler.
  138. @cyriux https://www.adapttransformation.com/devops-journey/foundations/conways-law/

  139. Conway’s Law: you can’t beat that.

  140. design components boundaries on feature boundaries

  141. BOUNDED Contexts

  142. @cyriux Component Component Component Feature Feature Feature Component team

  143. @cyriux Component Component Component Feature Feature Feature Feature team

  144. @cyriux Component Component Component Feature Feature Feature Component teams X

    X X Feature teams
  145. @cyriux @cyriux domain boundaries ≡ component boundaries

  146. product oriented

  147. Smarter Components Boundaries Sub-Domain A sub-sub domain A1 sub-sub domain

    B1 sub-sub domain C1 Domain Sub-Domain B Sub-Domain C sub-sub domain A2 sub-sub domain C2 Customers Experience X2 Customers Experience X3 Generic enabler Audience Experiences Business (Sub)- Domains Domain- agnostic Enablers Collaborators Experience X4
  148. That’s what they did at Spotify indeed!

  149. @cyriux ”Numerous autonomous squads that function as independent mini-startups”

  150. @cyriux Component Component Component Feature Feature Feature You never quite

    achieve that perfection X X X
  151. @cyriux Component Component Component Feature Feature Feature you will still

    have some cross-component/team coordination X X X X
  152. @cyriux Component Component Component Feature Feature Feature some is acceptable

    X X X X
  153. @cyriux Component Component Component Feature Feature Feature X X X

    X c’est la vie!
  154. @cyriux Component Component Component Feature Feature Feature X X a

    contract!
  155. @cyriux Component Component Component Feature Feature Feature X X a

    contract! stable!
  156. @cyriux Know your decoupling patterns! All the avoidable coupling must

    be avoided!
  157. @cyriux • Depend on a third-party contract • Tunnelling a

    payload
 Generic (e.g. key-value) • Expose your published language other can call • Micro-frontends • GraphQL
  158. @cyriux https://martinfowler.com/articles/data-monolith-to-mesh.html Zhamak Dehghani Data mesh

  159. in Closing

  160. @cyriux BUY MY BOOK!

  161. @cyriux https://medium.com/nick-tune-tech-strategy-blog/the-challenges-and-traps-of- architecting-sociotechnical-systems-94272a7c790f

  162. socio-technical is about teams

  163. and about components

  164. which are both about Bounded Contexts

  165. Take care of your Bounded Contexts

  166. And the Bounded Contexts will take care of yourself.

  167. Thanks! Cyrille MARTRAIRE @cyriux

  168. @cyriux