10.4 Grote en langlevende systemen in stand houden

Overzicht en motivatie

Het meeste schrijven over software-engineering gaat over nieuwe dingen bouwen. Maar de meeste belangrijke software ter wereld is oud, groot en draait nog: belastingsystemen, uitkeringsbetalingen, luchtverkeersleiding, kernbankieren, industriële besturing en de infrastructuur van het dagelijks leven. Deze systemen draaien routinematig tien, twintig of dertig jaar. Dat is veel langer dan de diensttijd van wie dan ook die ze bouwde, en vaak langer dan de bedrijven en talen die ze voortbrachten. Zulke systemen in stand houden betekent ze betrouwbaar, veilig, begrepen en veranderbaar houden, over decennia en generaties personeel. Het is een van de moeilijkste en minst glamoureuze disciplines in het vak, en een waar grote ondernemingen en overheden de zwaarste last dragen.

Waarom telt dit meer voor grote organisaties? Continuïteit van verplichting. Een startup kan haar software herschrijven of verlaten. Een nationale overheid kan niet stoppen met pensioenen betalen terwijl ze refactort. Ondernemingen en agentschappen bezitten systemen waarvan falen gevolgen heeft die in levensonderhoud, veiligheid of publiek vertrouwen worden gemeten. En ze bezitten er veel tegelijk, bemand door mensen die over decennia komen en gaan. De centrale bedreigingen zijn niet exotisch. Het zijn de langzame erosie van de mensen die het systeem begrijpen (bus factor, hoe weinig mensen moeten vertrekken voordat kennis van een systeem verloren gaat), de opstapeling van ongedocumenteerde kennis in een paar hoofden, het verval van de technologiestack richting einde van de levensduur en de verlamming die intreedt wanneer een systeem te kritiek wordt om aan te raken en te slecht begrepen om veilig te veranderen.

Dit hoofdstuk gaat over rentmeesterschap: het bewuste, onglamoureuze werk om een systeem zijn auteurs soepel te laten overleven. Het behandelt continuïteit van eigenaarschap en beperking van het bus-factorrisico, geplande uitfasering en afbouw, kennisoverdracht, de bijzondere uitdagingen van systemen die decennia meegaan en de voortdurende balanceeract tussen innoveren en de stabiliteit behouden waarvan burgers en klanten afhangen.

Kernprincipes

Elk kritiek systeem heeft altijd een eigenaar nodig. Eigenaarschap is een doorlopende toewijzing, geen herinnering aan wie het schreef.
Kennis die in één hoofd leeft is een risico, geen bezit. Institutionaliseer begrip voordat de persoon vertrekt.
Saai is een functie. Voor langlevende kritieke systemen gaan stabiliteit en voorspelbaarheid vaak voor nieuwigheid.
Plan het einde aan het begin. Elk systeem wordt ooit uitgefaseerd of vervangen. Ontwerp en documenteer voor die dag.
Verandering is hoe je veilig blijft. Een systeem dat te eng is om aan te raken faalt al. Het vermogen te veranderen is een overlevingseigenschap.
Continuïteit overleeft individuen. Ontwerp teams, documentatie en processen zo dat geen enkel vertrek een crisis is.
Vertrouwen is het echte product. Voor burger- en klantgerichte systemen zijn betrouwbaarheid en eerlijkheid die in de tijd worden volgehouden de missie.

Aanbevelingen

Stel rentmeesterschap en continuïteit van eigenaarschap vast

Wijs expliciet, actueel eigenaarschap toe voor elk systeem dat ertoe doet. Bezit op teamniveau, niet op individueel niveau, zodat eigenaarschap vertrek overleeft. Onderhoud een servicecatalogus die voor elk systeem vastlegt wie het bezit, wat het doet, waarvan het afhangt en hoe kritiek het is. Beoordeel eigenaarschap regelmatig en laat nooit een systeem wees worden. Een kritiek systeem zonder eigenaar is een noodgeval dat staat te gebeuren. Wanneer teams reorganiseren, draag eigenaarschap bewust over, met een overdracht, niet bij aanname. Zorg voor de meest kritieke langlevende systemen dat eigenaarschap niet alleen beheer omvat maar het vermogen het systeem te begrijpen en te veranderen, zodat rentmeesterschap niet vervalt tot louter oppassen.

