Soms lees je wat over de complexiteit in de ict-infrastructuur. Complexiteit werkt vrijwel altijd kostenverhogend. Het blijft dan vaak bij een constatering waarna snel wordt over gegaan tot de bestrijding ervan met maatregelen. Maar wat zijn nu de veroorzakers van complexiteit? Business- en applicatiearchitecten denken soms verbluffend eenvoudig over de infrastructuur, maar juist zij kunnen grote invloed uitoefenen op de complexiteit en daarmee op de kosten van de infrastructuur.
De zeven belangrijkste bouwblokken van iedere ict-infrastructuur zijn eindgebruikersapparaten (zoals desktops, pda's, etc.), opslagsystemen, servers, informatiebeveiliging, communicatie en netwerk, middleware en infrastructuursoftware en tenslotte ict-managementsystemen ten behoeve van operations. Dat lijkt een simpel en overzichtelijk geheel, maar zodra je je er wat in verdiept, blijkt een en ander in belangrijke mate geïntegreerd te zijn met elkaar.
De veroorzakers van de complexiteit in de ict-infrastructuur laten zich als volgt samenvatten (in willekeurige volgorde):
– Wijzigingen in de organisatie.
– Legacy-systemen.
– Meer applicaties.
– Toenemende mobiliteit van medewerkers.
– Meer regelgeving en andere voorschriften.
– Meer spullen in het datacenter.
– (On)volwassenheid van de ict-beheerorganisatie
Wijzigingen in de organisatie
Wanneer de grootte van de organisatie verandert, heeft dat meetal gevolgen voor de ict-organisatie. Denk aan het aantal ict-werkplekken, netwerkverbindingen en bandbreedte, inregelen dat applicaties beschikbaar zijn voor de nieuwe medewerkers en dat het aantal licenties in overeenstemming blijft met het gebruik. Meer dan eens wordt de ict-afdeling pas op het laatste moment op de hoogte gebracht van een verhuizing van een afdeling naar een ander pand en toch verwacht men dat alles maar gewoon werkt. Vanzelfsprekend speelt de frequentie van de organisatieveranderingen en de omvang een rol. Complexiteit wordt verder verhoogd door fusies en overnames waarbij de ict van de een door de ander geabsorbeerd moet worden. Dit speelt overigens net zo makkelijk ook intern, bij reorganisatie van grote divisies binnen ondernemingen en overheden.
Legacy-systemen
Legacy-systemen zijn (Wikipedia) verouderde ict-systemen die niet voldoen aan de huidige technologische standaarden welke de organisatie wil behouden voor geldige businessredenen. Deze systemen draaien vaak op verouderde en dus vaak langzamere hardware en reserveonderdelen voor zulke hardware is in toenemende mate moeilijker verkrijgbaar. Als er legacy-software gebruikte wordt op antieke systemen, dan is het verstandig om een business case te maken voor het vervangen van het gehele systeem, tenzij het mogelijk is om de software op nieuwere hardware met een backwards-compatible emulatieoptie (bijvoorbeeld virtualisatie) te draaien (indien dat gesupport en/of gecertificeerd wordt door de leverancier). Legacy-systemen zijn moeilijk te onderhouden, te verbeteren en uit te breiden omdat er een algemeen gebrek is aan iemand die nog weet hoe het in elkaar zit. Het toenmalige deskundige personeel is al uit dienst en het nieuwe personeel dat binnenkwam nadat het systeem ‘legacy' werd, heeft het systeem nooit leren kennen. Dit wordt vaak nog verergerd door een gebrek aan documentatie. Integratie met nieuwere systemen kan ook moeizamer zijn omdat de nieuwe software gebaseerd is op geheel nieuwe technologieën. Overbruggende software en hardware die vaak tegelijk met het nieuwe systeem ontwikkeld wordt om te integreren met andere (moderne) technologieën wordt vaak niet ontwikkeld voor de verouderde systemen door een gebrek aan voldoende vraag om de ontwikkeling rendabel te maken.
Meer applicaties
Wanneer het aantal applicaties dat een ict-organisatie moet ondersteunen toeneemt, dan neemt ook het aantal requirements toe dat deze applicaties hebben ten aanzien van de infrastructuur. Het is immers veel eenvoudiger om veertig applicaties te onderhouden dan vierhonderd, duizend of zelfs tweeduizend applicaties vanuit het perspectief van een change-manager. Denk eens aan het aantal mensen dat betrokken raakt bij een 'change advisory board' (CAB)-overleg dat de impact van een enkele applicatie, een applicatiesuite of de infrastructuur zelf overweegt bij dit toenemende aantal applicaties. Stel je eens voor hoe de rollen vergroten van een change-aanvrager (wie is gemachtigd), change-eigenaar, change-coördinator, change-procesmanager, tester (pre & post implementatie), testomgevingen, change-approver, QA/service-testmanager, service transitie manager en CAB-leden die betrokken zijn in een regulier CAB-overleg. Dat neemt niet weg dat je grote infrastructuren kunt bouwen, integendeel. Het legt wel de nadruk op het gebruik van architectuurprincipes en standaardisatie om te voorkomen dat de complexiteit exponentieel toeneemt met de grootte.
Compliancy en reguleringen, richtlijnen en regelgeving
In het algemeen neemt het aantal beleidsmaatregelen toe naarmate een organisatie groeit en vaak wordt van de ict een te grote bijdrage gevraagd in de handhaving er van als de technologie component van 'people, process en technology'. Heb je weleens het ‘protocol voor gebruik van internet en e-mail' gelezen van jouw organisatie? De forensische naspeurbaarheid ervan stelt eisen aan de ict. Het blijven voldoen aan beleidsmaatregelen onder veranderende omstandigheden is vaak een enorme uitdaging, zeker binnen de overheid waarbij wetswijzigingen snel gevolgen hebben voor systemen (applicatiekant), maar ook vaak op de infrastructurele kant zoals het verspreiden/updaten van de nieuwe applicatie naar de werkplek, netwerkbeveiliging en bandbreedte, etc. Als je er invloed op uit kunt oefenen, probeer de reikwijdte van reguleringen dan te beperken tot wat echt nodig is en alleen daar waar het effect heeft.
Toenemende mobiliteit van de medewerkers en gadgetgehalte
‘Vroeger' was alles simpel: je zat op kantoor om je werk te doen en als je al werk mee naar huis nam, dan was het een volle tas. We weten allemaal dat dat geen realiteit meer is. Mensen willen werken wanneer ze willen en waar ze willen en dat stelt eisen aan de verbindingen en aan de beveiliging. Ook het aantal eindgebruikerapparaten neem snel toe, denk aan laptops, pda's, smartphones, etc., waarvan het aantal en soort snel divergeert en er elke zes maanden een nieuwe generatie van is met nieuwere opties die de business wel graag direct wil gebruiken. Het kan allemaal wel, maar dan moet het wel veilig kunnen. Toch is het beter om eerste een selectie te maken van wat echt nodig is voor men tot aanschaf en implementatie over gaat.
(On)volwassenheid van de ict-beheerorganisatie
Bekwame mensen in dienst hebben is een vereiste als de complexiteit van de ict toeneemt, maar evenzo moet de volwassenheid van de organisatie meegroeien, zoals de processen die sturing geven. Indien de mensen en de organisatie niet meegroeien zal dat de toenemende complexiteit ernstig in de weg zitten.
Goed artikel van Vincent Jansen. Echter wat je hieraan kunt toevoegen is dat alles staat en valt met een juiste registratie en documentatie van hetgene wat men gebouwd heeft en op welke wijze. Maar in deze huidige wereld van hectiek en pragmatiek wil dit er nog wel eens bij inschieten. Ook de inzet van de vele partijen die alleen ingehuurd worden gedurende het project. En niet in de gelegenheid worden gesteld om afrondende zaken goed te documenteren. Een organisatie moet dan keuzes maken in deze. Dat zijn niet altijd de verstandigste. Onnodig kan dan de complexiteit in de ICT-infrastucturen toenemen omdat men het niet meer weet hoe het e.e.a. is gebouwd. Ook duurt het weer te lang om dit uit te zoeken. Vaak vanwege de short time to market ontwikkelingen voor een bedrijf, dat ze dan ook niet meer de tijd geven om dit te doen.
In dit stuk ontbreekt naar mijn smaak de allerbelangrijkste veroorzaker van complexiteit en dat is de wijze waarop IT afdelingen zijn ingericht. Traditionele IT afdelingen zijn technologie-centrisch georganiseerd en realiseren IT infrastructuren als sluitstuk van applicatieprojecten, gestuurd door oplevertermijnen en kwaliteitseisen binnen een gegeven budget. Dit model, dat zijn oorsprong kent in de tijd dat men slechts deelprocessen automatiseerde, is onhoudbaar geworden in een tijd waarin IT een primair bedrijfsmiddel geworden is. Op dit moment bestaat er een sterke behoefte aan een IT afdeling met het profiel van een service provider die werkt op basis van supply-chain principes. In een dergelijk model zit het streven naar de eenvoudigste implementatie als het ware ingebakken omdat het supply-chain mechanisme afdwingt dat er net als bij de andere bedrijfsmiddelen gezocht wordt naar implementatiemodellen die het best passen bij de ondernemingsdoelstellingen zoals kostenbesparing, risicobeperking of slagvaardigheid. Dit in tegenstelling tot het bestaande model waarbij men binnen het beschikbare budget altijd zal streven naar de technologisch fraaiste implementatie die helaas vaak ook de meest complexe is.
De overgang van het oude door technologie gedreven model naar het model van de door bedrijfsprincipes gedreven dienstverlener is zeer ingrijpend. Om die reden is het logisch dat veel IT afdelingen aarzelen om hierbij het voortouw te nemen. Het verantwoordelijke IT management dient zich echter te realiseren dat door de opmars van cloud computing de organisatie alternatieven binnen handbereik krijgt waarmee men zo nodig de hele IT afdeling kan omzeilen, met als risico dat de ouderwetse CIO zal degraderen tot ?Chief Maintenance Officer?.
Een prima artikel over de veroorzakers van complexiteit in infrastructuur. Ik ben het op alle punten eens met Vincent.
Vanuit een ICT oogpunt is het volgens mij ook belangrijk te kijken naar de complexiteit die “wij” zelf toevoegen. ICT afdelingen en ICT leveranciers zijn over het algemeen gericht op het bieden van de “beste” technische oplossing.
Een voorbeeld maakt dit duidelijk. Voor het realiseren van een HA omgeving introduceren we complexe technologie�n, die onbekend zijn bij ICT beheer. Is het in dat geval niet beter om te kiezen voor een oplossing in de vorm van een uitwijk procedure die wel begrepen wordt door de beheerafdeling?