Software-engineering en platforms in de publieke sector

Waarom dit ertoe doet bij publieke waarde

Vrijwel elke publieke dienst die een burger vandaag raakt – een geboorte registreren, een uitkering aanvragen, een belastingaanslag betalen, een zitting boeken – draait ergens achter het loket of het scherm op software. Die software is zelden een eenmalige aankoop; zij wordt een blijvend onderdeel van de infrastructuur van de staat, vaak ouder dan het bestuur dat haar opdroeg, de leverancier die haar bouwde en de programmeertaal waarin haar ingenieurs waren opgeleid. Een publiek orgaan ervaart software niet zoals een gebouw of een weg, waar de toestand van het bezit zichtbaar is; software verslechtert onzichtbaar, en de rekening voor dat verval komt jaren later als noodgeval.

De spanning die dit onderwerp drijft is structureel. Software is van nature iteratief – eisen worden duidelijker naarmate gebruikers met een werkend systeem omgaan, en de beste engineeringpraktijk is iets kleins bouwen, leren en bijsturen. Cycli van overheidsaanbesteding en verantwoording (zie Onderwerp 3.7 — Overheidsaanbesteding en opdrachtverlening) zijn daarentegen gebouwd voor kapitale werken en defensiecontracten: een vaste specificatie, één grote gunning, mijlpaalbetalingen en een businesscase die jaren voordat de levering begint wordt goedgekeurd. Wanneer een wetgever of auditor een contract met vaste prijs en vaste reikwijdte verwacht en een engineeringteam na de eerste release van koers moet veranderen, toont de mismatch zich als scope creep, budgetoverschrijding of een systeem dat in 2019 juist is gespecificeerd en verouderd is tegen de tijd dat het wordt opgeleverd.

De platforms die de engineeringpraktijk van dit onderwerp moet bouwen – gedeelde identiteitssystemen, betalingsrails, dossiersystemen hergebruikt over departementen – zijn het onderwerp van Onderwerp 5.1 (zie Onderwerp 5.1 — Digitale overheid en digitale transformatie); dit onderwerp gaat over de discipline van het bouwen en kopen van de software die elk zulk platform, of elke afzonderlijke dienst, betrouwbaar, vervangbaar en eigendom maakt van het publieke orgaan dat ervan afhangt en niet van de leverancier die haar toevallig het eerst schreef.

Kernbegrippen

De keuze tussen bouwen en kopen is de keuze tussen het laten maken van maatwerksoftware voor de behoefte van één organisatie en het overnemen van configureerbare standaardsoftware die al is gebouwd voor een markt van vergelijkbare kopers. Kopen is doorgaans goedkoper en minder riskant voor een behoefte die niet werkelijk onderscheidend is – salarisadministratie, e-mail, standaard dossierbeheer – terwijl bouwen alleen gerechtvaardigd is waar de eis zo verschillend is dat geen configureerbaar product past, of waar de capaciteit zelf een strategisch bezit is dat de organisatie moet bezitten en ontwikkelen.

Technische schuld is een metafoor, in 1992 bedacht door de software-engineer Ward Cunningham, voor de opgebouwde kosten van het kiezen voor een opportunistische manier om software nu op te leveren boven een grondigere manier die langer zou hebben geduurd. Technische schuld is, zoals financiële schuld, niet inherent verkeerd om aan te gaan – het punt van Cunningham zelf was dat snel werkende code opleveren en daarna refactoren de juiste keuze kan zijn – maar schuld die nooit wordt afgelost, loopt rente op als tragere oplevering, meer defecten en oplopend risico, en een publiek orgaan dat zijn schuld niet kan zien, kan niet besluiten of het haar moet aflossen of laten oplopen.

