Sinds Gartner Application Performance Management (APM) op de kaart heeft gezet, worden links en rechts APM initiatieven ontplooid binnen de Top 300 van Nederlandse organisaties. APM is het vakgebied dat zich bezig houdt met het monitoren, diagnosticeren en het managen van software applicaties waarbij eindgebruikers beschikbaarheid en performance de hoofdrol spelen. Ondanks duidelijke signalen dat organisaties het helemaal niet op orde hebben op het vlak van beschikbaarheid (zoals Allestoringen.nl elke dag laat zien) en performance, blijft de Top 300 aanmodderen met APM dan wel ziet men nog niet in dat het hoogtijd wordt om APM serieus op te pakken en op de agenda te plaatsen van iedere CIO.

Het is een verontrustende ontwikkeling als je ziet dat de gehele manier van dienstverlening in rap tempo aan veranderingen onderhevig is. Laten we de bancaire sector als voorbeeld nemen. De banken van tegenwoordig voeren een real-time online strategie waarbij men 24×7 beschikbaar moet zijn. De oude batch wereld is in rap tempo aan het verdwijnen. De bancaire sector ziet in dat ze innoverend moeten zijn om hun klanten niet kwijt te raken aan een bank die veel hipper is. De klant moet dezelfde klantervaring hebben, ongeacht via welk bankkanaal de klant binnenkomt en zaken doet, en niet het gevoel krijgen dat hij keer op keer dezelfde informatie moet verstrekken om iets voor elkaar te krijgen. Banken maar ook andere sectoren hebben hun focus op de jeugd, zij zijn de toekomst. Zij zijn gewend om nieuwe technologie sneller te omarmen, maar zijn ook genadeloos om de nieuwe functionaliteit af te serveren als deze niet voldoet aan hun ervaring. Daarnaast moet deze functionaliteit altijd aanwezig zijn of in ieder geval als men de dienst wil consumeren, waarbij het belangrijk is dat de dienstverlening snel moet presteren.

Ik constateer op basis van mijn gesprekken met potentiële klanten dat in negen van de tien gevallen APM niet of niet serieus is opgepakt door de organisatie. Van bestaande APM initiatieven valt het me op dat in het algemeen het rendement (Return Of Investment (ROI)) zwaar onder de maat is en blijft.

Dat brengt me tot het schrijven van dit Blog-artikel: Wat zijn de oorzaken dat APM maar mondjesmaat wordt opgepakt door de Top 300 bedrijven van Nederland?

  1. De organisatie is te weinig performance bewust
Digital Performance Platform

Digital Performance Platform

De business van de organisatie is onvoldoende bewust van wat haar online strategie betekent voor het hebben van permanente grip en controle op de eindgebruikersperformance en beschikbaarheid van de aangeboden online dienstverlening. Er wordt geen concern breed APM-beleid gevoerd waardoor de organisatie de performancegedachte niet omarmd heeft. De business acteert behoorlijk naïef of weet eenvoudigweg niet dat er iets is als performance en wat de consequenties zijn als de online dienstverlening niet performant is. Men weet wel dat onbeschikbaarheid van belang is, maar men koppelt onbeschikbaarheid niet aan performance. Als een website niet presteert, dan kan de eindgebruiker de dienstverlening als onbeschikbaar gaan ervaren.

In de bestaande organisatie zijn de (ITIL-)processen niet aangepast of onvoldoende ingericht waarin performance op de agenda staat. Een voorbeeld is dat changes beoordeelt dienen te worden op wat de impact is van de verandering op de responstijd en beschikbaarheid van de eindgebruiker. Vanuit capacity management en service management dient er een vertaling te zijn van wat marketing acties betekenen voor de verwachte belasting op de online dienstverlening. En bij incident en problem management moet er uit analyses van de incidenten en problemen blijken wat de oorzaak is van de verstoringen. Ligt de oorzaak in het niet goed uitvoeren van performance testen conform smart gemaakte Non Functional Requirements? Doet men alleen aan resource monitoring op de productieomgeving waarin er tijdsgaten zitten waarop er geen meetwaarden zijn waardoor men blind is wat er exact gebeurt? Weet men wel wat de eindgebruiker ervaart op het vlak van performance en beschikbaarheid?

Door gebrek aan kennis over eindgebruikersperformance en beschikbaarheid op businessniveau is men sterk afhankelijk van wat de ICT-organisatie voor gedachten erop nahoudt over performance en beschikbaarheid. De ICT-organisatie handelt echter conform aloude denkpatronen waarbij men denkt dat het monitoren van resource utilisation voldoende is en dat het iets zegt over de eindgebruikersperformance. Het dashboard van de beheerders toont groene stoplichten, terwijl de eindgebruiker klaagt over de onbeschikbaarheid en slechte performance van de geboden functionaliteit.

