vrijdag 15 juni 2012

Software ontwikkelen met de cloud in mind

Cloud computing betekent verschillende dingen afhankelijk van het perspectief waaruit je dit bekijkt. Een CFO ziet een mogelijk kostenbesparing, de business manager een mogelijkheid om sneller te schakelen en flexibel te zijn. Een IT manager ziet het wellicht als een bedreiging en de directeur ziet een mogelijkheid om een niet primair process uit te besteden aan een partij waarbij het thuis hoort.

Door de grote verschillen in SaaS, PaaS en IaaS is een discussie over cloud computing vaak al iets wat uitmond in het vaststellen van definities en voor en tegenstanders in verband met veiligheid.

De scope van mijn betoog is die van de softwareontwikkelaar. In Nederland zie ik enerzijds dat veel bedrijven wel software maken en deze aanbieden als SaaS over het internet (cloud als synoniem van internet), maar niet goed bekend zijn met cloud computing; een verregaande vorm van automatisering en virtualisatie waarbij je niet een fysieke server centraal stelt, maar het gebruiken van bronnen zoals data, geheugen en processor kracht.

Hier zijn een aantal tips over het ontwikkelen van software die geconsumeerd wordt over het internet.

Tip 1: Zelfbediening
Maak software as a service altijd op een manier dat klanten zichzelf kunnen helpen. Dat ze dus klant kunnen worden zonder dat er menselijk handelen nodig is voor jou als leverancier. Het klinkt als een open deur, maar ik kom zeer vaak tegen dat je eerst een contact formulier invult of iets dergelijks en dat je dus niet meteen aan de slag kan. Maar zelfbediening gaat veel verder. Veel diensten moeten worden ingericht voordat ze goed gebruikt kunnen worden, zorg ook dat een klant die wijsheid via jouw product op kan doen. Dus met instructie filmpjes of slimme pop-ups en tooltips. Soms gaat het om producten die ook beheer moeten worden. Als je bijvoorbeeld een Google Apps account aanmaakt, kun je ook e-mail adressen voor werknemers aanmaken en beheren. Het beheren van gebruikers en het domein dient dus ook te gaan op basis van zelfbediening. In feite moet je klant de tools kunnen gebruiken die je zelf ook gebruikt als beheerder.

Tip 2: Integratie
Eén van de grootste nadelen van SaaS is dat het vaak eilanden zijn. De dienst doet één ding heel erg goed, maar klanten willen meer. Nu kun je als een dolle al dat “meer” gaan maken, maar vroeg of laat verlaat je dan je comfortzone; het gebied waarop je deskundig bent. Je wilt een product in de regel niet te alomvattend maken omdat het dan snel zo complex word dat je in een spagaat terecht komt. Dit probleem los je op door integratie mogelijk te maken. De beste manier om dit te doen is door toegang te geven tot je product door middel van een Application Programming Interface (API) en deze te ontsluiten over het internet bijvoorbeeld met een webservice. Met een “CreateOrder” API kun je een bestelling plaatsen. Met “GetHours” haal je gewerkte uren van een medewerker op. Nu geef je andere bedrijven mogelijkheden om koppelingen te maken met jou product. Nog beter word het als het eigen product ook middels deze API’s met de database communiceert. Dit geeft meer vrijheid en leidt in de regel tot meer veiligheid en eenduidigheid. Je houdt je aan dezelfde regels waar anderen zich aan moeten houden en door je eigen product verder te ontwikkelen creëer je ook meer mogelijkheden voor andere partijen. Ook zorgt dit voor een “separation of concerns” (SoC); de presentatielaag en de businesslaag zijn zo mooi gescheiden en daardoor beter te onderhouden of onafhankelijk van elkaar door te ontwikkelen. In feite creëer je hiermee een platform en een platform kan leiden tot een hefboom. Een cliché voorbeeld is Amazon S3. Dropbox is een tool die data opslaat in S3 en alleen mogelijk was doordat S3 middels een API aan te sturen is. Hierdoor kan Dropbox 50 miljoen klanten bedienen met slechts 100 medewerkers. Amazon Webservices (AWS) waarvan S3 een onderdeel is laat zien hoe krachtig een platform kan zijn. Een ander voordeel van het werken met API’s is dat het platform onafhankelijk is. Een Java guru kan uitstekend een tool bouwen die gebaseerd is op een .NET API. Maar ook een Android of IOS App heeft per definitie een API nodig.

Overigens werkt integratie twee kanten op. Je kunt er ook naar toe werken dat jouw product kan communiceren met API’s van andere webdiensten. Vaak zijn dit soort koppelingen unique selling points (USP). Als je kijkt naar de universele afstandsbediening van Logitech, de Harmony serie, dan is de kracht ervan dat er een database bestaat met de koppeling en taal naar alle apparaten die met infrarood werken. Zonder die integratie is het product niets waard en snel namaken gaat niet omdat de kracht nu juist in die koppelingen zit.

Uiteraard is het een goed idee om bij integratie focus te hebben op andere cloud producten. Als dat andere cloud product succesvol is, kun je daar wellicht op meeliften.

