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
Idee van zelf veiligstellen van je data is leuk maar niet altijd mogelijk om verschillende redenen welke soms gewoon organisatorisch van aard zijn, SaaS gaat tenslotte om het uitbesteden van dit soort zorgen. Opmerking van Henri dat SaaS uiteindelijk ook gewoon IT is ligt dichter bij de waarheid dan hij meestal wil toegeven, het gaat uiteindelijk om beheer en of dat makkelijker is in de cloud is misschien discutabel. Maar misschien geeft rapport van Forrester aangaande data herstel bij enkele bekende (grote?) SaaS oplossingen wat meer duidelijkheid:
http://spanning_static.s3.amazonaws.com/website/PDFs/ForresterReportBack_Up_Your_Critical_Clo.pdf
@ Ruud:
Er is al echte praktijkervaring.
In januari 2013 heeft Rolf Zaal van AutomatiseringGids uitgebreid beschreven hoe een SaaS escrow in de praktijk werkte; niet op papier/fictief, maar in het ‘echt’.
Naast deze case hebben wij bij Escrow4all nog andere praktijkervaring mogen opdoen (effectuering van SaaS escrow regelingen vanwege faillissement SaaS vendor).
Zoals met andere onderwerpen is er in de media doorgaans meer aandacht voor zaken die misgaan dan voor zaken die vlekkeloos verlopen.
@Ewout En zo komen we toch weer terug op het de vraag hoe gemakkelijk SaaS wel niet is voor de klant. Als je dan helemaal ‘ontzorgt’ wil worden dan leg je ook het veiligstellen van je data bij de escrow agent neer. Maar dat veronderstelt technische kennis voor uitvoering hiervan bij de escrow agent. Voor het veiligstellen en weer opbrengen in een noodgeval.
Gaat het om een nieuw bedrijf dat vanaf nul begint dan kan ik me voorstellen dat het invoeren van een SaaS eenvoudiger is. Maar in een lopende situatie krijg je op zeker te maken met het omzetten van een bestaande situatie en waarschijnlijk ook nog koppeling met reeds aanwezige systemen. Dat lijken me allemaal technische exercities, ik denk dat eigenlijk dat je daar helemaal niet aan ontkomt.
Nog een toevoeging. Het veiligstellen van de code lijkt me ook iets gemakklijk gezegd dan gedaan. Het is niet alleen code dat een applicatie maakt maar ook de tools (bv database) en os waar gebruik van gemaakt. Kan me voorstellen dat je dan met licenties te maken krijgt. Kom ik toch weer uit mijn opmerking eerder: is het middel niet erger dan de kwaal. Buiten dat lijkt me de escrow oplossing iets voor kapitaalkrachtige klanten.
Louis, Escrow is geen WA verzekering, maar meer huwelijkse voorwaarden. Ze zijn alleen van toepassing bij een scheiding.
Als kleine partij is het soms een mogelijkheid om met een grote klant zaken te doen omdat je blijkbaar een bepaalde waarde hebt voor dat bedrijf. Die wil een stukje zekerheid en heeft daar ook geld voor over.
Je moet een escrow niet moeilijker maken dan het is. Code versioning en een goede deployment instructie die ook periodiek getest wordt zou voldoende moeten zijn om in geval nood verder te kunnen gaan. Alle randzaken er omheen zie je ook bij disaster recovery. Het hoeft niet perfect te zijn, maar workable.
@ Herman,
Dank voor de toelichting. Ik ga het artikel zeker even lezen.
@Louis
Het zal nu toch wel duidelijk zijn dat ontzorgen meer marketing is dan realiteit, carpe diem wordt al gauw carpe doom als je zorgeloos de cloud in gaat. Stellen dat het middel erger is dan de kwaal lijkt me echter onjuist want hoewel het om immateriële goederen gaat vertegenwoordigen deze meestal wel een economische waarde. Simpel gezegd is er sprake van een ondernemingsrisico wat je wel of niet af wilt dekken, net als dat je niet van alles een back-up hoeft te maken.
@Henri Je zegt niet moeilijker maken dan het is, plaatsen software bij de escrow agent, maar eigenlijk zeg je ook breng maar een schaduw systeem op. Om zeker te weten dat het goed is. Ik denk, dat is niet zo triviaal.
@Ewout Klinkt mij meer als afkopen van onzekerheid maar ik ben wel benieuwd of er praktijkgevallen zijn van het opbrengen van software door de escrow agent.
Ik moet zeggen, ik bekijk het puur vanuit een technisch standpunt maar ik begrijp ook dat het over juridische zaken gaat. Die kan ik in het geheel niet overzien. Als het om techiek gaat, dan is het aan de afnemer om de risico’s te realiseren en de maatregelen te nemen. In het geval van een failliet van de leverancier mag je hopen dat je bijtijds dat in de gaten hebt en maatregelen kan nemen.
Die cloud, het is me wat.
Ewout,
Ik zag nu pas je artikel. Omdat je de DHPA noemt wil ik nog even reageren:
De DHPA heeft een service escrow regeling ontwikkeld voor ISV’s / stack owners, samen met ICTrecht. Een goed doordachte juridische en technische constructie waarmee afnemers van hostign continuïteit kunnen regelen voor hun dient(en). ICTrecht heeft overigens ook een escrow regeling ontwikkeld voor falende afnemers (de stack /de data moeten bijv beschikbaar blijven ondanks bijv faillissement van ISV of klant ) Details vind je op onze site (ik kan geen linkje plaatsen)
http://www.dhpa.nl -> vertrouwen -> rechtsboven “escrow”
https://www.dhpa.nl/vertrouwen-escrow.html
Michiel,
Ik noem DHPA zijdelings, naar mijn opinie lieten jullie nog veel vrijheid aan de provider over. Hoewel sommige providers het perfect geregeld hebben zijn er helaas ook bedrijven waar het net wat minder is. En natuurlijk is niet iedereen deelnemer, SaaS markt is net het ‘Wilde Westen’