Strategies to Learn Complex Domains - Experiences from Developing Enterprise Software for Healthcare

Software developers are generally great solution-oriented people. We propose solutions to difficult problems, we try to make life easier for our customers by shielding them from overwhelming technologies by abstracting the details and creating nice and intuitive user-interfaces. However, in enterprise business domains, what happens when the business rules of the domain are overwhelmingly complex by themselves? In such circumstances, the ability to quickly propose solutions to customers’ problems could become an disadvantage.

When trying to understand complex domain a quick solution proposal could lead to wrong problem being solved. Inherent focus of a developer is on technology, not on business rules, which risks hiding the complex enterprise business rules beneath e.g. framework choices. How can one be sure that the correct solution was being applied to the correct problem?

Find the right problem to solve, then focus on technology that could help solve the problem.

Domain Driven Design (DDD) is a mindset for focusing on domain first when developing software. Some emerging DDD techniques offer light-weight, high-reward methods for learning complex domains while visualizing the complexities in the domain. Most notably, Event Storming and Domain Storytelling have been gaining traction recently and are astonishing methods for techies and non-techies alike. Both methods create an arena where domain knowledge can be shared among all participants in a project. In this talk I will present examples on learning the domain of healthcare and how applying Event Storming and Domain Storytelling methods helped my team to expose and embrace the complexities of the domain in our software. The methods reveal ways to deal with complexities using essential DDD patterns such as Bounded Contexts where complexity is naturally divided into different contexts that align with the boundaries that exist in the domain.

Transcript

