Over drie jaar zal dertig procent van alle software als dienst worden aangeboden. De eigenschappen van het web vragen specifieke aandacht van de programmeurs die deze nieuwe toepassingen moeten ontwikkelen.
"Als we de analisten mogen geloven, zal software als product op de lange termijn niet meer bestaan", zegt ceo Jan Aleman van Servoy, leverancier van een ontwikkelomgeving speciaal voor SaaS (software as a service). "In 2011 wordt dertig procent van de software als dienst aangeboden. Het concept ‘product' gaat vervallen. De scheidslijn tussen die twee is echter niet hard. Applicaties kunnen volledig in een webbrowser draaien, of alleen op basis van verbruik worden afgerekend."
Eindigen in een klik
De verschuiving van product naar dienst heeft consequenties voor de manier waarop software wordt geschreven. Hoewel de ontwikkelomgeving van Servoy tegelijkertijd zowel native applicaties als SaaS-programma's ondersteunt, zijn er wel degelijk belangrijke verschillen. "Als je iets met lokale hardware wilt, dan lukt dat niet in html. Ook printen vanuit de browser is een probleem. En de interface is anders. In een webbrowser moet je bijvoorbeeld zorgen voor een expliciete save-knop."
Dat laatste heeft te maken met het stateless http-protocol. "Op het web moeten alles eindigen in een klik," aldus Aleman. "Zo resulteert elke actie in een nieuwe pagina. Maar dat wordt steeds minder. Wij hebben alles event driven gemaakt, zodat je van het ‘pagina paradigma' af bent."
Ajax is het toverwoord
Het toverwoord is ajax (asynchronous JavaScript and xml). Daarbij hoeft niet elke keer de complete nieuwe pagina te worden geladen. Alleen het stuk dat is veranderd, wordt uitgewisseld en weergegeven. "Dat maakt web-applicaties sneller en interactiever. Je hoeft alleen een klein stukje dom (document object model) aan te passen."
Tegelijkertijd waarschuwt Aleman voor een te zwaar ajax framework. "Veel leveranciers hebben een groot clientside raamwerk. Daarbij draait alles in JavaScript in de browser. Dat maakt de beveiliging lastig, want iedereen kan zijn JavaScript debugger aanzetten. Daarom verzorgt ons framework alleen de event handling en de interface. Alle logica blijft aan de server-kant. Als een veld wordt gewijzigd, dan wordt dat via ajax gelijk naar de server gecommuniceerd en indien nodig een klein stukje dom-code teruggegeven."
Spagaat
Andere zaken blijven gewoon hetzelfde, ongeacht of je nu een native of een SaaS-toepassing bouwt. Hoe ver ga je bijvoorbeeld met de aanpasbaarheid van je applicatie? "Dat is een ingewikkelde spagaat," aldus Aleman. "Enerzijds wil je je software zo strak mogelijk houden. Anderzijds vraagt SaaS om diverse en flexibele applicaties."
"Er zijn toepassingen waar je de hele interface kunt aanpassen. Maar dat heeft grote consequenties voor de support. Hoe weet iemand aan de telefoon nog hoe jouw interface er uitziet? Daarnaast heeft dat consequenties voor de verdere ontwikkeling. De ontwikkelaar moet zich afvragen waar die vier nieuwe velden terechtkomen."
Aleman noemt SaaS-succesverhaal Salesforce.com als voorbeeld. "Zij hebben een grote installed base. Inmiddels moet je al aanvinken welke veranderingen in de software je wel en niet wilt doorvoeren. Maar dat is op termijn niet vol te houden."
Dictator nodig
Hetzelfde geldt voor de aanpasbaarheid van een toepassing. "Bij erp (enterprise resource planning) bijvoorbeeld ontkom je niet aan aparte onderdelen en schermen per klant. Dat vraagt om veel meer aandacht bij het onderhoud en de verdere ontwikkeling."
"Niet voor niets wordt bij de grote software-leveranciers nog zo weinig geïnnoveerd. Dat heeft te maken met het grote aantal gebruikers." Wat dat betreft zijn de Nederlandse leveranciers volgens Aleman te democratisch. "Dat is slecht voor de ontwikkeling. Soms heb je een dictator nodig om te zeggen ‘We gaan die kant uit'."
Nep-SaaS
Tenslotte moet Aleman nog iets van het hart met betrekking tot Windows-gebaseerde terminal servers. Hij noemt dat nep-SaaS. "Het schaalt helemaal niet, en kost tientallen of honderden malen zo veel hardware als echte SaaS." Hij vertelt over een klant die honderd servers had om tweeduizend gebruikers te bedienen. "Ze zijn die applicatie nu aan het herschrijven. Het lijkt er op dat ze straks aan twee servers genoeg hebben. Die herontwikkeling hebben ze dus binnen een jaar terugverdiend."
Hordes voor SaaS-programmeren
-
lokale hardware is moeilijk toegankelijk
-
printen vanuit de browser is een probleem
-
het ontwerp van de interface is anders vanwege het ‘webpagina paradigma'
-
ajax maakt html-applicaties sneller en interactiever
-
een SaaS-applicatie moet tegelijkertijd meerdere bedrijven kunnen bedienen (multi-tennant)
-
multi-tennant applicaties vragen om extra beveiligingsmaatregelen, soms bijvoorbeeld om een aparte database per klant
-
volledige internationalisatie is vereist; soms kun je dat ook door de eindklant zelf laten doen
Te zware ajax frameworks
-
de JavaScript-engine van met name Internet Explorer bevat veel geheugenlekken (memory leaks)
-
bij synchronisatie tussen client en server moeten te veel beveiligingscontroles worden uitgevoerd
-
kleine verschillen tussen de diverse browsers maken het lastig om het framework werkend te krijgen
-
het debuggen van deze topzware clientside-applicaties kost veel moeite
De vermelde 30 % is nog erg bescheiden. Er zijn ook al onderzoeken die aantonen dat in 2011 50% van de bestaande softwareleveranciers, ISVs niet meer bestaan.
Transformatie van softwareleverancier naar SaaS-leverancier is voor vele ISVs een noodzaak om te kunnen overleven. Naast de noodzakelijk financi?le investeringen voor het herschrijven van de software, dhr. Aleman heeft gelijk betreffende non-saas, en kannibalisme van bestaande omzet, moet de totale organisatie worden aangepast. Inkomsten worden op basis van abonnement verkregen en niet meer op basis van licentie. Verkoop moet op een andere manier worden aangestuurd, meer online, meer webinars, online kopen en online demos. Andere commissiestructuren.
De software moet multi-tenant worden. Er moeten allerlei meetinstrumenten worden ingebouwd. Er moet een SaaS-infrastructuur worden aangelegd. De architectuur moet zo worden gekozen, b.v. schermopbouw volledig aangestuurd vanuit de database, dat semi-maatwerk mogelijk is.
De customercare afdeling moet SLAs gaan naleven en wordt verantwoordelijk voor de churn. Daarnaast moeten er goede procedures komen (ITIL gebaseerd) voor het afhandelen van storingen.
De organisatie cultuur moet wijzigen van productori?ntatie naar dienstenori?ntatie. Er moet een sfeer komen van continue innoveren, van monitoren, van reageren op acties van de klant. De organisatie moet volledig op betaalde dienstverlening gericht zijn, die voor de afnemers toegevoegde waarde bied. De verkoop moet op de hoogte zijn van de klantprocessen en relaties leggen met business managers i.p.v. de IT manager.
Kortom de volledige strategie van de ISV moet om. Welke ISV durft die beslissing te nemen, wie behoort tot de 50% die overblijft. Wie pakt de uitdaging aan?