Diagnose, Ontwerp en Verandering

Snelheid (en snel een beetje)!

Snelheid is voor IT toepassingen vaak cruciaal. Toch worden deze lastige eisen zelden vooraf goed expliciet gemaakt, laat staan het zeer kundig analyseren van de consequenties van deze eisen op het systeem waaraan deze eisen worden gesteld.Bij het ontwerpen van complexe IT systemen is het noodzakelijk om zo vroeg mogelijk de prestatie-eisen scherp te krijgen. Prestatie-eisen worden vaak aangeduid met performance eigenschappen, maar vanuit ontwerp betekent dit vaak de volgende twee aspecten:

1-    Wat is de tijd waarbinnen een proces afgerond moet worden?

2-    Is er een IT systeem te realiseren wat kan voldoen aan de gestelde prestatie-eisen?

Vanuit de bedrijfskunde is gelukkig meer dan 100 jaar wetenschappelijke kennis beschikbaar die gebruikt kan worden voor het ontwerpen en optimaliseren van bedrijfsprocessen, zodat aan gestelde prestatie-eisen kan worden voldaan. Zo zijn vele methoden voor het optimaliseren van logistieke processen gemeengoed, maar ook als snelheid voor een klant noodzakelijk is, zijn vele methoden en technieken bekend om bijvoorbeeld via voorkomen van arbeidsdeling snelheid én werkvreugde hoog te houden. Veel is geschreven over een optimale inzet van schaarse (en vaak dure) productiemiddelen om zo toch aan gestelde prestatie-eisen te kunnen voldoen. Denk aan het inzetten en plannen van een operatiekamer, waarbij wachtlijsten voorkomen moeten worden. Capaciteit en performance is in de fysieke wereld vaak erg lastig te ontwerpen en te plannen. Denk aan het ontwerp van een stadion, waarbij het toch wenselijk is dat alle 100.000 bezoekers binnen 1 uur op de juiste stoel zitten, na afloop ook binnen redelijke tijd weer weg kunnen.

In de IT, waarbij klanten via internet een transactie moeten kunnen uitvoeren, is het ontwerpprobleem voor snelle systemen vaak nog lastiger en wordt het ontwerpprobleem zeer vaak onderschat. Zo is menig organisatie niet goed voorbereid op een plotselinge toeloop van tienduizenden klanten via het internetkanaal. Zo ligt de site voor Obamacare al maanden onder vuur. Het probleem met complexe digitale interactie is echter dat zonder het totaalontwerp te kennen vaak onmogelijk is om dé oplossing voor een bestaand probleem te realiseren. Wel is het gelukkig goed mogelijk om met de altijd aanwezige onzekerheid in het specificatietraject de architectuur zo op te zetten dat performance problemen alleen daar optreden waar ze te verwachten zijn, en dan zijn deze ook vanuit ontwerp natuurlijk eenvoudig te verhelpen.

slakZo kan het bij inzet van een webserver een goede overweging zijn, om als risico verminderde maatregel direct een webserver in te zetten die ontworpen is voor high performance omgevingen. Zoals bijvoorbeeld inzet van de bekende open source webserver nginx (zie http://nginx.org). Nginx  is een op events gebaseerde webserver.  Naast het kiezen van het juiste product is een goed ontwerpprincipe ook om processen te ontkoppelen waar mogelijk en nodig. Zo is het bijvoorbeeld niet handig om een vrachtwagen direct de weg op te sturen met slechts een pakketje erin, maar een compromis van eenmaal per dag om toch de snelheid voor klanten die een wachten op bestelling kan een goed compromis zijn.

Het ontkoppelen van klantvraag en realiseren van de klantvraag kan ook bij eProducten soms een goede oplossing zijn om knelpunten in de snelheid die klanten ervaren bij een online kanaal te voorkomen. De kracht kundig toepassen van IT architectuur is dat vooraf rekening wordt gehouden met alle vertragende IT aspecten die kunnen optreden bij het realiseren van producten in de online wereld.