1. E N A B L I N G E F F I C I E N T H E A L T H C A R E Cynefin Framework by Dave Snowden. Sketch by Edwin Stoop
2. E N A B L I N G E F F I C I E N T H E A L T H C A R E Strategies to Learn Complex Domains Mufrid Krilic, Senior Software Developer/Coach DIPS AS, Norway Experiences from Developing Enterprise Software for Healthcare
3. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Ignited curiosity about Domain Driven Design and Event Storming ▪ Lessons learned when dealing with complexity in healthcare Takeaways
4. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Definition of Complexity – “the state of having many parts and being difficult to understand or find an answer to” • Cambridge Dictionary ▪ How to recognize complexity in a domain? – Complexity on strategic level – Complexity on tactical level About complex domains
5. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Many-to-many relationships between domain terms ▪ Matrix-like relationships – Use case: Admission Letters sent from Hospital Complexity on Tactical Level
6. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Letter template depending on required treatment – Level of Care • Outpatient or hospitalization? – What department? – What is the health issue? • Related to the field of discipline within each department – Each discipline is related to a set of coded diagnoses that patient’s health issue fall within • Is patient entitled to health care provided by the state? ▪ In total 5 parameters Complexity in Healthcare - Admission Letters
7. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Letter template depending on a stage in admittance process – Referral Reception Letter • When hospital initially receives referral from patient’s GP – Referral Evaluation Result Letter • When hospital decides to either refer patient to another hospital or decline health care for a valid reason – Appointment Notice Letter • When hospital schedules patient for a visit – Without fixed appointment time – With tentative time – With fixed appointment time ▪ In total 6 parameters Complexity in Healthcare - Admission Letters
8. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ The matrix of parameters respectively related to required treatment and stage of admission process yields the letter template ▪ Precedence between parameters on the left-hand side ▪ Orthogonal complexity – Letter to next of kin, GP. Printed letter or electronic message. Cross- department letter templates. Complexity Revealed Referral received Referral rejected Referred to another hospital Appointment w/o fixed time Appointment w/ tentative time Appointment w/ fixed time Level of care Department Discipline Diagnosis Healthcare entitlement
9. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ The complexity matrix should be explicitly modeled in code – Preferably not mixed with technological concerns • UI framework • Persistency technology ▪ Why? – Reducing accidental complexity introduced by technology choices – Expose inherent complexity in business rules • Rules described in previous slides are there regardless of technology Complexity Exposed
10. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Use Case: Referral Flow in Norwegian Hospitals – Basic flow • GP creates referral on behalf of patient and sends it to a relevant hospital • Pre-sorting of received referrals followed by referral reception in each department • Referral made ready for evaluation by a supervising physician • Referral is evaluated by a physician – Accepted i.e. patient is entitled for public healthcare in a hospital – Or rejected on some formal or clinical basis • Patient is scheduled for admittance – Significant alternative flows • Patient is referred to another department for supplementary treatment • Patient is referred to another hospital for more specialized or extensive treatment – The flow involves multiple roles and takes time to complete Complexity on Strategic Level
11. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ The complexity in the overall business process should be visible early in the project – Without time-consuming studies and extensive documentation ▪ Why? – Can we reduce complexity on the strategic level by aligning teams with inherent subdomains in the problem space? • to enable teams to be efficient in dealing with complexity on tactical level – Establishing common language between developers and the business – Investing heavily in learning early on • A.K.A. «Knowledge Crunching» Complexity Exposed
12. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ What is DDD? – My personal definition or why I value DDD: • DDD is an approach for dealing with complex problems with emphasis on learning the domain in a close collaboration with domain experts in order to focus on the most important problems to solve. ▪ The term coined by Eric Evans in 2004 – The “Blue Book” • Tackling Complexity in the Heart of Software About Domain Driven Design (DDD)
13. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Ubiquitous Language – Develop domain model based on domain terms ▪ Bounded Context – tackle complexity by splitting application via inherent subdomain boundaries – The boundaries are primarily linguistic per the Ubiquitous Language • If a domain term has different meaning in different use-cases it is an indication of separate bounded contexts – Example: Patient » Patient as a subject of care » Patient as a customer paying the bill after visiting the clinic – Bounded Contexts are defined by the semantics of the Ubiquitous Language! The Two Pillars of DDD
14. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Knowledge Crunching technique – The term introduced by Eric Evans in the Blue Book ▪ Event Storming – Introduced to community by Alberto Brandolini in 2013 – Discovery and collaboration with domain experts put in practice • People with questions meet people with answers – Massive learning and sharing of different perspectives – Making the most important problems visible – Unlimited modelling space ▪ Multiple levels – Big picture, process modelling or software design About Event Storming
15. E N A B L I N G E F F I C I E N T H E A L T H C A R E – Use Case: Referral flow in Norwegian hospitals Big Picture Event Storming
16. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Domain Event – Orange sticky note – Verb at past tense – Relevant for domain experts Big Picture Event Storming Referral received from patient’s GP Referral for evaluation sent to attending physician Referral accepted Medical consultant Attending physician How is attending physician notified when GP sends a reminder on non- evaluated referral? Will GP send another referral (duplicate) if GP wants to remind hospital about non- evaluated referral? ▪ User/Actor/Persona – Yellow sticky note ▪ Hot Spots – Pink sticky note – This is where interesting discovery happens
17. E N A B L I N G E F F I C I E N T H E A L T H C A R E Complexity Revealed: Referral From GP to Hospital
18. E N A B L I N G E F F I C I E N T H E A L T H C A R E Complexity Revealed: Referral Evaluation in Hospital
19. E N A B L I N G E F F I C I E N T H E A L T H C A R E Complexity Revealed: In-Hospital and Inter-Hospital Referral
20. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Strong hints about Bounded Contexts – Suddenly visible when taking time into account! • One-way communication and work hand-off between roles and tasks – Identifying different roles in the business process • Medical consultant makes sure received referral is ready for evaluation • Attending physician evaluates the referral • Planning consultant schedules patience for admittance – Same role with different tasks at different points in time • Attending physician evaluates received referral • Patient is admitted but the treatment requires services from another hospital • Attending physician refers patient to another hospital by creating new referral ▪ Bounded Contexts emerged only in aftermath Lessons Learned - Big Picture Event Storming
21. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Assert perceived Bounded Contexts against the Ubiquitous Language – Referral with different meaning in different stages of the business process • Referral as in received referral • Referral as in evaluated referral • Referral as in referral to another department or hospital ▪ Perceived Bounded Contexts should be challenged throughout the development process – Learning is an iterative process, after all….. Lessons Learned – Bounded Contexts Assertions
22. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Respect, embrace and expose inherent complexity in the domain ▪ Reveal complexity by applying Knowledge Crunching methods – Event Storming, Domain Storytelling – Get an overview of the business process in a quick and efficient way ▪ Assess inherent subdomains and establish Bounded Contexts – Input for modularization in the application ▪ For multiple teams project align teams with subdomains and Bounded Contexts ▪ Apply appropriate technology on each problem within a Bounded Context Lessons Learned while Applying DDD
23. E N A B L I N G E F F I C I E N T H E A L T H C A R E ▪ Eric Evans – «Tackling Complexity in the Heart of Software» • «The Blue Book» ▪ Vaughn Vernon – «Implementing Domain Driven Design» • «The Red Book» – «Domain Driven Design Distilled» • «The Green Book» ▪ Alberto Brandolini – «Introducing EventStorming – an Act of Deliberate Collective Learning» • Book on LeanPub Further Reading