De server verdwijnt

Software op abonnementsbasis neemt momenteel een enorme vlucht en onderlinge integratie neemt werkbare vormen aan. Bij het oprichten van een nieuw bedrijf is het een reële mogelijkheid geworden om dit zonder eigen servers te doen. Sterker nog, ik denk dat er in veel gevallen helemaal geen server meer nodig is. Klinkt radicaal? Misschien wel, maar dat maakt het niet minder waar.

Het klinkt als een cliché vergelijking, toch pak ik hem weer op: stroom. Stroom is iets wat je afneemt en betaald naar gebruik. Van stroom zijn we behoorlijk afhankelijk en als een graafmachine de kabels kapot harkt doet niets het meer. Welk bedrijf heeft nog een eigen generator om stroom op te wekken? Juist, geen enkel bedrijf meer op een paar zeer uitzonderlijke gevallen na zoals een ziekenhuis. Gelukkig vertrouwen we op stroom en wordt er keihard aan gewerkt om je weer van stroom te voorzien. Zo is het ook met grote bedrijf die software aanbieden over het internet. Er kan altijd een ramp gebeuren, maar dit niet oplossen hoort niet bij de mogelijkheden.

Die generator om stroom op te wekken kun je vergelijken met een server. Ergens moet er nog wel een generator zijn om stroom op te wekken, maar je ziet hem niet meer. Het is voor het gebruik niet meer relevant geworden.

Terug naar de server. En de cloud. Cloud computing is helemaal niet relevant voor een afnemer van een software abonnement. Het is hooguit interessant voor het bedrijf dat de software maakt. Dus vergeet cloud computing.

Vanuit het perspectief van de software leverancier is het installeren van een server iets wat snel zal verdwijnen. Zeker in een tijd van cloud computing zijn alle servers sowieso al virtueel. En virtuele servers installeer je niet, het zijn gewoon files die door een stukje techniek zich voordoen als een server. Met een serverimage factory houd je virtuele servers up-to-date. AOL heeft een onbemand datacenter welke een virtuele server binnen 60 seconde productieklaar kan maken. Dat is iets anders dan een server bestellen en met de hand installeren.

Maar zelfs als softwaremaker wil je helemaal niet meer bezig zijn met een server. Je wilt code deployen op een platform. Dat het platform op servers draait zie je als ontwikkelaar niet. Het beheren van dit platform gaat gewoon met een management console die functioneert in een browser. Ook de database kan gewoon draaien op een platform en geldt hetzelfde voor.

Net als de generator is een server een generiek product geworden waar je eigenlijk niet meer individueel naar hoeft te kijken. Een server is nog steeds een complex stukje ijzer, maar het beheer is grotendeels versimpeld door verregaande automatisering. Automatisering bestaat uit laagjes en hoe beter de lagen op laag niveau geautomatiseerd zijn hoe minder er naar omgekeken hoeft te worden.

Traditioneel doet een server van alles. Het hosten van files, aannemen van connecties en het uitvoeren van code. Waar het in een virtueel scenario om draait is dat een server CPU kracht levert om code uit te voeren met vluchtig geheugen (RAM) . De specifieke files van bijvoorbeeld  de applicatie staan niet op de server maar op virtuele harde schijven (niet vluchtig geheugen). Wil je meer kracht? Dan schakel je virtuele servers bij. Gaat er één stuk? Dan switch een deel van de verwerkingskracht naar andere virtuele servers.

In de definities van cloud computing wordt vaak het piramide model gebruikt van SaaS, Paas en Iaas (afkortingen voor Software as a Service, Platform as a service en Infrastructure as a service). Als automatisering moderniseert zal de IaaS laag steeds minder zichtbaar worden en op termijn misschien zelfs verdwijnen. Je wilt geen servers, je wilt software!

Virtuele servers draaien op fysieke servers. Dat is onvermijdelijk. De titel van dit artikel zou dus eigenlijk moeten zijn; “De server verdwijnt uit het zicht…..”, maar dat klinkt al veel minder radicaal.

Rationalisering case: Productiviteit

Ik heb een aantal artikelen geschreven over het rationaliseren van het applicatie landschap. In deze artikelen ging ik niet dieper in op de praktijk met voorbeelden. Daarom beschrijf ik hier een concrete case waarin duidelijk wordt wat ik met rationaliseren bedoel en waarom het best lastig is.

