donderdag 7 juni 2012

Redenen voor een goed ontwerp: Deel 1

Een goed doordacht ontwerp zal ten alle tijden zorgen voor een duidelijke implementatie methode. Het is de basis voor de nakomende technische ontwerpen en installatie handleidingen. Een ontwerp is een leidraad voor alle betrokken partijen, en geeft een houvast in het geval van een keuze.

Dat dit ontwerp gedragen moet worden door alle betrokken partijen is essentieel. Afspraken over enkele basale zaken dienen door alle partijen gerespecteerd en gevolgd te worden. Dit klinkt natuurlijk allemaal logisch, en de algemene aanname is dat dit ook gebeurt.

Dat dit in het dagelijks leven vaak anders is zal ik proberen te vertellen in één of meerdere delen van dit blog. Dit zijn ervaringen uit mijn zakelijke omgeving. Dit is geenszins een verwijt, en ik zal ook nooit namen noemen van betrokken partijen.

Reden 1: Een solide netwerkontwerp.

Onlangs ben ik tegen een probleem aangelopen bij een partij. Het probleem was te beschrijven als slechte performance, verliezen van verbindingen en gewoon traag reageren van een Citrix omgeving. Hierbij zijn er meerdere externe partijen betrokken die verschillende onderdelen van de technische infrastructuur bieden.

Nu zal ik jullie alle bewandelde wegen besparen, en ik bied ook geen oplossing voor dit probleem. Feit was in ieder geval dat er ten tijde van implementatie nooit een set met ontwerprichtlijnen is geweest. Elke partij bood een deel van de oplossing, en werkte prima met de andere partijen samen om het e.e.a. te laten functioneren.

Er zijn meerdere metingen geweest op het gebied van het netwerk. Nu zijn dergelijke metingen vaak draken om te lezen of correct te interpreteren. Zo ook in dit geval. Meerdere personen hebben de metingen bekeken, maar het was niemand opgevallen dat er één grafiek weergaf dat er slecht ca. 45% van het aantal pings tussen twee netwerkcomponenten terug kwam. Een verlies van meer dan 50% dus.

De reden van dit verlies was vrij simpel. Alle netwerkcomponenten staan op 'Auto' ingesteld waar het gaat om de snelheidsinstellingen. Nu kan dit tussen twee componenten van hetzelfde merk al problemen opgeven, maar tussen twee verschillende merken is het vragen om problemen. Hoewel het als een 'best practice' wordt gezien om dit op een vooraf afgesproken instelling te zetten, blijkt dus niet altijd bij iedereen bekend te zijn.

Het beschrijven en volgen van enkele basis ontwerprichtlijnen (of architectuurprincipes) had dit probleem al in een veel eerder stadium kunnen tackelen.

Voorbeeld richtlijn/eis:
- Elk netwerkcomponent in de keten, welke een vaste locatie heeft in de netwerkinfrastructuur wordt op een vaste snelheid ingesteld, rekening houdende met de instellingsmogelijkheden van de andere kant. Het gebruik van de automatische instelling wordt alleen bij werkplekapparatuur geaccepteerd.

Een dergelijk simpele eis is ten tijde van acceptatie (nog zoiets wat vaak vergeten wordt) prima te controleren. Ook had dit dus richting kunnen geven ten tijde van implementatie. hadden alle partijen zich hier dan ook aan gehouden, dan was dit (deel)probleem in ieder geval nooit ontstaan.


Doe er je voordeel mee!

Geen opmerkingen:

Een reactie posten