Beperk het bus-factor- en sleutelpersoonrisico

Meet en verminder actief de concentratie van kennis. Als slechts één persoon een systeem kan deployen, debuggen of veranderen, is dat een single point of failure zo echt als elke hardware. Verminder het via pairing en rotatie, verplichte codereview, gedeelde bereikbaarheid en een bewuste regel dat geen kritieke taak precies één bekwaam persoon heeft. Leid kruislings op zodat minstens twee (bij voorkeur drie) mensen elke essentiële functie kunnen uitvoeren. Behandel het vertrek van een sleutelpersoon als voorzienbare gebeurtenis waarop je voortdurend voorbereidt, niet als schok die je opvangt. Documentatie helpt. Maar werkkennis die via echte praktijk over een team is verspreid is veel duurzamer dan documenten die niemand heeft geoefend.

Institutionaliseer kennisoverdracht

Leg de kennis vast die anders met mensen zou vertrekken. Richt je eerst op de kennis die moeilijk te reconstrueren is: waarom beslissingen werden genomen, welke alternatieven werden verworpen en waarom, waar de scherpe randen en de kritieke hacks zitten waarop de rest van het systeem stilletjes leunt en hoe het systeem zich onder stress gedraagt. Gebruik architectuurbeslissingsrecords om de redenering achter keuzes te bewaren, niet alleen de keuzes. Houd runbooks en operationele documentatie dicht bij het systeem en oefen ze regelmatig zodat ze waar blijven. Bouw onboardingpaden die nieuwe rentmeesters tot echte bekwaamheid brengen. Behandel vertrek als kennisoverdrachtsgebeurtenissen met echte overdrachtstijd. Onthoud dat impliciete kennis, het gevoel voor een systeem, vooral wordt overgedragen door samen te werken met iemand die het heeft, dus laat vertrekkende en aankomende rentmeesters overlappen waar je kunt.

Beheer uitfasering, afbouw en einde van de levensduur

Plan einden bewust. Wanneer je besluit een systeem uit te faseren of te vervangen, behandel de afbouw als project op zich: identificeer elke afnemer en afhankelijkheid, bied een migratiepad en een realistische tijdlijn, communiceer helder en herhaaldelijk en ondersteun afnemers door de overgang. Vermijd de valkuil het oude en nieuwe systeem eeuwig parallel te draaien omdat niemand het harde werk doet het oude uit te zetten. Wijs expliciete verantwoording toe voor het voltooien van de ontmanteling. Bewaar data, records en het vermogen vragen over het uitgefaseerde systeem te beantwoorden lang nadat het stopt met draaien, vooral waar wettelijke bewaarregels gelden. Een slecht uitgevoerde afbouw laat zombiesystemen achter die niet worden onderhouden maar nog steeds worden gebruikt: het slechtste van alle werelden.

Houd systemen decennia in stand

Plan voor systemen die twintig of dertig jaar moeten draaien alles te overleven: het oorspronkelijke team, de leveranciers, het taalecosysteem en de hardware. Geef de voorkeur aan open standaarden en gedocumenteerde interfaces boven eigen zwarte dozen, zodat toekomstige beheerders een kans hebben. Modulariseer, zodat onderdelen één voor één kunnen worden vervangen in plaats van via een alles-of-niets-herschrijving die te riskant is om ooit te proberen. Houd het systeem continu onderhouden. Een systeem dat in kleine stappen actueel wordt gehouden blijft houdbaar. Een systeem dat wordt bevroren “omdat het werkt” wordt stilletjes ononderhoudbaar naarmate zijn stack uit ondersteuning raakt. Houd ook de vaardigheden om het te beheren: train voor werkelijk oude technologie bewust opvolgers in plaats van te hopen dat de laatste expert nooit met pensioen gaat.

