Monolit: dela upp eller stabilisera? Beslutskriterier för modulär modernisering

Måndagsmorgon, 09:10: En verksamhetsavdelning rapporterar en „liten ändring“ i beställningsprocessen. IT tittar snabbt i tickettexten, verkar genomförbar. Två timmar senare är stämningen en annan. Bygget körs längre än planerat, ett bakjobb ligger på samma releasepaket, och vid en titt i databasen blir det tydligt: Denna ändring berör fler tabeller och triggers än väntat. Senast nu uppstår frågan som många team ofta brottas med: dela upp monoliten eller stabilisera den?

Den som reflexmässigt svarar „Microservices!“ förbiser ofta kärnan: Det handlar inte om en arkitektur-etikett utan om leveransförmåga och driftssäkerhet. Denna praktiska vägledning leder genom en pragmatisk granskning, visar beslutskriterier för modulär modernisering och beskriver genomförbara steg. Dessutom presenteras typiska felmönster samt tydliga avbrotts- och eskaleringspunkter – så att modernisering inte blir ett långvarigt projekt utan mätbar effekt.

dela upp monoliten eller stabilisera den: först symtomet, sedan arkitekturen

„Monoliten är skyldig“ låter entydigt, men är sällan tillräckligt precist för ett beslut. En monolit (en applikation som ett gemensamt Deployment-Artefakt) kan köra mycket pålitligt – eller ständigt skava. Detsamma gäller: Microservices (många små, separat deploybara tjänster) kan minska ledtiderna, men medför nödvändigtvis fler operationella uppgifter.

Martin Fowler bedömer den här verkligheten sakligt: Microservices är framför allt ett annat operationsavtryck – alltså en annan driftsinsats med fler komponenter, fler Deployments, fler felkällor och ett större behov av automatisering.^[Källa] Gränsen för detta uttalande: det ersätter inte en analys av ert system. Den praktiska slutsatsen är ändå klar: den som proklamerar ”Microservices” som mål innan flaskhalsen är tydligt beskriven moderniserar snabbt på fel ställe.

Beslutskriterier: När uppdelning verkligen hjälper – och när inte

Trycket att modernisera är verkligt: säkerhetskrav ökar, gränssnitt blir fler, team byts ut, och affärsprogramvaran ska samtidigt fortsätta att fungera och utvecklas. Uppdelning kan vara ett meningsfullt steg – men bara om den adresserar flaskhalsen och inte bara förskönar arkitekturdiagrammet.

Kriterium 1: Operativ mognad – klarar er drift av operationsavtrycket?

Med varje extra deploybar enhet ökar behovet av ordentlig leverans och övervakning: CI/CD (automatiserad Build-/Test-/Deploy-kedja), Observability (metrik, loggar och Traces för diagnos), incidentprocesser, runbooks och tydliga ansvarsfördelningar. AWS formulerar det som en avvägning: finare segmentering kan ge fördelar för tillförlitlighet och skalning, men ökar med antalet komponenter den operativa komplexiteten.^[Källa] Gränsen: detta är en riktlinje, ingen framgångsgaranti. Slutsatsen: Om ni idag redan har svårt att genomföra ett Deployment stabilt, multiplicerar en service‑landskap detta problem.

Konkreta kontrollpunkter som inte bör förbises:

• Release-förmåga: Rollback/Backout är definierat, underhållsfönster och kommunikation är etablerade.
• Monitoring & larmning: Larm är handlingsorienterade (inte „allt rött“), felkällor kan avgränsas.
• Incident-hantering: Det finns en rytm för postmortems och åtgärder, inte bara ad hoc-krisinsatser.
• Ownership: Vem beslutar om gränssnitt, vem prioriterar, vem ansvarar för drift och kvalitet?

Kriterium 2: Ändringsavkoppling – blockerar krav varandra?

