Voor Software as a Service

Transcriptie

1 Wednesday 27 October 2010 Product Software BEDRIJFSCONTINUÏTEIT Voor Software as a Service Door: Tommy van de Zande 1/33

2 Agenda Waarom sta ik hier? Onderzoek Wat verstaan we onder Bedrijfscontinuïteit Software Escrow Verschillen bij SaaS Hoe ziet een SaaS-continuïteitsregeling er uit? SaaS Escrow Garantiefonds Vergelijking Enquête uitslagen 2/33

3 Waarom sta ik hier? Afgelopen jaar bachelorscriptie geschreven over Business continuity with SaaS Onder begeleiding van Slinger Waarom dit onderwerp? Raakt direct met zowel IT als Business Zeer relevant voor bedrijven en dus praktisch nut Tot nu toe weinig aandacht voor dit onderwerp, zowel in de wetenschap als in het bedrijfsleven. 3/33

4 Onderzoek Geen voorafgaande papers: exploratief onderzoek State-of-the-art beschrijving van het probleem en de (mogelijke) oplossingen Werkwijze: Literatuurstudie Interviews met experts uit productsoftware industrie Enquête onder SaaS-klanten en aanbieders 4/33

5 Onderzoek Beperkingen Te weinig tijd om alle onderdelen volledig uit te zoeken Beperkt aantal interviews Beperkt aantal respondenten op enquete Vooral de (on)mogelijkheden van een SaaS garantiefonds kunnen nog veel verder onderzocht worden. Resultaat: Paper waarin het probleem wordt aangekaart en mogelijke oplossingen worden geboden. Artikel in het IT vakblad Automiseringsgids. 5/33

6 Bedrijfscontinuïteit Bedrijfscontinuïteit gaat over het (succesvol) voortzetten van de (bedrijfs-) activiteiten Bedrijven zijn daarvoor steeds vaker afhankelijk van software Er moet dus goed nagedacht worden over die afhankelijkheid Denk aan (de afhankelijkheid van) ERP-systeem CRM-systeem Kassa software Etc. 6/33

7 Bedrijfscontinuïteit Wat betekent het voor de klant als de aanbieder van een (traditioneel) softwarepakket verdwijnt? Geen support Geen onderhoud Geen updates Kortom: vervelende gevolgen Hoe kan een klant zich daar tegen indekken? 7/33

8 Oplossing? Simpele oplossing: Geef je broncode en de bijbehorende documentatie aan de klant Voordelen? Goedkoop Simpel Klant is verzekerd van continuïteit Nadelen? Bedenk zelf maar! 8/33

9 (betere) oplossing? Software Escrow! Ook wel: broncode escrow Definitie volgens Wikipedia: Source code escrow is the deposit of the source code of software with a third party escrow agent. Escrow is typically requested by a party licensing software (the licensee), to ensure maintenance of the software. The software source code is released to the licensee if the licensor files for bankruptcy or otherwise fails to maintain and update the software as promised in the software license agreement. Toegang tot de broncode in geval van nood is dus gewaarborgd zonder dat de ontwikkelaar open source hoeft te gaan. 9/33

10 Software Escrow 10/33

11 Heeft het zin? Broncode wordt in de praktijk vrijwel nooit vrijgegeven Vaak gaat het bedrijf simpelweg niet failliet, of de opvolger blijft het pakket (deels) ondersteunen Als het zo ver komt en de klant vraagt de escrow agent om de broncode vrij te geven, dan moet de escrow agent eerst om bevestiging vragen bij de licensor, en die kan dan alsnog moeilijk gaan doen. Dit kan een hoop juridisch getouwtrek geven! Broncode blijkt vaak incompleet! Mocht de broncode worden vrijgegeven, wat ga je er mee doen? Ondanks dit alles, in sommige gevallen is het beter dan niets! 11/33

