Zin van SaaS- en broncode-escrow

12 februari 2010

Ondanks de recente stabilisatie van het aantal faillissementen in de ICT-markt is het einde nog onzeker. Behalve faillissementen kunnen ook bedrijfsovernames van ICT-leveranciers gevolgen hebben voor het onderhoud van applicaties. Dat maakt de afhankelijkheid van de eindgebruiker van de leverancier pijnlijk duidelijk. Steeds meer eindgebruikers en leveranciers beseffen dat een adequate escrowregeling voor alle partijen van belang is. Maar welke problematiek speelt bij traditionele escrow een rol en waar moet men op letten bij SaaS-escrow? Traditionele software-escrow is immers niet meer voldoende voor een adequate SaaS-oplossing.

Een escrowregeling is zo sterk als de zwakste schakel, want wat is de zin van gedeponeerde broncode als de technische documentatie niet is bijgevoegd? Ontwikkeling van software lijkt op een bouwpakket. Zonder de technische documentatie zijn er duizenden onderdelen terwijl de structuur van opbouw en werking volledig onduidelijk is. Een handleiding om stap voor stap een softwareproduct op te zetten is zeer wenselijk en zelfs een cruciaal onderdeel van de kennisoverdracht, hetgeen nog te vaak wordt onderschat. Een goede escrowregeling heeft de aanwezigheid van relevante technische documentatie hoog op de kwaliteitscheck staan.
Bij het aangaan van een escrowregeling dient men duidelijke afspraken te maken over de deponering- en verificatiefrequentie. Zo worden de laatste updates steeds startklaar gemaakt zodat een compleet en actueel broncodepakket met gebruikershandleiding en andere onmisbare informatie snel kan worden opgeleverd indien er bijvoorbeeld sprake is van het faillissement van de leverancier. Men kan kiezen voor verschillende verificatieniveaus, van standaardverificaties tot aan het compleet laten nabouwen van een systeem en zelfs het testen van het nagebouwde pakket in een onafhankelijke omgeving. Het is goed als leveranciers minstens één keer een volledige compilatie uit laten voeren want de kans is groot dat vroeg of laat een van de eindgebruikers dit zal eisen en dan kan het erg lang duren voor al het materiaal beschikbaar is.

Eindgebruikers vragen vaak om een escrowregeling wanneer zij de indruk krijgen dat het niet goed gaat met de leverancier. Men is vaak te laat als de leverancier in een economische val terecht is gekomen. Niet alleen vergt de opzet van een escrowregeling enige tijd, ook de verzameling, aanlevering en verificatie kan in sommige gevallen enkele maanden in beslag nemen. Bij een verwacht faillissement verlaten de technici vaak als eersten het bedrijf en is er geen prioriteit meer voor een escrowregeling. Een dergelijke regeling moet dus als preventief middel worden ingezet, bij voorkeur als voorwaarde bij het inkoopproces.

Een ander veel gehoord argument is dat de kosten van escrow niet opwegen tegen de baten. Wat eindgebruikers vaak over het hoofd zien is de schade die ze lijden bij het wegvallen van de leverancier. Denk aan de onbereikbaarheid van de eigen organisatie, een verstoord werkproces met samenwerkende partners of klanten en niet-productief personeel. De vraag is dus niet hoeveel het softwarepakket kost, maar welke processen ermee zijn gemoeid en wat de gevolgen zijn bij uitval.

Ook voor leveranciers kan een escrowregeling buitengewoon zinvol zijn. Het is goed voor het bedrijfsimago en de professionele uitstraling wanneer klanten weten dat de leverancier de juiste maatregelen heeft genomen om hun belangen te waarborgen. De leverancier speelt daarmee in op de behoeften van (potentiële) klanten, creëert vertrouwen en dat geeft in sommige gevallen de doorslag voor de klant om zaken te doen. De tijdsinvestering voor de leverancier is minimaal mits de escrow-agent met een vastomlijnd en transparant proces voor broncodebeheer werkt. De leverancier wordt bovendien gestimuleerd om het product goed te documenteren en het eigen bedrijfsproces efficiënter in te richten bij doorvoering van wijzigingen en updates.
Een ander voordeel voor leveranciers is dat de afhankelijkheid van de ‘onmisbare’ ontwikkelaars binnen de organisatie wordt verkleind en eventuele toekomstige juridische conflicten worden voorkomen.

Wat is het voordeel van een derde partij? Er zijn ongetwijfeld leveranciers bereid om de sources af te staan bij een aankomend faillissement. De vraag is of de leverancier daartoe in staat is. Indien de leverancier in betalingsproblemen is gekomen, is het niet in zijn belang om de broncode zomaar af te geven. Bovendien is meer dan de helft van de te verifiëren code incompleet, de technische documentatie is vaak onvolledig of ontbreekt zelfs geheel, omdat dit nooit prioriteit heeft gehad. Bij driekwart van de aanleveringen wordt de contractuele afspraak over termijnen voor aanlevering van het escrow-materiaal (ruimschoots) overschreden.

Soms zijn de kennis en noodzakelijke documentatie verspreid over meerdere technici, om maar niet te spreken over de locaties van de sources, die kunnen in sommige gevallen grensoverschrijdend zijn. En dan hebben we het nog niet eens over de werking van het materiaal.
Daarnaast komt het in de praktijk voor dat leveranciers en eindgebruikers onderling een escrowregeling treffen in bijvoorbeeld SLA’s. Maar wie garandeert een kwaliteitsregeling waarbij de bedrijfscontinuïteit van de eindgebruiker is gewaarborgd? Bij een onderlinge regeling wordt doorgaans niet voorzien in een professionele, objectieve en periodieke beoordeling waarbij updates meegenomen worden in het escrowdepot. Het komt voor dat de eindgebruiker alles laat compileren op een niet onafhankelijk en mogelijk voorgeïnstalleerd systeem zonder dat daarmee rekening wordt gehouden. Een derde, onafhankelijke partij kan het proces bewaken en een objectief inhoudelijk oordeel geven over het te deponeren materiaal.