Een legacysysteem is een oude technologie, toepassing of platform die in actief gebruik blijft ondanks dat ze verouderd is, vaak omdat vervanging duur is of omdat niemand die overblijft in de organisatie volledig begrijpt wat het doet. Legacysystemen zijn bijzonder hardnekkig bij de overheid: kernsystemen voor belasting, uitkeringen en sociale verzekeringen die decennia geleden zijn geschreven in talen als COBOL – de Common Business-Oriented Language, in 1960 ontworpen voor administratieve computertoepassingen – verwerken nog transacties voor miljoenen burgers, omdat de systemen werken en de institutionele kennis die nodig is om ze veilig af te schaffen vaak zelf eerder met pensioen is gegaan.

Softwaremodernisering is de algemene term voor het omzetten, herschrijven of migreren van een legacysysteem naar een huidige architectuur, taal of platform. Softwaremodernisering loopt uiteen van een volledige herschrijving tot behoudender opties als het herhuisvesten van dezelfde code op moderne infrastructuur, en de keuze ertussen is evenzeer een risicobeheerbesluit als een technisch besluit.

Het wurgfeigpatroon (strangler fig pattern) is een incrementele moderniseringsaanpak, genoemd naar een liaan die zich om een gastheerboom wikkelt en hem geleidelijk vervangt, waarin nieuwe functionaliteit naast een legacysysteem wordt gebouwd en verkeer stukje bij beetje daarheen wordt omgeleid, in plaats van het hele systeem in één omschakeling te vervangen. Het wurgfeigpatroon doet ertoe omdat elk increment kan worden getest, teruggedraaid of gepauzeerd zonder de hele dienst plat te leggen – het tegendeel van een big-bangvervanging, waarin het oude systeem wordt uitgezet en het nieuwe aangezet in één moment, zonder weg terug als er iets mis is.

Leveranciersafhankelijkheid (vendor lock-in) ontstaat wanneer een klant zo afhankelijk wordt van de bedrijfseigen technologie, gegevensformaten of contractvoorwaarden van één leverancier dat overstappen naar een andere leverancier onbetaalbare kosten of risico meebrengt. Leveranciersafhankelijkheid is een bijzonder gevaar in publiekesectorsoftware omdat de koper een terugkerende klant is met beperkt praktisch vermogen weg te lopen van een systeem dat een kritieke dienst draait, wat zijn onderhandelingspositie bij elke volgende verlenging verzwakt.

Vrije en opensourcesoftware is software die wordt verspreid onder een licentie die gebruikers de vrijheid geeft de broncode te gebruiken, bestuderen, wijzigen en herverspreiden. Vrije en opensourcesoftware ligt ten grondslag aan een open-source-by-defaultbeleid, waarin een publiek orgaan standaard de broncode publiceert die het opdraagt, tenzij een specifieke reden – beveiligingsgevoeligheid, rechten van derden – het achterhouden rechtvaardigt; de grondgedachte wordt gewoonlijk samengevat als “public money, public code”: software die eenmaal met publiek geld is betaald, zou niet opnieuw betaald moeten hoeven worden, in een ander rechtsgebied, door een ander publiek orgaan dat hetzelfde probleem oplost.

Een digitaal publiek goed is open software, data of inhoud, vrijgegeven onder een open licentie, ontworpen om een publieke ontwikkelings- of bestuursdoelstelling te helpen halen en niet om commercieel rendement te genereren. Digitale publieke goederen herkaderen de opensourcerelease van één overheid als onderdeel van een bredere, gedeelde infrastructuur waarop andere overheden en maatschappelijke organisaties rechtstreeks kunnen putten, en niet slechts een interne transparantiegebaar.

Agile softwareontwikkeling is een overkoepelende term voor iteratieve benaderingen van het bouwen van software die werkende software, frequente oplevering en reageren op verandering verkiezen boven het volgen van een vooraf overeengekomen vast plan. Agile softwareontwikkeling staat in contrast met het watervalmodel, een opeenvolgende aanpak waarin eisen, ontwerp, bouw en test elk volledig worden afgerond voordat de volgende begint; de aantrekkingskracht van waterval voor publieke organen is altijd geweest dat haar mijlpalen netjes passen op een contract met vaste prijs en een jaarlijkse begrotingscyclus, waarom zoveel aanbestedingsrecht haar nog altijd veronderstelt, zelfs waar de oplevering werkelijk agile is.

