Regelmatig worden we verrast door discontinuïteit in de digitale dienstverlening, want hoewel we er steeds afhankelijker van worden vergeten we nog dat elke keten zo sterk is als de zwakste schakel. En die schakel is niet altijd technisch, maar is wellicht financieel, want zeker in de Cloud markt zitten veel start-ups die prachtige oplossingen hebben, maar de zaken aan de achterkant niet altijd goed geregeld hebben.
Beloven van continuïteit is makkelijker dan deze waar maken, zeker als voorzorgsmaatregelen nagelaten worden uit kostenoverwegingen. Het investeringsdal voor een uitwijk is soms gewoon te diep en wordt daardoor nog weleens half ingericht. Zeker bij veel SaaS-oplossingen is er nog weleens onduidelijkheid waar de data landt, wie nu precies de eigenaar is van de systemen en hoe de rechten en plichten precies liggen. SaaS-oplossingen worden ook bedrijfskritischer. Het begon met horizontale toepassingen (hr/payroll, boekhouding et cetera) maar breidt zich uit naar de bedrijfs- en branchspecifieke toepassingen (logistiek, onderwijs, gezondheidszorg). Uitval raakt dus al niet meer één afdeling maar de hele business, wat dus niet acceptabel is.
Back-door garanties
Niet zelden maken de SaaS-leveranciers gebruik van IaaS-diensten die geleverd worden door andere partijen. Hierdoor ontstaat een complex juridisch landschap waar ‘back-end agreements’ niet altijd goed geregeld zijn. Kiezen van een cloud oplossing is vanuit technisch perspectief al geen sinecure maar wordt met alle onduidelijkheden in het eigenaarschap nog wat complexer:
1. Eerste-lijns provider levert de functionele service (ip-eigendom)
2. Tweede-lijns provider levert de technische service (hw-eigendom)
3. Derde-lijns provider levert de facilitaire service (dc-eigendom)
Natuurlijk kan met een klassieke escrow-overeenkomst zeker gesteld worden dat de broncode van een SaaS-oplossing beschikbaar komt, maar wat heb je uiteindelijk aan een lege applicatie als je data onbereikbaar bij een derde partij ligt of de kennis ontbreekt om de service te continueren?
Een online dienst is meer dan broncode, zonder hardware heb je er niets aan om over de data nog maar niet te spreken. En een curator kan deze data gijzelen om de schuldeisers te dienen, Nebula-arrest is een achterdeur gebleken om de eventuele escrow- overeenkomst te negeren. Onderbreking van SaaS-dienst bij faillissement is moeilijker te mitigeren dan falende schijven of andere technische ongemakken door de juridische issues die nog vaak vergeten worden.
Garantie tot aan de voordeur
De duivel zit altijd in de details en een escrow-agent kan helpen om deze te identificeren en op te lossen. Er ligt namelijk nog een boa constrictor in het gras als de SaaS-provider de techniek uitbesteed heeft aan een IaaS-provider. Eindgebruiker heeft meestal alleen een cont(r)act met de eerste-lijn en weet vaak niet eens wie de achterliggende providers zijn. Geen ongebruikelijke constructie binnen de lokale markt waar niche spelers het vooral met niche spelers doen. Ook de Dutch Hosting Provider Association laat hier nog veel vrijblijvendheid voor de provider over.
Probleem bij SaaS is dat het niet om een gebruiksovereenkomst voor software gaat, maar om een dienst waarbij de data-opslag is inbegrepen. En dat vergroot dus de afhankelijkheid want data blijft uiteindelijk de belangrijkste asset van een bedrijf. En als een SaaS-provider gebruik maakt van diensten van derden staat aan de onderkant van service keten vaak een ‘databak’ waarbij eigenaarschap van de container wel bekend is, maar wie er allemaal instorten niet. De logische scheiding zit meestal aan bovenkant omdat multi-tenancy in de hele keten een zeldzaamheid is.
Trias politica
Misschien heeft de IaaS-provider de disaster recovery en back-up goed ingericht, iets waarvan je pas echt zeker bent als dit getest is, maar is dit een misplaatste investering als een curator alles stilzet. Het kan handig zijn om daarom de uitwijk te laten landen op een juridisch andere entiteit zodat deze niet gegijzeld kan worden. Replicatie binnen het datacenter is goedkoper dan tussen datacentra en je wilt niet dat jouw data bij de concurrent komt. De escrow-agent kan hier acteren als vertrouwde derde partij, door niet alleen de broncodes te bewaren, maar ook zeker te stellen dat uitwijk voldoende garanties biedt. Want nu ik het over vertrouwen heb, ervaring leert dat controle nog altijd beter is en vreemde ogen dwingen.
Tenslotte kost testen tijd en geld en is het niet moeilijk te raden waar het eerst op bezuinigd wordt als het economisch wat minder gaat. Let wel dat je met een SaaS-escrow uiteindelijk alleen maar tijd koopt want uiteindelijk zul je toch moeten migreren. Misschien zelfs wel heel primitief met steekkarretje een rack te verhuizen naar een ander datacenter.
Belangrijk dat er daarom gedacht wordt aan systeemdocumentatie, wijzigingen en nog wat van die details die vaak vergeten worden. Dat betekent dat de rol van de escrow-agent bij SaaS wat verder gaat dan een kopietje van de software in een kluis leggen. Er moet kennis aanwezig zijn om niet alleen de contracten te controleren maar ook technische inrichtingen en in het uiterste geval zelfs om hele ‘sloepenrol’ ter hand te nemen bij ontscheping als een partij in de lijn failliet gaat.
Titanic
Ook al zie je tot aan de horizon geen ijsberg, het is toch goed om aan reddingsboten te denken want een faillissement kan niet alleen onverwachts zijn maar de impact ervan ook catastrofaal. Nu zijn alle juridische aspecten in dit verhaal niet ‘my cup of tea’ omdat ik meer van de koffie ben, met een wolkje melk. Deze blog is derhalve mede tot stand gekomen in samenspraak met Herman Kui van Escrow4All.
@ Louis,
Dat laatste is zeker het meest belangrijk. En ja in mijn optiek regelt het escrow bedrijf dat.
@ Ewout,
Kan jij hier nog wat meer over roepen?
Hoi Ewout,
Helder artikel en ook best wel actueel. Het roept wel de volgende vragen bij mij op:
– Wat is de winst als je bij het kiezen van een Saas oplossing zoveel zaken moet afdekken/verzekeren?
– Is de winst van een cloud oplossing dan sterk afhankelijk van de grootte van een organisatie en/of de omvang van de data, afgezet tegen eigen beheer?
@ Louis Kossen:
Escrow providers (en andere aanverwante spelers) hanteren geen uniform standaard zoals bij de traditionele broncode escrow. Ieder escrow bedrijf heeft een eigen oplossing/invulling voor SaaS/Cloud. Dat varieert van een juridische uitwijk (‘special purpose entity’ cq stichting), hot/cold standby of ketenintegratie/’keep the lights on’.
In aanvulling op de discussie: In de praktijk is er bij SaaS escrow nooit sprake van one-size-fits-all. Een deskundige escrow provider zal een juiste vertaalslag maken van (business/IT continuity) requirements naar invulling van de escrow regeling. Twee extremen: Eenvoudige SaaS oplossingen moeten – bij deconfiture van de aanbieder – ‘gewoon nog even’ een paar maandjes doordraaien. Als gebruiker behoud je functionaliteit en toegang tot data. Weet de curator geen doorstart te realiseren, dan moet je alsnog definitief migreren. Een ‘basis escrow-tje’ voor mission critical of high exposure SaaS toepassingen zoals internetportalen van overheden zonder enige, grondige verificaties, is als een nieuwe Tesla alleen WA verzekeren.
Wat betreft diep in de keuken kijken, dat is al decennia de habitat van escrow aanbieders, (voor)namelijk het bewaren van software broncode. Integriteit en veiligheid behoren verankerd te zitten in de DNA van professionele escrow aanbieders. Een gezonde portie achterdocht van de SaaS vendor of ISV is eerder welkom dan misplaatst. Diezelfde Tesla breng je voor onderhoud niet naar een buurtgarage.
En mijn ogen is escrow niet per-se technisch of uitvoerend en vooral van toepassing bij een (onvrijwillige) exit. Ofwel op het moment dat een partij (klant of leverancier) zijn verplichting niet na kan komen.
Afhankelijk van de escrow overeenkomst kan het gaan om bepaalde zaken zoals bijvoorbeeld de broncode van de SaaS zodat deze gemigreerd kan worden, of de data voor als deze niet bereikbaar meer is.
Escrow is volgens mij geen actief onderdeel in bijvoorbeeld disaster recovery. Dus als er een ramp gebeurd, dan kan de escrow ervoor zorgen dat je niet alles kwijt bent, maar de procedure om het weer “goed” te krijgen kan gemakkelijk meerdere dagen of weken duren. Dit is niet werkbaar als je SaaS providers een bedrijfkritisch onderdeel bevat.
Duivel zit natuurlijk in de details. Hoe verder een escrow reikt (bijvoorbeeld ook door mee te nemen hoe lang het duurt voordat de escrow effectief word toegepast), hoe duurder het zal zijn. Ook zal een Escrow zeker niet altijd aangeboden worden. Probeer jij maar een escrow overeenkomst met Dropbox te sluiten 🙂
Laat ik daar meteen een voorbeeld van maken.
Je gebruikt de dienst en de tool van Dropbox. Alle data die gebruikers opslaan komt *niet* op servers van Dropbox terecht, maar op servers van een ander bedrijf, namelijk Amazon. Stel dat Dropbox zich niet aan de afspraken houdt met Amazon en Amazon sluit Dropbox af, dan kan zowel Dropbox als de eindgebruikers niet meer bij de data van Amazon. Als je als bedrijf en klant van Dropbox hier niet van bewust bent snap je het probleem.
In Nederland zal een zeer groot deel van de SaaS aanbieders de hardware waarop het draait in datacenters hebben van andere partijen. Leuk als jouw SaaS provider een mooi kenmerk op zijn site heeft staan. Als het datacenter waar de spullenboel staat dat niet heeft….
Dit zijn allemaal zaken waar je als bedrijf mee te maken krijgt als je dingen in de cloud wilt doen. Ja, het is gemakkelijk, Ja het is vaak nog veilig ook, en soms nog goedkoper ook, en ja, je betaald alleen maar voor wat je gebruikt zonder er lang aan vast te zitten (in veel gevallen), maar Nee, als je de hele keten beschouwt en alle dingen die erbij komen kijken blijft het iets wat niet simpel is. Stel je dan altijd af als bedrijf “Wat als….”.
Escrow is dus een mogelijkheid of alternatief en veel breder toepasbaar dan alleen voor SaaS.
Ik ben freelance ontwikkelaar en maak dingen voor klanten, maar hoe krijgen zij zekerheid voor als ik omval of door succes met vervroegd pensioen ga? Juist, Escrow.
@Louis
Hopelijk maakt de uitgebreide reactie van Henri meer duidelijk, je bent bij SaaS vaak van meerdere partijen afhankelijk. Dat kan dus voor vervelende verrassingen zorgen als je een dienst in de cloud gebracht hebt welke belangrijk is voor de bedrijfsvoering.
Migratie uit de cloud is al moeilijk als alles nog werkt maar onmogelijk wanneer niets meer werkt.
@Marianne
Goede vragen maar ik ga ze wel even omdraaien want er zijn veel goede redenen om van de cloud gebruik te maken en maar 1 fout antwoord: kostenverlaging.
Winst van de cloud zit namelijk in snelheid en mobiliteit nog niet in de continuïteit en stabiliteit, zeker niet bij SaaS oplossingen. Meen ergens gelezen te hebben dat Gartner voorspelt dat 25% van de SaaS providers failliet gaat maar weet niet precies of het hier om de ‘gratis’ of betaalde diensten gaat. Of je dat risico wel of niet af wilt dekken is afhankelijk van het verlies dat je hebt als bedrijf niet productief is, 10 of 1000 is niet zo relevant.
Samengevat gaat het om ‘value chains’ en tot op heden zie ik SaaS oplossingen die zich kenmerken als puntoplossing, bij eigen beheer niet veel anders. Hoewel bij faillissement er dan een omgekeerde situatie is omdat systemen het vaak prima doen maar mensen niet meer mogen werken. De andere kant van het verhaal is trouwens faillissementsfraude met de cloud wat hier al eens gepubliceerd is:
https://www.computable.nl/artikel/opinie/cloud_computing/4909606/2333364/cloud-hangt-als-donkere-wolk-boven-bv-nederland.html
Het is jammer dat Henri het met me eens is maar inderdaad zijn datavolumes wel bepalend bij een eventuele migratie uit de cloud. Het ‘pay-per-use’ principe is namelijk net als een ‘one night stand’ want hoe langer de relatie duurt hoe meer zekerheid je wilt hebben.
Het gaat namelijk vaak gewoon om uitbesteding en wat je precies buiten de deur zet is nog weleens de vraag, opmerkelijk vaak blijkt dit namelijk kennis te zijn. En zoals Henri al aangeeft wil je die toch borgen, escrow gaat toch vooral om intellectueel eigendom. Data valt daar dus niet onder en deze valt vaak ook buiten invloed van de SaaS provider.
Henri roept wel iets over veilig maar ik bedenk me dat de (decryptie)sleutels ook niet vergeten moeten worden, Opstelten wil ze graag hebben maar dat lijkt me een slecht idee.
@Ewout,
laatst heb ik zo’n EXIN cloud examen gedaan. De hele examenstof draait toch wel om kostenverlaging als belangrijkste motivatie voor migratie naar Cloud. Opmerkelijk verschil in inzicht. Ook jouw afweging snelheid en mobiliteit tegen continuiteit en stabiliteit. Voor iets waar je waarde aan hecht (je bedrijf ?) lijkt me de keuze snel gemaakt. Het meest interessante aan het artikel vind ik het doorbreken van de wolk mythe ( = Je applicaties draaien ergens en met je veilige thinclient/webbrowser en als klant maak je er gebruik van. Met SLA dek je de risicos af en klaar.)
Dat staat nogal in contrast met jouw verhaal waarin de klant juist (remote) de hele keten in de gaten dient te houden. Juridisch en technisch, want wat heb je eraan als je erbij mag maar niet weet hoe of weet hoe maar niet kan.
en het is helemaal niet jammer dat Henri het vaak niet me je eens is 🙂
@Marianne et al,
Ik stap zo in de auto voor een rit naar de andere kant van het land (so much for cloud…), en wil nog even snel een statement maken.
Ik help organisaties naar de cloud en als ik een organisatie zou starten is er geen haar op mijn hoofd die eraan zou denken om servers te kopen en te hebben, ik zou alles op basis van cloud computing doen.
Laten we dingen niet moeilijker maken dan ze zijn.
Momenteel verkies ik nog steeds de Google Apps boven Office 365. Een organisatie kan geen escrow afsluiten met Google. Maar door bijvoorbeeld een andere SaaS in te schakelen, voor het gemak Backupify genoemd, worden van *alle* gebruiker van een organisatie van Google Apps volledig bruikbare backups gemaakt naar deze dienst. Valt Google om, kan ik bij mijn data. Is Google stuk? kan ik bij mijn data. Gooit een gebruiker zijn data (express) weg, kan ik bij zijn data.
Ruud zal zeggen: Hoe lang duurt het dan voordat je je data terug hebt als je data van 1000 gebruikers terug moet halen? Maar dat terzijde, het gaat om het principe.
Het gaat erom dat je een vorm van controle hebt.
Gebruik je een CRM pakket in de cloud? Zorg dat je exports kan maken in een bruikbaar formaat als onderdeel van je exit strategie. Als je die regelmatig maakt en checkt zit je best goed.
Echter als je als grotere organisatie SaaS van een kleinere organisatie gaat gebruiken, dan is een escrow zeker iets wat in overweging genomen moet worden als er intellect achter de SaaS zit die je niet zo maar kunt overzetten. Als de SaaS provider omvalt heb je in ieder geval een set waarmee je het product opnieuw leven in kan blazen.
Cloud, ofwel online diensten is gewoon IT as usual waarbij een aantal zaken veranderen en shadow it op de loer ligt. Geen rocket science, wel moet je gewoon blijven nadenken.
Besparen met cloud computing is subtiel en zit in andere dingen dan een directe vergelijking. Technisch (en business wise) is het appels met peren en dat is altijd wat lastiger vergelijken. Besparen zou niet het uitgangspunt moeten zijn, dan kom je vaak bedrogen uit. Daarnaast betekent besparen vaak ook dat je *anders* moet gaan werken, is organisatie verandering = pittig.
Escrow heeft een plek en die zou best mogen groeien!
Escrow 3.0, anyone?
@Ewout Door de reacties hier en ook door het artikel over Europe Escrow even terug begin ik het wat te begrijpen denk ik. Wat je grofweg vraagt aan de SaaS leverancier is zijn hele hebben en houden open te gooien en een kopie van de code, data, documentatie bij de het Escrow bedrijf komt te liggen. Voor het geval dat. Het Escrow bedrijf fungeert als een soort kluis. En ik begrijp dat het niet bedoeld is voor een uitwijk bij een technische probleem maar voor het geval de SaaS leverancier niet meer kan leveren.
Mijn idee bij SaaS is dat SaaS zo handig was want je neemt een service af, hebt geen zorg over de achterkant en je hebt eigenlijk geen IT’ers meer nodig (denk dat het wel meevalt overigens). IT met losse handen. Maar met deze constructie wordt het wel degelijk een heel technische verhaal. In gedachte zie ik al software voor me die bv iedere nacht de data en de de meeste recente software en documentatie veilig stelt, van SaaS naar Escrow. Of is dat naief? Vind de vragen van @MarianneDorder dan ook treffend en terecht, is het dan wel verstandig om deze manier voor SaaS te kiezen? Is het middel niet erger dan de kwaal en is software in eigen huis houden dan niet passender. Ik denk ook dat punt 4 van @Reza’s reactie opgaat: denk niet dat SaaS leveranciers hier happig op zijn en terecht. Je zal als SaaS leverancier met iedere klant een Escrow overeenkomt moeten opzetten. Ik denk ook dat je het met de voorwaarden en de SLA van de leverancier hebt te doen. En als het een goede SaaS leverancier is zullen er vast mogelijkheden zijn de data veilig te stellen en als je betaalt is er vast van alles mogelijk om zekerheden te bieden. Kunnen ze dat niet bieden, dan is deze SaaS oplossing niet passend.
En wat ik mis in het Escrow verhaal met het veiligstellen van data, code, documenatie is dat je ook de kennis moet hebben om er mee om te gaan. Die kennis is misschien wel het belangrijkste. Kortom, ik ben niet overtuigd.
In dit geval denk ik, controle slaat dood en is vertrouwen toch beter.