Uppdelning är motiverad när oberoende förändringar i monoliten regelbundet blir beroende av varandra, trots att de är funktionellt separata. Typiskt mönster: ett portalsegment behöver frekventa anpassningar, medan ett faktureringsområde sällan får ändras och kräver hög noggrannhet. Om båda alltid hamnar i samma release‑tåg bromsar de varandra.

Omvänt blir uppdelning ofta ett självmål när nästan varje ändring går tvärs över många områden (behörigheter, prislogik, rapportering, datarensning). Då skapar man gränssnitts‑trafik istället för avkoppling – och koordinationen ökar istället för minskar.

Kriterium 3: Datakoppling – ligger komplexiteten i databasen?

Många system är mindre kopplade via kod än via data: gemensamma tabeller, triggers, transaktionella flöden och batch-jobb. Sam Newman konstaterar i sina dekompositionsmönster att den verkliga utmaningen ofta är data- och integrationsstrategin – och att Big-Bang-initiativ då blir särskilt riskfyllda.^[Källa]

Praktisk slutsats för driften: Om flera komponenter skriver till samma tabeller utan regler uppstår sidoeffekter som är svåra att rulla tillbaka på ett rent sätt. Modulär modernisering kräver därför tidiga beslut om dataägarskap, konsistens och avkoppling av rapportering.

Kriterium 4: Stabilitet och domänvärde – vad måste bevaras?

I etablerade digitala företagslösningar finns ofta mycket korrekt modellerad domänlogik: specialfall, affärsregler, avvikelser i processer, historiskt uppkommen datarensning. Det är inte „legacy-skräp“, utan ofta anledningen till att verksamheten överhuvudtaget fungerar. Modernisering blir ekonomiskt försvarbar om den inte lättvindigt avvisar detta värde – och samtidigt identifierar de delar som gör drift och vidareutveckling oproportionerligt dyra.

Val: Tre målbilder som fungerar i företag

Mellan „allt stannar“ och „allt blir mikrotjänster“ finns praktiska målbilder som gör modernisering planbar. AWS Prescriptive Guidance rekommenderar uttryckligen att innan dekompositionen granska vilka delar över huvud taget bör dekomponeras och att föredra inkrementella tillvägagångssätt.^[Källa]

Praktisk vägledning: Från granskning till genomförande (med Stop/Go-punkter)

1) Gör systemgränserna synliga – tillräckligt små för att användas

Du behöver ingen 80-sidig systemdokumentation för att fatta beslut. Det som hjälper är en kompakt karta: huvudprocesser, kritiska gränssnitt (t.ex. portaler, EDI, filexporter, REST-APIs), batchjobb samt punkter med hög felbenägenhet. Målet: att kunna fatta beslut, inte att arkivera kunskap.

En vy som förenar drift och verksamhet har visat sig fungerande: ”Vilken processkedja är affärskritisk, och vad är dess tekniska beroenden?” Då blir det snabbt synligt var en extraktion vore riskfylld – och var den faktiskt skulle ge avlastning.

2) Definiera baslinjemetriker – annars förblir det en trosfråga

Modernisering utan baslinje är som prestandaoptimering utan mätning. Avgörande är nyckeltal som speglar både leverans och drift: deploymentsfrekvens, Lead Time (från krav till produktion), Change Failure Rate (störningar efter ändringar), MTTR (genomsnittlig tid till återställning) och återkommande incidentklasser. Metrikerna behöver inte vara akademiskt perfekta – men de måste samlas in konsekvent, så att ett Stop/Go är möjligt.

3) Kandidater: dela enligt domän, inte efter tekniklager

Ett vanligt felsteg är att dela efter lager (”UI-service”, ”DB-service”). Det skapar nya beroenden istället för att minska dem. Domänsnitt innebär: en modul ansvarar för ett affärsområde inklusive regler och data. Det är för team oftast mer greppbart än en rent teknisk avgränsning.

Om ni inte kan namnge de affärsmässiga gränserna är det inte en anledning att skära snabbare – utan en signal att först stabilisera och modularisera i monoliten: klargör begrepp, förstå dataflöden, identifiera tvärgående funktioner.

