Monoliet opsplitsen of stabiliseren? Beslissingscriteria voor modulaire modernisering

Maandagochtend, 9:10 uur: een Fachbereich meldt een „kleine aanpassing“ in het bestelproces. De IT kijkt kort naar de tickettekst; lijkt uitvoerbaar. Twee uur later is de sfeer anders. De build duurt langer dan gepland, een achtergrondjob hangt aan hetzelfde release-pakket, en bij het kijken in de database wordt duidelijk: deze wijziging raakt meer tabellen en triggers dan gedacht. Op dat moment rijst de vraag die veel teams regelmatig bezighoudt: Monoliet opsplitsen of stabiliseren?

Wie daar reflexmatig met „Microservices!“ op antwoordt, mist vaak de kern: het gaat niet om een architectuurlabel, maar om leveringscapaciteit en operationele betrouwbaarheid. Deze praktijkgids leidt door een pragmatische beoordeling, toont beslissingscriteria voor modulaire modernisering en beschrijft uitvoerbare stappen. Bovendien komen typische foutbeelden aan bod en worden duidelijke stop- en escalatiepunten genoemd – zodat modernisering niet verandert in een langdurig project zonder meetbaar effect.

Monoliet opsplitsen of stabiliseren: eerst het symptoom, dan de architectuur

„De monoliet is schuldig“ klinkt eenduidig, maar is zelden precies genoeg voor een beslissing. Een monoliet (een applicatie als gezamenlijk Deployment-Artefakt) kan zeer betrouwbaar draaien – of voortdurend wrijving geven. Evenzo: Microservices (veel kleine, afzonderlijk deploybare diensten) kunnen doorlooptijden verkorten, maar brengen onvermijdelijk meer operationele taken met zich mee.

Martin Fowler plaatst deze realiteit nuchter: Microservices zijn vooral een andere Operations-Footprint – dus een andere operatieinspanning met meer componenten, meer deployments, meer foutbronnen en meer behoefte aan automatisering.^[Bron] De grens van deze uitspraak: het vervangt geen analyse van uw systeem. De praktische consequentie is toch duidelijk: wie als doel „Microservices“ uitroept voordat het knelpunt helder beschreven is, moderniseert snel op de verkeerde plek.

Beslissingscriteria: Wanneer opsplitsen echt helpt – en wanneer niet

De druk tot moderniseren is reëel: security-eisen nemen toe, er komen meer interfaces, teams veranderen, en de businesssoftware moet tegelijkertijd blijven draaien en zich verder ontwikkelen. Opsplitsen kan een zinvolle stap zijn – maar alleen als het het knelpunt adresseert en niet alleen het architectuurdiagram verfraait.

Criterium 1: Operationele volwassenheid – kan uw operatie de Footprint dragen?

Met elke extra deploybare eenheid neemt de behoefte aan nette levering en bewaking toe: CI/CD (geautomatiseerde build-/test-/deploy-keten), Observability (metriek, logs en traces voor diagnose), incidentprocessen, Runbooks en duidelijke verantwoordelijkheden. AWS formuleert dit als een afweging: fijnere segmentatie kan voordelen geven voor betrouwbaarheid en schaalbaarheid, maar verhoogt met het aantal componenten de operationele complexiteit.^[Bron] De beperking: dit is een richtlijn, geen succesgarantie. De consequentie: als u vandaag al moeite heeft een deployment stabiel uit te voeren, zal een service-landschap dit probleem vermenigvuldigen.

Concrete controlepunten die niet gebagatelliseerd mogen worden:

• Release-mogelijkheid: Rollback/Backout is gedefinieerd, onderhoudsvensters en communicatie zijn ingericht.
• Monitoring & alarmering: Alarmen zijn actiegericht (niet „alles rood“), foutbronnen zijn af te bakenen.
• Incidentafhandeling: Er bestaat een ritme voor postmortems en maatregelen, niet alleen ad-hoc brandblussing.
• Eigenaarschap: Wie beslist over interfaces, wie prioriteert, wie draagt beheer en kwaliteit?

Criterium 2: Wijzigingsontkoppeling – belemmeren eisen elkaar?

Opsplitsen loont wanneer onafhankelijke wijzigingen in de monoliet regelmatig van elkaar afhankelijk worden, hoewel ze functioneel gescheiden zijn. Typisch patroon: een portalgebied heeft vaak aanpassingen nodig, terwijl een afrekeningsgebied zelden gewijzigd mag worden en grote zorgvuldigheid vereist. Als beide altijd in dezelfde release-trein zitten, remmen ze elkaar af.