Balanceer innovatie met stabiliteit en vertrouwen

Onderscheid de delen van je landschap waar nieuwigheid waarde creëert van de delen waar stabiliteit de waarde is. Kernsystemen waarvan burgers en klanten dagelijks afhangen belonen meestal betrouwbaarheid, achterwaartse compatibiliteit en voorzichtige verandering boven opwindende herschrijvingen. Investeer innovatie aan de randen (nieuwe kanalen, nieuwe functies, nieuwe interfaces) terwijl je de duurzame kern stabiel en goed begrepen houdt. Verander de kern, ja, maar in kleine, omkeerbare, goed geteste stappen in plaats van heroïsche sprongen. Het doel is een systeem dat zowel betrouwbaar is als kan evolueren: nooit zo bevroren dat het verrot, nooit zo geroerd dat het onbetrouwbaar wordt.

Afwegingen: voor- en nadelen

Aanpak	Voordelen	Nadelen
Het oude systeem houden en onderhouden	Behoudt institutionele kennis. Weinig verstoring. Bewezen betrouwbaarheid	Verouderende stack. Schaarse vaardigheden. Oplopend risico als niet onderhouden
Big-bangherschrijving	Verse stack. Werpt opgehoopte rommel af	Zeer hoog faalpercentage. Verliest zuurverdiende kennis van randgevallen
Incrementele modernisering	Continue risicovermindering. Blijft draaien	Langzaam. Vraagt aanhoudende financiering en discipline
Documentatiezware overdracht	Expliciet, doorzoekbaar overzicht	Veroudert als niet onderhouden. Mist impliciete kennis
Mensgebaseerde overdracht (pairing/rotatie)	Duurzame werkkennis. Veerkrachtige teams	Kost huidige productiviteit. Vraagt bewuste planning
Kritieke kern bevriezen	Maximale stabiliteit op korte termijn	Stack veroudert tot onderhoudbaarheid verloren gaat. Wordt te eng om aan te raken

De bepalende afweging is stabiliteit tegenover evolutie, en de naïeve oplossingen falen beide. Bevries een kritiek systeem om het te beschermen en je garandeert dat het uiteindelijk ononderhoudbaar en onveilig wordt. Herschrijf het in zijn geheel om te moderniseren en je nodigt het hoge faalpercentage uit waarvoor big-bangvervangingen berucht zijn, en je gooit decennia gecodeerde kennis van randgevallen weg waarvan niemand zich herinnert dat die er was. Het duurzame pad is continue, incrementele verandering: houd het systeem levend en in beweging in kleine stappen, zodat het nooit uit ondersteuning veroudert en nooit een beangstigende sprong nodig heeft. Kennisoverdracht is een vergelijkbare afweging, tussen het gemak van documenten en de duurzaamheid van geleefde ervaring. Het antwoord is beide: geleefde, door het team gehouden kennis als ruggengraat, en documenten als naslag.

Vragen om met je team te bespreken