4) Strangler istället för Big Bang – dirigera kontrollerat om, stäng av konsekvent

När tillgänglighet räknas och risker måste kontrolleras är Strangler-Fig-Pattern en robust väg: funktioner ersätts stegvis parallellt med det befintliga systemet; trafiken dirigeras kontrollerat om tills gamla vägar stängs av.^[Quelle]

Det som krävs är disciplin bakom mönstret: klara routingbeslut, kompatibilitet i data och gränssnitt, övervakning över båda vägar – och ett verkligt ”Done” när den gamla vägen tas bort. Annars uppstår parallellkörning som ett permanent tillstånd.

5) Fäst data- och rapporteringsstrategin tidigt

I praktiken avgörs modernisering ofta av två frågor: Vem ”äger” vilka data – och hur rapporteras det? Om rapportering läser direkt från operativa tabeller hindrar det förändringar. Om flera komponenter ”delar” data utan regler uppstår inkonsekvenser.

Planera därför uttryckligen:

• Dataägarskap: vilken modul är ledande för vilken entitet (kund, order, faktura …)?
• Konsistenskrav: var krävs stark konsistens, var räcker eventuell konsistens?
• Rapporteringsavkoppling: hur förses analyser utan att härda de operativa modellerna?

6) Definiera säkerhet och drift per modul – inte något som sätts på i efterhand

Med varje ny komponent ökar ytan för attacker: tjänst‑till‑tjänst‑kommunikation, hemligheter, rättigheter, revisionsloggar. Klargör tidigt hur autentisering (t.ex. centralt via SSO) och auktorisering (roll-/rättighetsbaserat per domän) samspelar. I vardagen är det också viktigt att: loggar måste vara diagnostiskt användbara, men får inte bryta mot dataskydds‑ och lagringsregler. Dessa punkter hör hemma i runbooks och driftdokumentation – inte bara i arkitekturpresentationer.

8‑stegschecklista för ett välgrundat Go/No‑Go‑beslut

1. Nämn flaskhalsen: Vad exakt ska bli bättre (release‑tid, stabilitet, skalning, parallellutveckling)?
2. Mät baseline: Vilka nyckeltal avspeglar nuläget (Lead Time, Change Failure Rate, MTTR etc.)?
3. Kontrollera driftsförmåga: CI/CD, övervakning, larm, runbooks, incidentprocesser, ägarskap.
4. Skissera domänsnitt: Var finns naturliga fackliga gränser? Vad är tvärgående frågor?
5. Utforma datastrategi: dataägarskap, konsistens, rapportering, migrationsvägar.
6. Inventera beroenden: jobb, gränssnitt, filexporter, användargrupper, rättigheter.
7. Planera en slice: ett litet levererbart paket inkl. rollback och övervakningsmål.
8. Fastställ stop/go‑kriterier: Vilka signaler stoppar uppdelningen eller tvingar fram ett stabiliseringssteg?

Typiska felbilder – så visar de sig i drift

Fel 1: Fler komponenter, men ingen ownership

Om ingen är end‑to‑end ansvarig (prioritering, kvalitet, drift) blir entkoppling ett samordningsproblem. Vid en incident leder det till långa rundor, oklara beslut och reflexen att återigen deploya ”allt tillsammans”. Motåtgärd: för varje modul en tydlig ägargrupp, definierade överlämningar och en beslutslogg för gränssnitt och dataägarskap.

Fel 2: Delade data utan regler

Anti‑mönstret är välkänt: tjänster är separata men skriver fortfarande till samma tabeller eller använder direkta databasåtkomster över domängränser. Det bryter isolation, försvårar revisioner och gör rollbacks opålitliga. Motåtgärd: dataåtkomst via definierade gränssnitt, klart dataansvar och – där det behövs – kontrollerad synkronisering (t.ex. events).

Fel 3: Nätverkslatens och felkaskader planeras för men testas inte

