Opdele monolitten eller stabilisere den? Beslutningskriterier for modulær modernisering

Mandag morgen, 9:10: En fagafdeling melder en „lille tilpasning“ i bestillingsprocessen. IT kigger kort i ticketteksten, det virker gennemførligt. To timer senere er stemningen en anden. Builden tager længere tid end planlagt, et sideløbende job er bundet til den samme release-pakke, og et blik i databasen gør klart: Denne ændring berører flere tabeller og triggere end antaget. Senest nu dukker spørgsmålet op, som mange teams regelmæssigt beskæftiger sig med: Skal monolitten opdeles eller stabiliseres?

Den, der reflexmæssigt svarer „Microservices!“, overser ofte kernen: Det handler ikke om et arkitekturlabel, men om leveranceevne og driftsstabilitet. Denne praksisvejledning fører gennem en pragmatisk vurdering, viser beslutningskriterier for modulær modernisering og beskriver gennemførlige skridt. Derudover gennemgås typiske fejlbilleder samt klare stop- og eskalationspunkter – så moderniseringen ikke bliver et varigt projekt uden målbar effekt.

Opdele eller stabilisere monolitten: først symptomet, så arkitekturen

„Monolitten er skyld i det“ lyder entydigt, men er sjældent præcist nok til en beslutning. En monolit (en applikation som et fælles Deployment-Artefakt) kan køre meget stabilt – eller konstant skabe friktion. Ligeledes gælder: Microservices (mange små, separat deploybare tjenester) kan reducere gennemløbstider, men medfører uundgåeligt flere operationelle opgaver.

Martin Fowler vurderer denne realitet nøgternt: Microservices er først og fremmest et andet Operations-Footprint – altså en anden driftsmæssig indsats med flere komponenter, flere deploys, flere fejlkilder og større behov for automatisering.^[Quelle] Grænsen for denne påstand: Den erstatter ikke en analyse af jeres system. Den praktiske konsekvens er dog klar: Den, der proklamerer “Microservices” som mål, før flaskehalsen er klart beskrevet, moderniserer hurtigt det forkerte sted.

Beslutningskriterier: Hvornår opdeling virkelig hjælper – og hvornår ikke

Moderniseringstryk er reel: Sikkerhedskravene stiger, antal grænseflader vokser, teams skifter, og forretningssoftwaren skal både køre og videreudvikles. Opdeling kan være et fornuftigt skridt – men kun hvis den adresserer flaskehalsen og ikke blot pynter på arkitekturdiagrammet.

Kriterium 1: Operationel modenhed – kan jeres drift bære det driftsmæssige fodaftryk?

Med hver ekstra deploybar enhed vokser behovet for en velordnet levering og overvågning: CI/CD (automatiseret build-/test-/deploy-kæde), Observability (metrikker, logs og traces til diagnose), incident-processer, runbooks og klare ansvarsfordelinger. AWS formulerer det som en afvejning: finere segmentering kan give fordele for pålidelighed og skalering, men øger den operative kompleksitet i takt med antallet af komponenter.^[Quelle] Grænsen: Det er en rettesnor, ikke en succesgaranti. Konklusionen: Hvis I i dag allerede har svært ved at få et deployment stabilt igennem, så multiplicerer en service-landskab dette problem.

Konkrete kontrolpunkter, som man ikke bør negligere:

• Release-parathed: Rollback/Backout er defineret, vedligeholdelsesvinduer og kommunikation er etableret.
• Monitoring & alarmering: Alarmer er handlingsorienterede (ikke “alt er rødt”), fejlkilder kan afgrænses.
• Incident-håndtering: Der er en rytme for postmortems og tiltag, ikke kun ad-hoc brandbekæmpelse.
• Ownership: Hvem træffer beslutning om grænseflader, hvem prioriterer, hvem bærer drift og kvalitet?

Kriterium 2: Ændringsafkobling – blokerer kravene hinanden?