Welke van je kritieke systemen hebben nu geen actueel, benoemd teameigenaarschap? Eigenaarschap is een doorlopende toewijzing, geen herinnering aan wie de code schreef, en een kritiek systeem zonder eigenaar is een noodgeval dat staat te gebeuren, pas opgemerkt wanneer het breekt. Loop je servicecatalogus door (of bouw er een) en controleer dat elk systeem vastlegt wie het bezit, waarvan het afhangt en hoe kritiek het is. Neem bewijs mee: kies drie belangrijke systemen en probeer het verantwoordelijke team te noemen en de laatste keer dat eigenaarschap werd beoordeeld. Waar een systeem wees is, of waar een reorganisatie het stilletjes liet vallen, wijs eigenaarschap bewust toe met een echte overdracht in plaats van bij aanname. Zorg dat eigenaarschap het vermogen omvat het systeem te begrijpen en te veranderen, zodat rentmeesterschap niet vervalt tot louter oppassen.
Wanneer je een systeem vervangt, wie is verantwoordelijk voor het werkelijk uitzetten van het oude? De eeuwige parallelle run is een gangbare en kostbare fout: oud en nieuw systeem draaien onbepaald naast elkaar omdat niemand het uitzetten bezit, waardoor je twee systemen onderhoudt en de veiligheid van geen van beide krijgt. Behandel elke afbouw als beheerd project met benoemde verantwoording voor het voltooien van de ontmanteling, een in kaart gebrachte lijst afnemers, een migratiepad en een realistische tijdlijn. Neem bewijs mee: hoeveel “tijdelijke” parallelle runs of half uitgefaseerde systemen trekken vandaag nog onderhoud in je landschap? Bewaar data en records om aan wettelijke bewaarregels te voldoen lang nadat het systeem stopt met draaien, maar laat bewaring geen excuus worden om nooit af te maken. Een slecht uitgevoerde afbouw laat zombiesystemen achter die niet worden onderhouden maar nog steeds worden gebruikt, het slechtste van alle werelden.
Welke vaardigheden voor je langlevende systemen zal de arbeidsmarkt niet meer leveren, en wat is je opvolgingsplan? Systemen die twintig of dertig jaar draaien overleven hun taalecosystemen, hun leveranciers en de loopbanen van de mensen die de oude stack begrijpen, en de markt levert niet betrouwbaar vervangers. Verminder de bus factor bewust zodat geen kritieke functie precies één bekwaam persoon heeft, en leid kruislings op zodat minstens twee, bij voorkeur drie, mensen elke essentiële taak kunnen uitvoeren. Neem bewijs mee: tel voor elk verouderend kritiek systeem hoeveel mensen het veilig kunnen veranderen en hoe dicht de meest deskundigen bij pensioen zijn. Het antwoord moet bewuste training van opvolgers sturen en echte overlap tussen vertrekkende en aankomende rentmeesters, want impliciete kennis (het gevoel voor een systeem) wordt vooral overgedragen door samen te werken met iemand die het heeft. Documenten zijn de naslag. Geleefde, door het team gehouden kennis is de ruggengraat.
Wanneer veranderde je voor het laatst je meest kritieke langlevende systeem, en durft iemand dat nog? Een systeem dat al een jaar niemand heeft aangeraakt is niet stabiel, het drijft naar de valstrik “te eng om aan te raken”, waar elke verandering gevreesd wordt en de stack dus stilletjes uit ondersteuning veroudert. Voor een grote organisatie doet dit ertoe omdat verlamming samengesteld oploopt: hoe langer de bevriezing, hoe meer kennis vervaagt en hoe riskanter de uiteindelijke onvermijdelijke verandering wordt. Neem bewijs mee: voor elk kritiek systeem de datum van de laatste bewuste verandering, de omvang van de kleinste verandering die vandaag iemand zou proberen en of een routine-afhankelijkheids- of beveiligingspatch deze week zonder heldendaden kan worden uitgeleverd. De concurrerende overweging is echt, want verandering introduceert ook risico, dus het doel is geen onrust maar een stabiel ritme van kleine, omkeerbare, goed geteste stappen. Behandel in landschappen van onderneming en overheid, waar een bevroren kern een decennium onder een burgerdienst kan zitten, “we veranderen het nooit” als rode vlag in plaats van geruststelling, en financier het continue onderhoud dat de optie tot veranderen levend houdt.
Welk deel van je landschap draait op een technologie die op of nabij het einde van de levensduur is, en wie volgt die klok? Verouderende runtimes, niet-ondersteunde databases en frameworks zonder onderhoud zijn de langzame faalwijze die op de dag dat een beveiligingspatch niet meer arriveert in een plotselinge crisis verandert. Voor een groot team is het gevaar dat niemand de horizon bezit: individuele teams patchen wat breekt, maar niemand onderhoudt een portfolioblik op welke stacks wanneer leveranciersondersteuning verliezen. Neem bewijs mee: een inventaris van de kerntechnologieën van elk kritiek systeem, hun gepubliceerde datums van einde van levensduur of ondersteuning en het huidige gat tussen wat je draait en wat nog wordt ondersteund. De spanning is tussen de kosten van continu upgraden en het risico van uitstel, en uitstel wint meestal tot het catastrofaal verliest. In omgevingen van onderneming en overheid, waar aanbestedings- en accreditatiecycli een jaar of meer kunnen duren, valt een einddatum die ver weg lijkt vaak al binnen je doorlooptijd, dus het opvolgings- en upgradewerk moet ruim beginnen voordat de klok afloopt.
Waar in je landschap is stabiliteit de waarde en nieuwigheid een last, en hoe houd je die grens eerlijk? Niet elk systeem beloont dezelfde behandeling: kernsystemen waarvan burgers en klanten dagelijks afhangen belonen meestal betrouwbaarheid en voorzichtige verandering, terwijl de randen experimenteren belonen, en de twee verwarren verspilt geld of nodigt uitval uit. Voor een grote organisatie is het risico dat ambitie en loopbaanprikkels opwindende herschrijvingen duwen in precies de duurzame kern die saai zou moeten blijven. Neem bewijs mee: een kaart van je landschap die markeert waar betrouwbaarheid de missie is en waar nieuwigheid waarde creëert, plus recente wijzigingen die die grens in beide richtingen overschreden en wat ze kostten. De concurrerende overweging is dat zelfs een stabiele kern moet blijven evolueren, dus “stabiel” mag geen excuus voor bevriezen worden. Koppel in contexten van onderneming en overheid deze grens aan expliciete kritiekheidslagen en een benoemde autoriteit die een riskante herschrijving van een systeem kan afwijzen waarvan het publiek zich falen niet kan veroorloven, zodat het oordeel niet afdrijft met wie dit kwartaal het hardst roept.

