Multiple Models with Multiple Perspectives in a Cross-Functional Team - Case Study from Healthcare

In many cross-functional teams we encounter communication challenges between different roles in the team. Making domain experts, designers, testers, developers and tech leads align on the shared understanding is not an easy task. This is mainly due to different perspectives that each team member brings to the table, each perspective being a valid one however not adequate on its own. The different perspectives are particularly visible when reasoning about different approaches to the decomposition of the domain problem at hand which leads to different perceptions of subdomains and bounded contexts.

In this case study we will go through different models of domain problem decomposition that helped align the perspectives in a cross-functional team in the healthcare domain. We will go through functional, role-based, user-context based and business capability based decomposition along with pros and cons of each approach, backed up by the feedback provided by the impact each approach had on the data ownership in resulting bounded contexts.

We will wrap-up with the reasoning behind the choice the team actually made and how it played out in structuring the code base, delivering value to their customers, and how it impacted the different roles in the team.

Transcript

1. Multiple Models with Multiple Perspectives in a Cross-Functional Team Case Study From Healthcare DDD Europe 2024 Mufrid Krilic, Domain-Driven Design Coach CoWork, Norway
2. Modeling Breakthrough!
3. Why this talk? «At times, it is bewildering to read all of the material on #DomainDrivenDesign posted here. Close to zero talk about the actual models being fleshed out or related breakthroughs, which, let's face it, are at the heart of it.» - Yves Reynhout on LinkedIn
4. What I do…. • Coaching individuals, teams and organizations • Helping Build Domain-Driven Product Organizations • Feel free to reach out! Product Development Coaching
9. Let’s start with the story….
10. Five Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning different perspectives with Bounded Contexts 4. Delivering value in legacy constrained environments 5. Modeling breakthrough
12. Questions at menti.com 7890 5555 ▪ For patients with identical diagnoses sometimes the treatment has the best effect when done in a group of patients ▪ Examples from different subdomains in healthcare: • Conversation therapy groups in psychiatry • Training sessions post-injury Domain: Healthcare - Group Therapy
13. The Team ….and the constraints
14. Questions at menti.com 7890 5555 The business goal constraint • “Replace the legacy system” • It must work “everywhere” and for “everyone”
15. Questions at menti.com 7890 5555 Legacy system constraint Works “everywhere” and for “everyone”
16. Questions at menti.com 7890 5555 Legacy system opportunity! • Why are we replacing it? • “Complex systems run as broken systems.” • “How Complex Systems Fail” by Richard I. Cook
17. Questions at menti.com 7890 5555 Knowledge Constraint Rather limited domain knowledge • Developers • Tester
18. Questions at menti.com 7890 5555 Knowledge Opportunity! Domain Expert turned Product Owner “customers might be using the legacy system in unpredictable ways”
19. The cross-functional constraint 1 QA 1 Product Owner 4 developers UX-designer? Operations?
23. Five Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning different perspectives with Bounded Contexts 4. Delivering value in legacy constrained environments 5. Modeling breakthrough
24. Strategies to Learn Complex Domains
25. Tight-Loose-Tight (TLT)
26. Questions at menti.com 7890 5555 Two Mindsets • What kind of problems are you working on? • Simple • Complicated • or Complex Problems
27. Simple problems -> no need for TLT! Simple Problems 5. Our Mission 4. Our Users 3. Our Plans 2. My Role 1. My Expertise Outer Alignment Inner Alignment
28. Simple problems -> no need for TLT! Simple Problems Best Practice Rational Decision Making Standards 5. Our Mission 4. Our Users 3. Our Plans 2. My Role 1. My Expertise Automate! Outer Alignment Inner Alignment
29. If you have previous experience, stick to the plan! Complicated Problems 5. Our Mission 4. Our Users 3. Our Plans 2. My Role 1. My Expertise Outer Alignment Inner Alignment
30. If you have previous experience, stick to the plan! Complicated Problems We have previous experience We can trust the plan We can trust our judgement to guide the decisions 5. Our Mission 4. Our Users 3. Our Plans 2. My Role 1. My Expertise Outer Alignment Inner Alignment
31. Hypothesis-driven development 5. Our Mission 4. Our Users 3. Our Plans 2. My Role 1. My Expertise Outer Alignment Inner Alignment
32. Hypothesis-driven development Complex Problems 5. Our Mission 4. Our Users 3. Our Plans 2. My Role 1. My Expertise Outer Alignment Inner Alignment
33. Hypothesis-driven development Complex Problems Never done before Learn from Failure Challenge your assumptions We lack experience 5. Our Mission 4. Our Users 3. Our Plans 2. My Role 1. My Expertise Outer Alignment Inner Alignment
34. Combining TLT-leadership approach with strategic design Discover common goals by domain analysis Evaluating multiple models by collaborative modeling Challenge your assumptions
35. Questions at menti.com 7890 5555 TLT argues for Collaborative Modeling in complex domains The “First Tight” is all about discovering purpose and needs
36. Learning New Domain Healthcare – Group Therapy
37. How to learn a new domain? Discover Use Cases Drill into scenarios Listen! Repeat step 2 • Same or different scenario
38. Questions at menti.com 7890 5555 Use-Case Approach • Identify the most common use cases • or the ones with most “pain”
39. Questions at menti.com 7890 5555 ▪ Setting up a group • Planning ▪ Conducting group appointments • Check-in process Group Therapy Use Cases
40. Group Therapy Planning Somatic Department Rehabilitation after lifestyle affected diagnosis
47. Group Therapy Check-In Somatic Department Rehabilitation after lifestyle affected diagnosis
53. Group Therapy Planning Psychiatric Department Adult Psychiatry
59. Group Therapy Check-In Psychiatric Department Adult Psychiatry
66. Questions at menti.com 7890 5555 Five Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning different perspectives with Bounded Contexts 4. Delivering value in legacy constrained environments 5. Modeling breakthrough
67. Domain Problem Decomposition
68. Questions at menti.com 7890 5555 Data Ownership • A business concept is defined as a set of data properties
69. Questions at menti.com 7890 5555 Functional Decomposition • Boundaries in the system follow the function that a user needs to do hers/his job • Classic approach • Subdomain = Function
70. Group Treatment in Healthcare
71. Domain Model
72. Data Ownership in Domain Model – Functional Decomposition • One single “Group” for different functions • Physician and specialists • Patients • Appointments • Location/Venue • Patient attendance, including no-show • Patients exempted from payment • Invoice – preferred method • Diagnosis-based patient fee • Reference to § in law for compulsory interventions in psychiatry
73. Questions at menti.com 7890 5555 Role-based decomposition • Boundaries in the system based on which roles perform different functions • Leads to more task-oriented model • Subdomain = Role based function
76. Data Ownership in Domain Model – role-based decomposition “Group” planning context • Specialists • Patients • Appointments • Location • Reference to § in law for psychiatry “Group” check-in context • Patient attendance incl. no-show • Cancelled appointments • Patients exempted from payment • Invoice – preferred method • Diagnosis-based patient fee
77. Questions at menti.com 7890 5555 Time- and role-based decomposition • Boundaries in the system based on which roles perform different function at different times • Supports context-oriented systems • Subdomain = Role-based function in a user context
80. Data Ownership in Domain Model – time- and role-based decomposition “Group” planning context • Specialists • Patients • Appointments • Location • Reference to § in law for psychiatry “Group” check-in context • Patients exempted from payment • Invoice preferred method • Diagnosis-based patient fee “Group” billing context • Patient attendance, incl. no-show • Cancelled appointments
81. Questions at menti.com 7890 5555 About Functional Decomposition • Customer/end-user needs are hidden behind functions! • No incentives to decompose • Pull towards canonical domain model
82. Five Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning different perspectives with Bounded Contexts 4. Delivering value in legacy constrained environments 5. Modeling breakthrough
83. Choosing the Bounded Contexts
84. Questions at menti.com 7890 5555 End-users need flexibility • Somatic Rehabilitation • Different courses • Different diagnosis • Psychiatric Therapy • Adult groups • Pediatric groups • Different Locations
85. Questions at menti.com 7890 5555 Flexibility = complexity? • Allowing flexibility everywhere calls for highly customizable systems • Works for “everyone” and “everywhere” • High level of customization => high complexity
86. Questions at menti.com 7890 5555 Flexibility within a Bounded Context The degree of customization in a system is constrained to bounded contexts
87. What did we do?
88. Questions at menti.com 7890 5555 Role-based decomposition • Boundaries in the system based on which roles perform different functions • Leads to more task-oriented model • Subdomain = Role based function
90. Questions at menti.com 7890 5555 Why? The time perspective separates the models Group Checkin is about confirming what happened in an appointment Group Planning is about how appointments are going to happen
91. Hypothesis-driven development 5. Our Mission 4. Our Users 3. Our Plans 2. My Role 1. My Expertise Outer Alignment Inner Alignment
92. Multiple Models Reflected in Code Structure
93. Boundaries by Abstractions Use appropriate abstraction: • Repository • Namespaces
94. Bounded Models • Patient attendance incl. no-show • Cancelled appointments • Patients exempted from payment • Specialists • Patients • Appointments • Location • Reference to § in law for psychiatry
95. Five Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning different perspectives with Bounded Contexts 4. Delivering value in legacy constrained environments 5. Modeling breakthrough
96. Discovering value chains with Context Mapping
98. Questions at menti.com 7890 5555 Context Mapping • Group Check-in has relation to three other contexts • Patient Visit • Patient Billing • Scheduling
99. Questions at menti.com 7890 5555 Which relation describes our situation best? • “upstream-downstream relationship […]” • "the upstream team may succeed independently of the fate of the downstream team, [...] • Establish a clear customer/supplier relationship between the two teams • Negotiate and budget tasks for downstream requirements • (Source: DDD Reference by Eric Evans)
101. Questions at menti.com 7890 5555 Using dependencies to our advantage • It turned out that dependencies were working in our favor • Other teams could help us achieve the goal with relatively little work on their side
102. Questions at menti.com 7890 5555 Solved by navigating to other contexts using IDs patientID appointmentID UI Composition
103. Questions at menti.com 7890 5555 UI Composition • Works well as context integration pattern in a multi-team distributed environment • Legacy systems “compliant”
104. Questions at menti.com 7890 5555 Context Maps revealing possibility for early release • Achieving full autonomy could mean we need to do all the work ourselves • Group Planning • Negotiating deliveries with other teams to release early • Group Check-In
105. Five Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning different perspectives with Bounded Contexts 4. Delivering value in legacy constrained environments 5. Modeling breakthrough
106. Finally! Understanding the Domain
107. Questions at menti.com 7890 5555 The Business and the Legacy System • The more complex the legacy system…. • ….and the longer the system is in production • ….the more likely that the domain language will be affected …. by the language of the legacy system!
108. Questions at menti.com 7890 5555 Distilling the Domain with Pure Domain Stories Capturing the very essence of the business processes
109. Questions at menti.com 7890 5555 Facilitator’s guidance • “How would you do your work without the software system?” • “What are your needs at the particular step?” • “Why are you doing that?”
110. Group Planning Somatic Department
111. Group Planning Psychiatric Department
112. Departments •Accident and Emergency Department •Anaesthesia and Surgical Services •Cancer Treatment and Medical Physics •Children and Youth Clinic •Clinical Nutrition •Communication •Department of Occupational Therapy •Dermatology •Emergency Clinic •Emergency Department Short Stay Unit •Finance •Haukeland hotel •Heart Disease •Human Resources •Internal Medicine •International Collaboration •Laboratory Medicine and Pathology •Maternity Ward •Medical Biochemistry and Pharmacology MBF •Medical Genetics •Neurology •Neurosurgery •Occupational Medicine •Occupational Outpatient Clinic •Ophthalmology •Oral Surgery •Orthopedic Clinic •Physiotherapy •Psychiatry •Radiology department •Recruitment and Temporary Staffing Office •Regional Centre for Asthma, Allergy and Other Hypersensitivity illnesses in Western Norway •Research and Development •Rheumatology •Secretariat for hospital management •Surgical Clinic •The Cancer Center for Education and rehabilitation- CCER •The Norwegian Arthritis Registry - NorArthritis •The Norwegian Porphyria Centre NAPOS •Thoracic Medicine •Treatment abroad •Tuberculosis clinic •Women's Clinic
113. Questions at menti.com 7890 5555 Decompositions by business capabilities • Boundaries in the system follow the capabilities that the business offers its’ customers • Subdomain = Business Capability • Subdomain ≠ Function • Foundation for the product architecture
116. Data Ownership – Decomposition by Business Capabilities “Group” – psychiatry capability • Psychologist • Psychiatrist • Diagnosis • Reference to § in law • Patients • Appointments • Location for appointment outside hospital premises “Group” – medical clinical services • Physician • Diagnosis • Patients • Appointments
117. The cross-functional team! 1 QA 1 Product Owner 4 developers Field Specialist M issing! Working in legacy systems turns specialists into generalists!
118. Questions at menti.com 7890 5555 So…. Did we do anything about it? Nothing ☺ How committed are you to the model you have chosen?
119. Product architecture Which users are we tailoring our products for? The cost of customizing the product for diverse user groups The cost of developing separate products for separate user groups
120. Wrapping up
121. Questions at menti.com 7890 5555 So…. what have we learned? • Asking the right questions • Listening to the field specialists • Legacy Systems may significantly affect end-user’s language and mental model • Data Ownership for model validation • Context Mapping as a tool to discover value chains
122. Modeling Breakthrough! • There is always another model but…. modeling insights might come at most “inconvenient” times
123. Thank you!
124. Questions at menti.com 7890 5555 Photos • https://unsplash.com/@ratushny • https://unsplash.com/@jeshoots • https://unsplash.com/@mango_quan • www.vecteezy.com