Het is een bekend verhaal. Jaren geleden liet een bedrijf een maatwerkapplicatie bouwen: een klantportaal, een planningstool of een koppeling tussen webshop en boekhouding. De software doet zijn werk, iedereen is eraan gewend en er wordt weinig over nagedacht. Tot het moment dat er iets moet veranderen. De ontwikkelaar blijkt niet meer bereikbaar, niemand weet waar de broncode staat en de server draait op een account waarvan niemand het wachtwoord heeft.
Dan blijkt dat de software die het bedrijf draaiende houdt eigenlijk een zwarte doos is. Het goede nieuws: met een paar heldere afspraken en gewoontes voorkom je dat.
Wat bedoelen we met een zwarte doos?
Software is een zwarte doos als je wel ziet wat hij doet, maar niet weet hoe, waar of door wie. Signalen zijn bijvoorbeeld:
- Er is maar één persoon, intern of extern, die de applicatie echt kent.
- Je weet niet precies waar de broncode staat of wie daar eigenaar van is.
- Er is geen documentatie of erger, die is jaren oud.
- Wijzigingen worden direct op de live server gedaan, zonder versiebeheer of testomgeving.
- Je weet niet welke externe diensten, licenties of API-sleutels de applicatie gebruikt.
- Updates van het framework of de server worden al lange tijd uitgesteld omdat "het werkt nu toch".
Herken je een paar van deze punten? Dan is het verstandig om er nu iets aan te doen en niet pas als er iets misgaat.
Waarom dit een bedrijfsrisico is
In de IT wordt soms gesproken over de bus factor: hoeveel mensen moeten er uitvallen voordat een project vastloopt? Bij veel MKB-applicaties is dat getal één. Dat is kwetsbaar om een aantal redenen:
Continuïteit. Als de enige persoon met kennis vertrekt, ziek wordt of zijn bedrijf stopt, sta je stil. Zelfs kleine aanpassingen of storingen worden dan ineens een groot probleem.
Veiligheid. Software die niet wordt onderhouden, loopt achter met beveiligingsupdates. Hoe langer je wacht, hoe groter en risicovoller de inhaalslag wordt.
Afhankelijkheid. Als alleen jouw leverancier weet hoe het werkt, onderhandel je niet vanuit een sterke positie. Overstappen of een tweede partij inschakelen wordt duur en lastig.
Doorontwikkeling. Een nieuwe ontwikkelaar moet eerst uitzoeken hoe alles in elkaar zit voordat hij iets kan verbeteren. Dat kost tijd en geld, en dat had je deels kunnen voorkomen.
Zo houd je de regie
1. Zorg dat je eigenaar bent van de broncode
Leg contractueel vast dat de broncode van jouw maatwerkapplicatie van jou is of dat je er in ieder geval onbeperkt toegang toe en gebruiksrecht op hebt. Laat de code in een repository staan (bijvoorbeeld op GitHub, GitLab of Bitbucket) onder een account of organisatie waar jij zelf toegang toe hebt. Zo kun je altijd een andere partij inschakelen als dat nodig is.
2. Beheer je eigen accounts en toegang
Domeinnaam, hosting, DNS, e-mailservices, betaalproviders, API-sleutels: zorg dat deze accounts op naam van je bedrijf staan en dat je zelf kunt inloggen. Je leverancier kan prima meewerken via een eigen gebruikersaccount, maar de sleutels van het pand horen bij jou. Gebruik een wachtwoordmanager om toegangsgegevens veilig en centraal te bewaren.
3. Vraag om documentatie die ertoe doet
Documentatie hoeft geen boekwerk te zijn. Het belangrijkste is een beknopt overzicht met daarin:
- Hoe je de applicatie lokaal installeert en draait;
- Hoe er naar productie wordt uitgerold;
- Welke externe diensten en koppelingen er zijn;
- Waar back-ups staan en hoe je ze terugzet;
- Welke keuzes er in de architectuur zijn gemaakt, en waarom.
Een goede README en een paar korte beschrijvingen van belangrijke beslissingen helpen een nieuwe ontwikkelaar al een heel eind op weg.
4. Werk met versiebeheer, tests en een vaste uitrolstraat
Wijzigingen horen niet rechtstreeks op de live server gemaakt te worden. Met versiebeheer (Git) zie je wie wat wanneer heeft aangepast. Met een testomgeving en geautomatiseerde tests merk je problemen voordat je gebruikers ze merken. En met een geautomatiseerde uitrol (CI/CD) is het uitrollen van een nieuwe versie een herhaalbaar proces en geen handwerk dat alleen één persoon beheerst.
5. Kies voor gangbare technologie
Hoe exotischer de gebruikte technologie, hoe kleiner de groep ontwikkelaars die ermee overweg kan. Veelgebruikte, goed onderhouden frameworks met een grote community, zoals Laravel, Vue of React, maken het makkelijker om later hulp te vinden. Dat is geen garantie, maar het verkleint je afhankelijkheid van één specifieke persoon of partij.
6. Plan structureel onderhoud
Software veroudert, ook als je er niets aan verandert. Frameworks krijgen nieuwe versies, oude versies krijgen op een gegeven moment geen beveiligingsupdates meer en servers moeten bijgewerkt worden. Door onderhoud in te plannen, bijvoorbeeld met een onderhoudscontract of vaste uren per maand, voorkom je dat je na een paar jaar voor een grote en dure inhaalslag staat.
Al een zwarte doos in huis? Begin met een audit
Heb je nu al software waar je weinig zicht op hebt? Dan is een technische audit of code review een logische eerste stap. Daarbij brengt een ontwikkelaar in kaart hoe de applicatie in elkaar zit, welke versies er gebruikt worden, waar de risico's zitten en wat er nodig is om weer grip te krijgen. Op basis daarvan kun je gericht beslissen: doorontwikkelen, stap voor stap moderniseren of op termijn vervangen.
Tot slot
Goede software is niet alleen software die werkt, maar ook software die je kunt blijven beheren, aanpassen en overdragen. Met eigenaarschap over code en accounts, beknopte documentatie, een professionele werkwijze en structureel onderhoud houd je zelf de regie, ongeacht wie er aan de knoppen zit.
Twijfel je of jouw applicatie een zwarte doos is geworden, of wil je een bestaande applicatie laten doorlichten? Neem contact op met CodeBros. We brengen de situatie helder in kaart en helpen je met een concreet plan om weer grip te krijgen op je software.