Een standaardpakket werkt zichzelf bij: de leverancier brengt een nieuwe versie uit en elke klant krijgt die vanzelf. Maatwerksoftware heeft die leverancier niet. Er is een ontwikkelteam dat de applicatie voor jou heeft gemaakt, en alles wat daarna nodig is, van beveiligingsreparaties tot nieuwe functionaliteit, moet worden ingericht en belegd.
Kan maatwerksoftware dan automatisch updates ontvangen? Technisch wel, en voor een flink deel is dat ook verstandig. Maar de vraag die er meer toe doet: wie is er na de oplevering verantwoordelijk voor dat je applicatie veilig, stabiel en bij de tijd blijft?
Waar updates bij maatwerk vandaan komen
Elke maatwerkapplicatie steunt op bouwstenen van anderen: frameworks, bibliotheken, de programmeertaal, de server waarop alles draait. Voor die bouwstenen verschijnen doorlopend nieuwe versies, vaak met reparaties voor beveiligingslekken. Daarnaast verandert de applicatie zelf: fouten worden opgelost, functionaliteit komt erbij, een koppeling met een ander systeem wijzigt.
Bij een SaaS-pakket voert de leverancier al die wijzigingen ongevraagd door, op zijn moment en op zijn manier; hoe dat uitpakt beschrijven we in het verschil tussen maatwerk-webapplicaties en SaaS-oplossingen. Bij maatwerk verschijnen nieuwe versies van de bouwstenen wel vanzelf, maar het beoordelen, testen en doorvoeren ervan gebeurt niet uit zichzelf. Dat werk moet ergens belegd zijn.
Technisch kan er veel automatisch
Draait je applicatie als webapplicatie op een centrale server, dan werkt iedereen automatisch in de nieuwste versie; niemand installeert zelf iets. Een nieuwe versie kan zonder onderbreking live worden gezet, ook onder werktijd. En het signaleren van nieuwe versies van frameworks en bibliotheken is goed te automatiseren: het systeem meldt zelf wat er klaarstaat.
Wat wij afraden, is die updates ook ongezien laten installeren. Een nieuwe versie van een bouwsteen kan gedrag veranderen of botsen met de rest van je omgeving, en anders dan bij een pakket met duizenden gebruikers is er niemand die het probleem eerder tegenkwam dan jij. Tussen signaleren en live zetten hoort daarom een menselijke stap: een ontwikkelaar beoordeelt de wijziging, test die in een testomgeving en zet hem daarna gepland op productie.
Zonder afspraak is niemand verantwoordelijk
Opgeleverde software is niet af. Bouwstenen verouderen, beveiligingslekken worden ontdekt, browsers en gekoppelde systemen veranderen. Organisaties die daar niets over afspreken, merken dat meestal pas wanneer iets stilvalt of een lek het nieuws haalt. Stel de vraag daarom aan het begin van elk traject: wie bewaakt de applicatie, wie beoordeelt en test updates, wie voert ze door, en hoe snel wordt er gehandeld bij een acuut beveiligingslek?
Zo ziet een onderhoudsafspraak eruit
Een goede onderhoudsafspraak maakt die verantwoordelijkheid concreet. Een voorbeeld van wat erin staat:
- Monitoring: de applicatie en de onderliggende servers worden doorlopend bewaakt, zodat een storing opvalt voordat gebruikers hem melden.
- Een vaste updateronde, bijvoorbeeld maandelijks, waarin nieuwe versies van frameworks en bibliotheken worden beoordeeld, getest en doorgevoerd.
- Beveiligingsreparaties buiten die ronde om, zodra een kwetsbaarheid daarom vraagt.
- Elke wijziging eerst naar een testomgeving, daarna in een afgesproken venster naar productie.
- Een vast aanspreekpunt en heldere reactietijden bij storingen.
Met zo’n afspraak is automatisch updaten geen risico maar een werkwijze: het signaleren en uitrollen is geautomatiseerd, het beoordelen en testen blijft mensenwerk. En jij weet vooraf wat het kost en wie je belt als er iets is.
Draait er bij jou een applicatie waarvan niemand precies kan zeggen wie de updates doet? Voer dat gesprek liever nu dan na de eerste storing. Onze engineers monitoren, onderhouden en verbeteren maatwerkapplicaties, ook software die door een ander bureau is gebouwd. Wat zo’n onderhoudsafspraak inhoudt, lees je bij doorontwikkeling en beheer.