Fra MOX agent til et komplet hændelsesbaseret system. (til at understøtte tværsektorielt samarbejde inden for sundhedsvæsnet)

Transkript

1 Fra MOX agent til et komplet hændelsesbaseret system (til at understøtte tværsektorielt samarbejde inden for sundhedsvæsnet)

2 AGENDA Intro Horsens på forkant Fra monolit, over introduktion til MOX, til driftsinnovation Spørgsmål

3 Horsens på Forkant; projekt, produkt, wicked problem;

4

5 Mål og Fakta Flere offentlige domæner Flere privat domæner 5 sygdoms forløb 1 bruger interface (GUI) Flere hundrede apparater og komponenter Aflast en overbelastet sundheds- og omsorgssektor Hjælpe patienter/borgere med selvmonitorering af sygdom Spare offentlig penge Forbedre samarbejde

6 Wicked problem

7 Fokus på fælles krav Understøtte mange standard markup formatter Over mange platforme Med mange forskellige leverandører

8 EDA, Event Driven Arktitektur, har de karakteristika som vi manglede Benytter broadcast kommunikation. Producerer en besked som mange endpoints kan forbruge. Beskeder er tidsrelevant. Asynkront (producent og konsument er uafhængig) Forbrugeren har råderet over fortolkning af en besked

9 SE Next Step SE Next Step er en familie af virksomheder der skal understøtte og udbrede digitalisering og skabe jobs SE Next Step er 100% ejet af SE (Sydenergi+Stofa). SE er et AMBA. SE Next Step Challenge (RSD, Esbjerg, Accelerace) SE Next Step City SE Next Step Citizen

10 For halvandet år siden. Dårlige køer Inkonsistent: logning monitorering konfiguration Source kode Source kode Source kode B Y G T E S T F E J L Monolit deployment produktion MOX + Std. komponent Smertefuldt Ingen support organisation Så alt var som det plejer at være.

11 For halvandet år siden + 1 dag Gode køer Inkonsistent: logning monitorering konfiguration Source kode Source kode Source kode B Y G T E S T F E J L Monolit deployment produktion MOX + Std. komponent Smertefuldt Ingen support organisation

12 For halvandet år siden + 1 dag + Mox Gode køer Inkonsistent: logning monitorering konfiguration Source kode Source kode Source kode B Y G T E S T F E J L Monolit deployment produktion MOX + Std. komponent Smertefuldt Ingen support organisation

13 Beslutning Vi er udviklere ikke supportere Vi vil have et robust system Ændringer sker i forbindelse med udvikling Idriftsættelse skal være en non-event

14 Afkobling og Std. komponent i en flerleverandør strategi Afkoblet og standardiseret, ret smart syntes vi selv.. og læner sig næsten op ad KOMBIT s beskedfordeler og MOX

15 Men, men, men vi får jo aldrig lært om vores kunders reelle behov eller modnet vores produkt, hvis vi kun går i produktion en gang hvert kvartal eller hver 6. mrd Jo oftere vi kører igennem loopet, jo mere lærer vi. Jo hurtigere vi kører gennem loopet, jo hurtigere lærer vi.

16 Fra monolit til dynamisk miljø Og vi får jo aldrig sat hastigheden i innovationsloopet op med en monolit Monolit: En fejl stopper hele test/udrulningen og dermed alle de gode ting der er udviklet Microservices: En fejl stopper kun den enkelte komponent. Men vi skal koordinere og idriftsætte en masse forskellige komponenter hele tiden

17 Ny beslutning Nyt mål Vi vil have et fuldt automatiseret, komponentbaseret, DevOps drevet, Continous delivery understøttende og selvtestende system for os og vores partnere Driftsleverandører, teknologi & juristeri Youtube, inspiration Konferencer, én FØR og én EFTER Sparring med umulig kunde Hvem får nogensinde lov til at sætte en ny elektronisk patientjournal i produktion flere gange om ugen? Og hvad skulle der i givet fald til?

18 Hvordan? Innovation + Drift + Centrale monolitiske systemer + Regulatorisk miljø + (Arbejdsglæde)

19 Trin 1: Afkobling Projektteam 1 Projektteam 2 A P I Legacy Regulatory Legacy Regulatory Projektteam 1 Projektteam 2 A P I Innovationsplatform (team) A P I Legacy Regulatory A P I = ws + kø

20 Trin 2: Risikominimering Projektteam 1 Projektteam 2 A P I Innovationsplatform (team) A P I Legacy Regulatory = ws + kø Innovations-platform (team) Projektteam 1 Projektteam 2 A P I A P I Legacy Regulatory

21 Trin 3: I drift hele tiden Innovations-platform (team) Projektteam 1 Projektteam 2 A P I A P I Legacy Regulatory Kæphest: kun ting i drift har værdi IT drift = Ydre ramme: Sikkerhed Admin Selvbtj. Log pattern. Konfig templates Deployment dok/container Monitorering Audit log Simulation

22 Trin 4: Automatisering Automatisk proces (*) Pt. stadig manuel start Leverandør A Appstore Byggemiljø QA miljø Driftsmiljø Leverandør B Leverandør C Konfig templates Simulation Log pattern. Sikkerhed Admin Selvbtj. Leverandørkrav Log pattern. Deployment dok/container Monitorering Audit log (*) lidt langsom første gang hvor serverne skal installeres fra bunden af (8 min)

23 Trin 5: Automatisering II Sikkerhed Admin Database + Selvbtj. Log pattern. Konfig templates Deployment dok/container + Forretningslogik = Monitorering Audit log Container fabrik: lav pris, ensartet kvalitet Automatisk proces Appstore Byggemiljø QA miljø Driftsmiljø = ws + kø

24 Anvendelse Innovations-platform Nye produkter Projektteam 1 A P I A P I Legacy Regulatory Modning/oprydning af legacy Projektteam 2 Projektteam 3 Nye regulatory krav Fordele for leverandører: Er solgt Delvist solgt Platformen Sikkerhed Simulation Log pattern. Processen Monitorering Sikkerhed Statistik Reklame: Hvad bruger jeg min platform til i dag? Tværsektoriel telesundhed infrastruktur Men processen er universel og vi kalder det pt. for driftsinnovation

25 Konklusion Afkobling åbner for alt andet Standardisering hjælper det på vej Automatisering gør det praktisk anvendeligt

26 Spørgsmål? Kontakt: Marc Martin, System Arkitekt, Peter Lundkvist, Udviklingsdirektør, PS: Marc fik aldrig sin MOX agent