Heel veel software wordt min of meer gezien als een ‘levend product’. Software behoeft daarom onderhoud, deels met het oog op het wegwerken van bugs, deels met het oog op aanpassing aan nieuwe omstandigheden en nieuwe wensen van de gebruikers. Software die niet onderhouden wordt, dreigt niet zelden te verworden tot een verweesd product. In meer positieve termen: goed en gedegen onderhoud van software draagt bij aan de verduurzaming van het werk.
Onderhoudscontracten
In de contractpraktijk tussen softwareleveranciers en afnemers spelen onderhoudscontracten al decennialang een belangrijke rol. Goede afspraken over onderhoud hebben oog voor belangen van de gebruiker – bijvoorbeeld volstrekt legitieme belangen op het vlak van gebruikscontinuïteit – en belangen van de leverancier. Zo zie je onder meer dat softwareproducenten die een commercieel ‘dood paard’ moeten onderhouden, niet zelden een geringe bereidheid hebben om kostbaar en verkwistend onderhoud te verrichten. Het opstellen van een goed onderhoudscontract dat recht doet aan alle belangen, is daarom geen sinecure. Dat vraagt niet alleen inzicht in de wettelijke spelregels rondom onderhoud, bijvoorbeeld vastgelegd in de Auteurswet, maar ook is inzicht in product- en marktontwikkelingen van wezenlijk belang. Bekend is dat goed softwareonderhoud in de praktijk dikwijls sterk afhankelijk is van de grootte van de ‘installed base’. Als er meer afnemers en gebruikers van het softwareproduct zijn, dan is de kans op adequaat en duurzaam onderhoud groter.
Klassieke benadering
Bij het maken van – wat ik noem – klassieke softwareonderhoudscontracten wordt veelal aangeknoopt bij een traditionele driedeling van onderhoudsvormen. Sinds jaar en dag pleegt de IT-industrie in onderhoudscontracten onderscheid te maken tussen correctief onderhoud (= het herstellen van gebreken, stroringen en bugs), preventief onderhoud (= het voorkomen van storingen) en vernieuwend onderhoud (= het ontwikkelen van nieuwe functionaliteit of nieuwe versies van een softwareproduct). Zo’n klassieke benadering tref je bijvoorbeeld aan in de veelgebruikte ICT-inkoopvoorwaarden van de rijksoverheid, genaamd ARBIT 2016. Ook veel softwareleveranciers onderkennen in hun onderhoudscontracten deze categorisering.
Op het eerste gezicht lijkt met deze categorisering niets mis. Feit is wel dat zij inmiddels niet meer in de pas loopt met meer eigentijdse ontwikkelingen op het vlak van softwareontwikkeling, onderhoud en ICT-beheer. Tegenwoordig wordt steeds meer software ontwikkeld op basis van een Agile-methode, zoals Scrum of XP (Extreme Programming). In dat kader zie je steeds vaker dat het onderhoud van software van meet af aan onderdeel wordt gemaakt van een Agile-ontwikkelaanpak. Anders gezegd: de grenzen tussen het bouwen van software, het onderhouden en het beheer ervan vervagen daarmee.
DevOps
Men spreekt in dit verband wel van DevOps, een samentrekking van ‘developer’ en ‘system operator’. DevOps staat in softwareland steeds breder in de belangstelling. De meer klassieke driedeling van onderhoud doet – volgens de moderne inzichten van DevOps – kunstmatig en geforceerd aan en is in zichzelf een bron van juridische conflicten. Dat geldt zeker voor software die in een steeds meer service-georiënteerde IT-omgeving wordt aangewend. Een harde cesuur tussen bouw, onderhoud en beheer levert in zo’n omgeving al snel forse teleurstellingen op.
Mijn indruk is dat veel softwarecontracten die tegenwoordig gesloten worden, nog maar weinig rekening houden met DevOps. Dat is overigens niet onbegrijpelijk. Voor menigeen is het maken van bijvoorbeeld een goed Scrum-contract voor de bouw van software al een hele opgave, bijvoorbeeld omdat nieuwe soorten garantiebepalingen verlangd worden. Een voorbeeld daarvan is de zogeheten ‘velocity-garantie’, een clausule in het Scrum-contract waarin afspraken over de ontwikkelsnelheid met betrekking tot de software worden vastgelegd.
Een passend DevOps-contract gaat echter nog een stap verder dan een Scrum-contract. Een DevOps-contract biedt een stelsel van afspraken die – in beginsel – alle stadia van de levenscyclus van het betrokken softwareproduct – architectuur, ontwerp, ontwikkeling, operationeel gebruik, onderhoud en beheer – betreffen. Zo is bijvoorbeeld de positie van een helpdesk in een DevOps-contract doorgaans een andere dan in een klassiek ‘maintenance & support-contract.’
Bij het opstellen van een goed contract moet met die verschillen rekening worden gehouden. Dat vereist bij de makers van softwarecontracten een open oog voor nieuwe ontwikkelingen zoals DevOps. De ICT-contractpraktijk staat in dit opzicht voor nieuwe uitdagingen. Met verouderde ICT-contracten die teruggaan op denken uit de vorige eeuw komt u er tegenwoordig niet meer.