Softwarelicentiemodellen zijn altijd al aan verandering onderhevig geweest. De introductie van het SaaS-model is daar het meest recente en waarschijnlijk ook het meest rigoureuze voorbeeld van. Deze abonnementsvorm kent veel voordelen, maar is niet voor ieder bedrijf in elke situatie per se de beste optie. Maak daarom altijd goed geïnformeerd de keuze tussen legacy en innovatie.
Toen softwarelicenties in de jaren tachtig hun intrede deden, betekende dat een enorme game changer voor de it-industrie. Software was niet langer meer standaard onderdeel van de hardware: voortaan kreeg een gebruiker alleen onder vooraf bepaalde voorwaarden het recht om van de software gebruik te maken. Vanaf dat moment konden softwarebedrijven, dankzij intellectueel eigendom, écht geld gaan verdienen met hun product. Dat gebeurde door middel van licenties, waarin afspraken met en voorwaarden voor de gebruiker werden opgenomen. In de jaren die volgden ontstonden verschillende nieuwe licentiemodellen en net als de software zelf werden ze steeds complexer.
Legacy licenties
Het oudste en nog steeds meest voorkomende legacy licentie-type is de ‘proprietary’-licentie, waarbij de gebruiker het recht krijgt om de software te gebruiken als hij de voorwaarden accepteert. Vaak zijn deze licenties ‘perpetual’, oftewel eeuwigdurend: je hoeft maar één keer voor de licentie te betalen om de software altijd te mogen gebruiken. Daarnaast bieden softwareleveranciers vaak ook additionele diensten in de vorm van onderhoud of support aan. Voor een vast bedrag bovenop de licentiekosten verzeker je jezelf daarmee van software upgrades, updates, patches en bug fixes.
Elke licentie heeft ook zijn eigen ‘metrische’ systeem. Met een ‘license metric system’ definieert de softwareleverancier hoe het gebruik van de software precies gemeten gaat worden. Een voorbeeld daarvan is de ‘concurrent user’-metric: hierbij mag de gebruiker de software op meerde apparaten installeren, zolang het aantal apparaten dat de software op hetzelfde moment gebruikt maar niet hoger is dan het aantal aangeschafte licenties. De ‘named user’-metric of de ‘device’-metric zijn wat makkelijker te tellen: voor elke gebruiker of elk apparaat heb je een licentie nodig. Recentere metric systems kijken naar meer complexe zaken, zoals de computerkracht die nodig is om de software te draaien.
Intrede van SaaS
Zo veranderden de licentiemodellen door de jaren heen, maar de basis bleef grotendeels hetzelfde, met één grote investering bij de aanschaf van de licenties. Tot cloud computing zijn intrede deed, inmiddels alweer een jaar of tien geleden.
Dankzij het software as a service-model is de manier waarop software wordt aangeboden, ingezet en gelicenseerd rigoureus veranderd. De software hoeft niet langer on-premise te draaien en onderhoud en support zijn meestal in de prijs opgenomen. Maar de grootste verandering is misschien wel de manier waarop de betaling plaatsvindt. Software is geen eenmalige investering meer, maar een maandelijkse afschrijving – net als een telefoonabonnement.
Voor- en nadelen
De grote vraag: is deze innovatieve abonnementsvorm beter dan de bestaande legacy-modellen? Dat hangt er vanaf. Enerzijds zijn de voordelen van deze abonnementsvorm evident. De schaalbaarheid maakt snel groeien makkelijker, terwijl de capaciteit ook simpel tijdelijk opgeschaald kan worden. Je bent daarbij altijd verzekerd van de laatste versie van de software en medewerkers hebben altijd en overal toegang tot de software, als ze maar een internetverbinding tot hun beschikking hebben. Bovendien bundelt de leverancier vaak meerdere functionaliteiten en producten, waardoor je meer waar voor je geld krijgt.
Aan de andere kant brengt SaaS een hele andere dynamiek met zich mee. Oneindig gebruik van de software voor een eenmalig bedrag bestaat niet meer, software is nu veel meer een nutsdienst. Betaal je niet, dan heb je ook geen toegang tot de software. Betaalproblemen kunnen dus direct grote gevolgen hebben voor een organisatie, zeker als de volledige bedrijfsvoering afhankelijk is van software (en dat is steeds vaker het geval). Denk ook goed na bij de grote aanbiedingen die vendoren over hebben voor een overstap naar hun clouddienst. Op korte termijn meer krijgen dan waar je voor betaalt is mooi, maar lang niet in alle gevallen een voordeel, omdat het de kans op een vendor lock-in vergroot.
Goed geïnformeerde keuze
Zo is er voor beide kanten van het verhaal wat te zeggen. Er is dus geen eenduidig antwoord op de vraag of innovatieve licenties beter zijn dan legacy-licenties. Natuurlijk biedt SaaS allerlei geweldige nieuwe mogelijkheden, maar dat betekent niet dat een SaaS-model áltijd het beste is. Met SaaS is er vooral een nieuwe smaak bijgekomen, naast de bestaande smaken.
Zomaar blind elke innovatie omarmen heeft weinig zin – zeker niet bij iets dat zoveel impact heeft op je organisatie. Inventariseer eerst of jouw bedrijf er beter van wordt. Misschien kun je nog jaren vooruit met die on-premise database of misschien kun je beter nog vandaag dan morgen overstappen op een flexibele cloud-variant. Als je deze keuze maar goed geïnformeerd maakt, met een rekenmachine in de hand!
Goed verhaal, maar dat van die vendor lock-in SaaS, zit hem vooral op het licentie-stuk en de “black-box” houding van veel leveranciers, binnen on-premise is de vendor lock-in vaak op technisch inhoudelijk vlak. Vaak een monolitisch gedrocht waar je niet zo maar even afscheid kan nemen. Het domweg in de Cloud zetten van de functionaliteit gaat je niet lukken, want complexiteit kun je niet uitbesteden. Volgens mij doet me dit denken aan de outsourcing tijden, waarbij hele horden van organisatie hun IT buiten de deur plaatsten, want dat was goedkoper en die dienstverleners konden dat veel beter. Resultaat: peperdure contracten en nog minder gebruikerstevredenheid.
Het beprijzen van software is niet gestart in de jaren tachtig, maar begin jaren zeventig. Onder druk van de Amerikaanse anti trust wetgeving werd IBM gedwongen om hardware en software afzonderlijk te beprijzen. Die ‘unbundling’ werd de geboorte datum van de software industrie. Wij, als IBM account managers, waren daar overigens helemaal niet blij mee. Het maakte ons leven alleen maar ingewikkelder.
In dit kader verbaast het mij vaak dat een specifiek deel van de vendor lock-in weinig aan de orde komt. Denk hierbij als voorbeeld, dit is niet de enige, aan SalesForce, waarbij je het pakket afneemt per jaar per user en daarin zit zowel de hosting als de software, automatische updates etc.
Echter in de onverhoopte situatie van een failliet gaan van SalesForce kun jij de business niet meer doen, de applicatie draait niet meer en alle mooie afspraken die jij hebt gemaakt zijn gemaakt met een bedrijf wat dan failliet is.
Vroeger werd voor een oplossing van iets dergelijks de kreet Escrow gebruikt, waarbij een derde partij de broncodes en de documentatie van de software heeft opgeslagen, zodat die kan worden ingezet. Echter dat betekent dat je nog geruime tijd uit de lucht bent omdat e.e.a. bij een andere hosting partner zal moeten worden geinstalleerd etc.
Ik heb al eens gevraagd waarom bedrijven als voornoemde niet hun complete packet, inclusief de data van de klanten, ge-encrypt naar een externe partner spiegelen en daarbij met die partner contracten maken om af te spreken dat in genoemde situatie de klanten van dit bedrijf voor dezelfde kosten bij de partner dit pakket mogen draaien, bijvoorbeeld voor minimaal 2 jaar of iets dergelijks.
@ Henk
En heb je ooit antwoord gekregen?
Mark,
Goed verhaal.
Ik constateer dat veel organisaties niet begrijpen dat “iets” in de Cloud feitelijk Outsourcing is.
En daar gelden wat andere spelegels en Governance voor, op diverse niveaus.
Eén direct aan het begin van het selectie (“aanschaf”) traject: de exit strategie (HET ultime antwoord op vendor lockin)
Een ander aspect, het recht tot audit (Right to Audit).
En vergeet daarbij ook niet wat de wet rondom privacybescherming hierover te melden heeft.
Samenvattend, SaaS = Outsourcing licentie van de applicatie, de gegevens en OOK het Beheer.
@ Norman, ik wens je veel succes bij de grote marktpartijen dat allemaal juridisch dicht te timmeren……ze willen/doen/kunnen het gewoon niet……dit gaat nog jaren duren, voordat wat mij betreft keiharde wetgeving, gedrag, en natuurlijk (want eerst moeten aantal complete uitglijders breeduit worden uitgemolken) keiharde boetes.
@Atilla, het heeft niets te maken met klein of groot.Of keiharde boetes.
Voor beiden geldt hetzelfde verhaal: doe je het niet, dan loop je kans je eigen bedrijfsvoering te schaden (Beschikbaarhied en Integriteit). Resultaat: out of business.
De kunst is het om met weinig (financiële) middelen, met goed verstand, door goed te luisteren de weg zoekt naar effectieve oplossingen. En als professional elkaar te helpen bij het vinden van de weg daar naar toe.
Als je wat meer wilt weten hoe je dat kan doen voor de kleine organisaties, dan ken ik diverse goede voorbeelden. Ken jij die dan niet???
En voor ik het vergeet:
* Voor iedere SaaS toepassing moet je voor 25 mei a.s. een verwerkersovereemkomst hebben.
* Het gaat niet alleen om keiharde boetes. Er zijn zeker 5 maatregelen die kunnen worden gehanteerd.
@ Norman, Ik snap de noodzaak wel, alleen op dit moment zie ik dat veel van de grote leveranciers die echte SaaS-toepassingen aanbieden dergelijke voorzieningen niet aanleveren. Je kunt overeenkomsten opstellen tot je een ons weegt, als je geen overeenstemming krijgt, wat dan? Je blijft in een situatie zitten – zoals Mark aangaf – wat Cloud is de digitale vorm van outsourcing – hoe krijg je het technisch voor elkaar dat je door kan als leverancier op een blauwe maandag de stekker eruit trekt. Henk beschrijft het zoals je dat zou willen – ergens een dormant spiegel hebben draaien?
Even concreet: ik bestel een SaaS-toepassing, waarbij er geen on-premise variant bestaat (want dat is toch ons voorland). het idee dat je die software dan nog on-premise kan laten draaien is technisch – zelfs voor de leverancier – lastig te realiseren. Een professionele multi-tenant SaaS-omgeving is niet een verzameling single-tenant instances. Maar zelfs al zou dat lukken. Hoe moet ik mij in een dergelijke situatie die spiegel voorstellen. Ze moeten dan allerlei technische voorzieningen inbouwen omdat mogelijk te maken, in alle voorkomende gevallen (geen eenheidsworst). Een tweede probleem is, hoe zit dat dan met licenties, want je moet ergens anders vermoedelijk on-premise een instance van die single-tenant variant van de software hebben draaien. Dat zal juridisch heel ingewikkeld worden. Overigens alleen eisen dat een SaaS-leverancier zijn DR goed geregeld moet hebben is geen vrijbrief: als de SaaS-leverancier omvalt (failliet), dan is de DR oplossing ook weg.
Vooralsnog zie ik de meeste minimale technische oplossing in dag dagelijkse dump, een tweede zou zijn een automatische koppeling, waarover een synchronisatie loopt, zodat je niet een dag, maar korter achter loopt. En op zijn minst onderzoeken welke eenvoudige raadpleegtools op die data los gelaten kunnen worden. Maar dan stopt het toch echt, de applicatie van de SaaS-leverancier nabouwen is geen pad dat ik in zou gaan.
Ik hou me van harte aanbevolen hoe je deze problemen dan te lijf gaat.
In reactie op Atilla:
Nee, ik heb geen antwoord gehad anders dan dat degenen waarmee je dat dan bespreekt, commerciele mensen, alleen weten dat hun bedrijf erg solide is en er in genoemde situatie altijd wel iemand is die deze dienst wil overnemen. Niet echt een fundament om je bedrijf op te bouwen, in mijn ogen.
Henk
Hoi Henk,
Dank voor je terugkoppeling…..ik had niets anders verwacht. Ik noem dergelijke uitspraken van het sales volk (en ik ken gelukkig ook een aantal realistischere types) de zogenaamde vierkleurenfolder prietpraat. “Maakt u zich maar geen zorgen, wij ontzorgen u wel”.
Ik hou me nog steeds van harte aanbevolen of er iemand is, die het wel voor elkaar gekregen om juist in de pragmatische zin een situatie heeft georganiseerd waarbij, in geval van omvallen van een SaaS-leverancier, een scenario klaar heeft staan, dat je organisatie, zonder dagen dan wel weken of maanden stress, de je data en applicatie beschikbaar hebt?