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

Independent Service Heuristics: a rapid, business-friendly approach to flow-oriented boundaries - DDD EU - Matthew Skelton and Nick Tune

Independent Service Heuristics: a rapid, business-friendly approach to flow-oriented boundaries - DDD EU - Matthew Skelton and Nick Tune

From a talk at DDD Europe 2022

This session is an experience report of using a technique called Independent Service Heuristics (https://teamtopologies.com/ish) to provide a rapid, low-fidelity, business-friendly approach to finding possible team and service boundaries for fast flow. The Independent Service Heuristics (ISH) are rules-of-thumb (clues) for identifying candidate value streams and domain boundaries by seeing if they could be run as a separate SaaS/cloud product. Developed by the authors of the book Team Topologies (Matthew Skelton and Manuel Pais), and elaborated by organisations and members of the DDD community, the ISH approach is particularly suited to situations where stakeholders want rapid results and are sceptical of terminology-heavy approaches used by some DDD practitioners. We describe a recent engagement with a large retail customer in North America where we used ISH and DDD techniques in parallel for multiple perspectives on a challenging situation.

Ef1ef2e1c7ef8b1c2f501fde6895741a?s=128

Matthew Skelton
PRO

June 24, 2022
Tweet

More Decks by Matthew Skelton

Other Decks in Business

Transcript

  1. Independent Service Heuristics a rapid, business-friendly approach to flow-oriented boundaries

    DDD EU 2022 Matthew Skelton (Conflux) and Nick Tune (Independent)
  2. How the Independent Service Heuristics (ISH) work and why you

    might want to try them (to help find good boundaries for flow) 2
  3. Biogs Matthew Skelton Founder at Conflux - confluxhq.com Co-author the

    book ‘Team Topologies’ @matthewpskelton Nick Tune Independent - ntcoding.co.uk Author of the book ‘Architecture Modernization’ @ntcoding 3
  4. • What are ISH & what do they do? •

    Experience with ISH - Nick • Experience with ISH - Matthew • Takeaway points 4
  5. What are the Independent Service Heuristics? What do they do?

    5
  6. “The Independent Service Heuristics (ISH) are rules-of-thumb (clues) for identifying

    candidate value streams and domain boundaries by seeing if they could be run as a separate SaaS/cloud product.” 6 teamtopologies.com/ish
  7. Independent Service Heuristics evolved through helping 40+ customer organizations adopt

    Team Topologies since 2018 🌐 7
  8. ISH principle #1 8 Flow-friendly boundaries

  9. Good boundaries in 2022 are optimized for fast flow. 9

  10. DDD was originally not designed explicitly to work well with

    fast flow: DDD was “pre-cloud”. 10
  11. ISH principle #2 11 Business-friendly language

  12. DDD terminology and approaches can be baffling and inaccessible for

    many people. 12
  13. ISH principle #3 13 Promote group discussion and learning

  14. Coherence in concepts and terminology emerges through group learning sessions

    (a shared experience). 14
  15. ISH principle #4 15 Rapid results needed

  16. ISH is a rapid, ‘low-fidelity’ approach for fast flow boundaries

    that can benefit from using DDD alongside for further insights. 16
  17. Independent Service Heuristics 1. Sense-check: Could it make any logical

    sense to offer this thing "as a service"? 2. Brand: Could you imagine this thing branded as a public cloud service (like AvocadoOnline.com 🥑 )? 3. Revenue/Customers: Could this thing be managed as a viable cloud service in terms of revenue and customers? 4. Cost tracking: Could the organisation currently track costs and investment in this thing separately from similar things? 5. Data: Is it possible to define clearly the input data (from other sources) that this things needs? 6. User Personas: Could this thing have a small/well-defined set of user types or customers (user personas)? 7. Teams: Could a team or set of teams effectively build and operate a service based on this thing? 8. Dependencies: Would this team be able to act independently of other teams for the majority of the time to achieve their objectives? 9. Impact/Value: Would the scope of this thing provide a team with an impactful and engaging challenge? 10. Product Decisions: Would the team working on this thing be able to "own" their own product roadmap and the product direction? 17 https://github.com/TeamTopologies/Independent-Service-Heuristics
  18. Independent Service Heuristics 1 - Sense-check: Could it make any

    logical sense to offer this thing "as a service"? a. Is this thing independent enough? b. Would consumers understand or value it? c. Would it simplify execution? 18
  19. Independent Service Heuristics 2 - Brand: Could you imagine this

    thing branded as a public cloud service (like AvocadoOnline.com 🥑 )? a. Would it be a viable business (or "micro-business") or service? b. Would it be a compelling offering? c. Could a marketing campaign be convincing? 19
  20. 20

  21. 21

  22. 22

  23. 23

  24. 24

  25. 25

  26. 26

  27. 27

  28. 28

  29. 29

  30. Independent Service Heuristics 3 - Revenue/Customers: Could this thing be

    managed as a viable cloud service in terms of revenue and customers? 4 - Cost tracking: Could the organisation currently track costs and investment in this thing separately from similar things? 5 - Data: Is it possible to define clearly the input data (from other sources) that this things needs? 30
  31. Independent Service Heuristics 6 - User Personas: Could this thing

    have a small/well-defined set of user types or customers (user personas)? 7 - Teams: Could a team or set of teams effectively build and operate a service based on this thing? 8 - Dependencies: Would this team be able to act independently of other teams for the majority of the time to achieve their objectives? 31
  32. Independent Service Heuristics 9 - Impact/Value: Would the scope of

    this thing provide a team with an impactful and engaging challenge? 10 - Product Decisions: Would the team working on this thing be able to "own" their own product roadmap and the product direction? 32
  33. What are these ISH questions actually doing? 33

  34. 34 Viability

  35. 35 Existing SaaS

  36. 36 Decoupled?

  37. 37 Outsource-able?

  38. 38 Use biz expertise

  39. 39 Hinting at Haier

  40. ISH uses intuition and experience from domain experts and engineers

    to explore viable services 40
  41. Experience with ISH - Nick 41

  42. Case Study: North-American ecommerce market leader Health-related industry Regulatory obstacles

    Ambitious growth 42
  43. Why I Decided to Use ISH 43

  44. Validate & Refine: Are These Good Boundaries? 44

  45. Iteratively Identifying Value Streams 45 Credit: Team Topologies Academy academy.teamtopologies.com/courses/independent-value-streams-with-domain-driven-design

  46. Biz Context: Single to Multiple Verticals 46

  47. Biz Context: Landscape Evolution 47

  48. Biz Context: Do We Need Horizontals? 48

  49. Biz Context: Growing Pains 49

  50. Phase 1: Discovery and Modelling 50

  51. ISH: 1. Sense Check, 2. Brand 51

  52. ISH: 3. Revenue/Customers, 6. Personas 52

  53. ISH: 9. Impact/Value 53

  54. ISH: 5. Data 54

  55. ISH: 7. Teams, 8. Dependencies 55

  56. ISH: 4. Cost Tracking, 10. Product Decisions 56

  57. “Just the phrase 'independent enough' made us really think deeply

    about what level of coupling is acceptable for this domain especially with future evolution in mind.” – Senior Engineering Manager 57
  58. “This ISH session introduced me to a lot of new

    concepts that I never realised were so relevant to software architecture.” – Software Developer 58
  59. Experience with ISH - Matthew 59

  60. Case Study: North-American ecommerce market leader Health-related industry Regulatory obstacles

    Ambitious growth 60
  61. Execs: on-board but unrealistic 61 ~ “When I was building

    ecommerce sites 20 years ago, it was much quicker and simpler … The engineers obsess over details…”
  62. Execs: on-board but unrealistic 62 ~ “We want to see

    results in a few hours … How hard can it be to find some team boundaries?”
  63. Our approach: visual “heat-map” 63 Immediate sense of consensus or

    ambiguity. Identify areas for splitting off or further investigation.
  64. “I really like using the ISH as a rule of

    thumb for where we draw high level boundaries w/in the org.” – Head of Strategy 64
  65. “... this is how we can build teams that are

    as independent as possible while maintaining laser like focus on outcomes …” – Head of Strategy 65
  66. We used Independent Service Heuristics to help people realize what

    is involved in finding good boundaries for fast flow 66
  67. Case Study: Large retailer in South-East Asia Differentiating via digital

    services 67
  68. Wide spectrum of roles participating 68 • Engineering directors •

    Engineers • Head of SRE (reliability) • Product directors - physical goods • Product directors - digital services • CTO • Warehouse manager
  69. ISH bridged physical and digital product needs 69 checkout flow,

    High Net Worth customers, order picking, returns, shipping & fulfilment, warehouse management, …
  70. Our approach: visual “heat-map” 70

  71. “The framework and shared language [of] ISH … was transformational

    to the discussions … about our organisation and team structure.” – Head of Product 71
  72. “Thanks to the Team Topologies and ISH framework our team

    structure is more autonomous, meaningful, and productive.” – Head of Product 72
  73. Biz and product people often have an intuitive lightbulb moment

    💡 with ISH and become enthusiastic 73
  74. Takeaway points - ISH 74

  75. ISH is a rapid, ‘low-fidelity’ approach for fast flow boundaries

    that can benefit from using DDD alongside for further insights. 75
  76. Going through the ISH heuristics raised important topics that focusing

    on the domain only didn’t surface 76
  77. People would often mention heuristics in meetings - they started

    to become ingrained in day-to-day thinking 77
  78. We did design with a diverse group and didn’t need

    to introduce much theory or explain weird terminology 78
  79. Nick was skeptical of not starting with Event Storming -

    but the ISH discovery workshop had high engagement and enthusiasm. 79
  80. ISH increases practitioner and manager-level awareness of “service-oriented” - the

    business reasons for a change (rather than making changes to “an IT system” that happens to be easy to deploy) 80
  81. Biz and product people often have an intuitive lightbulb moment

    💡 with ISH and become enthusiastic 81
  82. ISH addresses many dimensions for flow-friendly boundaries: viability, (de)coupling, existing

    SaaS, outsource-able, Haier-style micro enterprises, … 82
  83. Try the Independent Service Heuristics (ISH): teamtopologies.com/ish 83

  84. Thank you Matthew Skelton Founder at Conflux - confluxhq.com @matthewpskelton

    Nick Tune Independent - ntcoding.co.uk @ntcoding 84 teamtopologies.com/ish