Een herkenbaar verschijnsel.
Jaar in jaar uit wijzen applicatiebeheerders en gebruikers in onze organisatie naar de servers en het netwerk bij snelheidsproblemen. Telkens weer kunnen we aantonen dat dit niet het geval kan zijn. Externe firma's die hier werkzaamheden moeten verrichten bevestigen onze stelling. Het netwerk en de servers functioneren zeer goed en snel. Het grootste probleem doet zich voor met het ZIS (Ziekenhuis Informatie Pakket). Ik zal de leverancier niet noemen, maar de keuze van de databases en de modulaire programmatuur laat wat snelheid zeer te wensen over. Om over de behoeften van opslag nog maar te zwijgen.
Specialisten weigeren om met bepaalde onderdelen van het pakket te werken omdat wachttijden lopen van 10 tot 72 sec. om een bepaald verslag gepresenteerd te krijgen. Er zou door de programmeurs veel meer aandacht moeten worden besteed aan de snelheid van pakketten. Nu worden vaak honderden libraries mee gecompileerd omdat het maken van een kleine en noodzakelijke selectie te veel kost. Dit vertraagt wel het pakket en zorgt voor extra problemen bij updates etc.

De oorzaken van slechte software performance
 
De oorzaak van veel problemen met de prestaties van applicaties ligt mijns inziens aan meerdere aspecten die tijdens het ontwikkelproces fout gaan.
 
De eerste stap waarbij het fout gaat, is bij het opstellen van de requirements in de ontwikkelfase. Hierbij wordt dikwijls onvoldoende rekening gehouden met de infrastructuur en de performance-eisen. Het is meer regel dan uitzondering dat tijdens het ontwikkeltraject wel de ontwikkelaars, testers en webdesigners worden betrokken, maar niet de netwerk- en databasespecialisten. Het is echter van cruciaal belang om de infrastructuur en performance-eisen te definiëren en om alle ‘stakeholders’ bij het ontwikkelprocess te betrekken.
 
Vervolgens worden veel nieuwe of vernieuwde bedrijfsapplicaties geïmplementeerd zonder de performance hiervan te valideren. Applicaties die in de test- en ontwikkelomgeving uitstekend hebben gepresteerd, kennen in de productieomgeving echter soms een slechte performance. Applicatieprofilering kan dit voorkomen, doordat eindgebruikers transacties in de bedrijfsapplicatie door de gehele multi-tier applicatieketen kunnen volgen. De performance, hoofdzakelijk de responsetijd van de transactie, moet worden geanalyseerd en getuned vóórdat de applicatie wordt geïmplementeerd.
 
Een ander probleem is loadtesting. Bij veel bedrijven vindt dat pas plaatsvindt na de ontwikkelfase. Loadtesting heeft als doel te bepalen hoeveel eindgebruikers de applicatie tegelijk kunnen gebruiken voordat de performance kritiek wordt. Naar mijn idee zou loadtesting dus naar de ontwikkelfase moeten worden verplaatst, zodat er bij het constateren van significante performance-problemen voldoende tijd is om deze op te lossen. Indien door loadtesting performance-problemen aan het licht komen, moeten deze ook worden geanalyseerd en opgelost. Best practice is om deze oplossingen door middel van ‘What if” scenarios te modeleren. Hiermee kan objectief worden bepaald of de bedachte oplossingen het probleem daadwerkelijk verhelpen. Dit voorkomt onnodige verspilling van tijd, resources en geld.
 
Naast het aanpakken van de genoemde knelpunten, is het tot slot nog essentieel dat ontwikkelteams aan het eind van het ontwikkelingtraject een gedetailleerde weergave kunnen geven van de applicatie- en systeemperformance. Deze weergave geeft de IT-manager de mogelijkheid om op basis van objectieve gegevens te bepalen of (extra) investeringen in infrastructuur of andere componenten in de applicatieketen noodzakelijk zijn. Deze objectieve gegevens kunnen tevens worden geïntegreerd in de change management processen van bedrijven die ITIL gebruiken. Zodra aan alle punten is voldaan, zal de software niet meer traag zijn maar betrouwbaar, schaalbaar, efficiënt en beheersbaar.
 
Winston Benjamin, presales consultant Application Service Management bij Compuware