De diverse rollen die betrokken zijn bij en verantwoordelijk zijn voor performance en beschikbaarheid reageren reactief in plaats van pro-actief ondanks de aanwezigheid van allerlei dure tools, methoden, technieken en processen. De performance gedachte loopt niet als een rode draad door de applicatie life cycle en het performance denken zit niet in het DNA van de mensen. Zo komt het voor dat anno 2015 er nog steeds grote organisaties zijn die denken er mee weg te komen om applicaties naar productie te brengen zonder adequate performance te eisen, performance te testen en performance te monitoren. Zo ontstaat er een lucratieve markt voor partijen die het monitoren van de performance en beschikbaarheid maar op zich nemen om de organisaties te controleren op en te confronteren met de beschikbaarheid en performance van de online dienstverlening. De site Allestoringen.nl toont genadeloos aan wat de onbeschikbaarheid is van de online websites van de grote organisaties, waarbij een koppeling plaatsvindt tussen keiharde meetwaardes en de subjectieve meningen van klanten van de diensten op de diverse social media. Actieve monitoring diensten zoals dynaTrace Gomez, mPulse of Ymonitor meten naast beschikbaarheid ook responstijd. De PR en marketingafdelingen van menig organisatie zouden continu ongerust moeten zijn, omdat de verstoringen en slechte responstijden het positieve corporate imago verstoren.

Om APM te kunnen realiseren, is het van belang dat tooling voldoet aan de APM-eisen. De ICT-organisatie haalt de diverse beschikbare tooling door elkaar waardoor men denkt dat het al APM tooling in huis heeft om performance en beschikbaarheid vanuit de eindgebruiker te monitoren. De ICT-organisatie houdt zich krampachtig vast aan de monitoring software van de grote vier (HP, CA, IBM,  BMC) die hopeloos achterlopen qua functionaliteit op de APM-ontwikkelingen, waardoor een schijnzekerheid ontstaat waarbij de organisatie onterecht denkt dat ze grip en controle heeft.

  1. Er is geen requirement management
Require Management

Require Management

Functionele eisen worden aan het begin van [programma’s|projecten] gedefinieerd. Non-Functional Requirements (NFR’s) zijn er nauwelijks en als ze er zijn, dan zijn ze totaal niet SMART gedefinieerd en ontbreekt het aan smart gemaakte definities wat men onder de diverse performance-eisen verstaat. Een ingericht proces voor het managen van requirements is rand voorwaardelijk om te zorgen dat de requirements up-to-date blijven en getoetst zijn. Bij het managen van de requirements hoort ook risico management; wat betekenen veranderingen in marketing strategie, nieuwe architecturen, applicaties etc. nu voor de reeds gestelde Non-Functional Requirements zoals throughput (tps), responstijden, beschikbaarheid, fail rate? Wat zijn de mitigerende maatregelen om te voorkomen dat bij live-gang van nieuwe functionaliteit de beschikbaarheid en performance van de huidige online diensten onder vuur komen te liggen? Kortom, het ontbreekt aan de noodzakelijke aanpassingen in de heersende processen en de kennis over performance-eisen binnen alle geledingen van de organisatie.

  1. DevOps ademt functionaliteit uit, geen performance

Doordat er geen performance requirements zijn en de performance awareness onder de maat is, is er onvoldoende aandacht voor performance binnen de applicatie life cycle en de betrokken organisatieonderdelen (DevOps). De DevOPs hebben hun vizier gericht op het leveren van nieuwe functionaliteit voor hun stukje binnen de keten. Daarvoor voelen zij zich verantwoordelijk en daar worden ze op afgerekend. De silogedachte overheerst, de ketengedachte niet. Dit tracht men op te lossen door het creëren van feature teams en het bij elkaar plaatsen van teams die verantwoordelijk zijn voor meerdere keten componenten. De performancetesten maken onderdeel uit van het [DevOps|Feature] team, maar worden uitgevoerd door mensen die niet of onvoldoende getraind zijn in het realiseren en uitvoeren van goede performancetesten en daar de tijd ook nauwelijks voor krijgen. Daarbij komt dat deze testen uitgevoerd worden door mensen die niet objectief kunnen zijn. Zij maken immers onderdeel uit van het team dat de software ontwikkelt. Hierdoor ontstaat “De slager keurt zijn eigen vlees”.

