Dele opp eller stabilisere monolitten? Beslutningskriterier for modulær modernisering

Mandag morgen, 09:10: En fagavdeling melder en „liten justering“ i bestillingsprosessen. IT ser kort på ticket-teksten, det virker gjennomførbart. To timer senere er stemningen en annen. Builden kjører lenger enn planlagt, en samtidig jobb er koblet til samme release-pakke, og ved et blikk i databasen blir det klart: Denne endringen berører flere tabeller og triggere enn antatt. Spørsmålet som mange team jevnlig står overfor dukker nå opp: Dele opp monolitten eller stabilisere den?

Den som refleksivt svarer „Microservices!“ overser ofte kjernen: Det handler ikke om et arkitekturmerke, men om leveranseevne og driftssikkerhet. Denne praksisveilederen leder gjennom en pragmatisk vurdering, viser beslutningskriterier for modulær modernisering og beskriver gjennomførbare trinn. I tillegg gjennomgås typiske feilmønstre samt klare avbrudds- og eskaleringspunkter – slik at modernisering ikke blir et varig prosjekt uten målbar effekt.

Dele opp monolitten eller stabilisere den: først symptomet, så arkitekturen

„Monolitten er skyldig“ høres entydig ut, men er sjelden presist nok for en beslutning. En monolitt (en applikasjon som ett felles deploy-artefakt) kan kjøre meget stabilt – eller skape vedvarende friksjon. Det samme gjelder: Microservices (mange små, separat deploybare tjenester) kan redusere gjennomløpstid, men medfører nødvendigvis flere operative oppgaver.

Martin Fowler plasserer denne realiteten nøkternt: mikrotjenester er først og fremst et annet driftsavtrykk – altså en annen driftsinnsats med flere komponenter, flere deploys, flere feilkilder og større behov for automatisering.^[Kilde] Grensen for denne påstanden: Den erstatter ingen analyse av Deres system. Den praktiske konsekvensen er likevel klar: Den som erklærer «mikrotjenester» som mål før flaskehalsen er grundig beskrevet, moderniserer raskt på feil sted.

Beslutningskriterier: Når oppdeling virkelig hjelper – og når den ikke gjør det

Presset for modernisering er reelt: sikkerhetskrav øker, antall grensesnitt vokser, team skifter, og forretningssystemet må både kjøre videre og videreutvikles. Oppdeling kan være et fornuftig grep – men bare hvis den adresserer flaskehalsen og ikke bare forskjønner arkitekturdokumentet.

Kriterium 1: Operativ modenhet – kan driften håndtere det økte avtrykket?

Med hver ekstra deploybar enhet øker behovet for pålitelig leveranse og overvåking: CI/CD (automatisert build-/test-/deploy-kjede), observability (metrikker, logger og traces for diagnostikk), incident-prosesser, runbooks og klare ansvarsforhold. AWS formulerer dette som en avveining: finere segmentering kan gi fordeler for pålitelighet og skalering, men øker med antall komponenter den operative kompleksiteten.^[Kilde] Begrensningen: Dette er en rettesnor, ikke en suksessgaranti. Konklusjonen: Hvis dere allerede i dag har problemer med å få gjennomført en stabil utrulling, så forsterker et tjenestelandskap dette problemet.

Konkrete sjekkpunkter som man ikke bør avfeie:

• Utgivelsesberedskap: Rollback/Backout er definert, vedlikeholdsvinduer og kommunikasjon er etablert.
• Overvåking og varsling: Varsler er handlingsorienterte (ikke «alt rødt»), feilkilder kan avgrenses.
• Håndtering av hendelser: Det finnes en rytme for postmortems og tiltak, ikke bare ad-hoc-brannslukking.
• Eierskap: Hvem avgjør grensesnitt, hvem prioriterer, hvem bærer drift og kvalitet?

Kriterium 2: Endringsavkobling – blokkerer krav hverandre?

