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.
Ewout,
Mooi artikel, goed geschreven, toegankelijk en zeker een andere schrijfstijl dan wat we van je gewend zijn.
Ik zat 1,5 jaar geleden in mijn artikel aan de rol van escrow-agent te denken. Ik heb het toen Nationale Business Garantie(NBG)genoemd:
https://www.computable.nl/artikel/opinie/cloud_computing/4573553/2333364/klant-kan-gevaar-zijn-voor-cloudleverancier.html
1- Escrow zou meer zekerheid bieden als je van een cloudoplossing gebruik maakt. Daarom is het zeer belangrijk om de kosten hiervan in je initiële businessplan mee te nemen als de overstap naar Cloud gedreven is door “kostenreductie” tov huidige situatie.
2- In het geval van uitwijk en escrow moet je het effect en de kosten in de hele keten bekijken/berekenen. Beschikbaar stellen van een dienst is niet alles. Hoe zit het met de onderliggende relaties en verwevenheden (tussen je overige (SaaS)applicaties, tussen je lokaties etc) ? Is het mogelijk om die ook te testen? Zijn deze kosten ook meegenomen in je escrow?
3- Weet je het zeker dat een SaaS provider akkoord gaat met de test? Een SaaS oplossing is een dienst die in de meeste gevallen gemaakt is voor meerdere klanten (dus niet alleen voor jou). Is de oplossing geschikt voor een uitwijk test als er meerdere klanten gebruik van maken? Of moet je toch een maatwerk aanschaffen?
4- Ik vraag me af of SaaS leveranciers akkoord gaan met zoveel ruimte die escrow-agent nodig heeft om diep in hun keuken te kijken.
Ewout,
Zeer interessant artikel waarvoor dank.
Reza,
Je haalt zeer valide punten aan.
Over punt 4 heb ik net als jij ook mijn twijfels. Mijn ervaring is dat ze meestal niemand in hun eigen keuken laten kijken.
Ewout dank voor je voortreffelijke verhaal.
Ook ik maak mij wel eens zorgen om de toekomst van sommige dienstverleners waar toch wel wat mensen van afhankelijk zijn.
Een hiaat zie ik toch in je artikel.
Ik (als random bedrijf) stap over om SaaS omdat ik de ballen verstand heb van de onderliggende technologie. mijn specialisatie is verkoop van bloemen, bemiddelen in hypotheken of wat dan ook… in ieder geval geen ict.
Wat schiet ik er mee op om me in SaaS te storten als ik alsnog noodscenario’s (reddingsboten) moet gaan inbouwen?
Zou ik die opdracht niet gewoon bij de SaaS-leverancier moeten kunnen neerleggen? Dat zul je vast geen goed idee vinden, maar wat dan?
Het probleem is dat grote van een bedrijf (Google, Microsoft) geen garantie biedt.
Immers mijn digitale geDRMde muziek die ik bij Microsoft kocht is ook verdwenen.
Reza,
The proof is in the pudding!
Hoewel Rob Geus van de Smaakpolitie wat overdreven is, kun je vierde punt natuurlijk ook omdraaien. Want waarom zou je niet in de keuken laten kijken als het allemaal prima op orde is?
Ewout, wat een heerlijk artikel en ik ben het er eigenlijk gewoon mee eens.
En juist als je je zaakjes op orde hebt dan WIL je dat er in je keuken gekeken word, want dat is juist goede marketing en betekent dat je snapt wat je aan het doen bent.
Ik moet eerlijk zeggen dat ik weinig ervaring met escrow heb anders dan dat ik mijn geld daar parkeer als ik zaken over het internet doe (freelancers inhuur, spulletjes koop, et cetera).
Het blijft uitdagend om dit goed op poten te zetten en de vraag is dan ook wat het gaat kosten, complexe zaken zijn vaak duur. Uiteraard kun je stellen: Wat kost het als je het niet doet?
Laatst was er een programmeur die als extra handjes aan het team werd toegevoegd omdat ie zo betaalbaar was. Totdat hij schade maakte die verder ging dan een paar jaarsalarissen, toen was het ineens wat minder goedkoop 🙂
Als je denkt dat een professional duur is, probeer dan eens een amateur!
Gelukkig zijn niet alle diensten bedrijfskritisch.
En dan het dilemma. Als je zaken doet met de grote jongens is de kans op escrow laag. Doe in ieder geval een risico analyse en werk vooraf aan een exit strategie.
Een dienst met escrow krijgt dan uiteraard de voorkeur voor een dienst zonder, als je niet kunt voorkomen, moet je toch genezen…
Maar nogmaals petje af voor je artikel: Een blijvertje.
Henri, Ewout en Reza die het met elkaar eens zijn.
Ik zeg, dat moet gevierd worden met een Computable Expert-borrel.
Dus @redactie wanneer staat er weer een expertsessie gepland?
@Pascal
Betreffende vraag of je alles niet gewoon bij een SaaS-provider neer kunt leggen moet ik denken aan de slager die zijn eigen vlees keurt. Als ik me niet vergis vinden we dat geen goed idee omdat ons dan knollen verkocht worden hoewel de meesten het verschil toch niet zien en vertrouwen op het etiket. Nu plakken velen zich door het gemak van de cloud het etiket van it-regiseur op, alsof je bankier bent wanneer je het bedrijfskapitaal op een IceSave-rekening kunt parkeren.
Naar de cloud gaan is tenslotte net zo makkelijk als geld storten op een rekening alleen is het eraf halen heel wat moeilijker wanneer provider failliet gaat, zeker als het de achterliggende provider is die de data bewaard en wat ik beschrijf gaat dan ook meer om een ‘stresstest’ dan een garantiefonds.
Toch een paar vragen na het lezen van het artikel. Wat me niet helemaal duidelijk is, zorgt het escrow bedrijf voor een uitwijkscenario mocht je SaaS-applicatie uit de lucht vallen? Verder lijkt me, als je zaken doet met een SaaS-leverancier, dan hoef je je toch geen zorgen te maken wat er aan de achterkant gebeurt?
@ Louis,
” Verder lijkt me, als je zaken doet met een SaaS-leverancier, dan hoef je je toch geen zorgen te maken wat er aan de achterkant gebeurt?”
Ja en nee. Bij eventuele uitdagingen zoals Ewout al aanhaalt is het wel erg handig om te weten uit welke partijen de keten bestaat.
@Ruud Ik vind het nogal gezocht. Natuurlijk moet je nadenken als je besluit om bedrijfskritische via SaaS afneemt over het scenario dat de SaaS provider uit lucht valt. Het veilig stellen en het in eigen handen hebben van je data lijkt me belangrijk al begin je zonder een applicatie natuurlijk ook niets.
Het uitvallen van de achterkant lijkt me inderdaad iets voor de SaaS leverancier en bovendien, we hebbe het over Cloud applicaties dus de SaaS leverancier zou het even makkelijk naar een andere leverancier kunnen omzetten? Tenminste… Als de SaaS provider zelf failliet gaat dan heb je wel een probleem en vooral een accuut probleem.
Ik kan het nog niet helemaal volgen, want zorgt het escow bedrijf er nu voor dat in geval van problemen dat je weer zo snel mogelijk up en running bent? Want dat lijkt me het belangrijkste, dat je door kan. Met al je data als het even kan.