Kæmpe legacy-oprydning i Rigspolitiet: Farvel til de store monolit-systemer

28. oktober 2021 kl. 03:4525
Kæmpe legacy-oprydning i Rigspolitiet: Farvel til de store monolit-systemer
Illustration: Morten Larsen.
Opgøret med den massive it-legacy hos Rigspolitiet skal give plads til et mere fleksibelt it-landskab. It-direktørens plan er at skabe noget let bearbejdeligt for fremtidens it-leder. For ingen ved, hvilken it-understøttelse fremtidens Politi kræver.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

I en knap så fjern fortid ligger Rigspolitiets drøm om det forkromede modersystem knust.

POLSAG-mareridtet spøger stadig, og fra politisk hold er det blevet dikteret, at der skal ryddes op. Og der er sat penge af til det.

I dag arbejder Rigspolitiet derfor på at få muget ud i den omfattende systemportefølje, og det giver plads til en anden tilgang hos it-direktør Lars Ole Dybdal.

Log ind og læs videre
Du kan læse indholdet og deltage i debatten ved at logge ind eller oprette dig som ny bruger, helt gratis.
25 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
25
1. november 2021 kl. 10:58

CI fortæller dig om den samlede løsning stadig kan kompilere når man opgraderer de enkelte dele. Men man skal stadig selv finde og lave rettelserne når der opstår problemer.

Ja, det er hele stuntet i bla at have CI/CD og evt noget a la dependency bot. Følger man hele tiden med i de små rettelser der kommer til frameworket eller andre dependencies, så er det manuelle rettelser minimale ifht at vente og lave big bang ændringer.

24
31. oktober 2021 kl. 23:48

Det er kun et problem, hvis man ikke har CI/CD på det man udvikler.

Du skal stadigvæk håndtere evt. breaking changes i et framework. Hvis et stykke software er røget i "maintenance-mode" hvor de fleste udviklere er flyttet væk og måske har dem der er tilbage ikke god forståelse for det samlede design ... så er den slags breaking changes ikke altid nemme at håndtere.

Derfor er det bydende nødvendigt at udviklere overvejer implicationerne hver gang de importerer komponenter eller frameworks udefra. Det handler om kodekvalitet, levetid, sikkerhed, etc. Det er ikke det samme som at man skal lave alt selv. Man skal bare huske at tænke sig om. Og det er desværre ikke altid folk gør det.

21
30. oktober 2021 kl. 19:57

Umidelbart vil jeg mene at man bør holde sig fra frameworks som hele tiden ændrer sig.</p>
<p>Et eksempel kunne .net sproget. Som et eksempel, så skal en komponent som er designet i .net 2.0 redesignes hvis det skal fungere med .net 5.x, hvilket godt kunne blive et problem når vi snakker om tidsintervaler på mere en 10 år. Jeg ved så ikke om Java 8 til Java 11 er anderledes da jeg ikke programmere i Java.

Det er kun et problem, hvis man ikke har CI/CD på det man udvikler.

Har lavet løsninger som er startet i .Net på ren windows platform og nu køre i .Net 5.0 og opgraderingerne har været minimale, da alt har været opgraderet løbende.

Ikke at bruge frameworks af den årsag er bare at tage alt arbejdet hjem på eget bord uden nogen åbenlys grund?

20
29. oktober 2021 kl. 12:39

Umidelbart vil jeg mene at man bør holde sig fra frameworks som hele tiden ændrer sig.

Et eksempel kunne .net sproget. Som et eksempel, så skal en komponent som er designet i .net 2.0 redesignes hvis det skal fungere med .net 5.x, hvilket godt kunne blive et problem når vi snakker om tidsintervaler på mere en 10 år. Jeg ved så ikke om Java 8 til Java 11 er anderledes da jeg ikke programmere i Java.

19
29. oktober 2021 kl. 09:00

Rigspolitiets ledelse har for længe siden udpeget de to fjolser øh lavere rangerede betjente, der skal tage ansvaret, når dette tiltag for at få etableret et link mellem betjentenes arbejde og et system, der kan understøtte samme crashlander.