Sectorperspectief

Startup. Met een handvol engineers en weinig runway zit je instandhoudingsrisico geconcentreerd in een of twee mensen die de systemen schreven die je je niet kunt veroorloven te verliezen, zoals facturering of authenticatie. Besteed bijna niets aan proces, maar doe nu de goedkope, waardevolle dingen: koppel een tweede persoon door elk kritiek systeem, schrijf een architectuurbeslissingsrecord van één pagina voor de verrassende onderdelen en houd een runbook dat je werkelijk gebruikt. Weersta de neiging iets te herschrijven alleen omdat het oud is, want op jouw omvang kan een mislukte herschrijving van een kernsysteem het bedrijf beëindigen.

Kleinbedrijf. Je hebt geen speciaal onderhoudsteam en een krap budget, dus geef de voorkeur aan kopen en hosten boven iets bouwen dat je zelf zou moeten onderhouden. Geef de voorkeur aan leveranciers en open standaarden waarmee je kunt vertrekken, en houd een eenvoudig overzicht bij van welk extern systeem welke kritieke functie draait en wie je belt wanneer het breekt. Waar je eigen code bezit, zorg dat minstens twee mensen (of een vertrouwde aannemer plus één medewerker) die begrijpen, zodat één vertrek of een verlopen ondersteuningscontract je niet laat stranden.

Grote onderneming. Je uitdaging is portfolioschaal: veel langlevende systemen, veel teams en personeel dat over decennia roteert. Standaardiseer eigenaarschap op teamniveau in een servicecatalogus, meet de bus factor over het landschap en financier continue incrementele modernisering in plaats van op big-bangherschrijvingen te wedden. Bestuur horizonten van einde van levensduur centraal zodat geen kritieke stack stilletjes uit ondersteuning veroudert, en voer elke afbouw uit als geauditeerd project met benoemde verantwoording voor het voltooien van de ontmanteling.