Ook zie ik dat de OPS-mensen binnen hun ketencomponent alleen aan technische monitoring doen (resource utilisation), maar men past geen performance monitoring en diagnostisering toe. Het zorgt voor een schijnzekerheid ten aanzien van performance met grote gevolgen voor de prestaties in de gehele keten.

  1. Ketengedachte: “Wat is dat?”

De beheergedachte binnen organisaties is nog steeds de silo. Als de beheerteams (of DevOPS) nu maar hun werk doen voor het component waar ze verantwoordelijk voor zijn, dan zit het wel goed. De DevOps-teams zijn verantwoordelijk voor de ontwikkeling van de applicatie en niet verantwoordelijk voor de onderliggende systemen en infrastructuur. Echter, de componenten vormen tezamen de value chain die de eindgebruikersfunctionaliteit aanbiedt. Deze dient te voldoen aan de afgesproken service levels. Het ontbreekt aan de saamhorigheid, de communicatie en de afstemming tussen de DevOPS-teams van de verschillende componenten om te garanderen dat de schakels in de keten tezamen goed functioneren en presteren conform de afgesproken performance-eisen. Het denken en acteren vanuit de keten is een organisatie verandering waar te licht of helemaal niet over wordt nagedacht. Het betekent veranderingen op de gebieden waaruit APM is opgebouwd (processen, organisatie, tooling). Het vraagt om een hele andere DNA van de mensen in je organisatie, de wil en de mogelijkheid om te veranderen, ofwel de intrinsieke motivatie.

  1. “Is er een keteneigenaar?”

Bij het ontbreken van de ketengedachte is er ook het gemis aan een keteneigenaar. De keteneigenaar is verantwoordelijk voor de gehele keten, zowel vanuit de business als vanuit de ICT. Deze rol moet zorgen voor de vereiste grip en controle op alle facetten die met de keten van doen hebben. Deze verantwoordelijkheid is belangrijk, omdat de keteneigenaar de rol is die bepaalt aan welke functionele en technische eisen veranderingen dienen te voldoen en deze ook laat valideren. De keteneigenaar begrijpt wat de impact is van een marketingcampagne op het te verwachten extra verkeer op de online websites van de organisatie. Voorbeeld 1: wanneer de eindgebruiker regelmatig onbeschikbaarheid dan wel verslechterde responstijden ervaart, dan zorgt de keten eigenaar ervoor dat deze problemen structureel worden opgelost. Voorbeeld 2: indien er in de keten grote veranderingen plaatsvinden op technsich gebied, bijvoorbeeld een migratie naar een data centrum, of de vervanging van de ene applicatie server smaak naar een andere, dan is de keteneigenaar verantwoordelijk voor het laten valideren van de veranderingen op de Non-Functional Requirements.

  1.  “We hebben het al”
Evolutie Performance Management

Evolutie Performance Management

De bekende uitspraak die wordt gedaan door de organisatie. Deze uitspraak heeft allerlei oorzaken. Een van de oorzaken is de aanwezigheid van een een krachtige interne software vendor lobbye. Het is de onzichtbare “vijand” van menig APM-initiatief waardoor het niet van de grond komt of waarbij het huidige APM-initiatief ondanks een aantoonbare lage ROI niet ter discussie staat. In alle lagen van de organisatie wordt bewust geroepen dat het nieuwe APM-initiatief veel geld kost, dat de huidige tooling briljant is en exact hetzelfde kan doen als het nieuwe APM-initiatief. Vervolgens komt de propagandamachine in actie en worden het prijsargument en andere dogredenen aangevoerd om het nieuwe APM-initiatief te ondermijnen. En tenslotte worden de tal van tool POC-initiatieven weer van stal gehaald, zonder afstemming op de concern brede ambitie rondom performance. Niemand grijpt in, geld en tijd van resources worden verbrand.

Grote contracten waaronder die van APM worden gesloten op de golf-baan en daar commit de hogere legerleiding zich aan. Men wil geen gezichtsverlies lijden door toe te moeten geven dat er een verkeerd besluit is genomen of dat het tijd wordt voor verandering. Geen enkele organisatie hoort graag dat ze met de huidige investeringen in APM niet die gewenste grip en controle hebben weten te bewerkstelligen.

Maar is er dan niemand binnen de organisatie die een gedegen analyse heeft gedaan van de incidenten en problemen, die gekeken heeft naar de huidige inrichting en uitnutting van de tooling, die de volwassenheid van de vereiste processen, organisatie en mensen onder de loep heeft genomen en tot de conclusie komt dat de huidige APM-implementatie een schijnzekerheid biedt?

  1. Aandacht voor slechts de tooling, niet voor APM als geheel