Een minimaal levensvatbaar product (minimum viable product) is de kleinste versie van een dienst die aan echte gebruikers kan worden vrijgegeven om te toetsen of ze werkt en te leren wat daarna te bouwen. Het concept van het minimaal levensvatbare product, aangepast in handboeken voor digitale publieke diensten, geeft een iteratief team een verdedigbare manier om een financier of auditor iets echts en werkends te tonen lang voordat de volledige reikwijdte klaar is – mits het verantwoordingsproces een werkelijk minimale release aanvaardt en haar niet onder een andere naam als het afgewerkte product behandelt.

Beste praktijken

1. Kies standaard voor kopen bij niet-onderscheidende behoeften en reserveer bouwen voor wat werkelijk onderscheidend is. Salarisadministratie, e-mail en algemene dossierbehoeften verschillen zelden genoeg van die van elke andere organisatie om maatwerksoftware te rechtvaardigen; bouw alleen waar de eis, schaal of de noodzaak de capaciteit decennialang te bezitten en te ontwikkelen werkelijk anders is dan wat de markt biedt.
2. Maak technische schuld zichtbaar voordat u besluit hoeveel ervan u draagt. Houd voor elk systeem in dienst een register bij van bekende shortcuts, uitgestelde oplossingen en niet-ondersteunde afhankelijkheden, volgens een vaste cyclus getoetst, zodat het dragen van schuld nog een jaar een bewuste afweging is en niet dat niemand keek.
3. Plan nooit één onomkeerbare omschakeling als enige route weg van een kritiek legacysysteem. Geef de voorkeur aan incrementele benaderingen zoals het wurgfeigpatroon waarbij elk stuk kan worden getest, teruggedraaid en geleidelijk uitgerold; een big-bangvervanging van een systeem waarvan miljoenen afhangen concentreert jaren aan risico in één weekend zonder weg terug als er iets faalt.
4. Behandel de broncode waarvoor uw organisatie betaalt als een bezit dat zij bezit en niet een dienst die zij huurt. Onderhandel over broncode-escrow of volledig eigendom op het moment van contracteren, niet nadat een geschil is begonnen, aangezien een leverancier die het enige exemplaar van de code van uw kritieke dienst heeft leveranciersafhankelijkheid door ontwerp is.
5. Publiceer broncode standaard als open en eis een specifieke rechtvaardiging om haar achter te houden. Een open-source-by-defaultbeleid, consequent toegepast, maakt van de maatwerksoftware van elk departement een gedeeld bezit over de overheid in plaats van een eenmalige kost, en laat externe deskundigen beveiligingsgebreken vinden die een intern team alleen zou missen.
6. Schrijf softwarecontracten die iteratieve oplevering juridisch mogelijk maken, niet alleen technisch. Een contract dat alleen betaalt tegen een bij ondertekening overeengekomen vaste specificatie dwingt een team te kiezen tussen eerlijke agile praktijk en contractuele naleving; gebruik in plaats daarvan gefaseerde financieringspoorten gekoppeld aan aangetoonde werkende software in plaats van één mijlpaal aan het eind.
7. Financier modernisering als doorlopend programma, niet als eenmalig kapitaalproject. Een legacysysteem dat eenmaal wordt gemoderniseerd en dan nog twintig jaar blijft liggen, hoopt hetzelfde risico op als waarmee het begon; budgetteer voor voortdurende, incrementele vernieuwing zoals een wegenautoriteit budgetteert voor herasfaltering, niet één grote vervanging per generatie.
8. Kies open standaarden en overdraagbare gegevensformaten, ook bij het kopen van commerciële software. Eisen dat het systeem van een leverancier gegevens opslaat en exporteert in open, gedocumenteerde formaten houdt overstapkosten laag, ook waar de software zelf bedrijfseigen is, en is vaak een haalbaardere waarborg op korte termijn tegen afhankelijkheid dan erop staan dat elk systeem open source is.
9. Bouw een minimaal levensvatbaar product en toon het aan echte gebruikers voordat u zich aan de volledige reikwijdte verbindt. Een werkelijk minimale versie vrijgeven en dan iteratief bijsturen op wat wordt geleerd, vangt verkeerde aannames terwijl ze nog goedkoop te herstellen zijn, en niet nadat een volledig systeem ertegen is gebouwd.
10. Houd voldoende interne engineeringcapaciteit om een verstandige koper te zijn, ook waar de oplevering wordt uitbesteed. Een publiek orgaan dat zijn technische expertise heeft uitgehold, kan het voorstel van een leverancier niet beoordelen, vroege waarschuwingstekenen van een in nood verkerend project niet herkennen of zich niet uit leveranciersafhankelijkheid onderhandelen, wat zijn aanbestedingsregels op papier ook zeggen.
11. Verwijder het risicoprofiel van een legacysysteem vóór de gebruikersinterface. Geef prioriteit aan het vervangen van niet-ondersteunde talen, niet-gepatchte infrastructuur en ongedocumenteerde integraties – de faalpunten die uitval en inbreuken veroorzaken – boven visuele modernisering die veel minder operationeel risico draagt.
12. Meet de leveringsgezondheid met engineeringindicatoren, niet alleen met budget- en planningsafwijking. Frequentie van uitrol, defectpercentages en de ouderdom van het oudste onopgeloste technische schuldpunt vertellen een bestuursorgaan meer over de vraag of een programma zal slagen dan of het momenteel binnen budget is, vaak de laatste indicator die beweegt.