12 Een voorbeeld: Vemics vs. Radvision In September 2006, we became aware that one of our customers, Vemics, Inc., or Vemics, had filed suit in a New York State trial court to obtain the source code of our Click to Meet, or CTM, product. In March 2005, we purchased certain assets of FVC associated with its CTM product in a bankruptcy proceeding. Prior to FVC s bankruptcy, FVC had signed a contract with Vemics to provide CTM licenses and service to Vemics for approximately $1.6 million, which remained outstanding at the date of the acquisition. When we purchased the CTM business of FVC, we assumed this contract. In connection with the contract, FVC had deposited certain CTM software into escrow with Iron Mountain Intellectual Property Management, Inc., or Iron Mountain. Following the closing of the FVC asset purchase, Vemics claimed financial difficulties and stated that it could not pay the amounts owed to us. In early 2006, without our knowledge, Vemics contacted Iron Mountain and requested release of the escrow. Neither Iron Mountain nor Vemics contacted us, despite contractual requirements that they do so. Vemics claimed it was entitled to the release of the escrow because the filing of bankruptcy by FVC was a release condition. When Iron Mountain did not release the escrow, Vemics filed suit against Iron Mountain in the Rockland County State Court in New York claiming that Iron Mountain had promised to release the escrow but had lost the escrowed property. Iron Mountain filed an interpleader action in the Superior Court of Santa Clara against us and Vemics, claiming that under the escrow agreement, we (as successor in interest to FVC) and Vemics were required to indemnify Iron Mountain against any claim (other than for their gross negligence). We since filed a suit against Vemics for sums owed to us and other violations of the CTM agreements, and Vemics has sued us claiming lost business based on FVC s failure to repair alleged bugs in the CTM product and/or failure to release the escrow. We also requested the State Court in California to direct that this matter be resolved by arbitration in accordance with the CTM agreements. Vemics challenged this request. Following a mediation process, the parties executed a settlement and mutual releases agreement on August 21, 2007, whereby all parties dismissed and waived all existing claims and disputes. 12/33

13 WAAROM ZOU NORMALE SOFTWARE ESCROW NIET WERKEN VOOR SAAS? 13/33

14 Waarom niet voor SaaS? Broncode is voor SaaS niet het belangrijkst Bij SaaS loopt een klant het risico (toegang tot) zijn data te verliezen! En uiteraard ook de complete toegang tot de applicatie 14/33

15 SaaS Continuiteit Hoogste prioriteit: behouden van (toegang tot) de data Vervolgens: toegang houden tot de applicatie Als laatste: onderhoud, support en updates van de applicatie Dus traditionele escrow-oplossing lossen voor SaaS enkel het laatste probleem op 15/33

16 Typische SaaS oplossing: 16/33

17 SaaS oplossing met iets minder risico: 17/33

18 SaaS met volledige continuiteit 18/33

19 Oplossing 1: SaaS Escrow Escrow agents zitten ook niet stil, en spelen dus in op deze verandering in de markt Sommige escrow agents blijven daarbij gewoon ouderwetse escrow aanbieden maar noemen het SaaS escrow. Daar heb je dus helemaal niets aan. Een aantal agents bieden wel echte SaaS escrow aan. 19/33

20 SaaS Escrow Bij SaaS treedt de escrow agent dus meer op als verzekeraar. Belangrijkste onderdeel: continuering van de hosting Meestal slaan ze alsnog de broncode op Als extra diensten bieden ze o.a. (technische) ondersteuning voor de software, en/of helpen klanten over te stappen naar een alternatief. 20/33

21 SaaS Escrow Voordelen: Ervaring Onafhankelijke derde partij Heldere kosten Makkelijk te regelen Nadelen: Kan vrij duur zijn Escrow agent continueert hosting, maar hoe zit het met eventuele third party content providers? Wat als de SaaS provider enorm groeit? Kan de Escrow agent dan nog steeds garant staan? 21/33