UNDSKYLD

18
29. oktober 2021 kl. 00:19

@michael Cederberg. Jeg forstår ikke helt hvad det er du argumenterer for; endsige imod. Samarbejde koster i fleksibilitet. Det er en gammel sandhed. Men intet samarbejde (ingen API'er) - det er vel ikke en diskussion vi behøver længere? At have åbne API / Interfaces er vel den eneste måde at kunne modulopbygge systemer med flere leverandører? - og langt hen af vejen kan den konkrete implementering gemmes bag interfaces.

Men når man bare skal bruge et politi-system eller et skatte-system, så er de omkostninger ikke altid det værd.

Alas, jeg har intet imod at man modulopbygger systemer. Rent faktisk mener jeg det er kriminelt ikke at gøre det. Pointen er bare at det ikke er nemt at ramme rigtigt med modulopdeling og med API'er så snart det bliver til store systemer. Og hvis man har eksponeret alt for meget så bliver det svært at lave om senere. For de ting jeg vælger at eksponere kan det være at jeg ikke ønsker alt for mange "kunder" fordi det igen gør det sværere at udvikle systemet.

Pointen er at det er ikke bare en teknisk problemstilling. Der er mange flere overvejelser.

Det i sig selv er ikke en undskyldning for ikke at offentligtgøre de pågældende API'er.

Nå. Eller mere præcist: Det bliver vi nok ikke enige i.

Der er heller ikke noget der forhindre en i at lave version 2,3,4 etc af et API, så man kan give mulighed for at lave forbedringer i sit UI.

Tjaa. Men så ender man nemt med at skulle supportere version 2, 3, og 4 på samme tid. Så længe det blot handler om additive ændringer så er det nemt nok. Men størrere ændringer kan nemt blive dyre.

Eksempel: For en del år siden designede jeg version 4 af et kritisk system. Vi havde version 3 kørende i produktion samtidigt og skulle lave en glidende udskiftning. Samme API til version 3 og 4. En del af version 3's API var funktioner der skannede det interne state med en række conditions. Det var nemt at lave i version 3 men skulle aldrig have været eksponeret til resten af verden for det var ikke en af systemets opgaver.

Version 3 kørte på en enkelt server. Version 4 kørte på et mesh af servere med automatisk failover og reconfig af mesh. Lige pludseligt var de pågældende funktioner meget meget dyre at implementere. De var lavet fordi det var nemt, men ingen havde overvejet om det faktisk var en god ide. Den slags løber man nemt ind i.

Om noget giver mening i andre kontekster ved man ikke altid selv, før folk begynder at bruge ens API'er, men det finder man ikke ud af, hvis de ikke er tilgængelige for andre.

Det er til dels rigtigt når man laver rent tekniske løsninger. Når man laver forretningsløsninger så er det meget mindre rigtigt. Jeg kan roligt sige at i min karriere har jeg oplevet det ganske få gange - både med egne systemer og med andre systemer i de virksomheder jeg har arbejdet i.

Og selv hvis nogen andre måske kunne bruge min service til at løse en opgave så kan det sagtens være at vi ikke ønsker den dependency af alle mulige andre grunde.

16
28. oktober 2021 kl. 22:42

Jeg ved godt i vil gå endnu længere end "bare" til EU kommunikation, men EU har rent faktisk beskrevet APIer (mere eller mindre åbent) som bruges til at udveksle data imellem politistyrker på tværs af EU lande.

F.eks. ved hjælp af EUCARIS samarbejdet (primært er bil området). - https://www.eucaris.net/services/ hvor EU lande der deltager i samarbejde i fællesskab driver og udvikler den platform der står for kommunikationen imellem landende (så den er ens) og det enkelte land så "kun" skal forbinde det med sine egne registre.

15
28. oktober 2021 kl. 22:23

Men når man udstiller et API til sine interne dele så låser man også sit design. Det forhindrer at man kan lave radikalt om på sit system. Men jeg er i øvrigt enig i at hvis man kan lave noget gennem UI, så er det god stil også at give adgang til samme gennem et API. Pointen er bare stadigvæk at disse API typisk er bundet ret tæt til systemet og sjældent giver mening i andre kontekste. Andre leverandører vil ikke leve med de constraints som et ældre API sætter.

Det i sig selv er ikke en undskyldning for ikke at offentligtgøre de pågældende API'er.

Der er heller ikke noget der forhindre en i at lave version 2,3,4 etc af et API, så man kan give mulighed for at lave forbedringer i sit UI.

Om noget giver mening i andre kontekster ved man ikke altid selv, før folk begynder at bruge ens API'er, men det finder man ikke ud af, hvis de ikke er tilgængelige for andre.

14
28. oktober 2021 kl. 22:18

Fordi vi fx ikke ønsker at hjælpe det syriske eller belarusiske politi med at undertrykke ders egen befolkning - herunder med tortur og drab. Den opgave har politiet i diktaturer foruden det helt legitime, som dansk politi laver. Derfor vil det være relevant at vælge, hvem man deler med (og det kan godt være som open source).

Så kan vi jo starte med at lukke alt open source og hele verdens udvikling ned, for tænk nu, hvad de onde magter kan bruge ting til.

Fordelene opvejer ved open source opvejer helt vildt risikoen for at et diktatur bruger noget open source til noget forkert.

13
28. oktober 2021 kl. 22:15

Man behøver ikke at lave et ekstremt modulært system med en masse forskellige leverandører, og fastfrosne APIer.

Man kan sagtens designe en monolit, på den betingelse at den kan sættes gradvist i drift, så man ikke risikerer at bruge et årti og adskillige milliarder på noget der til sidst kollapser og må skrottes uden nogensinde at have gjort gavn.

Desuden skal designerne have ekstremt høj IQ så de kan bevare overblikket. De mange tradeoffs mellem performance, kompleksitet og tidsforbrug kræver stor erfaring. Og design af model og interfaces kræver høj sproglig og konceptuel intelligens.

Desuden skal udviklerne ikke skifte job hvert 2. år, men blive på projektet i mange år.

11
28. oktober 2021 kl. 20:15

@michael Cederberg. Jeg forstår ikke helt hvad det er du argumenterer for; endsige imod. Samarbejde koster i fleksibilitet. Det er en gammel sandhed. Men intet samarbejde (ingen API'er) - det er vel ikke en diskussion vi behøver længere? At have åbne API / Interfaces er vel den eneste måde at kunne modulopbygge systemer med flere leverandører? - og langt hen af vejen kan den konkrete implementering gemmes bag interfaces.

10
28. oktober 2021 kl. 17:52

Fordi vi fx ikke ønsker at hjælpe det syriske eller belarusiske politi med at undertrykke ders egen befolkning - herunder med tortur og drab. Den opgave har politiet i diktaturer foruden det helt legitime, som dansk politi laver. Derfor vil det være relevant at vælge, hvem man deler med (og det kan godt være som open source).

Hmmm... og du tror virkeligt at det er den helt store hjælp hvis et system udviklet til politistyrker i demokrater falder i hænderne på et diktatur ?

I så fald er der nemlig noget helt galt med det system man udvikler.

Det vil nok gavne mere at pålægge software producenter (især Microsoft) at boykotte lande som ikke overholder menneskerettighederne... jo, det kan man godt - den type embargo lå på hele østblokken før murens fald - det var så formuleret omtrent som "salg af avanceret teknologi til østbloklande skal godkendes af USA's regering".

9
28. oktober 2021 kl. 13:58

Man er kommet langt, hvis API'et rent faktisk UDBYDER ALL funktionalitet der anvendes OG systemets egen UI f.ex. også anvender API'et til at gøre ting.

Men når man udstiller et API til sine interne dele så låser man også sit design. Det forhindrer at man kan lave radikalt om på sit system. Men jeg er i øvrigt enig i at hvis man kan lave noget gennem UI, så er det god stil også at give adgang til samme gennem et API. Pointen er bare stadigvæk at disse API typisk er bundet ret tæt til systemet og sjældent giver mening i andre kontekste. Andre leverandører vil ikke leve med de constraints som et ældre API sætter.

Forskellen på rent tekniske komponenter og komponenter der understøtter en given forretningsprocess er at få virksomheder ønsker at aligne deres kritiske forretningsprocesser med andre virksomheder.

8
28. oktober 2021 kl. 13:27

Hvorfor skulle diktature være en stopklods for at udvikle systemerne og have dem ude som open source?

Fordi vi fx ikke ønsker at hjælpe det syriske eller belarusiske politi med at undertrykke ders egen befolkning - herunder med tortur og drab. Den opgave har politiet i diktaturer foruden det helt legitime, som dansk politi laver. Derfor vil det være relevant at vælge, hvem man deler med (og det kan godt være som open source).

7
28. oktober 2021 kl. 12:54

Se der bliver det svært. For hvis der ikke er enighed om hvilke funktioner der skal ydes så bliver det lidt svært at blive enige om API'er. Og man ender nemt med at åbne API'er bliver en constraint på udviklingen.

Helt uenig. Et åbent API - behøver ikke at betyde at det er standardiseret endnu - det skal bare følge en standard der er implementeret i "almindelige klienter".. Så det er nemt at arbejde op i mod. f.ex. REST eller lign. (helst ikke SOAP ;)

Man er kommet langt, hvis API'et rent faktisk UDBYDER ALL funktionalitet der anvendes OG systemets egen UI f.ex. også anvender API'et til at gøre ting.

Det vil f.ex. betyde at man vil kunne udvikle sit eget (emne specifikt) UI f.ex. - for at gøre et system mere brugervenligt til ens specifikke behov - uden at skulle hacke noget ind - da API'et netop er veldokumenteret og anvendt af systemet selv.

Ligeså vil man kunne implementere sine egne systemer der snakker med systemet over dette API - og på den måde tilføje ny funktionalitet udenom - som man IKKE kan hvis det er et lukket system hvor al funktionalitet IKKE er udstillet via et API.

Jeg har set mange systemer hvor jeg har måtte gætte/hacke min vej igennem et brækket SOAP api, med mange lag er XML objekter og lign. hejs - der ikke implementerede halvdelen af det deres eget UI kunne f.ex..

Det gør det meget sværere at udskifte en enkelt komponent (som f.ex. et UI - så man kunne lave noget mere brugervenligt til en given opgave - uden at skulle udvikle et komplet system, men kan nøjes med noget React og en UI udvikler alene).

6
28. oktober 2021 kl. 12:48

Men det er mere end én leverandør til bankverdenen?

Selvfølgeligt er der det ... alle kommer med deres pros og cons.

... kan "interfaces/samarbejde" via en åben og specificeret metode (api) ...

Se der bliver det svært. For hvis der ikke er enighed om hvilke funktioner der skal ydes så bliver det lidt svært at blive enige om API'er. Og man ender nemt med at åbne API'er bliver en constraint på udviklingen.

Det er ikke ligesom et filsystem hvor der kan være mange implementationer med basalt set samme API. For når der er samme API så er det fordi vi har brugt de sidste 50 år på at slibe kanter af hinandens krav. Og så alligevel: hvert filsystem kommer med sine specialitet og hvis man vælger at udnytte disse så låser man sig fast.

... så skulle man gerne se at andre leverandører (og nogen gange sågar Open Source systemer) - der understøtter det pågældende - og dermed kan man nemmere skifte systemer ud - uden at alt andet også falder.

Det ville være dejligt hvis det bare var at skifte ud. Men der er arbejdsgange knyttet op på de systemer. Arbejdsgange som gør nogen banker mere konkurrencedygtige end andre på det givne område. Og der er ikke en optimal måde at gøre tingene på - den optimale afhænger af fx. volumen, produktsammensætning, organisationsstruktur, synergier med andre systemer.

Der dukker over tid enighed op om ting der er nogenlunde statiske og hvor der er enighed om hvordan det skal se ud - fx. at flytte penge fra en bank til en anden. Men det er småting.

5
28. oktober 2021 kl. 12:29

Når jeg kigger mig omkring indenfor det domæne jeg beskæftiger mig indenfor, så har jeg meget svært ved at se at vores API'er skulle give mening udenfor en bankverden.

Men det er mere end én leverandør til bankverdenen? - og HVIS de opgaver et givent system udfører - kan "interfaces/samarbejde" via en åben og specificeret metode (api) - så skulle man gerne se at andre leverandører (og nogen gange sågar Open Source systemer) - der understøtter det pågældende - og dermed kan man nemmere skifte systemer ud - uden at alt andet også falder.

Eller man har mulighed for at udvikle sin egen udgave af en mindre del af opgaven (fordi han har flere og mindre / ikke-monolit komponenter) og API'et det bruger til at samarbejde med "resten af kæden" er veldokumenteret/standardiseret.

4
28. oktober 2021 kl. 12:24

Det bliver ikke nemmere af at det bilver hakket op i smådele. Hvis de services/moduler man får lavet er forkerte så er man lige vidt. Det er ikke fordi jeg er uenig med fremgangsmåden men distribuerede systemer kommer med deres helt egne problemer hvor der kræves stort overblik for ikke at få malet sig ind i et hjørne. Hvis man ikke kan lave en monolit der virker så kan man heller ikke lave et distribueret system der gør det samme.

Åbne/standard API'er og data strukturer til udveksling</p>
<p>Skulle de pågældende systemer så helst anvende, så det er nemmere for dem at samarbejde - og for politiet at erstatte en delkomponent med en anden, skulle det blive nødvendigt - så man ikke er låst til én leverandør.

Jeg tror du forveksler teknologi med API'er. Et system til håndtering af politiopgaver har naturligt API'er der er rettet mod politifaglige opgaver. Jeg medgiver at der sikkert er nogle generelle aspekter der handler om sagsstyring men de er givetvis i undertal.

Når jeg kigger mig omkring indenfor det domæne jeg beskæftiger mig indenfor, så har jeg meget svært ved at se at vores API'er skulle give mening udenfor en bankverden. Rent faktisk er det svært at se dem passe godt i andre banker fordi virksomheder fungerer forskelligt. Et godt eksempel på hvor store forskelle der kan være mellem arbejdsgange og dermed også de IT systemer der bygges er sundhedsplatformen som kæmpede i år for at adaptere systemer designet til amerikanske "forretningsprocesser" til danske. Og ja, systemer er ikke det samme som API'er men problemstillingerne ofte de samme.

Derimod ville det være oplagt på EU-plan og i Norden, at vi begyndte at dele med hinanden.

Politiet fungerer vidt forskelligt i de Europæiske lande. Fx. har vi kun et politi mens nogen andre har 3. Og ja, man kan generellisere sig ud af den slags men ofte med øget kompleksitet til følge.

1
28. oktober 2021 kl. 11:24

Skulle de pågældende systemer så helst anvende, så det er nemmere for dem at samarbejde - og for politiet at erstatte en delkomponent med en anden, skulle det blive nødvendigt - så man ikke er låst til én leverandør.

Og al udvikling af systemer politiet betaler for, sørger de forhåbentlig for at de har copyright på (og fuld tilgang til) AL Source Code :)

Og så KUNNE man jo bidrage til udviklingslandes politi kvalitet - ved at udvikle sine egenudviklede systemer under en Open Source licens - som fattigere lande kunne anvende for at få et "godt system til samme opgave" evt. - hvis man vil bidrage med noget fornuftigt til verdenen samtidigt. (og håbe det er så godt så mange vil anvende det og måske bidrage med forbedringer :)