Vragen om met uw team te bespreken

Weten wij werkelijk hoeveel technische schuld wij dragen, systeem voor systeem? De meeste publieke organen kunnen hun kapitaalbudget voor het jaar noemen maar met weinig zekerheid niet zeggen hoeveel van hun softwarelandschap draait op niet-ondersteunde componenten, ongedocumenteerde logica of code die niemand van het resterende personeel volledig begrijpt. Gebruik deze vraag om elke systeemeigenaar in de kamer eerlijk te laten inschatten hoe zeker zij zijn dat hun team hun meest kritieke systeem veilig kan wijzigen zonder iets te breken waaraan niemand dacht. Bespreek wat nodig zou zijn om die schattingen om te zetten in een werkelijk register, volgens een vaste cyclus getoetst, in plaats van stilzwijgende kennis die vertrekt wanneer een sleutelingenieur vertrekt. Overweeg ook wie nu besluit hoeveel schuld aanvaardbaar is om te dragen en of dat besluit bewust is of standaard.

Als ons meest kritieke legacysysteem vandaag moest worden vervangen, zouden wij dan een big-bangomschakeling plannen of een incrementele migratie – en waarom? Het instinct om een oud systeem in één keer te vervangen wordt vaak gedreven door begrotingscycli en gemak voor programmamanagement in plaats van technische noodzaak, en het concentreert enorm risico in één moment. Gebruik deze vraag om concreet door te lopen hoe een incrementele migratie in de stijl van het wurgfeigpatroon van uw meest kritieke legacysysteem werkelijk zou uitzien, stuk voor stuk. Bespreek wat u vandaag belet die route te kiezen – financiering gestructureerd rond één livegangdatum, een bestuursproces dat één schone mijlpaal wil of een werkelijke technische beperking die incrementele migratie voor dit systeem onmogelijk maakt.

