Je webshop, klantportaal of interne planningstool draait al jaren zonder grote problemen. Eén vaste ontwikkelaar – een freelancer, een medewerker of dat ene kleine bureau – weet precies hoe alles in elkaar zit. Handig, totdat die persoon ineens niet meer beschikbaar is. Door ziekte, een nieuwe baan, een faillissement of simpelweg omdat de samenwerking stopt. Opeens blijkt dat niemand anders weet waar de code staat, hoe je een update uitrolt of welke wachtwoorden waar voor nodig zijn.
In de softwarewereld noemen we dit het busfactor-risico. In dit artikel leggen we uit wat het is, hoe je herkent of jij er last van hebt en wat je eraan kunt doen.
Wat is de busfactor?
De busfactor is een wat luguber, maar duidelijk begrip: hoeveel mensen moeten er uitvallen voordat een project niet meer verder kan? Is het antwoord "één", dan heb je een busfactor van 1. Alle kennis, toegang en verantwoordelijkheid is dan geconcentreerd bij één persoon.
Dat is geen verwijt aan die persoon. Vaak ontstaat het heel natuurlijk: iemand bouwt een systeem, onderhoudt het jarenlang en wordt vanzelf de enige die het echt begrijpt. Maar voor je bedrijf is het een risico dat vergelijkbaar is met het hebben van maar één sleutel van je pand – en die ligt bij iemand anders.
Herken je deze signalen?
Een lage busfactor is niet altijd zichtbaar totdat het misgaat. Let daarom op de volgende signalen:
- Je weet niet precies waar je broncode staat. Staat die in een repository waar jouw bedrijf eigenaar van is, of in het persoonlijke account van de ontwikkelaar?
- Domeinnamen, hosting en externe diensten staan op naam van een ander. Denk aan het hostingaccount, de DNS-beheerder, het e-mailaccount voor transactionele mails of API-sleutels van betaalproviders.
- Er is geen of nauwelijks documentatie. Hoe installeer je het project lokaal? Hoe rol je een nieuwe versie uit? Welke koppelingen zijn er met andere systemen?
- Updates worden handmatig en "op gevoel" uitgevoerd. Als het uitrolproces alleen in iemands hoofd bestaat, kan niemand het overnemen.
- Je stelt vragen en krijgt altijd hetzelfde antwoord: "Dat regelt hij/zij wel."
Herken je twee of meer van deze punten? Dan is het verstandig om er nu actie op te ondernemen, terwijl alles nog goed werkt.
Stap 1: Zorg dat jij eigenaar bent van alles wat van jou is
De belangrijkste stap is ook de meest praktische: zorg dat jouw organisatie de eigenaar is van alle cruciale accounts en bestanden. Concreet betekent dat:
- De broncode staat in een repository (bijvoorbeeld op GitHub, GitLab of Bitbucket) onder een organisatie-account van jouw bedrijf. Ontwikkelaars krijgen daar toegang toe, maar het eigendom ligt bij jou.
- Domeinnamen en hosting staan op naam van je bedrijf, met een zakelijk e-mailadres dat niet aan één persoon gekoppeld is.
- Wachtwoorden en sleutels worden bewaard in een gedeelde, beveiligde wachtwoordmanager waar minimaal twee vertrouwde personen bij kunnen.
Leg ook contractueel vast wie het intellectueel eigendom van de code heeft. Bij maatwerk is het niet vanzelfsprekend dat de opdrachtgever automatisch eigenaar wordt; dat hangt af van de afspraken die je maakt. Twijfel je, laat dit dan juridisch nakijken.
Stap 2: Documenteer wat nodig is – niet meer, niet minder
Documentatie klinkt als een saai en eindeloos project, maar dat hoeft het niet te zijn. Een goede basis bestaat uit een paar onderdelen:
- Een README waarin staat wat het systeem doet, hoe je het lokaal opstart en welke omgevingsvariabelen nodig zijn.
- Een overzicht van de architectuur: welke onderdelen zijn er, waar draaien ze en met welke externe diensten wordt gekoppeld?
- Een uitrolinstructie: hoe komt een nieuwe versie van de code live?
- Een noodprocedure: wat te doen als de site plat ligt, en waar staan de back-ups?
Het doel is simpel: een andere ervaren ontwikkelaar moet binnen redelijke tijd zelfstandig aan de slag kunnen.
Stap 3: Automatiseer terugkerende taken
Kennis die in een geautomatiseerd proces is vastgelegd, kan niet "vergeten" worden. Met een CI/CD-pipeline worden tests en uitrol automatisch uitgevoerd zodra er nieuwe code klaarstaat. Dat verkleint niet alleen de kans op fouten, maar maakt het proces ook overdraagbaar: de stappen staan immers in een configuratiebestand in plaats van in iemands hoofd.
Hetzelfde geldt voor back-ups, certificaatvernieuwingen en monitoring. Hoe meer daarvan automatisch en zichtbaar verloopt, hoe minder afhankelijk je bent van één persoon.
Stap 4: Kies voor gangbare technologie en leesbare code
Een zelfgebouwd framework of een zeldzame programmeertaal kan technisch interessant zijn, maar maakt het lastig om later iemand anders te vinden die ermee overweg kan. Gangbare, goed ondersteunde technologieën en frameworks – met een grote community en actieve ontwikkeling – maken je software een stuk beter overdraagbaar.
Daarnaast helpt het als code volgens vaste afspraken wordt geschreven, met duidelijke naamgeving, geautomatiseerde tests en code reviews. Een tweede paar ogen op elke wijziging zorgt er bovendien voor dat de kennis vanzelf over meerdere mensen verspreid raakt.
Stap 5: Laat af en toe iemand anders meekijken
Een van de meest effectieve manieren om je busfactor te testen, is door een onafhankelijke partij een code- en infrastructuurscan te laten doen. Kan een buitenstaander op basis van de beschikbare informatie het project opstarten, begrijpen en uitrollen? Dan zit je goed. Loopt diegene vast, dan weet je precies waar de gaten zitten – en kun je ze dichten voordat het echt nodig is.
Voorkomen is goedkoper dan redden
Een project overnemen van een ontwikkelaar die niet meer bereikbaar is, is vaak mogelijk, maar kost doorgaans veel meer tijd en geld dan wanneer alles netjes is vastgelegd. Denk aan het terugvinden van toegangsgegevens, het reconstrueren van het uitrolproces en het uitzoeken hoe koppelingen werken. Door nu een paar gerichte stappen te zetten, voorkom je dat je software op een kwetsbaar moment een blok aan het been wordt.
Hulp nodig bij het borgen van je software?
Bij CodeBros helpen we MKB-bedrijven om hun software overdraagbaar, gedocumenteerd en toekomstbestendig te maken. Of het nu gaat om het overnemen van een bestaand project, het opzetten van een CI/CD-pipeline of een onafhankelijke review van je code en hosting: we kijken graag met je mee. Neem contact met ons op voor een vrijblijvend gesprek en ontdek hoe het ervoor staat met de busfactor van jouw software.