Door nieuwe diensten zoals SaaS is een traditionele broncode-escrowregeling niet meer voldoende om de bedrijfscontinuïteit van de eindgebruiker te waarborgen. Want wat kan de eindgebruiker doen met enkel geverifieerde sourcecode als de hostingpartij de webdiensten stilzet? Hoe houdt men dan de data beschikbaar? Anderzijds, wat kan de eindgebruiker doen met een hosting/mirror­omgeving bij uitval van de leverancier zonder een bijbehorende broncode-escrowregeling om wijzigingen in de software aan te kunnen brengen?

Vaak wordt gezegd dat ook zonder een goede SaaS-escrowregeling voldoende waarborgen bestaan. Bij het faillissement van een SaaS-dienstverlener vormen immers de klanten een belangrijke inkomsten- en waardebron waardoor het in de lucht houden van de SaaS-diensten voor de curator hoge prioriteit heeft. Dit zou ook gelden voor de samenwerking met de hostingprovider. Daarnaast worden bij een SAS 70-certificering de beheersmaatregelen van organisaties door een externe controleur onderzocht op processen, systemen en procedures. Is dit allemaal dan niet voldoende? Nee, het gerucht van een mogelijk faillissement leidt ongetwijfeld tot vertrek van klanten waardoor inkomsten in korte tijd flink dalen. Bovendien ontbreekt vaak de complexe technische documentatie die de overnemende partij nodig heeft om zonder implicaties voor de eindgebruiker een eventueel gedwongen migratie succesvol uit te voeren. Hierdoor worden de kosten veel hoger en het tijdsbestek langer. SAS 70 is een goede waarborg voor kwaliteitsnormen en een prima meetinstrument om de actuele gezondheid van een organisatie te toetsen. Een SAS 70 is als een uitgebreide inspectie onder de motorkap van de nieuwe auto. Maar of men een vervangende auto krijgt van de garage wanneer deze toch stil komt te staan, is de vraag.

Met een SaaS-escrow wordt geregeld wie daadwerkelijk de betalings- en onderhoudsverplichtingen op zich neemt na een faillissement. Kunnen de gebruikers dan meteen doorgaan? Ligt er een pakket om ogenblikkelijk een doorstart te maken en is dit doorstartpakket met z’n tijd meegegaan? Kan er geverifieerde sourcecode worden afgegeven na uitval van de leverancier? Kortom: kunnen de gevolgen worden opgevangen ná het faillissement en is goed geregeld wie dat dan betaalt?
Een goede waarborg is een regeling die zowel de webdiensten in de lucht houdt als de sourcecode periodiek verifieert en deponeert. Ontbreekt een mirroromgeving, dan dient men deze bij een optimale SaaS-escrowregeling op te zetten.

Bij het elimineren van continuïteitsrisico’s door middel van escrowoplossingen kunnen ook maatregelen worden genomen met betrekking tot bijvoorbeeld fysieke brand- of waterschade bij een hostingprovider. Normaliter heeft de hostingprovider al een uitwijklocatie. Eindgebruikers willen echter zeker weten of de disaster-recovery-oplossingen toegespitst zijn op de eigen situatie. Wordt er periodiek geverifieerd aan de hand van real live testscenario’s door een derde onafhankelijke partij en kan men daadwerkelijk probleemloos overgaan naar een uitwijklocatie zonder verlies van data? Startklare kennis en informatie is noodzakelijk voor doorlopende beschikbaarheid van de infrastructuur, waarbij ook rekening wordt gehouden met eventueel toekomstig onderhoud.

Daarnaast dient een budget beschikbaar te zijn om de hosting/mirroromgeving te onderhouden en te continueren tijdens een vooraf overeengekomen overbruggingsperiode. Men kan met een escrow-agent afspreken dat hij de betalingsverplichting tijdelijk overneemt. Veel SaaS-leveranciers willen echter niet een jaarlijkse premie betalen die verdampt, zoals bij een ziektekostenverzekering als je niet ziek bent. De betaalde premie ziet men niet meer terug. Er is een andere oplossing waarbij de SaaS-aanbieder flink kan besparen. De leverancier definieert samen met de escrowdienstverlener een voldoende budget om bij faillissement of een andere afgiftegrond een vooraf bepaalde periode te kunnen overbruggen door dit budget beschikbaar te stellen via een stichting. Dit budget wordt aangewend voor continuïteitsdoeleinden van de aangesloten eindgebruikers, zoals het doorbetalen van de rekeningen aan de hostingpartij en eventuele betrokken derde partijen die de hardware verhuren. De escrowdienstverlener verifieert periodiek of alle processen en producten de benodigde continuïteit waarborgen. Daarbij wordt periodiek getoetst of de hoogte van het budget nog steeds toereikend is, de omstandigheden kunnen immers veranderen.

Daarnaast betaalt de leverancier de gebruikelijke kosten per jaar aan de escrowdienstverlener, afhankelijk van het aantal eindgebruikers. Zodra die jaarlijkse kosten bij elkaar opgeteld het eenmalig betaald budget hebben bereikt, wordt het eenmalig betaald budget teruggestort naar de leverancier tenzij een van de afgiftepunten is opgetreden. Het is een makkelijk en transparant proces dat op korte termijn kan worden opgezet. Deze oplossing geeft de hoogste zekerheid tegen de laagste kosten.

Quirien van Ojen is directeur van Save Source B.V. (www.savesource.nl).

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!