Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

WA-verzekering in de cloud

 

Expert

E D
Iets met ICT, nvt. Expert van voor het topic .

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5020126). © Jaarbeurs IT Media.

6,5


Lees meer over


 

Reacties

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:

http://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.



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,

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?

@ 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:

http://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.

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:

http://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?

@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)
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'

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×