Je systeem werkt prima. Zolang de persoon werkt die weet waarom.
Het bedrijf heeft een systeem dat zeven jaar lang is opgebouwd. Het werkt. Het bedient klanten. Het koppelt aan andere systemen. Het voert processen uit zonder welke het bedrijf in feite niet normaal zou kunnen functioneren.
In die zeven jaar hebben vijf developers aan het project gewerkt. Daarnaast twee freelancers en één bureau. Een deel van de documentatie staat in Confluence, een deel in Google Drive, een deel in tickets. Ergens is er ook nog een oud document over een van de integraties. En wanneer iemand vraagt waarom een bepaald deel van het systeem precies op deze manier werkt, luidt het antwoord: "Ik denk dat Michał dat nog wist."
Michał is drie jaar geleden vertrokken.
En precies dan begint het echte probleem.
Niet omdat het systeem slecht is geschreven. Niet omdat het plotseling stopte met werken. Het probleem is dat het bedrijf niet langer over de volledige kennis van zijn eigen systeem beschikt.
Het systeem werkt, maar het bedrijf controleert het misschien niet
Dat is een van de meest onderschatte vormen van technische schuld.
Wanneer we het over technische schuld hebben, denken we meestal aan oude code, verouderde bibliotheken, architecturale fouten, gebrek aan tests of oplossingen die ooit snel waren maar nu groei belemmeren.
Maar er bestaat nog een ander soort schuld. Kennisschuld.
Die ontstaat wanneer een systeem afhankelijk is van informatie die niet in de documentatie, het repository, de procedures of de organisatie staat, maar alleen in het hoofd van specifieke mensen.
En zolang die mensen beschikbaar zijn, lijkt alles normaal.
Het probleem verschijnt bij een teamwissel, het vertrek van een developer, het beëindigen van een samenwerking met een software house, een serverstoring, een wissel van beheerder of de noodzaak om snel een nieuwe oplossing te implementeren.
Plots blijkt dat het bedrijf code heeft, maar geen kennis.
Het heeft een server, maar geen zekerheid over wie toegang heeft.
Het heeft een integratie, maar weet niet onder welk account die is aangemaakt.
Het heeft documentatie, maar weet niet welke versie actueel is.
Het heeft een proces, maar weet niet waarom het juist zo is ontworpen.
En dan komt heel snel de vraag: wie is eigenlijk de eigenaar van dit systeem?
Bus factor, of wat gebeurt er als één persoon verdwijnt?
In de IT-wereld bestaat het begrip bus factor. Simpel gezegd betekent het het aantal personen waarvan de onbeschikbaarheid ertoe kan leiden dat het team niet langer in staat is een project effectief te ontwikkelen of te onderhouden.
Het gaat natuurlijk niet om een letterlijke gebeurtenis. Het is een manier van denken over kennisconcentratie.
Als maar één persoon weet hoe een kritieke integratie werkt, is de bus factor voor die kennis gelijk aan één.
Als maar één beheerder toegang heeft tot productie, is de bus factor gelijk aan één.
Als maar één persoon weet waarom het systeem elke nacht een bepaalde procedure uitvoert, kan de bus factor gelijk zijn aan één.
Als een bedrijf samenwerkt met een extern software house en aan klantzijde niemand de architectuur van de oplossing begrijpt, ontstaat een nog groter probleem - de kennis kan buiten de organisatie liggen.
Dat betekent niet dat elk bedrijf vijf experts moet hebben voor elk onderdeel van het systeem.
Het gaat om iets veel eenvoudigers: het bedrijf moet weten waar de kritieke kennis zich bevindt en of het die kan terughalen zonder een specifieke persoon.
Code zegt hoe. Niet altijd waarom.
Een developer kan code lezen en begrijpen wat een bepaalde functie doet.
Niet altijd weet die echter waarom die precies op die manier is geschreven.
Dat is een enorm verschil.
Je kunt het fragment vinden dat verantwoordelijk is voor het versturen van gegevens naar een extern systeem. Je kunt het endpoint, de parameters, de autorisatie en de foutafhandeling analyseren.
Maar de code beantwoordt niet per se de vragen:
- Waarom versturen we de gegevens om 2:00 uur ’s nachts?
- Waarom wordt deze specifieke status overgeslagen?
- Waarom probeert het systeem na een fout precies drie keer opnieuw?
- Waarom wordt één waarde omgerekend voor het versturen?
- Waarom mag de volgorde van deze operaties niet worden gewijzigd?
- Waarom gebruikt deze integratie een specifiek account?
Het antwoord kan in de projectgeschiedenis staan, in een oud ticket, in een e-mail van zes jaar geleden of - erger nog - alleen in het geheugen van iemand die al niet meer in het bedrijf werkt.
Daarom moet goede documentatie niet alleen een handleiding zijn voor "wat je moet aanklikken".
Ze moet ook context en beslissingen vastleggen.
Het grootste probleem kan een integratie zijn die niemand zich nog herinnert
Een modern systeem werkt bijna nooit volledig zelfstandig.
Het koppelt aan een ERP-systeem. CRM. Betaalgateway. SMS-leverancier. Koerierssysteem. Partner-API. Cloudservice. Analyseplatform. Boekhoudsysteem. Authenticatiemechanisme.
Elke dergelijke koppeling maakt deel uit van een technologische keten.
En elk onderdeel van die keten kan zijn eigen eigenaar, account, API-sleutel, certificaat, contract, limiet, API-versie en levenscyclus hebben.
Na enkele jaren weet niemand misschien nog wie het betreffende account heeft aangemaakt.
En dan is één verlopen certificaat of een API-wijziging al genoeg om het systeem te laten stoppen met werken.
Nog erger is het als het bedrijf niet eens weet dat zo’n afhankelijkheid bestaat.
Daarom krijgt in een volwassen benadering van systemen software provenance, afhankelijkheidsbeheer en transparantie van de software supply chain steeds meer betekenis. NIST wijst in zijn actuele materialen over supply-chainbeveiliging onder meer op het belang van informatie over componenten, hun herkomst, levenscyclus en afhankelijkheden. SBOM, oftewel Software Bill of Materials, is een van de instrumenten waarmee kennis over de samenstelling van software kan worden geordend.
Dat is niet langer uitsluitend een onderwerp voor het securityteam.
Het is ook een onderwerp voor het bestuur.
Want als een bedrijf niet weet waaruit zijn systeem is opgebouwd, wordt het moeilijker om risico’s, onderhoudskosten en de gevolgen van veranderingen in te schatten.
Documentatie is geen kostenpost. Het is een polis.
In veel bedrijven wordt documentatie gezien als iets dat "later wel komt".
Eerst de functionaliteit.
Dan de implementatie.
Dan de fixes.
Dan het volgende project.
En de documentatie?
"Als er tijd is."
Het probleem is dat tijd voor documentatie meestal pas verschijnt wanneer het al te laat is.
Documentatie zou moeten werken als een zakelijke verzekering. Niet omdat iemand die elke dag zal lezen. Integendeel - hopelijk is ze zo min mogelijk nodig in een noodsituatie.
Maar wanneer er een probleem optreedt, moet het bedrijf in staat zijn om basisvragen te beantwoorden:
- Hoe werkt het systeem?
- Waaruit bestaat het?
- Waar is de productieomgeving?
- Wie heeft toegang?
- Welke zijn de kritieke integraties?
- Welke accounts en externe diensten worden gebruikt?
- Wat zijn de afhankelijkheden?
- Hoe worden back-ups gemaakt?
- Hoe ziet het implementatieproces eruit?
- Wat gebeurt er tijdens een storing?
- Welke onderdelen zijn bedrijfskritisch?
- Waarom zijn de belangrijkste architectonische beslissingen genomen?
- Wie kan het onderhoud van het systeem overnemen?
Dat hoeft niet honderden pagina's documentatie te betekenen.
Goede documentatie moet vooral nuttig, actueel en toegankelijk voor de juiste mensen zijn.
"Laten we het niet aanraken, want het werkt" is niet altijd een slechte beslissing
Er is nog een heel vaak voorkomend probleem.
Het systeem draait al jaren, dus het bedrijf hanteert het principe: "We raken het niet aan. Het werkt."
En soms is dat absoluut verstandig.
Niet elke oude technologie hoeft onmiddellijk vervangen te worden. Niet elk ouder stukje code moet herschreven worden. Niet elke bibliotheek betekent een ramp. Niet elke architectuur van een paar jaar geleden is fout.
Het probleem begint wanneer "laten we het niet aanraken" ook betekent:
- "Laten we het niet analyseren."
- "Laten we het niet documenteren."
- "Laten we de afhankelijkheden niet controleren."
- "Laten we niet vragen wie toegang heeft."
- "Laten we niet controleren of we nog steeds alle accounts hebben."
- "Laten we niet vaststellen wat er gebeurt als de huidige opdrachtnemer niet meer beschikbaar is."
Dan is het uitblijven van verandering geen strategie.
Het is het uitstellen van risico.
Soms is de beste technische beslissing inderdaad om niets te herbouwen.
Maar die beslissing moet voortkomen uit kennis van het systeem, niet uit een gebrek aan kennis over het systeem.
Wat moet een audit van een geërfd systeem omvatten?
Wanneer een bedrijf een systeem overneemt van een ander softwarehuis, freelancer of intern team, zou de eerste stap niet automatisch het herschrijven van alles moeten zijn.
Eerst moet men begrijpen wat er eigenlijk is overgenomen.
De audit moet ten minste enkele basisgebieden beantwoorden.
Architectuur. Hoe is het systeem opgebouwd? Wat zijn de belangrijkste componenten? Waar bevinden de gegevens zich? Hoe communiceren de afzonderlijke elementen?
Code en repositories. Beschikt het bedrijf over de volledige broncode? Is bekend welke branch en versie in productie zijn? Is het bouw- en implementatieproces reproduceerbaar?
Infrastructuur. Waar draait de productie? Hoe ziet de testomgeving eruit? Wie heeft toegang? Hoe zien monitoring en back-up eruit?
Integraties. Met wat communiceert het systeem? Welke API's gebruikt het? Wie is eigenaar van de afzonderlijke accounts en sleutels?
Afhankelijkheden. Welke bibliotheken, frameworks en externe componenten worden gebruikt? Worden ze bijgewerkt? Hebben ze bekende beveiligingsproblemen? Hoe ziet hun levenscyclus eruit?
Implementatieproces. Kan een nieuw persoon een wijziging voorbereiden, testen en uitrollen zonder de voormalige ontwikkelaar te bellen?
Kennis. Wat staat in de documentatie en wat bestaat nog alleen in de hoofden van mensen?
Zakelijk risico. Wat gebeurt er als een bepaalde component een uur, een dag of een week niet werkt?
De moderne benadering van beveiliging van de softwareleveringsketen benadrukt steeds sterker juist de noodzaak van kennis over componenten, leveranciers, afhankelijkheden, hun herkomst en levenscyclus. NIST wijst ook op het belang van due diligence ten aanzien van technologieleveranciers en de beoordeling van veerkracht en risico's die samenhangen met de hele toeleveringsketen.
Een audit betekent niet "laten we het systeem vanaf nul opnieuw schrijven"
Dat is belangrijk, omdat een technische audit vaak ten onrechte wordt gelijkgesteld aan een herbouw.
Intussen kan een audit eindigen met een heel eenvoudige conclusie: "Het systeem is in orde. We moeten alleen de kennis ordenen en een paar risico's wegnemen."
Het kan ook blijken dat het systeem maar op één gebied gemoderniseerd hoeft te worden.
Of dat het grootste probleem niet de code is, maar het gebrek aan toegang tot de infrastructuur.
Of dat de applicatie goed geschreven is, maar niemand actuele kennis heeft van het implementatieproces.
Of dat alles werkt, maar het bedrijf afhankelijk is van één externe leverancier.
Daarom zou een goede analyse van een geërfd project de vraag moeten beantwoorden: "Wat moet er nu echt veranderen, en wat hoeft niet aangeraakt te worden?"
Pas dan kunnen investeringsbeslissingen worden genomen.
En wat als je van softwarehuis verandert?
Dat is een van de momenten waarop het probleem van onzichtbare kennisschuld aan het licht komt.
Het bedrijf beëindigt de samenwerking met de uitvoerder.
De nieuwe partner ontvangt de repository.
En begint vragen te stellen:
- "Waar is de productie?"
- "Hoe start ik het project lokaal op?"
- "Welke versie is actueel?"
- "Waar dient deze service voor?"
- "Wie bezit het account voor deze API?"
- "Wat doet deze cron?"
- "Waarom start dit proces op dat uur?"
- "Waar halen we deze parameter vandaan?"
- "Wat gebeurt er als we hem uitschakelen?"
Als het antwoord op de meeste vragen "we weten het niet" is, neemt het nieuwe softwarehuis het project niet over. Eerst moet het het ontdekken.
En het ontdekken van het systeem kost tijd. Tijd die later door de klant betaald wordt.
Daarom moet de overdracht van een project tussen teams een proces zijn, en niet het overgooien van een ZIP-bestand met code en het wachtwoord van één account.
Het systeem moet de mensen overleven
Dat is waarschijnlijk de belangrijkste regel.
Mensen veranderen. Ontwikkelaars veranderen van baan. Freelancers beëindigen de samenwerking. Softwarehuizen veranderen van klanten. Beheerders gaan naar andere bedrijven. Besturen veranderen.
Het systeem blijft.
Daarom moet het systeem zo ontworpen worden dat de kennis die nodig is voor het onderhoud ervan kan worden hersteld.
Dat betekent niet dat elke medewerker alles moet weten.
Het betekent dat de organisatie een mechanisme voor kennisopslag moet hebben:
- Repositories.
- Documentatie.
- Register van integraties.
- Informatie over de infrastructuur.
- Toegangen beheerd door het bedrijf.
- Beschrijving van sleutelprocessen.
- Geschiedenis van belangrijke beslissingen.
- Informatie over afhankelijkheden.
- Noodprocedures.
- En vooral - mensen die deze documentatie kunnen gebruiken.
NIST wijst in de actuele richtlijnen voor de veiligheidsplanning van systemen ook op het formeel vastleggen van verantwoordelijkheden, de operationele status van het systeem en de rollen van personen die het systeem beheren, ondersteunen of toegang ertoe hebben.
Dat laat een bredere verandering in het denken over technologie zien.
Een systeem is niet alleen code. Een systeem is ook mensen, processen, infrastructuur, afhankelijkheden, gegevens, toegang en verantwoordelijkheid.
Bij Web24 beginnen we vaak juist met de vraag: "Wat hebben we hier eigenlijk?"
De overname van een bestaand project zou niet moeten beginnen met de belofte dat alles vanaf nul opnieuw geschreven zal worden.
Het zou moeten beginnen met het begrijpen van de situatie:
- Wat werkt?
- Wat werkt niet?
- Wat is kritisch?
- Wat is verouderd?
- Waar zitten de grootste risico’s?
- Wat ontbreekt er in de documentatie?
- Welke afhankelijkheden zijn onzichtbaar?
- Kan het bestaande systeem veilig worden doorontwikkeld?
- Is er modernisering nodig, of alleen opschoning?
Pas daarna kun je beslissen of het project moet worden doorontwikkeld, herbouwd, gedeeltelijk herschreven of gewoon goed gedocumenteerd.
Dat is vooral belangrijk bij projecten die jarenlang zijn ontwikkeld door verschillende mensen en verschillende bedrijven.
Want een goede technologiepartner zou niet nodig moeten zijn omdat alleen diegene weet hoe het systeem werkt.
Die zou nodig moeten zijn omdat hij of zij dat systeem kan doorontwikkelen, beveiligen en kennis verder kan overdragen.
De gevaarlijkste fout kan een persoon zijn die al vertrokken is
Niet altijd is oude code het probleem.
Niet altijd is verouderde technologie het probleem.
Niet altijd is het ontbreken van het nieuwste framework het probleem.
Soms is het grootste risico de informatie die niemand heeft opgeschreven.
Eén knop.
Eén architectonische beslissing.
Eén integratie.
Eén uitzondering in het proces.
Eén persoon die jarenlang wist hoe het werkte.
En daarna is diegene vertrokken.
Daarom is het vandaag de moeite waard om jezelf een heel eenvoudige vraag te stellen: Als morgen de persoon die jullie systeem het beste kent uit het bedrijf zou verdwijnen, zouden jullie het dan nog steeds kunnen beheren?
Als het antwoord "ja" is - geweldig.
Als het "ik weet het niet" is - het is de moeite waard om het te controleren.
En als het "zeker niet" is - dan hebben jullie waarschijnlijk net een van de belangrijkste gebieden van technologisch risico binnen je bedrijf gevonden.
Een systeem moet groter zijn dan het geheugen van één persoon.
