Architectuur als continu proces

Posted on Posted in BCONN Nieuws

Agility van bedrijfsvoering vereist veel flexibiliteit binnen de IT-omgeving. Snel inspelen op veranderingen en de tijdsdruk die hiermee gepaard gaat, heeft vaak tot gevolg dat changes ad-hoc worden doorgevoerd. Er ontstaan creatieve work arounds zonder goed de consequenties te overzien. Performance problemen zijn dan vaak het gevolg, waarvan niet duidelijk is wat nou precies de oorzaak is. De techniek krijgt dan vaak de schuld. “Onterecht!”, zegt Gino van den Dungen, solution architect bij BCONN ICT. We spreken hem over zijn ervaring in de praktijk en hoe je zo’n situatie kunt voorkomen.

Wat zie jij in de praktijk gebeuren?
Ik voer geregeld assessments uit bij klanten. Je maakt dan in feite een analyse van de huidige IT-infrastructuur. Hoe ziet die eruit? Wat zijn de problemen? Wat zijn de wensen van gebruikers? Vaak zie je dat het niet aan de technologie ligt waardoor er gekke problemen ontstaan maar dat het fundament, lees: het design, niet meer aansluit bij de huidige requirements.

Hoe ontstaat zoiets?
Wat er vaak gebeurt is dat er bij de start van het project een goed ontwerp wordt opgesteld, maar dat dit vervolgens in de ijskast belandt en er niet meer naar omgekeken wordt. Door tijdsdruk worden problemen snel gefixt, zodat de business weer verder kan.

Wat zijn dan de gevolgen?
Een keertje een pleister plakken is natuurlijk geen punt, maar wat ik geregeld zie, is dat dit veel vaker gebeurt waardoor je na een paar jaar een IT-infrastructuur hebt gecreëerd die moeilijk beheersbaar is geworden. Er ontstaan performance issues en vaak problemen waarvan niet duidelijk is wat nou precies de oorzaak is. Het analyseren en opsporen kost dan veel tijd en frustratie. De kosten die gemaakt worden om de boel in de lucht te houden rijzen dan de pan uit. Als het werkelijk een draak van een systeem is geworden, dan denk ik vaak dat het beter is om een greenfield voor de werkplek te starten. Dit is ook mijn specialiteit. Op die manier maak je een nieuw ontwerp op basis van de huidige requirements en hoef je niet telkens de business te storen met changes. De doorlooptijd wordt met een greenfield verkort, omdat je gerust door kunt blijven bouwen. Een soort reset.

Is een greenfield de oplossing?
Uiteindelijk is het natuurlijk een kosten/baten analyse die je moet maken. Zo’n greenfield starten kost veel tijd, energie en daarmee geld. Voor de werkplek is dit goed te doen. Voor andere zaken ligt dit niet altijd voor de hand. Ik denk dat het goed is om bij veranderingen geregeld terug te gaan naar de tekentafel. Het oorspronkelijke ontwerp moet meegaan in die verandering. Dat gebeurt vaak niet. Het wordt als een lastig onderwerp gezien en vooruitgeschoven. Maar ja, als je dan toch maar blijft sleutelen gaat het uiteindelijk mis. Belangrijk is om in te zien dat architectuur geen momentopname, maar continu proces is!

Hoe weet je wat er verandert binnen het ontwerp?
Requirements veranderen ook voortdurend. Dit is ook een proces. Om goed in kaart te hebben wat de wijzigingen zijn en het belangrijk is om de business erbij te betrekken. Zo weet je wat de behoefte is. Als dit niet gebeurt, is het project gedoemd te mislukken.

Wat is jouw advies?
Het moet geen IT-feestje zijn. Bedenk met elkaar oplossingen en werk dit uit. Zorg voor een goede PoC, zodat je kunt zien of het echt werkt. Check dit ook bij de gebruikers en vraag of dit nou voldoet aan de wensen. Wat wil de business precies? Deze vraag wordt vaak niet goed beantwoord. Er worden geregeld keuzes gemaakt op basis van aannames en niet op basis van gesprekken met de business. Blijf dus continu in gesprek met de organisatie! Als er wensen of eisen bijkomen, betekent dit dus ook een verandering cq. aanpassing in het ontwerp. Op deze wijze ben je in control en blijft de IT-infrastructuur goed beheersbaar.