Det som i monoliten var ett anrop i processen blir i distribuerade arkitekturer ett nätverksanrop med timeouts, retries och potentiella kaskader. Utan tydliga timeouts, korrelation (request‑IDs) och realistiska end‑to‑end‑tester blir felanalysen avsevärt svårare. Motåtgärd: tydliga SLOs (mätbara service‑mål), definierade timeouts, trace‑korrelation och belastningstester längs kompletta processflöden.

Fel 4: Snitt efter organisationsschema istället för efter domänlogik

Om tjänster främst speglar teamgränser, men funktionellt löper tvärs igenom processer, kvarstår kopplingen – bara på en annan nivå. Motåtgärd: domänspecifik avgränsning, även om det initialt skapar friktion. Om det organisatoriskt inte är möjligt är en modulär monolit ofta ett bättre mellanliggande steg.

Avbrotts- och eskaleringspunkter: När stabilisering blir det bättre beslutet

Ett moderniseringsprojekt behöver stoppregler, annars förbrukar det budget och uppmärksamhet. Dessa signaler är starka skäl att medvetet byta fokus:

• Operativ överbelastning: larmflöde, ökande MTTR, on-call kan inte längre bemannas.
• Ingen mätbar förbättring: Lead Time, Change Failure Rate eller stabilitet förbättras inte tydligt.
• Gränssnittskomplexiteten exploderar: versionshantering oklar, Breaking Changes blir vanligare, felsökning blir ett gissningsspel.
• Datakonflikter: inkonsekvenser, dubbla sanningar, svårförklarliga avvikelser i rapporter.
• Ägarskap förblir oklart: beslut dröjer, ingen tar ansvar för drift och vidareutveckling.

Eskalering betyder då inte „tillbaka till det gamla“, utan: prioritera stabilisering. Typiska åtgärder är: köra regression för kärnprocesser, förbättra Observability, konsolidera dataåtkomst, skärpa modulgränser i monoliten – och först därefter åter pröva om en extraktion verkligen ger nytta.

Vad „stabilisera“ konkret innebär – och varför det ofta ger effekt snabbare

Stabilisering är ingen kosmetisk uppröjning. I drift visar den sig som färre överraskningar och planbara releaser. Konkreta hävstänger som teamen känner omedelbart:

• Release-mekanik: reproducerbar build, konsekventa miljöer, inövad rollback-väg.
• Transparens: loggningsstandarder, felklassificering, korrelation av requests över processflöden.
• Testfokus: end-to-end-regression för kärnflöden (inte bara isolerade tester).
• Modulgränser i monoliten: definierade interna API:er, disciplinerad dataåtkomst, tydliga ansvarsområden.
• Datahygien: entydiga stamdatakällor, dokumenterade bieffekter av jobb, minskad specialfalllogik.

Resultatet blir ofta en robust modulär monolit: Mjukvaran förblir hanterbar som en enhet, men internt tydligare uppdelad. På så vis får teamen tillbaka mycket av det man förväntar sig av uppdelning – utan att omedelbart multiplicera den operationella komplexiteten.

Sista kontrollfrågan innan ni beslutar

Om ni skulle dela upp systemet i dag: Kan ni i morgon bitti vid en incident snabbt säga, vilken del som är ansvarig, vem som reagerar, vilken mätning som belägger felet och hur ni rullar tillbaka? Om den frågan kvarstår obehagligt öppen är beslutet oftast inte „mer arkitektur“, utan „mer driftsäkerhet“.

Om ni vill utvärdera er utgångssituation strukturerat och upprätta en moderniseringsväg med tydliga Stop/Go-punkter, kan ni kontakta oss för ett enstaka och målinriktat uppdrag:

För detta ämne är även legacy-modernisering och Strangler Fig-mönstret viktiga. Artikeln sätter dessa aspekter i ett begripligt sammanhang och visar vad som spelar roll i det dagliga arbetet.

Diskutera projekt eller moderniseringsinitiativ med Net-Base.