Omgekeerd is opsplitsen vaak een eigen doelpunt wanneer vrijwel elke wijziging dwars door vele gebieden loopt (autorisaties, prijslogica, reporting, gegevensopschoning). Dan creëer je interfaceverkeer in plaats van ontkoppeling – en neemt de coördinatiebehoefte toe in plaats van af.

Criterium 3: Gegevenskoppeling – zit de complexiteit in de database?

Veel systemen zijn minder via code gekoppeld dan via gegevens: gemeenschappelijke tabellen, triggers, transactionele processen en batch-jobs. Sam Newman stelt in zijn decompositiemodellen vast dat de eigenlijke uitdaging vaak de data- en integratiestrategie is – en dat Big-Bang-projecten daarbij bijzonder risicovol worden.^[Bron]

Praktische consequentie voor de operatie: als meerdere componenten zonder regels naar dezelfde tabellen schrijven, ontstaan bijwerkingen die u moeilijk netjes kunt terugdraaien. Modulaire modernisering vereist daarom vroegtijdige beslissingen over gegevenssoevereiniteit, consistentie en ontkoppeling van rapportage.

Criterium 4: Stabiliteit en inhoudelijke waarde – wat moet behouden blijven?

In gegroeide digitale bedrijfsoplossingen zit vaak veel correct afgebeelde domeinlogica: randgevallen, bedrijfseconomische regels, uitzonderingen in processen, historisch gegroeide gegevensopschoning. Dat is geen „legacy-rommel“, maar vaak de reden dat de business überhaupt werkt. Modernisering is rendabel wanneer zij deze waarde niet lichtvaardig verwerpt – en tegelijkertijd de onderdelen identificeert die exploitatie en doorontwikkeling onevenredig duur maken.

Een keuze maken: Drie doelbeelden die in organisaties werken

Tussen „alles blijft“ en „alles wordt microservices“ liggen praktische doelbeelden die modernisering planbaar maken. AWS Prescriptive Guidance raadt nadrukkelijk aan om vóór decompositie te beoordelen, welke onderdelen überhaupt gedekomposeerd zouden moeten worden, en incrementele benaderingen te verkiezen.^[Bron]

Praktische handleiding: van beoordeling naar uitvoering (met Stop/Go-punten)

1) Systeemgrenzen zichtbaar maken – klein genoeg om gebruikt te worden

U heeft geen 80 pagina’s systeemdocumentatie nodig om te kunnen beslissen. Wat helpt, is een compacte kaart: hoofdprocessen, kritische interfaces (bijv. portalen, EDI, dateiexporten, REST-APIs), Batch-Jobs, evenals plekken met hoge storingsgevoeligheid. Doel: besluiten kunnen nemen, niet kennis archiveren.

Bewezen heeft zich een blik die operatie en vakafdeling samenbrengt: „Welke procesketen is bedrijfskritisch, en waarvan hangt die technisch af?“ Dan wordt snel zichtbaar waar een extractie riskant zou zijn – en waar ze daadwerkelijk verlichting kan brengen.

2) Baseline-Metriken definieren – sonst bleibt es eine Glaubensfrage

Modernisering zonder baseline is als een performance-optimalisatie zonder meting. Cruciaal zijn kengetallen die zowel delivery als operatie afbeelden: Deployment-Frequenz, Lead Time (van aanvraag tot productie), Change Failure Rate (storingen na Changes), MTTR (Mean Time to Recovery) en terugkerende incidentklassen. De Metriken hoeven niet academisch perfect te zijn – maar ze moeten consistent worden verzameld, zodat een Stop/Go mogelijk is.

3) Kandidaten schneiden – nach Domäne, nicht nach Technikschichten

Een veelvoorkomende misstart is de splitsing naar lagen („UI-Service“, „DB-Service“). Dat creëert nieuwe afhankelijkheden in plaats van ze te verminderen. Domeinscheiding betekent: een module is verantwoordelijk voor een functioneel domein inclusief regels en data. Dat is voor teams meestal concreter dan een louter technische afbakening.

