Dataeierskap som grunnlag for applikasjonsutvikling - Make Data Smart Trondheim 2022

Tradisjonelt har dataanalyse og rapportering tatt utgangspunkt i spesiallagde datamodeller opprettet på bakgrunn av konvertering og transformasjon av operasjonell data. Det er derimot applikasjonsutviklingen som ligger bak designet av operasjonell data og som regel har denne datamodellen vært lite egnet til analyse og rapportering. En av de direkte årsakene til dette skillet er tilnærmingen som de aller fleste applikasjonsutviklere tar, nemlig funksjonell dekomponering av systemer, basert på systemfunksjoner beskrevet i kravspesifikasjoner, use-case, produkt backlogg etc.

Hva om det fantes en annen måte å utvikle applikasjoner på som gjør at data spiller mye mer sentral rolle i dekomponering av systemer? Hva om denne måten å modularisere systemet på gjør at dataanalyse, rapportering og applikasjonsutvikling plutselig sitter mye nærmere hverandre?

Bli med og se hvordan komplekse systemer kan designes med bakgrunn i dataeierskap og forretningstjenester (business capabilities), noe som fører til et helt annet utgangspunkt for dataanalyse og rapportering. Presentasjonen er basert på reelle historier fra helse- og forsikringsdomenet.

Transcript

