SaaS vanuit ontwikkelperspectief

Een concept voor het maken van 'Software as a Service' is snel geboren. Als je enige ervaring hebt met het maken van een website die als applicatie functioneert zul je wellicht het idee hebben gehad dit in te gaan zetten als SaaS-product. Dit lijkt makkelijker gedacht dan gedaan en ik zal uitleggen waarom.

Het bedenken van een aantal schermen met crud-functionaliteit (create, read, update, delete) om een crm, hrm of andere behoefte te vervullen is zo gedaan. Als je een idee hebt voor een interface zijn deze ook relatief snel gemaakt ten op zichten van de zaken waar je tegenover komt te staan als ontwikkelteam.

Eén van de eerste fundamentele beslissingen die je maakt is of er een database gemaakt wordt voor elke klant, of dat meerdere klanten in één database ondergebracht kunnen worden. Deze keuze heeft namelijk direct betrekking op de genericiteit van een applicatie. Als een functionaliteit is dat een klant extra velden kan toevoegen of inzetten wordt dat al snel moeilijker in een omgeving waarin meerdere klanten zijn ondergebracht. Dit kan deels overigens weer opgevangen worden door data verticaal op te slaan. Dit wordt bereikt door een tabel te vullen met records die een gegevenstype en een waarde bevatten. Aanvullend is het dan wel weer een uitdaging om zulke data in rijen en kolommen te tonen en zul je door de hoeveelheid aan records tegen andere performance issues aanlopen.

Als SaaS succesvol is zullen er meerdere databases ontstaan die allemaal onderhouden moeten worden. Een product wordt vervolgens doorontwikkeld en nieuwe functionaliteit moet naar alle database uitgerold kunnen worden zonder dat dit de instellingen en inrichting van de applicatie aantast. Updateability is rocketscience en er zijn al grote goden over gestruikeld. Testen van die wijzigingen is niet gemakkelijk omdat je ook rekening moet houden met standaard maatwerk, of de mogelijkheden die klanten hebben voor het aanpassen van de database. Het inzicht komt al snel om gebruik te maken van globaal unieke sleutels (guid's) en die brengen ook hun eigen complexiteit met zich mee.

Kennis om een applicatie te maken heeft elke ontwikkelaar, maar met veiligheid heeft een ontwikkelaar doorgaans geen brede ervaring. Natuurlijk moet je voor een deel vertrouwen op de veiligheid die een platform (besturingsysteem en platform waarop ontwikkeld wordt)  en een datacenter biedt, maar ook de manier waarop de software in elkaar gezet wordt kan de veiligheid aantasten. Een lek of een geslaagde hackpoging zijn funest voor een SaaS-aanbieder. Daarnaast is kennis over veiligheid lastig te vinden. Een veiligheidsexpert moet immers ook de taal van de ontwikkelaar begrijpen om een gefundeerde mening over de veiligheid van de software te kunnen geven. 

Een groot verschil met standaard software en SaaS is dat een de laatste niet op een server van de klant draait. Integratie tussen applicaties is enorm belangrijk omdat er anders veel handmatig gedaan moet worden en dit fouten uitnodigt. Als je bijvoorbeeld een crm aanbiedt dan is het niet meer dan logisch voor een gebruiker dat dit kan communiceren met Outlook voor mail, contactpersonen en agenda. Als het gaat om hrm wil je ook dat er een koppeling bestaat naar de salarisadministratie. Anders krijg je wéér een systeem waarin handmatig gegevens bijgehouden moeten worden. SaaS zal dus moeten kunnen communiceren en webservices maken en integreren is toch heel anders dan de schermen maken van de oorspronkelijk bedachte interface.

Dan is er nog het juridische aspect. In Nederland heerst er nog niet zo'n claimcultuur als in Amerika, toch is het belangrijk om over een aantal juridische zaken na te denken. Wie is eigenaar van de data, wat gebeurt er als er toch een geslaagde hackpoging gedaan wordt? Hoe ga je om met gegevens, en overtreedt je daarmee geen wetten? Toegegeven, deze zaken moet je ook bedenken bij traditionele software, toch geeft een SaaS eigen unieke vraagstukken die je als aanbieder op moet lossen anders neem je een niet te overzien risico. En hoe ga je om met beschikbaarheid? De klant merkt dat de software "het niet doet", maar misschien ligt de oorzaak wel bij de ISP, hoe ga je om met overmacht? Al zijn dit zaken die je met traditionele software ook hebt.

Wat je als aanbieder van Saas moet realiseren is dat een bedrijf in feite een deel van zijn it bij jou outsourced. Je neemt namelijk een deel van de it-werkzaamheden van een bedrijf over. In een aantal gevallen zul je zelfs de gebruikers ondersteunen, naast het beheer van updates, servers, hosting omgeving, back-ups en recovery bij 'ongevallen. Dit is anders dan bij het leveren van een installatie'-cd.

Het aanbieden van SaaS betekend ook hosting. Kennis van bandbreedte, beschikbaarheid, concurrency en schaalbaarheid hoort daar dus bij en is een wereld op zich. Het zijn allemaal zaken die aan SaaS verbonden zijn, maar die pas naar voren komen als je het concept aan het uitwerken bent.

Als je dit allemaal getackeld hebt, staat niets een succesvolle introductie meer in de weg. Toch?

Eén van de lastigste succesfactoren voor SaaS is de commercie. Nieuwe Saas verkoopt zichzelf niet. Je komt toch andere uitdagingen tegen dan de verkoop van traditionele software. Hoe stel je een licentiemodel op? Hoe overtuig ik een prospect om over te stappen op SaaS?  Wie zijn je concurrenten en welk model hanteren zij. Het zijn stuk voor stuk dingen die anders zijn dan met applicaties die je verkoopt en lokaal geïnstalleerd worden. Daarnaast is vertrouwen een eerste horde die genomen moet worden. Voor veel ondernemingen is het afnemen van een SaaS-product ook nieuw en zeker nog gemeengoed.

Zo zie je dat het ontwikkelen en exploiteren van SaaS geen één-tweetje is. Sta je er voor open om als bedrijf een SaaS-oplossing in te zetten, neem de aanbieders dan onder de loep en neem deze punten mee. Een aanbieder die al je vragen op dit gebied bevredigend kan beantwoorden heeft per definitie al een lange weg afgelegd en verdiend hiervoor in mijn ogen kredietwaardigheid. Dat SaaS toekomst heeft is voor mij duidelijk, alleen zal dit proces naar volwassenheid nog enige tijd vergen. Het laatste woord hierover is nog niet gezegd en geschreven. Dat houdt de discussie wel levendig.