De Case: Productiviteit
Bij een grote opdrachtgever kreeg ik de opdracht om productiviteit inzichtelijk te maken. Veel medewerkers werkte met een administratief systeem. Handelingen hadden een nummer en voor elke handeling stond het aantal minuten hoelang er over die handeling gedaan mocht worden. Dat lag in waardes tussen de 2 en 20 minuten. Per dag had een medewerker dus een aantal handelingen verricht en door dat te vermenigvuldigen met de normtijd kon je uitrekenen hoeveel werk een medewerker had verricht. Voor de berekening van productiviteit was dit niet genoeg. De input van het werkelijk aantal gewerkte uren was nodig om te kijken hoe de werkelijke productie was. Mensen hadden meer taken en variabele werktijden. Als iemand volgens de norm 6 uur had gewerkt, maar in de werkelijkheid 8 uur was bezig geweest, dan was diens productiviteit dus onder de norm.

Overigens is dit een vereenvoudiging van de werkelijke opdracht, ik houd me aan het noodzakelijke voor dit stuk.

Om de berekening dus te kunnen maken had ik de werkelijk gewerkte uren nodig. Deze konden (met enige moeite en autorisatie) uit een centraal management systeem verkregen worden. Daar zaten echter twee nadelen aan: De output was op weekniveau, en er was geen onderverdeling in het soort uren (administratieve handelingen en al het andere). Als iemand vergadering, studiedag of telefonische werkzaamheden verrichtte, dan kon dit niet herleid worden. Daarmee werd een berekening waardeloos.

Uitwerking van de case
Voor deze opdracht heb ik een tool ontwikkeld. Deze las dagelijkse de afgewerkte handelingen uit van medewerkers en controleerde op veranderingen in de norm tijden. Nu had ik nog de input nodig van de medewerkers die aan konden geven hoeveel uur ze op het administratieve systeem hadden gewerkt. Om dit zo eenvoudig mogelijk te maken konden roosters eenvoudig ingevoerd worden. Deze werden naar een planning in tijd geëxtrapoleerd. Alleen de afwijkingen invoeren volstond.

Nu was de output zuiver als mensen op tijd hun uren hadden ingevoerd. Diverse rapporten gaven inzicht op medewerker en afdeling niveau afgezet tegen een periode van tijd.

Door teamleiders aan te sturen kon de tool per afdeling worden uitgerold.

Teamleiders blij omdat ze nu ook op getallen konden sturen, opdrachtgever blij omdat een probleem was opgelost.

Alleen als je dit bekijkt in het kader van rationaliseren was dit helemaal niet goed. Het applicatielandschap was namelijk ingewikkelder geworden. Bij veranderingen had dit mogelijk ook impact op de tool en mensen moesten weer extra handelingen verrichten en een tool heeft ook onderhoud nodig als iets niet werkt of als er een fout hersteld moet worden. De IT kosten zijn dus toegenomen.

Hoe de case uitgewerkt had moeten worden
Allereerst was een besluit nodig of het een probleem was dat uren op week niveau binnen kwamen zoals beschreven in de case. Als dit geen probleem was, konden de uren geautomatiseerd worden ingelezen. Ik denk dat het geen probleem was. Je stuurt niet op wat er op een dag is gebeurd. Een slechte dag wordt misschien weer gecompenseerd met een goede dag later in de week. Je wilt niet sturen op microniveau, maar op trends. Welke afdeling zit onder de norm, en daarna, welke medewerker zit onder de norm, en in mijn ogen gebeurt dit niet op dagniveau.

Het eerste probleem dat er alleen een geautomatiseerde input op weekniveau beschikbaar was lijkt dus niet het grote probleem te zijn. De specificatie van de uren was dat wel. Door te kijken wat er mogelijk was aan de invoerkant, namelijk dat uren beter gespecificeerd moeten worden bij invoer zou dit opgelost kunnen worden. Ik had kort onderzoek gedaan en zag dat er wel wat meer mis was met de invoer. Zo boekte de ene afdeling reistijdcompensatie netjes, bij de andere afdeling werd alleen het totaal ingevoerd. Hier zat dus al een vervuiling die organisatorisch opgelost kon worden. Ook dat is rationaliseren, processen uniform maken levert economisch voordeel op.

Door dus de wijziging in de manier van registreren te veranderen (een organisatorische uitdaging) zou de berekening geautomatiseerd kunnen verlopen en het systeem veel eenvoudiger maken. Wellicht is er dan helemaal geen tool nodig en kan het met slimme rapportages worden uitgevoerd.

Deze manier van uitvoeren is wel lastiger omdat meer mensen op één lijn moesten komen en er meer mensen bij het proces betrokken zijn. Er was dus minder input van techniek nodig en meer input van de organisatie.