1. Dataeierskap som grunnlag for applikasjonsutvikling Make Data Smart Trondheim 2022 Mufrid Krilic Domain-Driven Design Coach, CoWork
2. @mufridk CoWork – Ingen ledere men fullt av ledelse • Tight Loose Tight – TLT • Strategisk og smidig ledelse • Domain-Driven Design • Taktisk og operativ produkt- og teknologiledelse
3. Bok anbefaling #1
4. @mufridk Læringsmål for neste ~30 min • Ulike perspektiver for applikasjonsutvikling og data analyse • Domain Storytelling • metodikk for å forstå domene og forretning • Etablere dataeierskap med Domain-Driven Design
5. Om ulike perspektiver Applikasjonsutvikling og data analyse
6. Ulike perspektiver • Applikasjonsutvikling • Data analyse • Operasjonelle data • Analytiske data
7. @mufridk Ulik organisering • Team for data analyse og rapportering • Atskilt fra applikasjonsutviklingen • Forankret i ekte behov for egen datamodell for analytiske data • Datamodellen lagd for applikasjonsbehov er ofte ikke tilstrekkelig
8. Kan vi redusere gapet? • Kan vi ha et annet utgangspunkt? • Modellering av applikasjonsdata
9. Bok anbefaling #2
10. Etablerte domenegrenser! • Forutsetning for Data Mesh! • «domain-oriented decentralized data ownership and architecture»
11. Use Case Gruppebehandling - Oppmøteregistrering
12. @mufridk ▪ For pasienter med identiske diagnoser kan felles behandling i grupper gi en god effekt ▪ Eksempler • Psykiatri • Samtalegrupper • Somatikk • Bassengtrening Domene: Gruppebehandling i sykehus
13. @mufridk
14. @mufridk
15. @mufridk
16. @mufridk
17. @mufridk Tegnet med egon.io
18. Bok anbefaling #3
19. Dataeierskap og modellering Om ulike tilnærminger til applikasjonsutvikling
20. @mufridk Dataeierskap • Et domenebegrep er definert som et sett med data-egenskaper
21. @mufridk Funksjonell dekomponering • Avgrensninger i systemet etter funksjonene som en bruker trenger for å gjøre jobben sin • Klassisk tilnærming • Subdomene = Funksjon
22. @mufridk Gruppebehandling i sykehus
23. @mufridk Domenemodell
24. Dataeierskap – funksjonell dekomponering • «Gruppe» for ulike funksjoner • Behandlere • Pasienter som deltar i behandlingen • Oppmøtetidspunkter • Lokasjon • Hvem som (ikke) møtte opp • Hvem som kansellerte • Hvem har frikort • Hvordan motta faktura • Hva er egenandel ut fra diagnosegruppe
25. @mufridk Rollebasert dekomponering • Avgrensninger i systemet ut fra hvilke roller som utfører ulike funksjoner • Tillater for mer oppgaveorientert applikasjon • Subdomene = Rollebasert funksjon
26. @mufridk
27. @mufridk Domenemodell
28. @mufridk Dataeierskap - rollebasert dekomponering «Gruppe» planleggingskontekst • Behandlere • Pasienter som deltar i behandlingen • Oppmøtetidspunkter • Lokasjon «Gruppe» oppmøtekontekst • Hvem som (ikke) møtte opp • Hvem som kansellerte • Hvem har frikort • Hvordan motta faktura • Hva er egenandel ut fra diagnosegruppe
29. @mufridk Tids- og rollebasert dekomponering • Avgrensninger i systemet ut fra hvilke roller utfører ulike funksjoner på ulike tidspunkter • Tillater for brukerkontekst-orientert applikasjon • Subdomene = Rollebasert funksjon i en tidskontekst
30. @mufridk
31. @mufridk Domenemodell
32. @mufridk Dataeierskap - tids- og rollebasert dekomponering «Gruppe» planleggingskontekst • Behandlere • Pasienter som deltar i behandlingen • Oppmøtetidspunkter • Lokasjon «Gruppe» økonomikontekst • Hvem har frikort • Hvordan motta faktura • Hva er egenandel ut fra diagnosegruppe «Gruppe» oppmøtekontekst • Hvem som (ikke) møtte opp • Hvem som kansellerte
33. @mufridk Dekomponering etter forretningstjenester • Avgrensninger i systemet etter tjenester som forretningen tilbyr sine kunder • Subdomene = Forretningstjeneste • Subdomene ≠ Funksjon • Utgangspunkt for produktarkitektur Forretningstjeneste aka Business Capability
34. @mufridk
35. @mufridk Domenemodell
36. @mufridk Dataeierskap - forretningstjenester dekomponering «Gruppe» psykiatri tjeneste • Psykolog og/eller psykiater som behandlere • Diagnose • Psykiatrivedtak • Pasienter • Oppmøtetidspunkter «Gruppe» somatikk tjeneste • Lege som behandler • Diagnose • Oppmøtelokasjon utenfor sykehuset • Pasienter • Oppmøtetidspunkter
37. @mufridk Flere eksempler på forretningstjenester Helsedomenet: • Nevrokirurgi • Føden • Blodbanken
38. @mufridk Flere eksempler på forretningstjenester Forsikringsdomenet: • Husforsikring • Bilforsikring • Personforsikring Forretningstjenester istedenfor funksjoner
39. Om funksjonell dekomponering • Brukerbehovene blir gjemt bak funksjoner! • Svært lite bærekraftig modell !!
41. @mufridk Språk som verktøy • Ett og samme domenebegrep i ulike subdomener er definert med ulik, evt. delvis overlappende sett med egenskaper • Bruk domenespråket til å finne passende nivå for dekomponering
42. Bok anbefaling #4
43. Domain-Driven Design Om prinsippene for strategisk DDD
44. Kjernedomenet • Det som skiller deg fra dine konkurrenter • “Ikke alle deler av et system vil bli designet på en like god måte” • Generiske subdomener • Støtte-subdomener • Supporting Subdomain
45. Problemrommet og løsningsrommet Problemrommet • Domeneanalyse for å oppdage naturlige Subdomener Løsningsrommet • Modellere applikasjon på en tilsvarende måte for å etablere Avgrensede Kontekster • Bounded Contexts
46. Språklige grenser Ubiquitous Language • Omforent språk • Det samme språket overalt • Samtaler • Dokumentasjon • Kode
47. De to pilarene av DDD 1. Omforent språk 2. Avgrensede kontekster • Avgrensede kontekster (Bounded Contexts) i applikasjonen defineres av språklige grenser • Kontekst er en del av applikasjonen der et domenebegrep er entydig
48. Tverrfaglig samarbeid • Lage programvare som er så nært som mulig til det domeneeksperter hadde lagd om de hadde vært utviklere • En utforskningsprosess der alle , inkl. domeneeksperter faktisk kan lære enda mer om domene
49. Strategisk DDD • Fokusere på kjernedomenet • Problem- og løsningsrommet • Subdomener og Bounded Contexts • Språklige grensene • Omforent språk • Tverrfaglig samarbeid mellom domeneeksperter og produktteam
50. Oppsummering og takeaways ▪ Respektere og forene ulike behovene for applikasjonsutvikling og data analyse – Data Mesh ▪ Ulike tilnærminger til modellering i applikasjonsutviklingen – Unngå funksjonell dekomponering ▪ Etablere dataeierskap med Domain-Driven Design Ella Fitzegerald – «They Cant’t Take That Away From Me»
51. Takk for meg! • https://www.linkedin.com/in/mufrid/
53. @mufridk Bilder • 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