$30 off During Our Annual Pro Sale. View Details »

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.

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)

    View Slide

  2. How the Independent
    Service Heuristics (ISH)
    work and why you might
    want to try them
    (to help find good boundaries for flow)
    2

    View Slide

  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

    View Slide


  4. What are ISH & what do they do?

    Experience with ISH - Nick

    Experience with ISH - Matthew

    Takeaway points
    4

    View Slide

  5. What are the Independent
    Service Heuristics?
    What do they do?
    5

    View Slide

  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

    View Slide

  7. Independent Service Heuristics
    evolved through helping 40+
    customer organizations adopt
    Team Topologies since 2018 🌐
    7

    View Slide

  8. ISH principle #1
    8
    Flow-friendly
    boundaries

    View Slide

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

    View Slide

  10. DDD was originally not
    designed explicitly to work
    well with fast flow:
    DDD was “pre-cloud”.
    10

    View Slide

  11. ISH principle #2
    11
    Business-friendly
    language

    View Slide

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

    View Slide

  13. ISH principle #3
    13
    Promote group
    discussion and learning

    View Slide

  14. Coherence in concepts and
    terminology emerges through
    group learning sessions (a
    shared experience).
    14

    View Slide

  15. ISH principle #4
    15
    Rapid results needed

    View Slide

  16. ISH is a rapid, ‘low-fidelity’
    approach for fast flow
    boundaries that can benefit
    from using DDD alongside for
    further insights.
    16

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  20. 20

    View Slide

  21. 21

    View Slide

  22. 22

    View Slide

  23. 23

    View Slide

  24. 24

    View Slide

  25. 25

    View Slide

  26. 26

    View Slide

  27. 27

    View Slide

  28. 28

    View Slide

  29. 29

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  33. What are these ISH
    questions actually doing?
    33

    View Slide

  34. 34
    Viability

    View Slide

  35. 35
    Existing SaaS

    View Slide

  36. 36
    Decoupled?

    View Slide

  37. 37
    Outsource-able?

    View Slide

  38. 38
    Use biz expertise

    View Slide

  39. 39
    Hinting at Haier

    View Slide

  40. ISH uses intuition and
    experience from domain
    experts and engineers to
    explore viable services
    40

    View Slide

  41. Experience with ISH - Nick
    41

    View Slide

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

    View Slide

  43. Why I Decided to Use ISH
    43

    View Slide

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

    View Slide

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

    View Slide

  46. Biz Context: Single to Multiple Verticals
    46

    View Slide

  47. Biz Context: Landscape Evolution
    47

    View Slide

  48. Biz Context: Do We Need Horizontals?
    48

    View Slide

  49. Biz Context: Growing Pains
    49

    View Slide

  50. Phase 1: Discovery and Modelling
    50

    View Slide

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

    View Slide

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

    View Slide

  53. ISH: 9. Impact/Value
    53

    View Slide

  54. ISH: 5. Data
    54

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  59. Experience with ISH -
    Matthew
    59

    View Slide

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

    View Slide

  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…”

    View Slide

  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?”

    View Slide

  63. Our approach: visual “heat-map”
    63
    Immediate sense of
    consensus or ambiguity.
    Identify areas for splitting off
    or further investigation.

    View Slide

  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

    View Slide

  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

    View Slide

  66. We used Independent
    Service Heuristics to help
    people realize what is
    involved in finding good
    boundaries for fast flow
    66

    View Slide

  67. Case Study:
    Large retailer in
    South-East Asia
    Differentiating via
    digital services
    67

    View Slide

  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

    View Slide

  69. ISH bridged physical and
    digital product needs
    69
    checkout flow, High Net Worth customers, order picking,
    returns, shipping & fulfilment, warehouse management, …

    View Slide

  70. Our approach: visual “heat-map”
    70

    View Slide

  71. “The framework and shared language
    [of] ISH … was transformational to the
    discussions … about our organisation
    and team structure.”
    – Head of Product
    71

    View Slide

  72. “Thanks to the Team Topologies and
    ISH framework our team structure is
    more autonomous, meaningful, and
    productive.”
    – Head of Product
    72

    View Slide

  73. Biz and product people often
    have an intuitive lightbulb
    moment 💡 with ISH and
    become enthusiastic
    73

    View Slide

  74. Takeaway points - ISH
    74

    View Slide

  75. ISH is a rapid, ‘low-fidelity’
    approach for fast flow
    boundaries that can benefit
    from using DDD alongside for
    further insights.
    75

    View Slide

  76. Going through the ISH
    heuristics raised important
    topics that focusing on the
    domain only didn’t surface
    76

    View Slide

  77. People would often mention
    heuristics in meetings - they
    started to become ingrained in
    day-to-day thinking
    77

    View Slide

  78. We did design with a diverse
    group and didn’t need to
    introduce much theory or
    explain weird terminology
    78

    View Slide

  79. Nick was skeptical of not
    starting with Event Storming -
    but the ISH discovery
    workshop had high
    engagement and enthusiasm.
    79

    View Slide

  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

    View Slide

  81. Biz and product people often
    have an intuitive lightbulb
    moment 💡 with ISH and
    become enthusiastic
    81

    View Slide

  82. ISH addresses many dimensions
    for flow-friendly boundaries:
    viability, (de)coupling, existing
    SaaS, outsource-able, Haier-style
    micro enterprises, …
    82

    View Slide

  83. Try the Independent Service
    Heuristics (ISH):
    teamtopologies.com/ish
    83

    View Slide

  84. Thank you
    Matthew Skelton
    Founder at Conflux -
    confluxhq.com
    @matthewpskelton
    Nick Tune
    Independent -
    ntcoding.co.uk
    @ntcoding
    84
    teamtopologies.com/ish

    View Slide