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

Multiple Models with Multiple Perspectives in a...

Multiple Models with Multiple Perspectives in a Cross-Functional Team

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.

Mufrid Krilic

October 06, 2023
Tweet

More Decks by Mufrid Krilic

Other Decks in Programming

Transcript

  1. Multiple Models with Multiple Perspectives in a Cross-Functional Team Case

    Study From Healthcare KanDDDinsky 2023 Mufrid Krilic, Domain-Driven Design Coach, CoWork, Norway
  2. About myself…. • Developer, architect, agile and technical coach •

    Healthcare, Telecom, Insurance • “Domain-Driven Design enthusiast” • Feel free to reach out! • www.linkedin.com/in/mufrid/ • [email protected] Crafting Your Digital Confidence
  3. CoWork - something to inspire you • Trust-Based Leadership in

    Practice Tight-Loose-Tight - TLT Crafting Your Digital Confidence
  4. 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
  5. The topics to be covered • Strategies to learn complex

    domains • Domain problem decomposition • Aligning different perspectives in a cross-functional team • Delivering value in legacy constrained environments • Modeling breakthrough
  6. Questions at menti.com 8937 4165 ▪ 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 Treatment
  7. Questions at menti.com 8937 4165 The business goal constraint •

    “Replace the legacy system” • It must work “everywhere” and for “everyone” • Is this really a business goal? • However, reality in many organizations
  8. Questions at menti.com 8937 4165 Legacy system constraint • ….or

    the opportunity? • Works “everywhere” and for “everyone” • Why are we replacing it? • “Complex systems run as broken systems.” • Quote from “How Complex Systems Fail” by Richard I. Cook
  9. Questions at menti.com 8937 4165 The team and the knowledge

    constraint • No prior/limited knowledge of the domain • Developers • Tester • Product Owner • Very knowledgeable in the domain • Very good overview of customer’s organization and history • Apprehensive that the customers might be using the legacy system in “unpredictable” ways • 4 developers • 1 QA • 1 Product owner
  10. Questions at menti.com 8937 4165 Two Mindsets • What kind

    of problems are you working on? • Simple • Complicated • or Complex Problems
  11. 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
  12. 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
  13. Hypothesis-driven development for complex problems 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
  14. Questions at menti.com 8937 4165 Combining leadership approach with strategic

    design • Tight-Loose-Tight • Discover purpose and needs (T) • Evaluating multiple models (L) • Challenge your assumptions (T)
  15. Questions at menti.com 8937 4165 TLT argues for Collaborative Modeling

    • Collaborative Modeling workshops • Discovering purpose and needs • All the right people in the same room • Different perspectives! • End-users and stakeholders from different departments • To challenge our assumptions
  16. How to learn a new domain? 1.Discover Use Cases 2.Drill

    into scenarios using collaborative modeling techniques • Ask a bunch of questions 3.Listen! 4.Repeat step 2 on different or same(!) scenarios • Ask (hopefully) the right questions ☺
  17. Questions at menti.com 8937 4165 Use-Case Approach • Pre-workshop conversations

    • Identify the most common use cases • or the ones with most “pain”
  18. Questions at menti.com 8937 4165 ▪ Setting up a group

    • Planning ▪ Conducting group appointments • Check-in process Group Treatment Use Cases
  19. Questions at menti.com 8937 4165 Data Ownership • A business

    term is defined as a set of data properties
  20. Questions at menti.com 8937 4165 Functional Decomposition • Boundaries in

    the system follow the function that a user needs to do hers/his job • Classic approach • Subdomain = Function
  21. 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
  22. Questions at menti.com 8937 4165 Role-based decomposition • Boundaries in

    the system based on which roles perform different functions • Leads to more task-oriented model • Subdomain = Role based function
  23. 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
  24. Questions at menti.com 8937 4165 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
  25. 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
  26. Questions at menti.com 8937 4165 About Functional Decomposition • Customer/end-user

    needs are hidden behind functions! • No incentives to decompose • Pull towards canonical domain model
  27. Questions at menti.com 8937 4165 End-users need flexibility • Somatic

    Rehabilitation • Different courses • Different diagnosis • Psychiatric Therapy • Adult groups • Pediatric groups • Different Locations
  28. Questions at menti.com 8937 4165 Flexibility and complexity • Allowing

    flexibility everywhere calls for highly customizable systems • Works for “everyone” and “everywhere” • High level of customization => high complexity • Configuration permutations
  29. Questions at menti.com 8937 4165 Flexibility within a Bounded Context

    • Different bounded contexts for different end-user needs • The degree of customization in a system is constrained to bounded contexts
  30. Questions at menti.com 8937 4165 Role-based decomposition • Boundaries in

    the system based on which roles perform different functions • Leads to more task-oriented model • Subdomain = Role based function
  31. Questions at menti.com 8937 4165 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
  32. Decomposition approach with respect to the problem we are facing

    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
  33. Team Maturity by Levels of Alignment Organization Steering Write unit

    tests Become better developer Deliver new feature Clinically effective group treatment for diverse patient needs Different user needs in group treatment in somatic and psychiatry Outer Alignment Inner Alignment 5. Mission 4. User 3. Project 2. Role and process 1. Expertise Developers, Product Owner, Tester Product Owner, Tester Using appropriate decomposition approach to reach higher Level of Alignment
  34. Questions at menti.com 8937 4165 Boundaries by Abstractions Use appropriate

    abstraction: • Repository • Namespaces • Whatever might be available in your programming environment
  35. Questions at menti.com 8937 4165 Bounded Models • Patient attendance

    incl. no-show • Cancelled appointments • Patients exempted from payment • Specialists • Patients • Appointments • Location • Reference to § in law for psychiatry
  36. Questions at menti.com 8937 4165 Context Mapping • Group Check-in

    has relation to three other contexts • Patient Visit • Patient Billing • Scheduling
  37. Questions at menti.com 8937 4165 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)
  38. Questions at menti.com 8937 4165 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
  39. Questions at menti.com 8937 4165 Solved by navigating to other

    contexts using IDs patientID appointmentID UI Composition
  40. Questions at menti.com 8937 4165 UI Composition • Works well

    as context integration pattern in a multi-team distributed environment • Possible in most scenarios • Legacy systems “compliant”
  41. Questions at menti.com 8937 4165 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
  42. Questions at menti.com 8937 4165 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!
  43. Questions at menti.com 8937 4165 Distilling the Domain with Pure

    Domain Stories • Capturing the very essence of the business processes Questions to ask: • How would you do your work without the software system? • What are you trying to achieve? • Why are you doing this?
  44. 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
  45. Questions at menti.com 8937 4165 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
  46. 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
  47. Questions at menti.com 8937 4165 So…. Did we do anything

    about it? • Nothing ☺ • This insight came at slightly inconvenient time • How committed are you to the model you have chosen? • What is your TLT “mandate”?
  48. Questions at menti.com 8937 4165 Product architecture • There are

    some product related decisions to be made. • Which users are we tailoring our products for? • What is the cost of customizing the product for diverse user groups? • What is the cost of developing separate products for separate user groups?
  49. Questions at menti.com 8937 4165 So…. what have we learned?

    • Collaborative Learning by asking the right questions and listening • Legacy Systems constrains your thinking • Levels of Alignment helps you respect different perspectives • There is always another model • ….but modeling insights might come at most “inconvenient” times • Data Ownership as a tool to validate the model • Context Mapping as a tool to discover value chains