Wie bezit werkelijk de broncode van de software waarvoor onze organisatie heeft betaald, en kunnen wij dat bewijzen? Veel publieke organen ontdekken pas wanneer een relatie met een leverancier zuur wordt dat het contract nooit duidelijk eigendom of escrow van de code waarvan hun kritieke diensten afhangen heeft vastgelegd. Gebruik deze vraag om de contracten van uw drie belangrijkste maatwerksystemen erbij te pakken en specifiek te controleren wat elk zegt over eigendom van code, escrow en het recht de code naar een andere leverancier mee te nemen. Bespreek wat er morgen zou gebeuren als uw primaire leverancier voor een van die drie systemen failliet ging of weigerde de relatie voort te zetten.

Waar vallen wij uit gewoonte terug op gesloten, bedrijfseigen software, terwijl een open-source-by-defaultaanpak ons even goed of beter zou dienen? Open-source-by-defaultbeleid bestaat juist omdat de meeste publieke organen overlappende problemen onafhankelijk oplossen, elk de volle kosten betalend van software die een ander publiek orgaan al heeft gebouwd en had kunnen delen. Gebruik deze vraag om één systeem te identificeren dat nu wordt gebouwd of gespecificeerd en te vragen of er elders in de overheid al een equivalent als opensourcesoftware bestaat, of dat het systeem dat u bouwt nuttig zou kunnen worden vrijgegeven voor hergebruik door anderen. Bespreek welke specifieke barrière – beveiligingszorg, aanbestedingsgewoonte, ontbreken van een duidelijk beleid – dat hergebruik werkelijk belet, in plaats van aan te nemen dat het hier niet relevant is.

Staat ons aanbestedings- en verantwoordingsproces eerlijke agile oplevering werkelijk toe, of herlabelt het alleen watervalmijlpalen als sprints? Het komt vaak voor dat een team nominaal agile ceremonies draait terwijl het nog steeds wordt gefinancierd, bestuurd en gerapporteerd tegen een bij contractondertekening overeengekomen vaste specificatie, wat elk watervalfaalpatroon onder een agile label herschept. Gebruik deze vraag om één lopend digitaal programma van zijn businesscase tot zijn huidige bestuursrapportage te volgen en te vragen of de financieringsstructuur zou tolereren dat het programma van richting verandert op basis van wat een echte vroege release leerde. Bespreek wat er aan de financiering en rapportage van het programma zou moeten veranderen opdat iteratieve oplevering echt is en niet cosmetisch (zie Onderwerp 3.7 — Overheidsaanbesteding en opdrachtverlening).

Hebben wij voldoende interne engineeringcapaciteit om een verstandige koper te zijn van de systemen waarvan wij het meest afhangen? Een organisatie die al haar technisch oordeel heeft uitbesteed, en niet alleen haar leveringscapaciteit, kan niet zien of het voorstel van een leverancier deugt, of een project stilletjes op problemen afstevent of wat een eerlijke prijs voor het werk werkelijk is. Gebruik deze vraag om te vragen hoeveel mensen in uw organisatie geloofwaardig een technisch architectuurvoorstel voor uw belangrijkste systeem zouden kunnen beoordelen en hoe dat aantal de afgelopen vijf jaar is veranderd. Bespreek wat nodig zou zijn om die capaciteit te herbouwen waar ze is uitgehold, en wat uw organisatie verliest, zowel aan onderhandelingspositie als aan leveringsrisico, voor elk jaar dat zij zonder blijft.

In de praktijk: een voorbeeld van publieke waarde

Een fictieve regionale overheid – uitsluitend illustratief, geen beschrijving van een bestaand rechtsgebied – verwerkte haar aanvragen voor werkloosheidsuitkeringen via een systeem dat meer dan dertig jaar eerder voor het eerst was geschreven, onderhouden door een krimpend aantal ingenieurs die de oorspronkelijke programmeertaal begrepen. Het aanvraagvolume was ver voorbij wat de ontwerpers van het systeem hadden verwacht gegroeid, nachtelijke verwerkingsruns faalden steeds vaker voordat de transacties van de ochtend begonnen, en de technologieleiding van het agentschap waarschuwde dat een ongeplande uitval die uitkeringsbetalingen raakte nu een kwestie van wanneer was, niet of.