Tip 3: Hou rekening met meertaligheid
Zeker op het gebied van cloud computing moet je jezelf niet beperken tot één taal. Dit betekent niet dat je meteen uit moet rollen naar alle landen van de wereld. Wel dat mensen graag aangesproken worden in hun eigen taal maar wees er klaar voor dat als jou idee werkt in Nederland, dit wellicht ook werkt in andere landen. Dit vergt wel wat denkwerk. Sommige data uit de database moet met meerdere talen overweg kunnen (bijvoorbeeld als je moet kiezen uit een geslacht ofwel gender), maar ook datum notaties zijn in landen verschillend. Dan heb je nog de teksten zelf en instructies. Nederlandse instructies in Nederland spreken meer aan dan Engels ondanks dat Nederlanders goed in Engels zijn. Coderen en commentaar in de code zou ik overigens wel gewoon Engels houden en zeker geen Nederlands. Ten eerste ben je dan beperkt met als je delen wilt uitbesteden, maar ook ben je minder aantrekkelijk als de software wordt overgenomen door een grotere speler in de branche.

Tip 4: Denk breder dan de organisatie
Software wordt vaak gemaakt voor interne gebruikers of voor klanten. Maar in het verlengde van tip 2 beperk je niet dat die twee soorten gebruikers. Denk ook aan bijvoorbeeld leveranciers en klanten van klanten of andere dienstverleners. Met andere woorden; iedereen heeft wel iets in de software te zoeken. Accessibility ofwel de toegang tot data is functioneel gezien het allerbelangrijkste. Heb je een HRM oplossing, dan heeft een (externe) bedrijfsarts wellicht ook wat te zoeken in de database. Of een leverancier die jouw voorraden kan bijwerken. Of een externe accountant die financiële rapporten of data zelf op kan halen. Of kijk naar Google Docs. Twee samenwerkende bedrijven kunnen een map samen delen en op zo’n manier samenwerken. Dit concept creëert een enorme hefboom en heeft veel toegevoegde waarde omdat veel andere software dit niet kan omdat het niet fundamenteel is meegenomen in het ontwerp. Ik zeg niet dat je alles zo generiek mogelijk moet maken of dat je met elk mogelijk scenario rekening hoeft te houden, maar het kan ook geen kwaad om vooruit te kijken zodat je niet ineens te beperkt bent als de wens geopperd word.

Tip 5: Ontwikkel met de Cloud in mind
Ik spreek regelmatig software ontwikkelaars. Zowel de business eigenaren als de ontwikkelaars zelf, en het verbaasd me hoe weinig kennis zij hebben van cloud computing. Een database opzetten in Microsoft Azure, een instance van een virtuele server de lucht in schieten in Amazon EC2, zelfs het consumeren van een webservice is iets wat ik te weinig tegen kom. Ik ben absoluut een voorstander om een simpel tooltje te ontwikkelen en dit uit te bouwen in plaats van direct een complex systeem neer te zetten. Maar het nadeel is dat als de basis niet gebouwd is voor schaalgrootte dit een lastige en dure transitie wordt als het gebruik van de tool groeit. Een voorbeeld van een beslissing die vroeg genomen moet worden is deze; gebruiken klanten samen één database, of krijgt iedere klant zijn eigen database. Deze keuze heeft verstrekkende gevolgen als het klantenbestand groeit. Ik zeg niet dat één van de twee keuzes de beste is, maar dat je de vanaf scratch al bouwt met het idee van schaalgrootte in je achterhoofd.

Een andere valkuil die ik vaak zie is dat er op een server ontwikkeld wordt en dat de inrichting van de server een onderdeel is van de oplossing. Voor een prototype is dit wellicht logisch, maar uiteindelijk dien je een server slechts als een leverancier van bronnen te zien. Een kort door de bocht voorbeeld: Een server wordt aangeschaft en daarop wordt een database server geïnstalleerd. Stel dat het aantal klanten snel groeit, dan voldoet de database server niet meer. Er moet een server bijkomen of naar een “dikkere” server worden gemigreerd. Door Amazon RDS of Microsoft Azure te gebruiken heb je dit probleem niet. Opslag van data is bijna onbeperkt en de beschikbaarheid is hoog. Je hoeft geen diepgaande architectuur op te zetten.

Met de cloud in mind ontwikkelen is echt wat breder dan alleen denken aan techniek, het is een filosofie. Een beetje gekscherend maar wel illustratief voorbeeld is dat er vroeger altijd gedacht werd in doosjes. Je schaft software aan op een DVD en doet deze in een computer om het te installeren. Voor de klant lastig, want die moet eerst naar een winkel, maar je moest ook als ontwikkelaar een doosje ontwerpen, DVD’s laten persen en sleutels maken voor licenties en denken aan piraterij. Dit zijn uitdagingen die je niet hebt als cloud dienst. Tien jaar geleden kwam er nog iemand van automatisering langs om je computer te updaten, dat schaalt niet. Ontwikkelen met de cloud in mind is echt automatiseren. De functie staat centraal, alles wat daaronder of daarachter zit is ballast.