Slide 1

Slide 1 text

Data Ownership in Legacy Systems Building a Foundation for Data Mesh Software Craftspeople India Community, Online 2023-11-22 Mufrid Krilic, Domain-Driven Design Coach CoWork, Norway

Slide 2

Slide 2 text

About myself…. • Developer, architect, agile and technical coach • Healthcare, Telecom, Insurance • “Domain-Driven Design enthusiast” Crafting Your Digital Confidence

Slide 3

Slide 3 text

CoWork - something to inspire you • Trust-Based Leadership in Practice Tight-Loose-Tight - TLT Crafting Your Digital Confidence

Slide 4

Slide 4 text

Some light reading

Slide 5

Slide 5 text

Takeaways after the session • Different perspectives between application development and data analysis • Understanding needs for business insights with Domain Storytelling • Establishing data ownership with Domain-Driven Design

Slide 6

Slide 6 text

On Different Perspectives Application Development and Data Analysis

Slide 7

Slide 7 text

The problem we are solving • Being data-driven is a mandatory in modern business • However …. • Data management at scale is highly complex area with socio- technical implications

Slide 8

Slide 8 text

Different perspectives • Application Development • Data Analysis • Operational data • Transaction based and state-aware • Analytical data • Aggregated business events to provide future insight or retrospect

Slide 9

Slide 9 text

Organizational Legacy • Common to find a team for data analysis and reporting • Separate from application development • Based on a real needs for different data model for analytical data • Data model for operational data is usually not adequate

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

Four Principles 1. Domain-oriented data ownership 2. Data as a product 3. Self-served data platform 4. Federated Computational Governance

Slide 12

Slide 12 text

Established Domain Boundaries • Prerequisite for Data Mesh! • «domain-oriented decentralized data ownership and architecture»

Slide 13

Slide 13 text

Domain-oriented? • Data ownership closely aligned with the data source • Multiple autonomous yet integrated models

Slide 14

Slide 14 text

How to Reduce the Gap? • Reducing the gap between the operational and analytical data addresses complexity with socio- technical approach • Combined with decentralization to address scaling • Can we take a different approach? • Modelling of application data

Slide 15

Slide 15 text

Domain-Driven Design Principles of Strategic DDD

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Strategic DDD • Focusing on Core domain • Problem and solution space • Subdomains and Bounded Contexts • Linguistic boundaries • Ubiquitous Language • The two pillars of DDD

Slide 18

Slide 18 text

Core Domain • The thing that distinguishes you from the competitors • “Not every part of the system will be well-designed” • Generic subdomain • Supporting subdomain

Slide 19

Slide 19 text

Problem Space and Solution Space Problem space • Domain analysis to discover inherent Subdomains Solution space • Domain modeling to discover corresponding Bounded Contexts • Hard to find 1:1 mapping though

Slide 20

Slide 20 text

Linguistic Boundaries Ubiquitous Language • The same language everywhere • Conversations • Documentation • Code

Slide 21

Slide 21 text

The Two Pillars of DDD 1. Ubiquitous Language 2. Bounded Context Bounded contexts in your application are defined by linguistic boundaries

Slide 22

Slide 22 text

Cross-Functional Collaboration • Build software in a way that domain experts would have built it themselves • Discovery process where everyone, including domain experts, learn and understand more about the domain

Slide 23

Slide 23 text

Strategic DDD • Focusing on Core domain • Problem and solution space • Subdomains and Bounded Contexts • Linguistic boundaries • Ubiquitous Language • The two pillars of DDD

Slide 24

Slide 24 text

It’s Story Time Domain of Healthcare – Group Treatment

Slide 25

Slide 25 text

▪ For patients with identical diagnoses sometimes the treatment has the best effect when done in a group of patients ▪ Examples from different subdomain in healthcare: • Conversation therapy groups in psychiatry • Training sessions post-injury Domain: Group Treatment

Slide 26

Slide 26 text

▪ Setting up a group • Planning ▪ Conducting group appointments • Check-in process Group Treatment Use Cases

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

Group Treatment Planning Somatic Department Rehabilitation after lifestyle affected diagnosis

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

Group Treatment Check-In Somatic Department Rehabilitation after lifestyle affected diagnosis

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

Group Treatment Planning Psychiatric Department Adult Psychiatry

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

Group Treatment Check-In Psychiatric Department Adult Psychiatry

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

Data Ownership and Modeling On different approaches to application development

Slide 55

Slide 55 text

Data Ownership • A business term is defined as a set of data properties

Slide 56

Slide 56 text

Functional Decomposition • Boundaries in the system follow the function that a user needs to do hers/his job • Classic approach • Subdomain = Function

Slide 57

Slide 57 text

Group Treatment in Healthcare

Slide 58

Slide 58 text

Domain Model

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Role-based decomposition • Boundaries in the system based on which roles perform different functions • Leads to more task-oriented model • Subdomain = Role based function

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Aligned with the Business? The first principle of Data Mesh “Domain-oriented decentralized data ownership and architecture”

Slide 69

Slide 69 text

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!

Slide 70

Slide 70 text

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?

Slide 71

Slide 71 text

Group Planning Somatic Department

Slide 72

Slide 72 text

Group Planning Psychiatric Department

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

More business capabilities in healthcare • Neurosurgery • Birth clinic • Cardiology • Etc.

Slide 79

Slide 79 text

Business capabilities in other domains Insurance - Centered on products or capabilities • House • Car • Life Instead of functions • Such as policy, coverage

Slide 80

Slide 80 text

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?

Slide 81

Slide 81 text

Conclusion and Takeaways

Slide 82

Slide 82 text

About Functional Decomposition • Customer/end-user needs are hidden behind functions! • No incentives to decompose • Pull towards canonical domain model • One of the main reasons behind the gap between operational data model and needs for data-insight aligned model

Slide 83

Slide 83 text

Data-Driven • Consider modeling around Business Capabilities to unlock the real Business Needs • Reducing the gap between operational and analytical data needed for business insights

Slide 84

Slide 84 text

Language as a tool • The same domain term in different subdomains is defined with different or possibly overlapping set of data properties • Use domain language to find appropriate level for decomposition

Slide 85

Slide 85 text

Takeaways ▪ Respect and align different needs for application development and data analysis – Data Mesh ▪ Different approaches to modeling in application development to get closer to the real business needs – Avoid functional decomposition ▪ Establish data ownership with Domain-Driven Design Ella Fitzegerald – «They Cant’t Take That Away From Me»

Slide 86

Slide 86 text

No content

Slide 87

Slide 87 text

Images • https://unsplash.com/@x_vinicius • https://unsplash.com/@mpho_mojapelo • https://unsplash.com/@fazurrehman • https://unsplash.com/@freegraphictoday • https://unsplash.com/@dancristianp • https://unsplash.com/@patrickperkins • https://unsplash.com/@nadineshaabana • https://unsplash.com/@chuttersnap • https://unsplash.com/@ceebeesnap • https://unsplash.com/@renemolenkamp • https://unsplash.com/@rosiekerr • https://unsplash.com/@janilson123 • https://unsplash.com/@profwicks • Bing AI