Het eerste instinct van het agentschap was een conventionele reactie op een probleem dat urgent aanvoelde: één groot contract opdragen om het hele systeem te vervangen door een modern platform, vooraf volledig gespecificeerd, geleverd tegen een vaste tijdlijn van twee jaar met aan het eind één omschakelweekend. Een voorafgaande toetsing opgedragen door de auditcommissie van het agentschap stelde een harde vraag voordat het contract werd getekend: wat zou er met de uitkeringsbetalingen aan enkele honderdduizenden aanvragers gebeuren als het nieuwe systeem in zijn eerste week van volledige, live werking een onontdekt defect had, terwijl het oude systeem al buiten gebruik was gesteld en er geen weg terug was.

Het agentschap veranderde van koers. Het hield het legacysysteem draaiend als registratiesysteem en begon naast het oude systeem nieuwe functionaliteit voor aanvraagopname en geschiktheidsbeoordeling te bouwen, met een wurgfeigaanpak: elke nieuwe module werd eerst vrijgegeven voor een klein percentage van nieuwe aanvragen, geverifieerd tegen de parallelle uitvoer van het oude systeem en pas uitgebreid zodra de resultaten overeenkwamen. Binnen achttien maanden liep de meerderheid van de nieuwe aanvragen via moderne componenten terwijl het oorspronkelijke systeem een krimpend restbestand afhandelde, met de mogelijkheid elk afzonderlijk geval terug te leiden naar het oude pad als er iets mis leek. Het agentschap eiste ook, in elk nieuw contract voor dit werk, dat de broncode eigendom van het agentschap zou zijn en als open source zou worden gepubliceerd zodra de beveiligingstoetsing was afgerond, zodat andere regionale overheden met hetzelfde probleem van verouderde mainframes de componenten konden aanpassen in plaats van dezelfde bouw vanaf nul te herhalen.

De volledige vervanging van de laatste resterende functies van het legacysysteem duurde bijna vier jaar – op papier langer dan het oorspronkelijke big-bangplan van twee jaar beloofde. Maar geen enkele aanvrager ondervond tijdens de overgang een ongeplande uitval, elk increment was klein genoeg om binnen uren te worden teruggedraaid wanneer een defect werd gevonden, en twee naburige regionale overheden begonnen binnen het eerste jaar na de release de gepubliceerde code voor geschiktheidsbeoordeling van het agentschap voor hun eigen systemen aan te passen.

Vier sectorperspectieven

Lokale overheid

De lokale overheid draait doorgaans een groot aantal kleinere, niet-verbonden systemen in plaats van een handvol platforms op nationale schaal, wat betekent dat technische schuld zich ophoopt over veel afzonderlijk aanbestede, afzonderlijk onderhouden toepassingen in plaats van in één zichtbaar vlaggenschipsysteem. Lokale autoriteiten hebben doorgaans de minste interne engineeringcapaciteit van elke bestuurslaag, wat het argument voor het kopen van configureerbare standaardsoftware boven maatwerk bijzonder sterk maakt, en gedeelde regionale of nationale platforms – het onderwerp van Onderwerp 5.1 (zie Onderwerp 5.1 — Digitale overheid en digitale transformatie) – een bijzonder waardevolle route om te vermijden dat elke autoriteit afzonderlijk dezelfde capaciteit opnieuw bouwt.

Nationale overheid

De nationale overheid is waar de oudste en meest ingrijpende legacysystemen doorgaans zitten – kernadministratie van belasting, sociale verzekeringen en uitkeringen – omdat deze vaak tot de eerste grootschalige computerisatiepogingen bij de overheid behoorden en nu de hoogste inzet dragen voor elk moderniseringsfalen. De nationale overheid heeft doorgaans de specialistische commerciële en engineeringcapaciteit om een werkelijk incrementeel moderniseringsprogramma uit te voeren en echt eigendom van code in haar contracten te onderhandelen, en is doorgaans het overheidsniveau dat het best in staat is een open-source-by-defaultbeleid vast te stellen met voldoende schaal erachter om hergebruik over de overheid werkelijk te laten plaatsvinden.

