Wie betaalt de prijs van onwetendheid?

Investeringen in it-infrastructuren worden weinig gedaan op basis van een duidelijk beleid. Request for Proposal trajecten gaan vaak op ad hoc basis en nog vaker worden wat snel opgestelde technische specificaties bij een paar partijen neergelegd om uiteindelijk voor de laagste prijs per kilo te kiezen. Het gevolg is dat er verrassend veel slechte beslissingen worden genomen over de it-infrastructuur – ook in grote, proefessionele organisaties.

Hoe kun je ervoor zorgen dat je een juiste beslissing neemt waar je ook na drie jaar geen spijt van hebt? Zo moet het in ieder geval niet:

"Ik wil graag een offerte voor 10 TB schijfruimte. Wat kost dat?"

Het is jammer dat de capaciteitsvraag meestal als de belangrijkste wordt gezien bij de keuze voor een storagesysteem. Niet omdat capaciteit niet belangrijk zou zijn, maar omdat het bijna dezelfde vraag is als: "Ik wil graag een nieuwe auto. Wat kost dat?". Iedereen snapt dat die laatste keuze van meerdere factoren afhankelijk is. Veiligheid, ruimte, betrouwbaarheid, snelheid, trekkracht, et cetera.

Te weinig informatie
Bij het kiezen van de juiste storage-oplossing gelden ruwweg dezelfde overwegingen. Storage is een ondersteunend deel van de infrastructuur en moet de groei van de bedrijfsactiviteiten ondersteunen. Het moet voldoen aan de hoogste beschikbaarheidseisen teneinde de applicatie- en serverlaag optimaal te voorzien van stabiele toegang tot data en moet die data in het geval van calamiteiten tóch veiligstellen. De keuze voor een nieuwe storage omgeving kan dus met goed fatsoen niet beperkt blijven tot een schatting van het aantal terabytes en algemene uitspraken over ‘we moeten de boel wel weer binnen een halve dag kunnen terugzetten vanaf tape'. Uiteraard ligt het genuanceerder dan dit, maar feit is dat veel belangrijke beslissingen worden genomen op grond van veel te weinig informatie.

Dit is met name het geval als het gaat om het vaststellen van de minimale performance-eisen of de tijd die nodig is voor een grootschalige restore. Nog een voorbeeld van hoe het niet moet: "Wilt u dat de nieuwe omgeving sneller is dan de huidige?" "Nou, graag!" "Wat is uw huidige performance?" "Geen idee, hoe bereken je zoiets?" Een bijna letterlijke weergave van een gesprek met een it-manager, niet zo lang geleden. Het budget lag boven de twee ton, maar welke van de reeds uitgebrachte voorstellen nu het beste was, kon de manager in kwestie niet beoordelen omdat hij appels, peren, pruimen en meloenen aangeboden had gekregen. En dan is het lastig kiezen.

Appels met appels vergelijken
Hij stelde overigens wel de goede vraag: "Hoe bereken je zoiets?" Die vraag moet worden gesteld als het gaat om het bepalen van de minimale piekperformance die een systeem moeten kunnen leveren, maar ook als het gaat om het maximale dataverlies, de schaalbaarheid van het systeem, en de minimale beschikbaarheid. Het is heel goed mogelijk om daar vooraf een checklist van op te stellen die door verschillende aanbieders op verschillende manieren kan worden ingevuld, maar in alle gevallen dezelfde eigenschappen zal hebben. Je vergelijkt dan een Elstar met een Goudreinet, en dat kiest toch een stuk prettiger.

Nieuw is het gebruik van een checklist niet. In feite kent iedereen die checklist in de vorm van een functioneel ontwerp, maar voor sommige organisaties is dat een stap te ver. Het idee bestaat vaak dat een (her)ontwerp voor vervanging of uitbreiding van een deel van de infrastructuur niet noodzakelijk is. Die aanname klopt meestal niet. Denk aan het plaatsen van een dakkapel: ook al is dat standaardwerk, toch wil je graag vooraf een tekeningetje zien om zeker te weten dat het voldoet aan je verwachtingen, en of het wel helemaal goed gaat passen, voordat je gaat zagen.

Kies verstandig, vraag om appels
Om de beslissing over storage, back-up en archivering zo objectief mogelijk te kunnen nemen moet niet worden beknibbeld, en gelukkig bestaan er modellen die het mogelijk maken om die keuze te maken, zonder dat er moet worden geïnvesteerd in dure it-architecten. Er zijn uiteenlopende beslissingsmodellen waarmee een onafhankelijke checklist kan worden opgesteld, waardoor een goed onderbouwde afweging kan worden gemaakt van de oplossingen van meerdere leveranciers. In plaats van dat je je weg moet zoeken in een ‘fruitmand' van features en it-jargon, dwing je alle aanbiedende partijen om hun mooiste appel te presenteren. Het voordeel is dat je een heel gezonde, functionele beslissing kunt nemen.

Naast een model dat ervoor zorgt dat verschillende oplossingen vergelijkbaar zijn, is het meestal zo dat een nader onderzoek nodig is om te achterhalen wat de werkelijke eisen zijn. De praktijk leert dat je technische eisen als i/o-belasting en de failover tijd van server clusters niet kunt baseren op nattevingerwerk: je zult gewoon moeten testen en de juiste formules moeten hanteren om te weten welke systemen wel, en welke niet geschikt zijn. Je mag nooit voetstoots aannemen dat een systeem werkt zoals het in de brochure staat beschreven; de praktijk levert per definitie andere resultaten op.

Risico's vermijden
Zo'n onderzoek kost geld, maar interessant genoeg blijkt dat het gebruik van een beslissingsmodel en het uitvoeren van relevante assessments om een objectieve baseline vast te stellen, tot concrete kostenbesparingen leiden. Dat heeft te maken met de natuurlijke neiging om risico's te vermijden. Als je niet precies weet hoe je data groeit, zul je geneigd zijn om de capaciteit wat ruimer in te schatten, en als je niet weet wat voor performance de servers van de storage vragen, zul je geneigd zijn om op zeker te spelen en te kiezen voor Fibre Channel terwijl iSCSI misschien uitstekend zou passen. Wie echt risico's wil vermijden, kiest daarom voor een vooronderzoek. Dat er iedere dag weer beslissingen worden genomen over systemen met een totale waarde die vaak ver boven de ton ligt, zonder dat er gebruik wordt gemaakt van simpele methodes om ervoor te zorgen dat appels met appels worden vergelijken, is jammer en leidt tot onnodige investeringen. Noem dat gerust de prijs van onwetendheid.