Wednesday 27 October 2010
Product Software
BEDRIJFSCONTINUÏTEIT Voor Software as a Service Door: Tommy van de Zande
1/33
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
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
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
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
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
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
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
(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
Software Escrow
10/33
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
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
WAAROM ZOU ‘NORMALE’ SOFTWARE ESCROW NIET WERKEN VOOR SAAS?
13/33
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
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
Typische SaaS oplossing:
16/33
SaaS oplossing met iets minder risico:
17/33
SaaS met volledige continuiteit
18/33
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
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
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
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
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
Vergelijking SaaS Escrow
Garantiefonds
• Relatief makkelijk te
• In eigen beheer op te
regelen • Ervaring • Onafhankelijke derde partij
zetten (zowel een voorals nadeel) • Waarschijnlijk voordeliger • In te richten voor een specifieke oplossing
24/33
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
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-aService 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
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
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 SaaS-
oplossing te overwegen als er geen continuïteitsoplossing geboden wordt. 28/33
Enquête
29/33
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
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
Vragen? • Verder lezen: • Artikel in Automatiseringsgids: • http://www.automatiseringgids.nl/artikelen/2010/37/bedrijfscontinu-teit-
voor-saas.aspx • Volledig paper: • http://people.cs.uu.nl/slinger/
32/33
EINDE
33/33