Overheid. Continuïteit van verplichting is absoluut: je kunt niet stoppen met uitkeringen betalen of luchtverkeersleiding draaien terwijl je refactort, en falen zijn publiek en ingrijpend. Aanbestedingsregels duwen je naar open standaarden, dataoverdraagbaarheid en gedocumenteerde interfaces zodat toekomstige beheerders en toekomstige leveranciers een kans hebben. Financier bewuste opvolgingstraining voor de oudere technologieën die de arbeidsmarkt niet meer levert, bewaar records van uitgefaseerde systemen om aan wettelijke bewaring te voldoen en behandel aanhoudende betrouwbaarheid van burgerdiensten als de verantwoorde missie in plaats van overhead.

Voorbeelden

Startup. Een startup van vijf personen heeft al een systeem dat ze zich niet kan veroorloven te verliezen: de factureringsservice die een oprichter in de eerste maand schreef en die nu elke klantbetaling draait. Alleen die oprichter begrijpt het, dus het team behandelt de bus factor als echt risico in plaats van compliment. Ze koppelen een tweede engineer door een volledige factureringscyclus, schrijven een kort architectuurbeslissingsrecord dat uitlegt waarom de vreemde herhalingslogica bestaat en houden een runbook naast de code dat ze tijdens een incident werkelijk oefenen. Ze weerstaan het herschrijven alleen omdat het oud en onglamoureus is, en verbeteren het in plaats daarvan in kleine omkeerbare stappen, zodat de service die het bedrijf in leven houdt door meer dan één hoofd wordt begrepen.

Grote onderneming. Een grote verzekeraar draait een polisadministratiesysteem dat decennia geleden werd geschreven en nog centraal staat in haar bedrijf. In plaats van een riskante herschrijving in zijn geheel te proberen modulariseerde ze het systeem achter goed gedefinieerde interfaces en vervangt nu één component tegelijk, elke wijziging klein en omkeerbaar. Elke kritieke functie heeft minstens drie mensen die haar kunnen uitvoeren. Bereikbaarheid wordt gedeeld. Architectuurbeslissingsrecords leggen vast waarom het systeem werkt zoals het werkt. Een gecureerde interne cursus brengt nieuwe engineers tot bekwaamheid op de legacy-stack, en vertrekkende experts overlappen met opvolgers zodat impliciete kennis door doen wordt overgedragen.

Overheid. Een nationaal agentschap voor sociale zekerheid beheert uitkeringsbetalingssystemen die al meer dan dertig jaar draaien en niet kunnen stoppen. Het legt expliciet teameigenaarschap vast in een servicecatalogus. Het financiert continu onderhoud in plaats van de systemen te bevriezen. Het traint opvolgers bewust in de oudere technologieën, omdat de arbeidsmarkt ze niet zal leveren. Wanneer het een verouderd subsysteem uitfaseert, voert het de afbouw uit als beheerd project: elke afnemer in kaart brengen, migratieondersteuning bieden, records bewaren om aan wettelijke bewaring te voldoen en verantwoording toewijzen voor het werkelijk voltooien van de ontmanteling, zodat geen zombiesysteem blijft hangen.

Zakelijke onderbouwing: motivatie, ROI en TCO

Het rendement van langlevende systemen in stand houden komt uit het vermijden van de twee catastrofale faalwijzen die hun total cost of ownership domineren. De eerste is de plotselinge crisis: een sleutelpersoon vertrekt, een niet-ondersteunde component wordt gehackt of een wees geworden systeem faalt zonder dat iemand het begrijpt. De tweede is het mislukte megaproject: een overhaaste volledige herschrijving die uitloopt, tekortschiet of instort. Beide zijn enorm duur, en beide zijn grotendeels te voorkomen met gestaag rentmeesterschap. De kosten van één vermeden herschrijvingsfalen, of één vermeden langdurige uitval van een kritieke burgerdienst, overstijgen meestal jaren aanhoudende onderhoudsinvestering.