22 Oplossing 2: SaaS Garantiefonds Gebaseerd op het idee van Stichting Garantiefonds Reisgelden Stichting/fonds staat los van provider zelf en is dus onafhankelijk In te richten naar wens Op te zetten voor specifieke SaaS provider en haar klanten Maar natuurlijk ook voor meerdere providers Schaalvoordeel Betere controle 22/33

23 SaaS Garantiefonds Voordelen: Waarschijnlijk voordeliger Specifiek in te richten Complete controle Nadelen: Kost veel initiatief/tijd/moeite van provider zelf Nog steeds in beheer bij dezelfde mensen Geen praktijkervaring 23/33

24 Vergelijking SaaS Escrow Relatief makkelijk te regelen Ervaring Onafhankelijke derde partij Garantiefonds In eigen beheer op te zetten (zowel een voorals nadeel) Waarschijnlijk voordeliger In te richten voor een specifieke oplossing 24/33

25 Is een continuïteitsregeling wel nodig? Bij SaaS is het switchen een stuk eenvoudiger Geen (dure) investeringen vooraf Die investering hoeft dus ook niet terugverdiend te worden Oftewel; je kan weg wanneer je wil Aan de andere kant: als je SaaS provider failliet gaat dan zijn de gevolgen een stuk ingrijpender dan bij traditionele software Je verliest de gehele toegang tot de applicatie! 25/33

26 Een voorbeeld: Coghead PaaS (Platform as a Service) Provider A Web-based service for building and hosting custom online database applications Failliet verklaard in februari 2009 Bericht aan klanten: "Dear Valued Coghead Customer: On behalf of the entire Coghead team, I would like to thank you for your past business. We have taken pride in offering you our state-of-the-art Platform-as-a- Service to support your development of software applications. Regretfully, due to the impact of economic challenges, Coghead has discontinued its operations...." Klanten hadden slechts 1 maand om een oplossing te vinden. 26/33

27 Is een continuïteitsregeling wel nodig? Wat een klant zich dus moet afvragen: Wat zijn de gevolgen als ik enkele dagen of weken zonder toegang tot de applicatie kom te zitten? (hoe kritisch is de applicatie) Hoe lang ben ik van plan deze oplossing te gebruiken? Wat kost een continuïteitsoplossing in relatie tot de kosten van de SaaS-oplossing zelf? 27/33

28 Enquête 20 respondenten (allen IT ers) 50% (prospectieve) SaaS-klanten 50% SaaS-aanbieders Slechts 3 van de 20 respondenten gaven aan dat hun SaaS-product op dit moment een continuïteitsoplossing heeft. 7 van de 10 SaaS-klanten gaven aan nooit een SaaSoplossing te overwegen als er geen continuïteitsoplossing geboden wordt. 28/33

29 Enquête 29/33

30 Conclusie Faillissement blijft altijd een risico Met SaaS kunnen de gevolgen voor klanten vervelender zijn dan bij traditionele software. Klanten moeten dus goed nadenken over de gevolgen als de SaaS provider zou verdwijnen. Als de gevolgen desastreus zouden zijn: is SaaS dan wel de beste oplossing? Niet desastreus maar wel heel erg lastig: kijk naar continuïteitsoplossingen Zorg ten alle tijden in ieder geval voor een eigen back-up van je data 30/33

31 Conclusie (2) SaaS continuïteitsoplossing worden op dit moment nog maar weinig toegepast Waarom? Weinig vraag van klanten Klanten zijn zich vaak niet bewust van de risico s Een SaaS provider is uit zichzelf niet geneigd om een continuïteitsregeling op te zetten, hij heeft er zelf immers vrij weinig aan. Sommige SaaS providers zijn zelfs bang dat het hun geloofwaardigheid beschadigd als ze uit zichzelf een continuïteitsregeling op gaan zetten. De vraag moet dus echt van klanten komen. 31/33

32 Vragen? Verder lezen: Artikel in Automatiseringsgids: Volledig paper: 32/33

33 EINDE 33/33