In een wereld waar steeds meer kernapplicaties gevirtualiseerd zijn, bestaat een applicatie voor een gebruiker uit schermen. Een gebruiker zit bijvoorbeeld in Rio de Janeiro, terwijl applicatie en data in een rekencentrum in Frankfurt zoemen. Een dikke, digitale pijplijn verbindt alles. In client-server omgevingen draaien applicaties veelal decentraal met een ‘dikke’ desktop. Er zit geen halve wereld tussen.
Wat betekent de trend naar virtualisatie voor key performance indicatoren?
Voor applicaties gelden traditioneel ratio's als login- en responstijden. Voor infrastructuur gelden andere kengetallen als bandbreedte en server utilisation. Beide groepen metrics zijn in een virtuele omgeving van belang voor de échte performance. Tientallen technische metertjes moeten integraal worden gemonitord. Met application performance management tools worden technische prestaties al gemeten. APM is zinvol, maar meet traditioneel vanuit het datacenter. Wat goed presteert in een datacenter in een virtuele omgeving, hoeft nog niet goed te werken op het device van de gebruiker. Soms zit er een halve wereld tussen. De optelsom van datacenters, netwerken en uiteindelijk het device (notebook, desktop, tablet, smartphone) bepalen de echte performance.
Virtueel gaan betekent dat datacenter, netwerk en device samen de performance bepalen. De geaccepteerde norm is dat SLA's gaan over uptime, CPU performance, bandbreedte en andere technische parameters. Deze typische meetratio's helpen echter om te bepalen wat de werkelijke performance is. Gebruikers kunnen bijvoorbeeld klagen dat hun applicaties traag zijn bij een utilisation van een applicatieserver bij 90 procent, maar ook bij 50 procent. ‘Rara', wat is de oorzaak? Bij multisourcing wordt het antwoord nog ingewikkelder: applicaties en infrastructuur zijn ondergebracht bij verschillende service providers. Samenwerking moet dan in het DNA zitten.
Wanneer bedrijven hun it-infrastructuur uitbesteden en de transformatiestap zetten naar applicatie en desktopvirtualisatie, kun je niet langer gescheiden KPI's hanteren. De gebruiker is de enige die ervaart of het allemaal werkt. User experience is echt iets anders dan het klassieke onderzoek naar gebruikerstevredenheid. In de regel wordt eens per jaar een kto'tje - jargon voor klanttevredenheidonderzoek - gedaan. Doordat je een keer per jaar meet, meet je gestolde emoties in plaats van relevante service-ervaringen.
Wat doe je wanneer een gebruiker belt met de servicedesk dat zijn applicatie of de desktop ‘zo traag is'? De desbetreffende gebruiker wordt langzaam gek. In de meeste gevallen wordt dan weliswaar een ticket aangemaakt, maar vervolgens wordt die afgesloten zonder dat het probleem is opgelost. Het is namelijk geen incident dat wordt aangemeld, maar een impliciete klacht. En daar is (vaak nog) geen proces voor. Of gebruikers krijgen te horen dat de traagheid komt doordat hardware sterk is verouderd. De gebruiker krijgt eerst een opbeurend mailtje van de service desk in de stijl van ‘wij kunnen er ook niets aan doen', een minuut later volgt een tweede mailtje met de strekking: ‘het ticket is hierbij gesloten'. Dan moet je niet vreemd opkijken als er geen enkele positieve beweging in het jaarlijkse kto-tje zit.
Het is het serieus luisteren naar de belangrijkste graadmeter voor de performance in een sterk gevirtualiseerde omgeving. Wie uitbesteedt zal extra alert moeten zijn op hoe user experience in het stuurraamwerk wordt opgenomen. En graag ook aandacht voor ouderwetse technische KPI's die belangrijker worden dan ooit. Hoeveel tijd zit er tussen een muisklik of het intoetsen van de return-key om een verzoek te submitten en het op je scherm zien van de resultaten? Deze tijd wordt key-to-glass genoemd en is een belangrijke meting om gebruikerservaring ook technisch te meten.