De adoptiekosten zijn doorlopend en onglamoureus: onderhoud financieren dat geen nieuwe functies oplevert, betalen voor kruisopleiding en documentatietijd die de korte-termijnoutput verlaagt en investeren in incrementele modernisering die nooit de krantenkoppen haalt. De kosten van niet adopteren zijn uitgesteld en groter: oplopend risico naarmate de stack veroudert, opzwellende sleutelpersoonblootstelling en uiteindelijk een gedwongen, risicovolle, dure vervanging onder noodomstandigheden. Wanneer je de zaak voor leiderschap maakt, herformuleer onderhoud van “kostenpost” naar “risicobeheer voor systemen die de organisatie zich niet kan veroorloven te verliezen.” Presenteer total cost of ownership over het volledige meerdecennialange leven (inclusief instandhouding en uiteindelijke ontmanteling) in plaats van alleen de bouw. En benadruk dit: voor burger- en klantgerichte systemen is aanhoudende betrouwbaarheid geen overhead. Het is het vertrouwen dat het eigenlijke product is.

Antipatronen en valkuilen

De heldenbeheerder. Eén onvervangbare persoon die het systeem begrijpt. Zijn of haar vertrek is een existentiële gebeurtenis.
Bevriezen en vergeten. Een kritiek systeem “klaar” verklaren, het onderhoud stoppen en toekijken hoe haar stack veroudert tot onderhoudbaarheid verloren gaat.
De gedoemde herschrijving. De organisatie verwedden op een volledige vervanging die gecodeerde kennis weggooit en meestal uitloopt of faalt.
Wees geworden systemen. Kritieke software zonder huidige eigenaar, pas opgemerkt wanneer ze breekt.
Documentatietoneel. Volumes documenten die verouderd zijn, niet geoefend en door niemand vertrouwd.
De eeuwige parallelle run. Oud en nieuw systeem onbepaald naast elkaar draaiend omdat niemand verantwoordelijk is voor het uitzetten.
Verlies van impliciete kennis. Experts laten vertrekken zonder overlap, zodat het gevoel voor het systeem verdampt.
Te eng om aan te raken. Een systeem zo slecht begrepen dat elke verandering wordt gevreesd, wat garandeert dat het vervalt.

Volwassenheidsmodel

Niveau 1: Initiëren. Instandhouding is ad hoc en reactief. Systemen hangen af van individuele helden, eigenaarschap wordt herinnerd in plaats van toegewezen en kennis leeft ongedocumenteerd in een paar hoofden. Oude systemen worden bevroren tot ze breken, verouderende stacks drijven ongemerkt naar het einde van de levensduur en uitfasering wordt aangekondigd maar nooit voltooid.

Niveau 2: Ontwikkelen. Basispraktijken verschijnen maar variëren per team. Eigenaarschap is opgeschreven voor de meest voor de hand liggende grote systemen, enige runbooks en documentatie bestaan en een paar kritieke functies hebben een tweede bekwaam persoon. Onderhoud is gefinancierd maar reactief, kruisopleiding gebeurt wanneer iemand eraan denkt en er is geen gedeelde manier om iets hiervan over de organisatie te doen.

Niveau 3: Standaardiseren. Rentmeesterschapspraktijken zijn gedocumenteerd en organisatiebreed afgedwongen. Eigenaarschap op teamniveau is vastgelegd in een servicecatalogus en overleeft reorganisaties. Beperking van de bus factor via rotatie en kruisopleiding is een vaste regel, architectuurbeslissingsrecords en geoefende runbooks worden verwacht, modernisering is per beleid incrementeel en elke afbouw loopt als beheerd project met benoemde verantwoording voor het voltooien van de ontmanteling.