Oppdeling lønner seg når uavhengige endringer i monolitten regelmessig blir avhengige av hverandre, selv om de er faglig adskilte. Typisk mønster: Et portalområde trenger hyppige tilpasninger, mens et faktureringsområde sjelden endres og krever høy presisjon. Hvis begge alltid havner i samme release-løp, hemmer de hverandre.

Omvendt er oppdeling ofte et selvmål når nesten hver endring går på tvers av mange områder (autorisering, prislogikk, rapportering, datarensing). Da skaper man trafikk over grensesnitt i stedet for avkobling – og koordinasjonen øker i stedet for å synke.

Kriterium 3: Datakobling – ligger kompleksiteten i databasen?

Mange systemer er mindre koblet via kode enn via data: felles tabeller, trigger, transaksjonelle prosesser og batch-jobber. Sam Newman påpeker i sine dekomponeringsmønstre at den egentlige utfordringen ofte er data- og integrasjonsstrategien – og at Big-Bang-prosjekter blir spesielt risikable.^[Kilde]

Praktisk konsekvens for drift: Hvis flere komponenter uten regler skriver til de samme tabellene, oppstår sideeffekter som det er vanskelig å rulle tilbake på en ryddig måte. Modulær modernisering krever derfor tidlige beslutninger om dataeierskap, konsistens og avkobling av rapportering.

Kriterium 4: Stabilitet og faglig verdi – hva må bevares?

I modne digitale virksomhetsløsninger ligger ofte mye korrekt avbildet domenelogikk: særtilfeller, kommersielle regler, unntak i prosesser, historisk opparbeidet datarensing. Dette er ikke «legacy-søppel», men ofte grunnen til at virksomheten i det hele tatt fungerer. Modernisering blir økonomisk fornuftig hvis den ikke lettvint forkaster denne verdien – samtidig som den identifiserer de områdene som gjør drift og videreutvikling urimelig kostbart.

Ta et valg: Tre målbilder som fungerer i virksomheter

Mellom «alt blir værende» og «alt blir mikrotjenester» finnes praktiske målbilder som gjør modernisering planbar. AWS Prescriptive Guidance anbefaler uttrykkelig å undersøke hvilke deler som overhodet bør dekomponeres før man går i gang, og å foretrekke inkrementelle tilnærminger.^[Kilde]

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

1) Synliggjør systemgrensene – små nok til å kunne brukes

Det er ikke behov for en 80-siders systemdokumentasjon for å kunne fatte beslutninger. Det som hjelper, er et kompakt kart: hovedprosesser, kritiske grensesnitt (f.eks. portaler, EDI, fileksporter, REST-APIer), batch-jobber, samt steder med høy feilutsatthet. Mål: å kunne ta beslutninger, ikke å arkivere kunnskap.

En velprøvd tilnærming er et perspektiv som kobler drift og fagavdeling: «Hvilken prosessbane er forretningskritisk, og hva avhenger den av teknisk?» Da blir det raskt synlig hvor en ekstraksjon ville være risikabel – og hvor den faktisk kunne gi avlastning.

2) Definer baseline-metrikker – ellers blir det et spørsmål om tro

Modernisering uten baseline er som en ytelsesoptimalisering uten måling. Avgjørende er nøkkeltall som dekker både leveranse og drift: deploy-frekvens, Lead Time (fra krav til produksjon), Change Failure Rate (feil etter endringer), MTTR (Mean Time to Recovery) og tilbakevendende incident-klasser. Metrikkene trenger ikke være akademisk perfekte – men de må innhentes konsistent, slik at et Stop/Go er mulig.

3) Avgrens kandidater – etter domene, ikke etter tekniske lag

En vanlig feilstart er å dele etter lag («UI-Service», «DB-Service»). Det skaper nye avhengigheter i stedet for å redusere dem. Domeneavgrensning betyr: Et modul har ansvaret for et fagområde inklusive regler og data. Det er for team vanligvis mer håndgripelig enn ren teknisk avgrensning.

Hvis dere ikke kan navngi de faglige grensene, er det ikke grunn til å dele raskere – men et signal om først å stabilisere og modularisere i monolitten: begreper avklare, dataflyter forstå, tverrgående funksjoner identifisere.