Opdeling er fornuftig, når uafhængige ændringer i monolitten regelmæssigt bliver afhængige af hinanden, selvom de er fagligt adskilte. Typisk mønster: Et portalområde kræver hyppige ændringer, mens et afregningsområde sjældent skal ændres og kræver høj omhu. Hvis begge altid lander i samme release-strøm, hæmmer de hinanden.

Omvendt er opdeling ofte et selvmål, når næsten enhver ændring går på tværs af mange områder (rettigheder, prislogik, reporting, datarensning). Så skaber man trafik over grænseflader i stedet for afkobling – og koordinationen stiger i stedet for at falde.

Kriterium 3: Datenkopplung – ligger kompleksiteten i databasen?

Mange systemer er mindre bundet via kode end via data: fælles tabeller, Trigger, transaktionelle forløb og Batch-Jobs. Sam Newman fremhæver i sine dekompositionsmønstre, at den egentlige udfordring ofte er data- og integrationsstrategien – og at Big-Bang-Vorhaben dermed bliver særligt risikable.^[Kilde]

Praktisk konsekvens for driften: Hvis flere komponenter uden regler skriver til de samme tabeller, opstår der sideeffekter, som er svære at rulle tilbage på en ren måde. Modulær modernisering kræver derfor tidlige beslutninger om dataejerskab, konsistens og afkobling af rapportering.

Kriterium 4: Stabilitet und fachlicher Wert – hvad skal bevares?

I etablerede digitale virksomheds­løsninger ligger ofte meget korrekt modelleret domænelogik: undtagelsestilfælde, kommercielle regler, afvigelser i processer, historisk udviklet datarensning. Det er ikke „Legacy-Müll“, men ofte årsagen til, at forretningen overhovedet fungerer. Modernisering er økonomisk forsvarlig, når den ikke letkøbt forkaster denne værdi – og samtidig identificerer de steder, der gør drift og videreudvikling uforholdsmæssigt dyre.

Auswahl treffen: Drei Zielbilder, die in Unternehmen funktionieren

Mellem „alt forbliver“ og „alt bliver Microservices“ findes praktiske målbilleder, der gør modernisering planbar. AWS Prescriptive Guidance anbefaler udtrykkeligt at vurdere, hvilke dele overhovedet bør dekomponeres, og at foretrække inkrementelle tilgange.^[Kilde]

Praksisvejledning: Fra vurdering til implementering (med Stop/Go-punkter)

1) Gør systemgrænser synlige – små nok til at blive brugt

I behøver ikke en 80-siders systemdokumentation for at træffe en beslutning. Det, der hjælper, er et kompakt kort: hovedprocesser, kritiske grænseflader (f.eks. portaler, EDI, fileksporter, REST-APIs), batch-jobs samt steder med høj fejlfølsomhed. Målet: at kunne træffe beslutninger, ikke arkivere viden.

En tilgang, der har vist sig effektiv, samler drift og fagafdeling: ”Hvilken processtrækning er forretningskritisk, og hvad hænger den teknisk sammen med?” Så bliver det hurtigt synligt, hvor en ekstraktion ville være risikabel – og hvor den rent faktisk kunne give aflastning.

2) Definér baseline-metrikker – ellers bliver det en tro-sag

Modernisering uden baseline er som performance-optimering uden måling. Det afgørende er nøgletal, der dækker både delivery og drift: Deployment-frekvens, Lead Time (fra krav til produktion), Change Failure Rate (fejl efter ændringer), MTTR (Mean Time to Recovery) og tilbagevendende incident-klasser. Metrikkerne behøver ikke være akademisk perfekte – men de skal indsamles konsekvent, så et Stop/Go er muligt.

3) Afgræns kandidater – efter domæne, ikke efter tekniske lag

Et hyppigt fejlagtigt udgangspunkt er snittet efter lag (”UI-service”, ”DB-service”). Det skaber nye afhængigheder i stedet for at reducere dem. Domæneopdeling betyder: Et modul har ansvaret for et fagligt område inklusive regler og data. Det er for teams ofte mere håndgribeligt end en ren teknisk afgrænsning.

Kan I ikke navngive de faglige grænser, er det ikke et argument for at skære hurtigere – men et signal om først at stabilisere og modularisere i monolitten: afklare begreber, forstå dataflows, identificere tværgående funktioner.