Sociale sector en non-profit

Non-profitorganisaties en goede doelen bouwen zelden zelf grote maatwerkplatforms, maar zijn vaak de ontvangende partij van software die door een overheidsfinancier is opgedragen of verplicht gesteld – een rapportageportaal, een dossiersysteem dat een subsidie of contract hen verplicht te gebruiken – met weinig invloed op ontwerp, technische schuld of leverancier. Een organisatie in de sociale sector die afhangt van een door de overheid verplicht systeem erft de faalpatronen ervan zonder de hefboom om ze op te lossen te erven, wat nog een reden is waarom uitkomstgerichte financieringsrelaties rekening moeten houden met de operationele last van verplichte technologie (zie Onderwerp 3.7 — Overheidsaanbesteding en opdrachtverlening), en niet alleen met de uitkomstmaatstaf zelf.

Multilateraal en internationaal

Multilaterale organen en ontwikkelingsagentschappen bevorderen steeds vaker software die voor het openbaar bestuur van één land is gebouwd als herbruikbaar digitaal publiek goed dat andere landen kunnen aanpassen, in plaats van dat elke overheid tegen volledige kosten een equivalent systeem bij een private leverancier opdraagt. Het kenmerkende risico hier is dat een digitaal publiek goed gebouwd voor de juridische en administratieve context van één land elders met te weinig aanpassing kan worden overgenomen, waarbij aannames – over identiteit, geschiktheid of proces – worden geïmporteerd die zich niet werkelijk laten overdragen; de belofte van gedeelde, open infrastructuur is reëel, maar alleen waar echte lokale aanpassingscapaciteit de code vergezelt.

Veelvoorkomende faalpatronen

De big-bangomschakeling die bij livegang faalt. Een kritiek legacysysteem wordt vervangen in één onomkeerbare omschakeling na jaren van ontwikkeling zonder live productieblootstelling, en een defect dat zich alleen op echte schaal of in een randgeval toont dat niemand testte, komt aan de oppervlakte op de eerste dag van volledige werking, zonder weg terug naar het oude systeem omdat het al buiten gebruik is gesteld. De kosten worden gemeten in gemiste betalingen, geweigerde diensten of uitval die precies de burgers raakt voor wie het systeem bestaat, op het slechtst denkbare moment – het moment waarop iedereen erop vertrouwde dat de vervanging werkte.

Stille ophoping van technische schuld. Deadlinedruk wint herhaaldelijk het argument van de tijd die nodig is om bekende shortcuts te herstellen, en elk uitstel is afzonderlijk verdedigbaar, totdat de opgehoopte schuld zelfs een kleine wijziging onevenredig duur en riskant maakt. De kosten tonen zich jaren later als een systeem dat niemand veilig kan wijzigen, een personeelsbestand dat stilletjes heeft opgehouden iets anders dan de meest urgente patches te proberen, en een uiteindelijk moderniseringsprogramma veel groter en duurder dan voortdurende, kleinere vernieuwing zou zijn geweest.

Leveranciersafhankelijkheid aangezien voor stabiliteit. Een publiek orgaan verlengt herhaaldelijk het contract met dezelfde leverancier omdat overstappen te ontwrichtend lijkt om te proberen, zonder ooit te toetsen wat werkelijke overstapkosten zouden zijn of te onderhandelen over eigendom van code en open gegevensformaten die die kosten beheersbaar zouden houden. De kosten zijn een blijvend verzwakte onderhandelingspositie over prijs en voorwaarden, pas ontdekt wanneer de dienstkwaliteit van de leverancier daalt of zijn prijzen stijgen en het publieke orgaan constateert dat het geen geloofwaardig alternatief heeft.

