Saas staat voor Software as a Service. Een term die je misschien al vaak gehoord hebt, of die je hier voor het eerst tegen komt. SaaS is een ontwikkeling, die de ICT wereld ingrijpend gaat veranderen. Deze keer veranderd er echter weinig aan de techniek. Alle benodigde techniek om SaaS te kunnen doen is er namelijk al. Er veranderd vooral veel voor de eind gebruiker.

Goed, wat is het nu eigenlijk dat SaaS. SaaS, of Software as a Service kun je eigenlijk vrij letterlijk nemen. Software, waarvoor op regelmatige basis (meestal maandelijks) aan de hand van het gebruik, een bedrag wordt betaald, dat is SaaS. Dat betaald moet je ruim zien, het kan ook zijn, dat de dienst die je gebruikt, wordt betaald door de reclames op de webpagina. En oohh ja, de software dient wel via een browser op het internet benaderbaar te zijn. Met deze omschrijving is zo ongeveer elke pagina, op het internet een SaaS dienst, dus die discussie over wat een SaaS dienst nu precies is, zal voorlopig wel even doorrazen.

Wat maakt SaaS nu zo bijzonder, dat het de ICT wereld ingrijpend gaat veranderen. Daar spelen een aantal belangrijke factoren een rol in. SaaS bied de mogelijkheid om:

Bijna iedereen heeft tegenwoordig wel eens gehoord van agile werken of heeft zelfs bij een aantal projecten met agile gewerkt. Ook ik heb mijn dosis agile gehad in de vorm van MSF Agile of SCRUM. Toch bekruipt mij uiteindelijk het gevoel dat agile werken nooit het rendement geeft wat het belooft en dat was uiteindelijk toch de reden om voor een agile ontwikkelmethodiek te kiezen.

Waar gaat het dan fout? Het ontwikkelen in iteraties van twee tot vier weken is een van de beste ideeën die er zijn geweest in mijn mening. Het is volstrekt logisch om de klant tussendoor te vragen of het product tot nu toe voldoet aan zijn verwachtingen. Ook de roep om directere communicatie met de klant en (directe) collega's en flexibele aanpak van problemen verdient mijn lof. Waarom kunnen volledig agile methodieken mij dan niet bekoren? Waar komt die nare bijsmaak vandaan?
Het antwoord niet zo zeer in fouten in de methodiek als wel in de mensen die de methodiek toepassen. In de loop der jaren is agile het slachtoffer geworden van hetzelfde lot als design patterns; het is een gewoonte geworden, een ritueel. We gaan gewoon het lijstje af dat de methodiek voorschrijft zonder er bij na te denken hoe toepasbaar het lijstje is in onze projectsituatie. Braaf staan we elke ochtend in bij de stand-up zonder dat we echt luisteren naar elkaar. Misschien erger je je wel aan het verloren kwartiertje. (als het al een kwartiertje is) 

Vooral het letterlijk nemen van dat werkende software beter is dan uitgebreide documentatie, levert een hardwerkende club ontwikkelaars op, die uiteindelijk nog steeds niet opleveren wat de klant bedoelde. Architectuur en requirements blijven nog altijd van belangrijk en mogen niet worden afgeschreven als iets uit het watervaltijdperk. Ook totale commitment van de organisatie en/of opdrachtgever is vaak een utopie. Hier hoort dan gewoon op de klassieke manier omheen gewerkt in plaats van dit op te nemen als het volgende projectrisico. Agile moet worden toegepast wanneer het werkt en niet wanneer het je belemmerd. Als dit zou voorkomen bij een framework, dan zou je deze niet eens gebruiken!