Je systeem werkt geweldig. Zolang er iemand werkt die weet waarom.
Stel je een bedrijf voor met een systeem dat al zeven jaar draait. Het is stapsgewijs opgebouwd. Eerst heeft een softwarehuis het gemaakt. Daarna nam een freelancer een deel over. Later bouwde een ander team een B2B-module. De volgende agency koppelde het CRM aan. Iemand anders integreerde de betalingen.
Het systeem werkt.
Het bedrijf verdient er geld mee.
Werknemers gebruiken het dagelijks.
Klanten weten niet eens hoeveel processen er op de achtergrond plaatsvinden.
Er is alleen één probleem.
Niemand weet nog precies, hoe dit allemaal werkt.
De documentatie staat deels in Confluence. Iets staat op Google Drive. Enkele informatie is terug te vinden in tickets. Eén integratie is beschreven in een e-mail van vier jaar geleden.
En het belangrijkste ding "heeft Łukasz vast onthouden".
Alleen Łukasz is drie jaar geleden weggegaan.
En drie jaar lang gebeurde er niets.
Tot die ene dinsdagochtend.
Het systeem werkt. Dus alles is in orde?
Dit is een van de verraderlijkste toestanden waarin een bedrijfssysteem zich kan bevinden.
Het werkt.
Er zijn geen storingen.
Gebruikers zijn tevreden.
De verkoop gebruikt de applicatie.
Bestellingen komen door.
Gegevens komen in het CRM terecht.
Rapporten worden gegenereerd.
Dus de natuurlijke reactie is: Laten we het niet aanraken. Waarom rommelen aan iets dat werkt?
En inderdaad - er is geen reden om een werkend systeem te veranderen alleen omdat het kan.
Het probleem is dat een systeem technisch stabiel kan zijn en tegelijk organisatorisch erg instabiel.
Het kan vandaag werken, maar niemand weet wat er gebeurt als de server, API-leverancier, het domein, de bibliotheek, de authenticatiemethode of een deel van het bedrijfsproces gewijzigd moet worden.
Het kan goed functioneren, maar afhankelijk zijn van één persoon.
Het kan veilig zijn, maar niemand weet waar alle toegangssleutels zich bevinden.
Het kan verder ontwikkeld worden, maar alleen door iemand die de geschiedenis van alle beslissingen kent.
En precies hier komt het begrip bus factor om de hoek kijken.
Hoeveel mensen kunnen verdwijnen voordat het project problemen krijgt?
De bus factor is een heel eenvoudig, al is het een brute, concept.
We vragen: Hoeveel mensen moeten niet langer beschikbaar zijn voordat het project niet meer goed te onderhouden is?
Als het antwoord luidt: "Eén", hebben we een probleem.
Als het antwoord luidt: "Twee, maar ze werken allebei bij een ander bedrijf", hebben we een nog groter probleem.
Het gaat natuurlijk niet om het letterlijke "verdwijnen" van mensen.
Een programmeur kan het bedrijf verlaten.
Een freelancer kan de samenwerking beëindigen.
Een softwarehuis kan stoppen met het bedienen van de klant.
Een beheerder kan van baan veranderen.
De persoon verantwoordelijk voor een specifieke integratie kan naar een andere afdeling overstappen.
De eigenaar van de kennis kan simpelweg ziek worden of enkele weken niet beschikbaar zijn.
Als daarmee ook het vermogen verdwijnt om het systeem te begrijpen, dan heeft het bedrijf geen personeelsprobleem.
Het heeft een businessprobleem.
Code vertelt niet altijd waarom iets werkt
Je kunt zeggen: "Maar we hebben de broncode. Indien nodig leest een nieuwe programmeur die gewoon door."
Theoretisch wel.
In de praktijk beantwoordt code vooral de vraag: hoe het systeem iets doet.
Niet altijd de vraag: waarom het dat juist op deze manier doet.
En dat is een enorm verschil.
In de code kan een voorwaarde staan: "Als de klant een bepaald type account heeft, voer dan operatie X uit."
Een nieuwe developer kan dat vinden.
Maar hoe moet die weten waarom?
Het kan een zakelijke vereiste zijn.
Het kan een overblijfsel zijn van een oude integratie.
Het kan een beveiliging zijn tegen een fout van een externe API.
Het kan een workaround zijn voor een probleem dat vijf jaar geleden voorkwam.
Het kan een oplossing zijn voor een uitzonderlijk geval van een van de grootste klanten.
Er kan een heel goede reden voor zijn.
Of helemaal geen.
Zonder context is dat moeilijk te beoordelen.
Daarom mag de documentatie van een systeem niet beperkt blijven tot instructies:
"klik hier, en dan hier".
De waardevolste documentatie beschrijft vaak beslissingen en afhankelijkheden, en niet alleen het gebruik van functies.
De gevaarlijkste kennis is die welke alleen in iemands hoofd bestaat
Bedrijven hebben heel vaak documentatie. Alleen is documentatie niet altijd hetzelfde als kennis.
We kunnen een API-beschrijving hebben - maar geen informatie over waarom we juist deze API gebruiken.
We kunnen een implementatiehandleiding hebben - maar geen lijst van alle plekken waar de configuratie gewijzigd moet worden.
We kunnen een integratiebeschrijving hebben - maar niet weten wat er gebeurt als de externe leverancier de autorisatiemethode wijzigt.
We kunnen een lijst met servers hebben - maar niet weten welke daarvan kritisch is voor een specifiek proces.
We kunnen toegang hebben tot de repository - maar geen toegang tot het account waar de productie-infrastructuur zich bevindt.
Dit zijn precies die elementen die van een ogenschijnlijk eenvoudige wijziging een onderzoek van meerdere dagen kunnen maken.
Een integratie die al vijf jaar werkt, is nog steeds een afhankelijkheid
Een van de meest genegeerde gebieden zijn externe diensten;
- Betalingen.
- Sms.
- E-mail.
- CRM.
- ERP.
- Kaarten.
- Koerierssystemen.
- Marketingplatforms.
- Boekhoudsystemen.
- Cloudservices.
- Externe API's.
- Open-sourcebibliotheken.
Elk van die dingen is onderdeel van een groter ecosysteem.
Als een systeem tien externe diensten gebruikt, hebben we niet één systeem. We hebben een systeem plus tien afhankelijkheden. En elk daarvan kan veranderen.
De leverancier kan de API wijzigen.
Hij kan de dienst beëindigen.
Hij kan het prijsmodel aanpassen.
Hij kan de oude versie uitfaseren.
Hij kan nieuwe beveiligingseisen invoeren.
Hij kan worden overgenomen door een ander bedrijf.
Daarom speelt ook kennis over de herkomst van componenten en softwareafhankelijkheden een steeds grotere rol. NIST wijst onder meer op het belang van SBOM, oftewel Software Bill of Materials - een formeel overzicht van de componenten die zijn gebruikt om software te bouwen. Zo’n lijst helpt begrijpen waaruit het systeem bestaat en maakt het sneller mogelijk om de impact van kwetsbaarheden of veranderingen in de toeleveringsketen te beoordelen.
Voor het bedrijf kun je dit terugbrengen tot een heel eenvoudige vraag:
Weet je waarvan jouw systeem afhankelijk is?
Stel je nu eens voor dat het softwarehuis wordt vervangen
Dat is een van de momenten waarop alle gebreken aan het licht komen.
Het bedrijf werkte jarenlang samen met één leverancier. Plotseling eindigt die samenwerking. Daar kunnen veel redenen voor zijn; Strategiewijziging. Budgetwijziging. Overname van het bureau. Organisatorische problemen. Gebrek aan competentie voor verdere ontwikkeling. Of het bedrijf wil gewoon met een andere partner werken.
Het nieuwe softwarehuis vraagt:
"Waar is de repository?" - Die is er.
"Waar is de infrastructuur?" - Die is er.
"Hoe implementeren we productie?" - "We weten het niet, dat deed het vorige team."
"Hoe werkt de integratie met ERP?" - "Waarschijnlijk via die server."
"Welke API-sleutels hebben we?" - "Zouden in de e-mail moeten staan."
"Welke API's zijn productie?" - "We weten het niet."
"Welke processen zijn kritiek?" - "We moeten Lukas vragen."
Lukas werkt daar al niet meer...
En juist daarom is een projectoverdracht niet alleen een overdracht van code. Ook de kennis moet worden overgedragen.
Documentatie is geen kostenpost. Het is een verzekering
In veel bedrijven wordt documentatie gezien als iets dat je doet "als er tijd voor is".
Dus meestal nooit.
Of aan het einde van het project.
Of wanneer iemand ernaar vraagt.
Dat is een fout.
Documentatie is een van de mechanismen die operationeel risico beperken. Ze genereert niet direct omzet. Verbetert de conversie niet. Ziet er niet spectaculair uit op een presentatie.
Maar in een crisissituatie kan het het verschil zijn tussen: "we lossen dit vandaag op"
en: "eerst moeten we de persoon vinden die zich herinnert hoe het werkte".
In de nieuwe NIST-richtlijnen voor beveiligingsplannen, privacy en risicobeheer in de softwareketen wordt het documenteren van het doel van het systeem, de status ervan, de controles en de verantwoordelijkheden en het gedrag van de mensen die het beheren gezien als een element van gestructureerd systeembeheer.
Dat laat heel goed zien hoe het denken verandert.
Documentatie is niet alleen een hulpmiddel voor de developer.
Het is een element van de continuïteit van de organisatie.
Wat moet worden gedocumenteerd?
Het gaat niet om het maken van documentatie van 800 pagina's die niemand ooit opent.
Goede documentatie moet vooral antwoorden geven op vragen die opduiken wanneer er iets verandert of stopt met werken.
- Wie is eigenaar van het systeem?
- Waar bevindt de code zich?
- Waar bevindt de productie zich?
- Hoe ziet het implementatieproces eruit?
- Welke omgevingen zijn er?
- Welke kritieke integraties zijn er?
- Welke externe diensten gebruiken we?
- Wie is de leverancier daarvan?
- Welke contracten en accounts hebben we?
- Waar zijn de sleutels en toegangsinformatie?
- Wie heeft rechten?
- Hoe ziet de back-up eruit?
- Hoe ziet het herstel van het systeem eruit?
- Welke open-sourcecomponenten worden gebruikt?
- Welke bibliotheken zijn verouderd?
- Wat zijn de belangrijkste architecturale beslissingen?
- Welke onderdelen zijn kritiek voor het bedrijf?
- Wat gebeurt er als een specifieke externe dienst stopt met werken?
Dit is geen documentatie "voor programmeurs".
Dit is een kaart van de afhankelijkheden van het bedrijf van technologie.
"Het werkt, dus laat het zoals het is" kan een strategie zijn. Maar dan moet je de prijs ervan kennen
Niet elk bedrijf heeft een herbouw van een oud systeem nodig.
Niet elk legacy-systeem is slecht.
Niet alle oude code hoeft herschreven te worden.
Integendeel - soms is een stabiel, ouder systeem een veel betere oplossing dan een dure migratie die zonder concrete reden wordt uitgevoerd.
Het probleem is niet de leeftijd van het systeem.
Het probleem is het gebrek aan kennis over de staat ervan.
Als we weten hoe het systeem werkt, welke afhankelijkheden het heeft, waar de risico's zitten en wie het kan onderhouden, kunnen we bewust beslissen:
- laten we het zoals het is,
- moderniseren we het,
- herschrijven we een onderdeel,
- migreren we,
- of doen we helemaal niets.
Als we dat niet weten, is de beslissing "we laten het zoals het is" geen strategie.
Het is een gok.
Hoe ziet een audit van een geërfd systeem eruit?
Wanneer een bestaand systeem bij een softwarehuis terechtkomt, zou de eerste stap niet moeten zijn: "Laten we het herschrijven." - Eerst moet je het begrijpen.
Een goede audit moet onder meer de applicatiearchitectuur, de broncode, de database, de infrastructuur, het implementatieproces, afhankelijkheden, integraties, beveiliging, toegang tot diensten en documentatie omvatten.
Maar even belangrijk is het begrijpen van het bedrijf;
- Welke processen zijn kritiek?
- Welke functies worden dagelijks gebruikt?
- Welke modules zijn verantwoordelijk voor omzet?
- Welke onderdelen kunnen zonder gevolgen worden uitgeschakeld?
- Wat gebeurt er als een specifieke integratie stopt met werken?
- Welke onderdelen zijn het meest risicovol?
Pas nadat het technische en zakelijke perspectief is gecombineerd, kun je zeggen wat echt verandering vereist.
Een audit hoeft niet te eindigen in een revolutie
Soms is de uitkomst van een audit verrassend eenvoudig.
Het systeem is in orde, er moet alleen:
- Documentatie worden aangevuld.
- Toegang worden geordend.
- Een paar bibliotheken worden bijgewerkt.
- Het eigenaarschap van accounts worden overgedragen.
- Het implementatieproces worden beschreven.
- Monitoring worden toegevoegd.
- Back-up worden ingesteld.
- Een tweede persoon worden ingewerkt in de gebieden die alleen één developer kende.
En plotseling verandert de busfactor van 1 naar 3.
Je hoeft niet de hele applicatie te herschrijven.
Je hoeft zeven jaar werk niet weg te gooien.
Je hoeft niet alles vanaf nul op te bouwen.
Soms is het grootste probleem niet de technologie.
Het is het gebrek aan een kaart.
Het systeem moet de mensen overleven die het hebben gemaakt
Dat is waarschijnlijk de belangrijkste regel: een goed systeem moet het vertrek van een developer kunnen overleven.
Het moet een wissel van de beheerder kunnen overleven.
Het moet een wissel van het softwarehuis kunnen overleven.
Het moet een reorganisatie van het bedrijf kunnen overleven.
Het moet meerdere jaren ontwikkeling kunnen overleven.
Dat betekent niet dat elke programmeur elke regel code moet begrijpen. Het betekent dat kennis die cruciaal is voor het functioneren van het bedrijf niet alleen in het hoofd van één persoon mag bestaan.
Want een werknemer kan vertrekken.
Een freelancer kan de samenwerking beëindigen.
Een bureau kan verdwijnen.
Een leverancier kan zijn dienst wijzigen.
En het bedrijf moet nog steeds blijven werken.
Technologie moet eigendom zijn van de organisatie, niet van het geheugen van één persoon
Dat is vooral belangrijk bij systemen die gedurende vele jaren zijn opgebouwd.
Als een bedrijf betaalt voor software, moet het niet alleen weten waar de code zich bevindt.
Het moet weten:
- wat het bezit,
- waar het van afhankelijk is,
- wie toegang heeft,
- wie het kan wijzigen,
- hoe het kan worden geïmplementeerd,
- hoe het kan worden hersteld,
- hoe het aan een ander team kan worden overgedragen.
NIST wijst in actuele materialen over due diligence van leveranciers onder meer op herkomst, veerkracht, cyberbeveiligingspraktijken en afhankelijkheden in de toeleveringsketen. Dit laat een bredere richting zien: organisaties zouden steeds vaker niet alleen moeten weten, wie het systeem heeft geleverd, maar ook waaruit het systeem bestaat en welke risico's samenhangen met het onderhoud ervan.
Dat is allang niet meer alleen een onderwerp voor de IT-afdeling.
Het is een onderwerp van bedrijfsrisicomanagement.
Het slechtste moment om je systeem te leren kennen is een storing
Je kunt een paar dagen besteden aan een audit.
Je kunt de documentatie op orde brengen.
Je kunt de afhankelijkheden controleren.
Je kunt de architectuur beschrijven.
Je kunt de toegangen verifiëren.
Je kunt vaststellen wie echt verantwoordelijk is voor de afzonderlijke gebieden.
Je kunt de bus factor verlagen.
Of je kunt wachten.
Tot het moment dat het systeem niet meer werkt.
Dan zullen de vragen precies dezelfde zijn.
Alleen zal de druk groter zijn, zullen gebruikers wachten, kan de verkoop stilvallen en kost elk uur geld.
Daarom is het de moeite waard jezelf één vraag te stellen voordat er een probleem ontstaat: Als morgen de persoon zou verdwijnen die jouw systeem het beste kent, zouden we dan nog steeds weten hoe we het moeten onderhouden?
Als het antwoord "nee" is, betekent dat nog niet dat het systeem slecht is.
Het betekent dat het bedrijf verborgen risico loopt dat het tot nu toe niet hoefde te activeren.
Bij Web24 nemen we niet alleen de code over
Het overnemen van een bestaand project is heel ander werk dan het vanaf nul starten van een nieuw systeem.
Eerst moet je begrijpen wat er al bestaat.
Wat werkt.
Wat kritiek is.
Wat een afhankelijkheid is.
Wat het probleem is.
Wat slechts een overblijfsel is van eerdere beslissingen.
En vooral - waar de kennis zich bevindt zonder welke het systeem niet veilig kan worden doorontwikkeld.
Pas dan kun je verdere stappen plannen.
Soms zal dat modernisering zijn.
Soms groei.
Soms het op orde brengen van de infrastructuur.
Soms het overnemen van het onderhoud.
En soms gewoon het maken van een degelijke systeemskaart, waar niemand jarenlang de tijd voor heeft gehad om die voor te bereiden.
Want een verantwoord softwarehuis zou geen technologie moeten bouwen die alleen werkt wanneer de juiste persoon achter de computer zit.
Een systeem moet groter zijn dan het geheugen van één persoon.
En het bedrijf moet erop kunnen vertrouwen dat wanneer iemand vertrekt, de technologie niet met hem of haar meegaat.