Niveau 4: Beheersen. Instandhouding wordt gemeten en beheerst met data tegen uitgangswaarden. Je volgt de bus factor per kritiek systeem, het aantal mensen dat elk veilig kan veranderen, de leeftijd van elke kerntechnologie tegen haar datum van einde van levensduur, het aandeel van het landschap onder continu tegenover uitgesteld onderhoud en het aantal vastgelopen parallelle runs en half voltooide ontmantelingen. Deze statistieken dragen drempels die actie triggeren: een systeem dat onder de ondergrens van de bus factor zakt of een horizon van einde ondersteuning passeert krijgt gefinancierde herstelmaatregelen, en de gezondheid van rentmeesterschap wordt naast oplevering aan leiderschap gerapporteerd.

Niveau 5: Orkestreren. Rentmeesterschap wordt continu verbeterd en over de organisatie geïntegreerd. Geen enkel kritiek systeem is een menselijk single point of failure, kennisoverdracht inclusief impliciete kennis via overlap is routine en systemen evolueren in kleine omkeerbare stappen zodat geen enkel uit ondersteuning veroudert. Eigenaarschap, volgen van einde van levensduur, opvolging en afbouwplanning zijn geweven in portfolio- en risicoplanning, het landschap wordt herbalanceerd naarmate technologieën en verplichtingen verschuiven en systemen van meerdere decennia worden in stand gehouden terwijl het vertrouwen van de mensen die ervan afhangen behouden blijft.

Ideeën voor discussie

Hoe meet je de bus factor betekenisvol, en welk doel is juist voor verschillende kritiekheidsniveaus?
Wanneer is incrementele modernisering werkelijk onhaalbaar, waardoor een herschrijving het kleinere risico is?
Hoe financier en beloon je onderhoudswerk zodat rentmeesterschap een gerespecteerd loopbaanpad is, geen dood spoor?
Wat is de juiste manier om impliciete kennis te bewaren wanneer de laatste expert met pensioen gaat en geen overlap mogelijk is?
Hoe lang moet je het vermogen behouden vragen over een uitgefaseerd systeem te beantwoorden, en wie betaalt dat?
Waar in je landschap is stabiliteit de waarde en nieuwigheid een last, en hoe houd je dat oordeel in de tijd eerlijk?

Belangrijkste inzichten

De meeste belangrijke software is oud en langlevend. Haar over decennia en generaties personeel in stand houden is een eersterangs discipline.
Elk kritiek systeem heeft actueel eigenaarschap op teamniveau nodig. Wees geworden kritieke systemen zijn latente noodgevallen.
Verminder de bus factor bewust (geen kritieke taak moet precies één bekwaam persoon hebben) en draag impliciete kennis over via overlap, niet alleen documenten.
Houd langlevende systemen continu en incrementeel onderhouden. Ze bevriezen en op volledige herschrijvingen wedden zijn beide faalwijzen.
Plan einden als beheerde projecten met verantwoorde voltooiing, en bewaar data en records om aan verplichtingen te voldoen.
Voor burger- en klantgerichte systemen zijn aanhoudende betrouwbaarheid en eerlijkheid de missie, en is onderhoud risicobeheer voor wat je je niet kunt veroorloven te verliezen.

Referenties en verder lezen

Michael Feathers, Working Effectively with Legacy Code
Titus Winters, Tom Manshreck, and Hyrum Wright, Software Engineering at Google
Frederick P. Brooks Jr., The Mythical Man-Month
Nat Pryce and Steve Freeman, Growing Object-Oriented Software, Guided by Tests
Sam Newman, Monolith to Microservices
Martin Fowler, Refactoring and writings on the Strangler Fig pattern
Betsy Beyer et al., Site Reliability Engineering and The Site Reliability Workbook (Google)
Diomidis Spinellis, Code Reading: The Open Source Perspective
U.S. Government Accountability Office, reports on federal legacy IT modernisation