Het gebeurt wel vaker. We zijn de hardware aan het regelen voor een belangrijk systeem, en vragen ons af of die wel genoeg capaciteit zal hebben. Daar wil je van te voren over nadenken, want gebrek aan capaciteit bij de ‘live’-gang leidt tot performanceproblemen tijdens productie. Dat is een onaanvaardbaar risico.
Je stelt dus aan de softwarebouwer de vraag hoeveel capaciteit je netwerk, servers en opslagruimte moeten hebben om je systeem goed te laten functioneren. De ‘sizing'-vraag, zogezegd. Maar daar krijgen we vervolgens geen enkel antwoord op. De bouwer weigert categorisch te vertellen wat zijn eigen inzichten, en de ervaringen van andere klanten zijn.
Het enige wat de bouwer zegt is: zet het op heel veel hardware die je niet deelt met andere toepassingen. Maar ons beleid was nu juist server- en storageconsolidatie. De keuze voor deze software jaagt ons dus op kosten en dwingt ons capaciteit aan te schaffen die we eigenlijk niet nodig hebben. Verspilling.
Wat is hier aan de hand? Het kan zijn dat de bouwer het echt niet weet. Zou me weinig verbazen, want de doorsnee softwareontwikkelaar heeft zero verstand van performance.
Misschien weet de bouwer het wel ongeveer, maar durft hij niets te zeggen. Als zijn informatie niet blijkt te kloppen en er een ramp gebeurt in productie, krijgt hij de schuld. Ik snap het wel, vanuit zijn risicomanagement is het verstandig om je mond te houden.
Het frustrerende is dat de bouwer er mee weg komt, want de keuze voor de software is een gepasseerd station, er is geen weg terug. Daar ga je met je mooie beleid van standaardsoftware en gedeelde infrastructuur.
Het is net of je een vliegtuig koopt, en de bouwer wil je niet vertellen hoeveel brandstof dat toestel verbruikt. 'Hoe veel moet ik dan meenemen?', vraag je hem. 'Gooi maar helemaal vol, en kijk hoe ver je komt,' luidt het antwoord. 'Maar dan is het toestel zo zwaar, dan kan ik geen passagiers meer meenemen!', zeg je. 'Tja, dat is niet mijn probleem, het is nu jouw vliegtuig,' zegt de bouwer dan.
Zou daar niet een wet tegen zijn, of zo?
Wat denkt u van een betere selectieprocedure die zowel hardware- als software-eisen omschrijft?
De preek van Pragt: Als je niet, tijdens de bouw, de FCAPS gebieden afgedekt hebt ben je gewoon een prutser. Dat de bouwer vervolgens zegt: “dat is jouw probleem” is dan je verdiende loon.
Je koopt toch geen vliegtuig zonder het brandstofverbruik mee te nemen als design / acceptatie criterium. Een IT-systeem is geen broodje kaas.
http://en.wikipedia.org/wiki/FCAPS
En voor zover dit niet in de offertefase als selectiecriteria kan worden meegenomen, maak je het een milestone in de beginfase van het project.
Het omgekeerde komt helaas net zo goed voor. Klanten die niet tegemoetkomen aan de eisen die aan (de inrichting van) de hardware worden gesteld en vervolgens piepen dat de performance zo tegenvalt. Het is dus het beste die eisen van te voren duidelijk aan te geven, vast te leggen en tot verantwoordelijkheid van de klant te maken.
Gesproken als een echte , traditionele, IT’er. Als het goed gaat ben je de bink, als het fout gaat is het de schuld van de klant. Die snapt het niet of doet niet wat er afgesproken is. Sorry joh, die tijden zijn voorbij.