4) Strangler frem for Big Bang – omdiriger kontrolleret, sluk konsekvent

Når tilgængelighed tæller og risici skal kontrolleres, er Strangler-Fig-mønsteret en robust vej: Funktioner erstattes trinvis ved siden af det eksisterende system; trafikken dirigeres kontrolleret om, indtil de gamle stier afbrydes.^[Kilde]

Vigtigt er disciplinen bag mønsteret: klare routing-beslutninger, kompatibilitet i data og grænseflader, monitoring på begge veje – og et reelt „Done“, når den gamle sti er fjernet. Ellers bliver parallelkørsel en permanent tilstand.

5) Fastlæg data- og rapporteringsstrategi tidligt

I praksis afgøres modernisering ofte af to spørgsmål: hvem ‚ejer‘ hvilke data – og hvordan rapporteres der? Hvis rapportering direkte læser fra operative tabeller, blokerer det for ændringer. Hvis flere komponenter ‚deler‘ data uden regler, opstår inkonsistenser.

Planlæg derfor eksplicit:

• Dataejerskab: hvilket modul er førende for hvilken entitet (kunde, ordre, faktura …)?
• Konsistenskrav: hvor er stærk konsistens nødvendig, hvor rækker Eventual Consistency?
• Afkobling af rapportering: hvordan forsynes analyser, uden at de operative modeller hærdes?

6) Definér sikkerhed og drift per modul – ikke noget, der føjes på bagefter

Med hver ny komponent øges angrebsfladen: service-til-service-kommunikation, Secrets, rettigheder, Audit-Trails. Afklar tidligt, hvordan autentificering (f.eks. centralt via SSO) og autorisation (rolle-/rettighedsbaseret pr. domæne) spiller sammen. I hverdagen tæller desuden: logs skal være diagnostisk nyttige, men må ikke overtræde databeskyttelses- og opbevaringsregler. Disse punkter hører i Runbooks og driftsdokumentation – ikke kun i arkitekturfolier.

8-trins-tjekliste for en robust Go/No-Go-beslutning

1. Angiv flaskehalsen: Hvad præcist skal blive bedre (release-varighed, stabilitet, skalering, paralleludvikling)?
2. Mål baseline: Hvilke målepunkter afbilder nuværende tilstand (Lead Time, Change Failure Rate, MTTR osv.)?
3. Tjek driftsparathed: CI/CD, overvågning, alarmering, Runbooks, incidentprocesser, ejeransvar.
4. Skitsér domænesnittet: Hvor ligger de naturlige faglige grænser? Hvad er tværgående emner?
5. Udform datastrategi: dataejerskab, konsistens, rapportering, migrationsveje.
6. Inventariser afhængigheder: jobs, grænseflader, filudtræk, brugergrupper, rettigheder.
7. Planlæg slice: en lille, leverbar pakke inkl. rollback og overvågningsmål.
8. Fastlæg Stop/Go-kriterier: Hvilke signaler stopper opdelingen eller tvinger et stabiliseringsskridt?

Typiske fejlscenarier – sådan ser de ud i drift

Fejl 1: Flere komponenter, men intet ejeransvar

Hvis ingen er ende-til-ende ansvarlig (prioritering, kvalitet, drift), bliver afkobling til et koordineringsproblem. I incident-tilfælde fører det til lange runder, uklare beslutninger og refleksen at deploye igen „alt sammen“. Modforanstaltning: en klar ejerkreds pr. modul, definerede overdragelser og et beslutningslog for grænseflader og dataejerskab.

Fejl 2: Delte data uden regler

Mønsteret er kendt: tjenester er adskilte, men skriver stadig til de samme tabeller eller bruger direkte databaseadgang på tværs af domæner. Det bryder isolation, gør audits vanskeligere og gør rollbacks upålidelige. Modforanstaltning: dataadgang via definerede grænseflader, klart dataansvar og – hvor nødvendigt – kontrolleret synkronisering (f.eks. Events).

Fejl 3: Netværkslatenstid og fejlkaskader planlægges „med“, men testes ikke