Conclusie
De case is in mijn ogen een goed voorbeeld over de subtiliteit van rationalisatie en het nemen van goede, maar moeilijke beslissingen. De case was goed uitgewerkt en heeft geleid tot een goed resultaat, de gekozen oplossing was dus helemaal niet fout en mogelijk de enige mogelijkheid. Maar op de langere termijn en met een visie van vereenvoudiging was de case niet goed uitgewerkt. De investering lag nu meer in techniek terwijl deze in de organisatie had moeten zitten. Dit is in mijn ogen een heel goed voorbeeld hoe het er in de praktijk aan toe gaat. Er wordt een technische oplossing gezocht terwijl een voornamelijk organisatorische oplossing had kunnen volstaan. En als je aan een techneut of leverancier een probleem beschrijft, zal deze in de regel zoeken naar een technische oplossing omdat dit namelijk geld oplevert en met de minste weerstand kan worden uitgevoerd. De gerationaliseerde oplossing zou de leverancier overbodig maken, en als de trend doorzet voor omzetverlies zorgen. Maar dan moet er wel goed leiderschap aanwezig zijn.

Rationaliseren is zeker niet (in alle gevallen) slecht voor een leverancier, maar dit voorbeeld illustreert wel wat ik bedoel met rationaliseren en dat dit meer vergt van een organisatie dan een besteding van geld.

Wat laatste gedachten
Uiteraard is niet alles zwart-wit. In het beschreven geval was rationaliseren misschien niet goed mogelijk geweest. Een andere oplossing was wellicht dat de administratieve software zou registreren wanneer een gebruiker inlogt en uitlogt, maar dan heb je weer de mogelijke afwijking dat iemand niet netjes afsluit voordat hij of zij een vergadering in gaat. Punt blijft wel dat als je een ontwikkelaar vraagt naar een oplossing, deze vaak gevonden wordt in het maken van een tool.

Besparen met rationaliseren

Het hebben en beheren van software kost veel geld. Vooral als dit maatwerk is of maatwerk op standaard software. Dit kom ik zeer veel tegen in de praktijk en de werkelijke kosten hiervan zijn nog hoger dan een optelling van de uren die besteed worden aan externe consultants, licentiekosten en kosten die gepaard gaan met het upgraden van deze niet meer zo standaard software. Deze kosten stijgen nog sneller als de software al langer mee gaat. Een ander fenomeen is dat er door de tijd steeds meer software bij komt.

Naast al deze zichtbare kosten zijn er ook onzichtbare kosten die niet direct gekoppeld worden aan het hebben beheren en onderhouden van deze software. Dit zijn kosten zoals de uren die vanuit de eigen organisatie besteedt worden aan deze software, bijvoorbeeld die van de IT afdeling. Maar de vergaderingen, testen en overleg uren van niet IT mensen over de software problematiek zijn per definitie onzichtbaar en worden niet toegekend aan de total cost of ownership (TCO).

Hoe groter het applicatielandschap hoe meer verborgen kosten er zijn en de grootte is nauwelijks vast te stellen. Vraag er eens naar binnen de organisatie. Kansen zijn zeer groot dat mijn stelling direct bewezen wordt. Klopt dit niet? Gefeliciteerd, u bent echt de eerste!

Hoe kunnen die kosten verlaagd worden? Hoe kan er op software bespaard worden?

Dit is geen gemakkelijke taak en het inhuren van een ervaringsdeskundige is een goede beslissing (hint: check de schrijver van dit artikel).

Een belangrijke eerste stap is bewustwording. Als de kosten inzichtelijk worden gemaakt kan de potentie van de besparing gedimensioneerd worden. Als deze bewustwording er is komt stap 2: Het rationaliseren van het applicatielandschap; of in mensen taal economischer maken.

Een aantal acties die onder rationaliseren vallen zijn: Pensioneren, Consolideren, vervangen, verbouwen, bevriezen, virtualiseren, ontsluiten, et cetera.

Voor elke voorbeeld geldt dat sommige manieren veel beter zijn dan andere manieren en foute toepassing leidt tot meer kosten. Onderschat interne politiek en gebrek aan consensus niet.

Praktische voorbeelden van rationaliseren zijn dat aanvragen op het gebied van aanpassingen scherp onder de loep genomen worden en dat een organisatorische wijziging verkozen wordt boven een software aanpassing. Dat er serieus gekeken wordt om een applicatie met pensioen te sturen of te verplaatsen naar een gevirtualiseerde server. Uiteindelijk wil je het applicatie landschap eenvoudiger maken en zoveel mogelijk aan laten sluiten op standaard software. Als een ander bedrijf in dezelfde branche het met standaard software kan, waarom uw organisatie niet?

Hoe slanker de software, hoe minder er over gesproken hoeft te worden, hoe minder incidenten plaats vinden en hoe makkelijker de software mee groeit met de nieuwe ontwikkelingen. Less is more. En hoe minder er is om rekening mee te houden hoe flexibeler uw organisatie wordt.