Als APM wordt opgepakt door een organisatie, dan wordt veelal slechts de tooling opgepakt. Voor de noodzakelijke processen, organisatie, mensen en afstemming binnen de gehele organisatie is er weinig aandacht.  De focus ligt puur op de technische implementatie van de tool en de technische producttrainingen die men kan volgen. Het implementeren van de tooling is traditioneel een klus voor de ICT-afdeling, geholpen door de APM-vendor of een lokale dienstverlener. Het probleem hierin is, dat de meeste dienstverleners helemaal niet de kennis, kunde en ervaring hebben om de managementkant van APM op te pakken. Zowel de software vendor als de dienstverleners rekenen torenhoge tarieven om APM als geheel te implementeren, waar de klantorganisatie op basis van negatieve ervaringen en lage ROI met vroegere zware tool framework implementaties helemaal geen zin in heeft.

Tooling blijft hangen in het vergelijken van producten (product feature vergelijk), het doen van POC-op-POC waarbij SMART-gemaakte functionele en technische acceptatiecriteria ontbreken die niet of onvoldoende in lijn zijn met de wensen en behoeften van de business. Op deze manier houdt de tooling-afdeling hun eigen ecosysteem in stand met hoge operationele kosten om de tooling te laten doen wat het in hun ogen zou moeten doen.

Ook wordt vaak de liaison rol gemist die de brug slaat tussen tooling en de business. Deze rol begrijpt wat de tool aan functionaliteit kan brengen waar de business baat bij heeft, weet de business’ wens te vertalen naar aan te bieden tool-functionaliteit en peilt regelmatig of de tool-functionaliteit voldoet aan de business’ wens.

  1. APM sluit niet aan bij ambitie van de organisatie

APM tool leveranciers en dienstverleners willen te snel gaan met het implementeren van APM en pakken de APM implementatie te groot aan. De klantorganisatie zucht onder het juk van de APM-implementatie en kan de vele veranderingen op [proces|organisatie|tool] simpelweg niet bijhouden. Er is onvoldoende geluisterd naar wat de ambitie en behoefte is van de klant en de heart beat waarin de klant leeft en opereert. De klantorganisatie begeeft zich ook op een bepaald volwassenheidsniveau met het daarbij behorende skill level.

Tevens moet goed gekeken worden of de APM-toolleverancier en/of de -dienstverlener de klant wel kan bedienen op basis van het gewenste ambitie niveau. APM tool leveranciers en dienstverleners die APM in hun portefeuille hebben, zijn goed in licentieverkoop en de initiële APM-toolimplementatie middels hun eigen Professional Services Organisation (PSO). Echter, de transitie van de APM-projectimplementatie naar de lijn vraagt wederom om een andere skillset want het gaat niet alleen om de tool. APM herbergt het woord “Management” in zich! De transitie houdt een verandering in van de huidige organisatie en haar medewerkers attitude (pro-actief i.p.v. reactief).

  1. “Performance en onbeschikbaarheid is opgelost, we hebben het niet nodig”

Zo zijn er situaties waarin er performance-pijn was en deze incidenteel is opgelost. De organisatie vindt het daarna niet meer nodig om de verhoogde bewaking aan te houden en te effectueren in een APM-initiatief. De huidige tooling volstaat. Menig klant ziet APM als een EHBO-kitje; je pakt het erbij op het moment dat er problemen zijn. Dit is typisch het gedrag van een reactieve organisatie. Het is als het leven op een slapende vulkaan, je weet nooit wanneer de vulkaan losbarst. De performance-pijn is er nog steeds, maar is niet waarneembaar, omdat men het niet meet en er dus geen weet van heeft.

  1. Te veel veranderingen in de klantorganisatie

Ondanks duidelijke signalen dat een APM-initiatief vruchtbare voedingsbodem heeft bij de klant, wordt er onvoldoende progressie geboekt. Meerdere grote veranderingen vinden tegelijk plaats zoals grootschalige projecten en interne organisatieveranderingen waardoor het initiatief blijft steken, de APM-focus verslapt en er weinig budget aan wordt toegekend. Het APM-initiatief moet knokken en zorgvuldig door een orkaangebied laveren om enigszins rendement te halen. Veelal hebben deze projecten wel baat bij een APM-initiatief om te voldoen aan de eerder genoemde Non-Functional Requirements.