Strangler Pattern: Genvejen til moduliseret it

Kvæl monolitten bid for bid med Strangler Pattern
Home / Det offentlige / Strangler Pattern: Genvejen til moduliseret it

Strangler Pattern er en konkret metode til at opnå den modulisering af offentlig it og fordelene herved, som jeg beskrev i min artikel fra sidste uge. Læs den her. Hurtigt opsummeret, så argumenterer jeg for, at vi kan spare penge og genvinde dynamikken i den offentlige it ved at øge uafhængigheden mellem it-systemernes dele.

I denne artikel beskriver jeg, hvordan vi kan lykkedes med dette, uden at skulle viske tavlen helt ren først.

Kvæl monolitten bid for bid med Strangler Pattern

Frem for at etablere et stort moderniseringsprojekt, hvor systemet genudvikles eller ombygges på én gang, kan vi med Strangler Pattern, bid for bid,  flytte funktionalitet ud i nye moduler.

Princippet er, at vi udvælger et modul, som vi udvikler en uafhængig udgave af. Når det nye modul er udviklet og testet udfases den tilsvarende funktionalitet i monolitten og erstattes med det nye modul.

Fra monolit til service-baseret arkitektur med Strangler Patterns.
Fra monolit til service-baseret arkitektur med Strangler Pattern.

Eksemplet med dokumenthåndtering fra sidste uges artikel kan være et sted at starte. Vi bygger et nyt dokumenthåndteringsmodul mens det eksisterende forsætter som hidtil og definerer en håndfast kontrakt mellem modulet og det gamle system.

Det nye modul har sin egen datamodel og sin egen database. Når det nye dokumenthåndteringsmodul er klar, erstatter det så det gamle, der lukkes ned. Strangler Pattern hjælper os dermed til at ”kvæle” det gamle system – bid for bid.

”Hvordan organiserer vi arbejdet med moderne it bedst muligt?”

Jo større et modul er, jo mere ligner det i sig selv en monolit. Samtidig er yderpolen et virvar af utallige moduler, og det er heller ikke optimalt. Modulerne skal kunne tale sammen, og sammenhængen skal være overskuelig. Så hvordan deler vi monolitten op?

Nøglen er, at sætte sig ned og se hvilke elementer, moduler, vi naturligt kan dele systemet op i.

Opdelingen skal være logisk, og hvert modul skal have et veldefineret ansvar, hvor der ikke opstår et unødvendigt kompliceret landskab af afhængigheder.

Når du på papiret har delt modulerne op første gang, så tag fat i dem hver især og se om disse også kan deles op eller om du nu er i mål med en overordnet struktur med passende modulstørrelser.

Seks tommelfingerregler for arbejdet med Strangler Pattern og moduliseret arkitektur

I erkendelse af, at systemets arkitektur ikke er den eneste faktor, som påvirker organiseringen af arbejdet, er her et par tommelfingerregler at have for øje, når moduliseringsarbejdet går i gang.

  • Overvej hvor store teams I ønsker at arbejde i. Min erfaring er, at en teamstørrelse på fem til ni personer er godt. Overvej så hvor meget ét team kan håndtere. Dét er en god rettesnor for en modulstørrelse.
  • En opdeling i fem til ni moduler er et godt leje som udgangspunkt.
  • Det giver typisk mening at skille de administrative dele fra anvendelser der refererer til disse.
  • Sikkerhed og rettighedsstyring er også en god ting at have i et modul for sig.
  • Integrationer til tredjepartssystemer bør være selvstændige moduler. Således kan ændringer i relaterede systemer ikke påvirke de centrale moduler i løsningen.
  • Hver frontend til løsningen er kandidat til sit eget modul. Byg en backend-service til den specifikke frontend efter ’Backend for Frontend’-princippet.

Adfærdsændringen er den største udfordring

Som en afslutning på denne artikel, vil jeg knytte en kommentar til det jeg faktisk mener er det sværeste at gennemføre i overgangen fra monolit til moduliseret eller service-baseret it. Nemlig adfærdsændringen.

Udviklere har arbejdet med monolitter længe, og vaner er som bekendt svære at ændre i praksis.

Adfærdsændringer hos udviklingsstaben er ofte vanskeligt.
Adfærdsændringer hos udviklingsstaben er ofte vanskeligt.

En service-baseret og moduliseret it-arkitektur stiller nye krav til den enkelte udvikler, som pludselig skal forholde sig til at de enkelte moduler reelt er uafhængige. Emner som transaktioner, konsistente data og fejlhåndtering kræver et nyt og anderledes tankesæt hos udviklere.

Overgangen er svær, men jo længere vi lader stå til, jo større bliver regningen. Samtidig er det selvfølgelig vigtigt, at rykke på det rigtige tidspunkt.