4) Strangler fremfor Big Bang – kontroller omdirigering, konsekvent avvikling

Når tilgjengelighet teller og risiko må kontrolleres, er Strangler-Fig-Pattern et robust valg: funksjoner erstattes trinnvis ved siden av det eksisterende systemet; trafikken omdirigeres kontrollert inntil de gamle banene slås av.^[Kilde]

Viktig er disiplinen bak mønsteret: klare routing-beslutninger, kompatibilitet i data og grensesnitt, overvåking over begge veier – og et ekte «Done» når den gamle banen er fjernet. Ellers oppstår parallelldrift som en permanent tilstand.

5) Fastslå data- og rapporteringsstrategi tidlig

I praksis avgjøres modernisering ofte av to spørsmål: hvem «eier» hvilke data — og hvordan rapporteres det? Hvis rapportering går direkte mot operative tabeller, hindrer det endringer. Hvis flere komponenter deler på data uten regler, oppstår inkonsistenser.

Planlegg derfor eksplisitt:

• Dataeierskap: hvilket modul er ledende for hvilken entitet (kunde, ordre, faktura …)?
• Konsistenskrav: hvor er sterk konsistens nødvendig, hvor holder Eventual Consistency?
• Avkobling av rapportering: hvordan forsyne analyser uten å gjøre de operative modellene rigide?

6) Definer sikkerhet og drift per modul – ikke bare legge det til i etterkant

Med hver ny komponent øker angrepsflaten: tjeneste-til-tjeneste-kommunikasjon, Secrets, rettigheter, Audit-Trails. Avklar tidlig hvordan autentisering (f.eks. sentralt via SSO) og autorisering (rolle-/rettighetsbasert per domene) samspiller. I det daglige teller også: logger må være diagnostisk hjelpsomme, men må ikke bryte personvern- eller oppbevaringsregler. Disse punktene hører hjemme i Runbooks og driftsdokumentasjon – ikke bare i arkitekturfolier.

8-trinns sjekkliste for en robust Go/No-Go-beslutning

1. Navngi flaskehals: Hva skal forbedres konkret (utgivelsestid, stabilitet, skalering, parallellutvikling)?
2. Mål baseline: Hvilke nøkkeltall beskriver dagens tilstand (Lead Time, Change Failure Rate, MTTR osv.)?
3. Sjekk driftsberedskap: CI/CD, overvåking, varsling, Runbooks, incident-prosesser, eierskap.
4. Skisser domeneskillet: Hvor ligger de naturlige faggrenser? Hva er tverrgående temaer?
5. Utform datastrategi: dataeierskap, konsistens, rapportering, migrasjonsveier.
6. Kartlegg avhengigheter: jobber, grensesnitt, fil-eksporter, brukergrupper, rettigheter.
7. Planlegg en Slice: en liten, leverbar pakke inkl. Rollback og overvåkingsmål.
8. Definer Stop/Go-kriterier: Hvilke signaler stopper oppdelingen eller krever et stabiliseringssteg?

Typiske feilbilder – slik ser de ut i drift

Feil 1: Flere komponenter, men ingen eierskap

Når ingen har ende-til-ende-ansvar (prioritering, kvalitet, drift), blir løs kobling et koordinasjonsproblem. Ved incident fører det til lange runder, uklare beslutninger og refleksen å deploye «alt sammen» igjen. Mottiltak: for hvert modul en tydelig eiergruppe, definerte overganger og en beslutningslogg for grensesnitt og dataeierskap.

Feil 2: Delte data uten regler

Anti-mønsteret er kjent: tjenester er atskilt, men skriver fortsatt til de samme tabellene eller bruker direkte database-tilgang på tvers av domener. Det bryter isolasjon, gjør revisjon vanskeligere og gjør Rollbacks upålitelig. Mottiltak: datatilgang via definerte grensesnitt, klart dataansvar og – der det er nødvendig – kontrollert synkronisering (f.eks. Events).

Feil 3: Nettverkslatens og feilkaskader blir «inkludert i planen», men ikke testet