Cosmetische agile. Een leveringsteam neemt agile ceremonies over – stand-ups, sprints, een backlog – terwijl de onderliggende contract-, financierings- en bestuursstructuur nog steeds een vaste specificatie en één go/no-gomijlpaal veronderstelt, zodat het team sprintsnelheid rapporteert terwijl het in werkelijkheid onder de oppervlakte tegen een watervalplan levert. De kosten zijn dat geen van de werkelijke voordelen van agile – vroege gebruikersfeedback die richting verandert, vroeg zichtbaar gemaakt risico – zich voordoet, terwijl de schijn van moderne praktijk de onderliggende starheid moeilijker zichtbaar en betwistbaar maakt voor toezichtorganen.

Opensourcebeleid zonder onderhoudsplan. Een publiek orgaan publiceert broncode om aan een open-source-by-defaultbeleid te voldoen maar behandelt de release als eenmalige nalevingsstap, zonder middelen voor het beoordelen van externe bijdragen, het patchen van kwetsbaarheden of het onderhouden van documentatie. De kosten zijn een gepubliceerde repository die open lijkt maar functioneert als onderhoudsloze doodlopende weg, wat het vertrouwen in het bredere open-source-by-defaultprogramma meer schaadt dan nooit publiceren zou hebben gedaan.

Volwassenheidsmodel

Checklist

• Inventariseer de technische schuld van elk kritiek systeem en toets het register volgens een vaste cyclus.
• Pas een gedocumenteerd kader voor bouwen versus kopen toe vóór u zich aan enige significante nieuwe software verbindt.
• Kies bij elke vervanging van een legacysysteem standaard voor een incrementele migratiemethode en eis een expliciete rechtvaardiging voor een big-bangomschakeling.
• Bevestig vóór ondertekening in elk softwarecontract de voorwaarden voor eigendom van broncode of escrow.
• Publiceer broncode onder een open-source-by-defaultbeleid, met een gedocumenteerd uitzonderingsproces.
• Voorzie doorlopend onderhoud van middelen voor elke repository die onder dat beleid is gepubliceerd, niet alleen de eerste release.
• Eis open, gedocumenteerde gegevensformaten, ook waar de onderliggende software bedrijfseigen is.
• Structureer financieringspoorten rond aangetoonde werkende software in plaats van één mijlpaal met vaste specificatie.
• Bouw en test een minimaal levensvatbaar product met echte gebruikers vóór u zich aan de volledige reikwijdte verbindt.
• Volg frequentie van uitrol, defectpercentages en openstaande technische schuld als vaste bestuursindicatoren.
• Beoordeel de interne engineeringcapaciteit aan wat nodig is om een verstandige koper te zijn en dicht vastgestelde lacunes.
• Geef niet-ondersteunde infrastructuur en ongedocumenteerde integraties prioriteit boven cosmetische modernisering.

Belangrijkste bronnen

• GOV.UK Service Standard, Government Digital Service, Verenigd Koninkrijk — een nationale digitale dienstnorm die iteratieve, gebruikersgerichte oplevering en open standaarden voor publieke diensten vereist.
• Office of Management and Budget, Federal Source Code Policy (M-16-21), Verenigde Staten — het federale beleid dat agentschappen verplicht hergebruik en opensourcevrijgave van op maat ontwikkelde overheidssoftware te overwegen.
• Free Software Foundation Europe, campagne Public Money, Public Code — de grondgedachte, ontwikkeld voor een Europees publiek, voor het vrijgeven van de broncode van met publiek geld gefinancierde software onder vrije en opensourcelicenties.
• Ward Cunningham, “The WyCash Portfolio Management System” (ervaringsrapport OOPSLA 1992) — de oorspronkelijke formulering van de metafoor van technische schuld.
• Digital Public Goods Alliance — een initiatief van meerdere belanghebbenden dat normen en een register bijhoudt voor open software, data en inhoud ontworpen om publieke ontwikkelingsdoelstellingen te dienen.

Referenties

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. "The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/