Managed hosting door True

Veel bedrijven kampen met trage software

 

Bijna 90 procent van de Nederlandse organisaties kampt met trage applicaties. In België worstelt 60 procent van de organisaties met dit productiviteitsprobleem.

Dat blijkt uit onderzoek van Citrix Systems. Het bedrijf vroeg 285 zakelijke computergebruikers in diverse sectoren naar hun ervaringen op het gebied van software-applicaties en de toegankelijkheid daarvan. De meerderheid van de organisaties in de Benelux heeft last van trage applicaties. In de meerderheid van de gevallen ligt het probleem aan de software zelf en niet aan de hardware of het netwerk.

De redenen voor de traag werkende software zijn divers. Bij 28 procent van de ondervraagde organisaties is slecht werkende hardware het probleem. Bijna een op de drie organisaties denkt dat het probleem aan de netwerkcapaciteit ligt. In de meeste gevallen is echter de software zelf de reden voor de traagheid; bijna de helft van de respondenten gaf dit als belangrijkste oorzaak aan.

Uit het onderzoek komt ook naar voren dat webapplicaties in de Benelux steeds populairder worden. 65 procent van de ondervraagde organisaties heeft het afgelopen jaar nieuwe webapplicaties in gebruik heeft genomen. Bij een kwart van de organisaties betrof het vijf of meer nieuwe toepassingen.

Heeft uw organisaties ook te maken met trage software? Wat is de oorzaak van dit probleem? Geef uw mening op computable.lezers@bp.vnu.com  of klik op de link ‘reageer op dit artikel’.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/1671963). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

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

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×