Det som i monolitten var et in-process-kall, blir i distribuerte arkitekturer et nettverkskall med Timeouts, Retries og potensielle kaskader. Uten tydelige Timeouts, korrelasjon (Request-IDs) og realistiske ende-til-ende-tester blir feilanalyse betydelig vanskeligere. Mottiltak: klare SLOs (målbare tjenestemål), definerte Timeouts, Trace-korrelasjon og lasttester langs komplette prosessløp.

Feil 4: Oppdeling etter organisasjonskart i stedet for etter faglogikk

Hvis tjenester først og fremst reflekterer teamgrenser, men faglig krysser prosessene, forblir koblingen – bare på et annet nivå. Mottiltak: domenespesifikk avgrensning, selv om det i starten skaper friksjon. Er det ikke organisatorisk mulig, er en modulær monolitt ofte et bedre mellomsteg.

Stopp- og eskaleringspunkter: Når stabilisering blir det bedre valget

Et moderniseringsprosjekt trenger stopp-regler, ellers spiser det budsjett og oppmerksomhet. Disse signalene er tungtveiende grunner til å bevisst omstille seg:

• Operativ overbelastning: alarmflom, økende MTTR, on-call ikke lenger håndterbart.
• Ingen målbar forbedring: Lead Time, Change Failure Rate eller stabilitet viser ingen klar forbedring.
• Grensesnittkompleksitet eksploderer: versjonering uavklart, Breaking Changes blir hyppigere, debugging blir et gjettespill.
• Datakonflikter: inkonsistenser, doble sannheter, vanskelig forklarbare avvik i rapporter.
• Eierskap forblir uklart: beslutninger tar tid, ingen bærer ansvar for drift og videreutvikling.

Eskalering betyr da ikke «tilbake til det gamle», men: prioritere stabilisering. Typiske tiltak er: gjennomføre ende-til-ende-regresjon for kjerneprosesser, forbedre Observability, konsolidere dataaksess, skjerpe modulgrenser i monolitten – og først deretter vurdere på nytt om en ekstraksjon virkelig gir nytte.

Hva «stabilisere» konkret betyr – og hvorfor det ofte virker raskere

Stabilisering er ingen kosmetisk opprydding. I drift viser den seg som færre overraskelser og planbare releases. Konkrete grep som teamene merker umiddelbart:

• Release-mekanikk: reproduserbar build, konsistente miljøer, innøvd rollback-prosess.
• Transparens: logging-standarder, feilklassifisering, korrelasjon av forespørsler over prosessforløp.
• Testfokus: ende-til-ende-regresjon for kjerneflyter (ikke bare isolerte tester).
• Modulgrenser i monolitten: definerte interne API-er, disiplinert dataadgang, klare ansvarsforhold.
• Datahygiene: entydige kilder for stamdata, dokumenterte sideeffekter av jobber, redusert spesialtilfellslogikk.

Resultatet er ofte en robust modulær monolitt: Programvaren forblir driftbar som en enhet, men er internt klarere avgrenset. Dermed får teamene mye av det tilbake de forventer fra oppdeling – uten å umiddelbart mangedoble operasjonell kompleksitet.

Siste kontrollspørsmål før dere avgjør

Dersom dere delte opp i dag: Kan dere i morgen tidlig ved en hendelse raskt angi hvilken del som er ansvarlig, hvem som skal reagere, hvilken metrikk som dokumenterer feilen og hvordan dere ruller tilbake? Hvis dette spørsmålet forblir ubehagelig åpent, er beslutningen som regel ikke «mer arkitektur», men «mer driftssikkerhet».

Hvis dere vil vurdere utgangssituasjonen strukturert og legge en moderniseringsvei med klare stopp/go-punkter, kan dere kontakte oss en gang for målrettet bistand:

For dette temaet er også modernisering av legacy-systemer og Strangler Fig-mønster viktige. Artikkelen setter disse aspektene i en klar kontekst og viser hva som er avgjørende i praksis.

Drøft prosjekt eller moderniseringsinitiativ med Net-Base.