Hvad i monolitten var et in-process-kald, bliver i distribuerede arkitekturer et netværkskald med timeouts, retries og potentielle kaskader. Uden klare timeouts, korrelation (Request-IDs) og realistiske ende-til-ende-tests bliver fejlanalysen væsentligt vanskeligere. Modforanstaltning: klare SLOs (målbare servicemål), definerede timeouts, trace-korrelation og load-tests langs komplette procesforløb.

Fejl 4: Opdeling efter organisationsdiagram i stedet for efter faglig logik

Hvis services primært afspejler teamgrænser, men fagligt løber på tværs af processer, forbliver koblingen — blot på et andet niveau. Modforanstaltning: domæneafgrænset opdeling, selvom det i starten skaber friktion. Hvis det organisatorisk ikke er muligt, er en modulær monolit ofte det bedre mellemliggende skridt.

Stop- og eskalationspunkter: Hvornår stabilisering er den bedre beslutning

Et moderniseringsprojekt har brug for Stop-Regeln, ellers æder det budget og opmærksomhed. Disse signaler er stærke grunde til bevidst at skifte fokus:

• Operationel overbelastning: alarmflod, stigende MTTR, On-Call kan ikke længere dækkes.
• Ingen målbar forbedring: Lead Time, Change Failure Rate eller stabilitet forbedres ikke tydeligt.
• Grænsefladekompleksiteten eksploderer: versionering uklar, Breaking Changes hober sig op, debugging bliver et gætteri.
• Datakonflikter: inkonsistenser, dobbelte sandheder, svært forklarlige rapportafvigelser.
• Ownership forbliver uklar: beslutninger trækker ud, ingen påtager sig ansvaret for drift og videreudvikling.

Eskalering betyder ikke ’tilbage til det gamle’, men: prioritér stabilisering. Typiske tiltag er: følge op med regressionstest for kerneprocesser, forbedre Observability, konsolidere dataadgange, skærpe modulgrænserne i monolitten – og først derefter vurdere igen, om en ekstraktion virkelig giver reel gevinst.

Hvad „stabilisere“ konkret betyder – og hvorfor det ofte virker hurtigere

Stabilisering er ikke en kosmetisk oprydningsaktion. I driften viser den sig som færre overraskelser og planlagte releases. Konkrete greb, som teams mærker med det samme:

• Release-mekanik: reproducerbar build, konsistente miljøer, etableret rollback-procedure.
• Transparens: logging-standarder, fejlkategorisering, korrelation af requests på tværs af processtrækninger.
• Testfokus: ende-til-ende-regression for kerneflows (ikke kun isolerede tests).
• Modulgrænser i monolitten: definerede interne APIs, disciplineret dataadgang, klare ansvarsområder.
• Datahygiejne: entydige stamdatakilder, dokumenterede bivirkninger fra jobs, reduceret særtilfælde-logik.

Resultatet er ofte en robust modulær monolit: Softwaren forbliver driftbar som en enhed, men internt mere klart opdelt. Derved opnår teams meget af det, man forventer af en opdeling — uden øjeblikkeligt at multiplicere den operative kompleksitet.

Sidste kontrolspørgsmål, før De beslutter

Hvis De begyndte at opdele i dag: Kan De næste morgen ved et incident hurtigt sige, hvilken del der er ansvarlig, hvem reagerer, hvilken metrik der dokumenterer fejlen og hvordan De ruller tilbage? Hvis dette spørgsmål forbliver ubehageligt åbent, er beslutningen som regel ikke „mere arkitektur“, men „mere driftsikkerhed“.

Hvis De ønsker at vurdere Deres udgangspunkt struktureret og etablere en moderniseringsvej med klare Stop/Go-Punkten, kan De kontakte os for dette enkeltstående og målrettede engagement:

I denne sammenhæng er også legacy-modernisering og Strangler Fig-mønster vigtige. Artiklen sætter disse aspekter i en forståelig kontekst og viser, hvad der er vigtigt i praksis.

Drøft projekt eller moderniseringsprojekt med Net-Base.