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.
Henri,
Leuk dat die organisaties naar jou hebben geluisterd en zich laten verclouden. Een organisatie met gezond verstand gaat eerst verschillende aspecten van deze verandering in een businesscase uiteen zetten en dan pas besluit nemen. In de discussie hierboven hebben we een aantal zaken benoemd maar zeker niet alles. In dit kader als je eerst inzichtelijk maakt welke onderwerpen gerelateerd zijn aan deze verandering (je vertrekpunt, de aard van je organisatie, juridische en technische aspecten etc etc)dan kun je pas meer duidelijkheid krijgen over waar je aan gaat beginnen en of het verstandig is.
De leveranciers van VDI producten zeiden al 10 jaar geleden dat hun VDI product klaar en compleet was. Misschien was hun product klaar en compleet maar niet “geschikt”! Daarom hebben we bij VDI leveranciers (zoals Citrix of VMWare) in de afgelopen jaren verschillende overnames gezien van bedrijven die hun VDI-product “geschikt” kunnen maken.
Hetzelfde moet ook nog verder met cloud gebeuren. Cloud is misschien klaar (is het zo?) maar nog niet helemaal geschikt.
@Felix
Ik moet erg lachen over de SLA’s in de cloud, het gaat 99.999% om inspanningsverplichtingen en maar 0.0001% om een resultaatverplichting. Nu heb ik al gezegd dat de juridische kant van het verhaal niet mijn expertise is maar als ik kijk naar hoe soms de dingen technisch ingevuld worden dan weet ik wel dat het niet lang goed kan gaan.
Er wordt vaak alleen gestuurd op incidents in plaats van events waardoor het dus vooral genezen in plaats van voorkomen is. En met events bedoel ik niet alleen technische meldingen uit de infrastructuur komen want signaal dat provider in financieel zwaar weer zit kan even belangrijk zijn.
Waar het intern nog vaak gaat om People, Processes and Tools gaat moet bij uitbesteding de Lawyer aan dit rijtje toegevoegd worden. En voor IT-regiseurs die zonder enige praktijkervaring of inzicht besluiten nemen ook steeds vaker de curator.
Grappig dat Henri nu wel het fenomeen Shadow IT erkent maar op mijn artikel ‘De schaduwkanten van de cloud’ reageerde met: “Ik vind het een flut artikel waar ergens wel wat klepels hangen, maar geen bellen waar ze inpassen.” Dat lijkt op een voortschrijdend inzicht dat altijd komt als blijkt dat het nieuwe zich toch weer moet onderwerpen aan oude wetten.
Hopelijk dat hij na een dagje in het nuchtere noorden – alleen bij temperaturen onder de nul stijgt daar de gekte – weer met beide benen op de grond staat.
Ik had al wat gezegd over ‘value chains’ want de ‘penny wise and pound foolish’ regel kom ik ook nog vaak tegen in interne IT aangelegenheden waar IT manager budgetgebonden kiest voor oplossingen die gewoon niet passend zijn voor de workload. Besparen met de cloud is net als met virtualisatie een verschuiving in de boekhouding tussen CapEx en OpEx. Zolang IT nog als een costcenter gezien wordt blijft het laveren tussen de (ijs)schotsen.
Dat EXIN een commercieel belang heeft bij nietzeggende certificaten is business as usual waarbij nog weleens opportunistisch ingezet wordt op nieuwe technology. Heb zelf ook de nodige examens gedaan, recentelijk nog twee keer 20 minuten klikken voor TOGAF certificering. Of zo’n papiertje me nu echt een betere architect maakt is net zo twijfelachtig dat een SLA zekerheid geeft over de resultaten in de toekomst.
Bij sommige SaaS oplossingen is de beurswaarde trouwens nog weleens bepalender dan de werkelijk toegevoegde waarde voor het bedrijfsproces maar dat even terzijde.
@ Henri,
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.
Ik wilde eigenlijk niet happen. Maar je haalt wel een punt aan. Want als je er organisatiebreed gebruik van maakt? Zoals een Ahold bijvoorbeeld? Geef je dan de eindgebruikers een zelf-restore functie? En hoe ga je met afdelingsdata om? Dit is wel iets waar je vooraf goed over na moet denken. Bandbreedte moet natuurlijk ook niet vergeten worden. Maar daar heb ik al meer dan genoeg over geroepen en geschreven.
Ik ben erg benieuwd hoe Ahold dit met Google heeft ingericht. Zal Ahold ook geen escrow overeenkomst hebben? En hoe stelt men de data veilig?
Ruud, Google heeft Aapjes (API’s).
Je backup / restore / maatwerk strategie kun je zelf ontwikkelen. Google Admin tools zijn niet sterk genoeg voor de enterprise, maar door de Aapjes kunnen enterprises dit wel zelf regelen (en als dat maatwerk door derden ontwikkelt wordt… Escrow!) En dat is meteen antwoord op je bandbreedte, teamdata en potentiële selfservice .
Eigenlijk is het gewoon IT, maar dan net wat makkelijker. Governance heeft alleen wat extra aandacht nodig 🙂
@Henri Maartwerk geleverd door het Escrow bedrijf, het Escrow bedrijf als software leverancier. Niet het idee wat ik gekregen heb na wat ik gelezen heb. Enne, dat moet je toch zelf kunnen doen? Wel zo prettig.
@Henri Ik denk dat ik het niet goed begrepen heb. Je bedoelt zeker, je laat die software (voor het veiligstellen van de data) maken door een andere partij en laat de software etc neerleggen bij het escrow bureau gedurende de ontwikkeling? Ook voor het geval dat.
Thanks Henri.
Het is mij nu helemaal duidelijk.
@Louis
Escrow, met name de software-versie is een regeling waar de maker (SaaS leverancier) de broncode deponeert bij een derde (escrow-agent) om zeker te stellen dat de gebruiker deze kan onderhouden en gebruiken als de maker ervan failliet gaat.
Zoals reeds gezegd valt data in traditionele regelingen er buiten, deze was altijd in het bezit van gebruiker bij on-premise oplossing. Bij SaaS veranderd dat en SaaS-escrow is een combinatie van software escrowovereenkomst en een technisch/juridische uitwijk, de back-up wordt in dat geval bij een neutrale partij opgeslagen.
Henri brengt met het maatwerk eeen leuke variatie in, je zult daar ook rekening mee moeten houden. misschien een beetje buiten scope van verhaal maar enige tijd geleden was hier een artkel te lezen over open source (drupal), maatwerk en de problemen met migratie. Zie ook mijn reacties:
https://www.computable.nl/artikel/nieuws/ecm/4945814/1277020/drupal-we-schudden-cmsmarkt-op.html
@Ewout Dat zou inderdaad al wat logischer zijn, dat een SaaS leverancier zelf een escrow agent in de arm neemt om daar de broncode neer te leggen. Als garantie voor de klanten ihgv het op de fles gaan. En als de SaaS leverancier de risico’s voor de klant realiseert dan zullen ze ongetwijfeld ook de mogelijkheden bieden om zelf je data veilig te stellen.
Vind het gebruik maken van een escrow agent in de situatie van een software bedrijf dat maatwerk levert al voor de hand liggender.
Wat ik me wel blijf afvragen hoe het in de praktijk gaat werken als de nood aan de man is. Het zal nog een klus zijn om alles weer up en running te krijgen en kennis zal nodig zijn.
@ All,
Heeft er iemand al echte praktijkervaring met bovenstaand?