Als u de functionele grenzen niet kunt benoemen, is dat geen reden sneller te splitsen – maar een signaal eerst in de monoliet te stabiliseren en te modulariseren: begrippen verduidelijken, datastromen begrijpen, cross-cutting functies identificeren.

4) Strangler statt Big Bang – kontrolliert umleiten, konsequent abschalten

Als beschikbaarheid telt en u risico’s moet beheersen, is het Strangler-Fig-Pattern een solide weg: functies worden stapsgewijs naast het bestaande systeem vervangen; het verkeer wordt gecontroleerd omgeleid totdat oude paden zijn uitgeschakeld.^[Quelle]

Belangrijk is de discipline achter het patroon: duidelijke routingbeslissingen, compatibiliteit in data en interfaces, monitoring over beide routes – en een echte „Done“ wanneer het oude pad is verwijderd. Anders ontstaat parallelle operatie als blijvende toestand.

5) Data- und Reporting-Strategie früh festzurren

In de praktijk wordt modernisering vaak bepaald door twee vragen: wie „bezit“ welke gegevens – en hoe wordt gerapporteerd? Als rapportage direct op operationele tabellen toegang heeft, blokkeert dat veranderingen. Als meerdere componenten gegevens „gedeeld gebruiken“ zonder regels, ontstaan inconsistenties.

Plan daarom expliciet:

• Data-eigendom: welke module is leidend voor welke entiteit (klant, opdracht, factuur …)?
• Consistentie-eisen: waar is sterke consistentie nodig, waar volstaat Eventual Consistency?
• Ontkoppeling van rapportage: hoe worden rapportages gevoed zonder de operationele modellen star te maken?

6) Security en operatie per module definiëren – niet later „er aanplakken“

Met elke nieuwe component neemt het aanvalsoppervlak toe: service-naar-service-communicatie, Secrets, machtigingen, Audit-Trails. Leg vroeg vast hoe authenticatie (bijv. centraal via SSO) en autorisatie (rol-/rechtgebaseerd per domein) samenwerken. Voor de dagelijkse praktijk geldt bovendien: logs moeten diagnostisch nuttig zijn, maar mogen geen privacy- en bewaarplichten schenden. Deze punten horen in Runbooks en operationele documentatie – niet alleen in architectuurslides.

8-Schritte-Checkliste für eine belastbare Go/No-Go-Entscheidung

1. Knelpunt benoemen: Wat precies moet er beter worden (Release-Dauer, stabiliteit, schaalbaarheid, parallelle ontwikkeling)?
2. Baseline meten: Welke kerncijfers geven de huidige situatie weer (Lead Time, Change Failure Rate, MTTR etc.)?
3. Operationele gereedheid beoordelen: CI/CD, monitoring, alarmmeldingen, Runbooks, incidentprocessen, eigenaarschap.
4. Domeinscheiding schetsen: Waar liggen natuurlijke vakinhoudelijke grenzen? Wat zijn domeinoverschrijdende thema’s?
5. Datastrategie uitwerken: Data-eigendom, consistentie, rapportage, migratiepaden.
6. Afhankelijkheden inventariseren: Jobs, interfaces, bestandsexporten, gebruikersgroepen, rechten.
7. Slice plannen: een klein, leverbaar pakket inclusief rollback en monitoringdoelen.
8. Stop/Go-criteria vaststellen: Welke signalen stoppen de opsplitsing of dwingen een stabilisatiestap?

Typische Fehlerbilder – so sehen sie im Betrieb aus

Fout 1: Meer componenten, maar geen eigenaarschap

Als niemand end-to-end verantwoordelijk is (prioritering, kwaliteit, operatie), verandert ontkoppeling in een afstemmingsprobleem. In geval van incidenten leidt dat tot lange overlegrondes, onduidelijke beslissingen en de reflex om weer „alles samen“ te deployen. Tegenmaatregel: per module een duidelijke kring van eigenaren, gedefinieerde overdrachten en een beslissingslog voor interfaces en data-eigendom.

Fout 2: Gedeelde gegevens zonder regels

Dit anti-pattern is bekend: diensten zijn gescheiden, maar schrijven nog steeds naar dezelfde tabellen of gebruiken directe databasetoegang over domeinen heen. Dat doorbreekt isolatie, bemoeilijkt audits en maakt rollbacks onbetrouwbaar. Tegenmaatregel: datatoegang via gedefinieerde interfaces, duidelijke gegevensverantwoordelijkheid en — waar nodig — gecontroleerde synchronisatie (bijv. events).

