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.

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. View Slide

21. View Slide

22. View Slide

23. View Slide

24. View Slide

25. View Slide

26. View Slide

27. View Slide

28. View Slide

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