Fout 3: Netwerklatentie en foutkaskades worden „meegepland“, maar niet getest

Wat in de monoliet een in-process-aanroep was, wordt in gedistribueerde architecturen een netwerkaanroep met timeouts, retries en potentieel kaskades. Zonder strikte timeouts, correlatie (Request-IDs) en realistische end-to-end-tests wordt foutanalyse aanzienlijk moeilijker. Tegenmaatregel: duidelijke SLOs (meetbare service-doelstellingen), gedefinieerde timeouts, trace-correlatie en loadtests langs complete procespaden.

Fout 4: scheiding volgens organigram in plaats van volgens domeinlogica

Als Services primair teamgrenzen afbeelden, maar functioneel dwars door processen heen lopen, blijft de koppeling bestaan – alleen op een ander niveau. Tegenmaatregel: een domeingerichte scheiding, ook als dat aanvankelijk wrijving oplevert. Als dat organisatorisch niet mogelijk is, is een modulaire monoliet vaak de betere tussenstap.

Stop- en escalatiepunten: wanneer stabiliseren de betere beslissing wordt

Een moderniseringsproject heeft stopregels nodig, anders vreet het budget en aandacht. Deze signalen zijn sterke redenen om bewust over te schakelen:

• Operationele overbelasting: alarmvloed, stijgende MTTR, On-Call niet meer te bemensen.
• Geen meetbare verbetering: Lead Time, Change Failure Rate of stabiliteit verbeteren zich niet merkbaar.
• Complexiteit van interfaces explodeert: versiebeheer onduidelijk, Breaking Changes stapelen zich op, debugging wordt giswerk.
• Gegevensconflicten: inconsistenties, dubbele waarheden, moeilijk te verklaren afwijkingen in rapportages.
• Ownership blijft onduidelijk: beslissingen duren, niemand draagt verantwoordelijkheid voor beheer en verdere ontwikkeling.

Escalatie betekent dan niet „terug naar het oude“, maar: stabilisatie prioriteren. Typische maatregelen zijn: regressietests voor kernprocessen uitvoeren, Observability verbeteren, toegang tot gegevens consolideren, modulegrenzen in de monoliet aanscherpen – en pas daarna opnieuw beoordelen of een extractie werkelijk voordeel oplevert.

Wat „stabiliseren“ concreet betekent – en waarom het vaak sneller werkt

Stabilisatie is geen cosmetische opruimactie. In de operatie uit zich dat in minder verrassingen en planbare releases. Concrete hefbomen die teams direct merken:

• Release-mechaniek: reproduceerbare build, consistente omgevingen, geoefend rollback-pad.
• Transparantie: logging-standaarden, foutclassificatie, correlatie van requests over procesketens.
• Testfocus: end-to-end regressie voor kernflows (niet alleen geïsoleerde tests).
• Modulegrenzen in de monoliet: gedefinieerde interne API’s, gedisciplineerde datatoegang, duidelijke verantwoordelijkheden.
• Datahygiëne: eenduidige stamgegevensbronnen, gedocumenteerde neveneffecten van jobs, verminderde uitzonderingslogica.

Het resultaat is vaak een robuuste modulaire monoliet: de software blijft als geheel beheersbaar, maar intern duidelijker gesneden. Daarmee winnen teams al veel terug van wat men zich van opsplitsing belooft – zonder meteen de operationele complexiteit te vermenigvuldigen.

Laatste controlevraag voordat u beslist

Als u vandaag zou opsplitsen: kunt u morgenochtend bij een incident snel zeggen, welk deel verantwoordelijk is, wie reageert, welke metriek de fout aantoont en hoe u terugrolt? Als deze vraag oncomfortabel open blijft, is de beslissing meestal niet „meer architectuur“, maar „meer operationele betrouwbaarheid“.

Als u uw uitgangssituatie gestructureerd wilt beoordelen en een moderniseringspad met duidelijke stop/go-punten wilt opzetten, kunt u ons daarvoor eenmalig en gericht aanspreken:

Voor dit onderwerp zijn ook legacy-modernisering en het Strangler-Fig-patroon belangrijk. Het artikel plaatst deze aspecten op een heldere manier en toont waar het in de dagelijkse praktijk om gaat.

Een project of moderniseringsproject met Net-Base bespreken.