Is een verzameling bomen altijd een bos? Is een grote groep dieren altijd een kudde? Is een verzameling informatiesystemen altijd een eenheid? Als we beleid uitstippelen voor onze it, zijn we niet altijd even logisch bezig. We proberen soms de ict als één geheel te zien, zonder onderscheid naar gebruik, toepassing, functionaliteit, techniek en behoefte.
Soms knippen we de ict en de daarbij behorende organisatie, processen en procedures op langs technische lijnen. Een storage-groep, een Windows-groep, een netwerkgroep, een Mainframe-groep, een supportgroep en een architectuurgroep zijn maar een paar voorbeelden.
Zoals in het artikel ‘Verhuizen van ICT levert vaak hoofdpijn op‘ van Ruud Mulder op Computable.nl op 13 maart besproken wordt, is het verhuizen van ICT anno 2013 niet eenvoudig. Dit is namelijk net een moment dat we keihard geconfronteerd worden met al deze vragen. Waarom die vragen juist nu,, en misschien nog veel belangrijker; is er iets aan te doen.
Om met de eerste vraag te beginnen. De oorzaak in deze is de combinatie van de behoefte en noodzaak aan controle en besturing en groei, ontwikkeling en diversificatie. De rol van de ict in een moderne organisatie is groot en divers: van het mogelijk maken van het primaire processen richting leverancier en klant, het interne proces van gegevensverwering en/of productie tot het faciliteren van alle communicatie (van mail tot ip-telefoon).
We werken niet meer met een enkelvoudig systeem (het mainframe) voor een enkelvoudige taak. Informatietechnologie is divers, gedistribueerd en ontwikkelt zicht sterk. Zowel in de breedte als in de ‘diepte’ neemt het belang en de rol van de ict toe. Structuren die uitgaan van een holistische en enkelvoudige ict-functie lopen vast in de complexiteit van een te veel aan variabelen.
Een veel toegepaste manier om dit te ondervangen, is om de organisatie in te delen over de as van de techniek, de in de eerste alinea genoemde groepen. Dit maakt de taak en functie van een organisatieonderdeel een stuk overzichtelijker. Rollen, functies en kennisgebieden liggen bij elkaar in de buurt en door een concentratie van aandacht en kennis kan elk van de groepen optimaal presteren.
Conflicten
Probleem opgelost? Ik denk het niet. Want hoe natuurlijk en volledig is de scheiding tussen al die gebieden. Samenwerking en kennisoverdracht tussen de groepen is lastig, sommige groepen krijgen tegengestelde belangen of gaan zelfs met elkaar concurreren (denk aan de Windows Server groep versus de Linux groep). Ook worden beslissingen genomen zonder het geheel in ogenschouw te nemen. Wat goed is vanuit het perspectief van de storagegroep kan best conflicteren met ideeën en keuzes van een server- of netwerkgroep.
Komt er nog bij dat het niet alleen een verdeling is langs de lijnen van een technology-stack. Het wordt een matrix waar naast de op de techniek gerichte afdelingen ook teams voor support, helpdesk, architectuur en technisch- en applicatiebeheer bestaan. Een Babylonische situatie dreigt die alleen met heel veel praten, mailen en managen in de hand te houden is.
Dit is lastig in een bestaande situatie. Bij het doorvoeren van ‘grensoverschrijdende’ veranderingen dreigt een patstelling en de verhuizing is daar weer de overtreffende trap van. Aan verhuizen is echter soms niet te ontkomen. Een verhuizing van de gehele organisatie, een data center dat gewoon te klein of (milieu-)technisch achterhaald is, … Wat moet, moet.
Een aantal lessen om dit soort verhuizingen tot een goed einde te brengen heeft Ruud al naar voren gebracht. Is de complexiteit vooraf echter te vermijden? Ik denk het wel. Dit vraagt echter wel een heel andere manier van kijken naar it. Niet van binnen naar buiten, maar veel meer van buiten naar binnen. Als die verschillende componenten vormen samen een functie die vanuit de taakstelling van de organisatie nuttig is (anders moet je sowieso de stekker er uit trekken). Ict bestaat ter ondersteuning en facilitering van de doelstelling van de organisatie, of dit nu het verzorgen van patiënten in een ziekenhuis, het produceren van fietsbellen of het ophelderen van fraude door de politie is.
Vanuit deze functies, in wat generaliserend in de ict meestal ‘de business’ genoemd wordt, kun je gaan kijken naar de onderliggende groepen. Binnen dergelijke workloads, groepen of ketens zitten weer applicaties met specifieke processing, data en communicatie-eigenschappen. Als deze patronen helder zijn, dan kun je stukken ict gaan verhuizen zonder het ‘vork in de spaghetti’-effect op te roepen.
Verhuizen als het moet gaat nu een stuk eenvoudiger. Verhuizen omdat het kan wordt nu een optie. Plaats je workload op de plek waar deze het best tot zijn recht komt. Erg veilig en erg snel in je eigen datacenter, veel communicatie en hoge eisen in een remote private cloud dicht bij de internet backbone, veel volume in date en gebruikers in de WW Cloud, et cetera. De Hybrid Enterprise kan echt beginnen. Je hoeft geen bos meer te kappen om een paar bomen te rooien.
En o ja, voor je het vraagt. Hoe ga je nu om met al die specialistische kennis die in al die ketens nodig is? Door specialisten onder te brengen in kennisteams die hun specialisme op project en incidentbasis beschikbaar stellen aan de keteneigenaren.
INDIEN MOGELIJK OP VRIJDAG 29/03 PUBLICEREN.
Gudio,
Heb je misschien ook een versie van dit artikel in “Jip & Janneke” taal? De tekst, opbouw en schrijfstijl doen me aan Ewout denken die ook toevallig je collega is!
Een automonteur hoor je ook niet klagen over de complexiteit van het systeem onder de motorkap van een (bijvoorbeeld) BMW uit 1980 vs 2013! Dat hoort gewoon bij deze tijd en ontwikkelingen.
De punten die Ruud in zijn artikel benoemd heeft, zoals ik er op gereageerd heb, zijn terecht maar ze behoren gewoon bij de huidige ict-migratie/landschap. Met een beetje ervaring als projectmanager weet je goed hoe je de verhuizing van zo`n complexe omgeving moet realiseren! Dan denk ik waar hebben we het over!
Misschien in je reactie ga je je artikel wat toegankelijk maken, in dat geval mag je de volgende reactie van mij verwachten 🙂
@Guido
Wanneer de netwerkstructuur op orde is en je weet wat er staat en hoe geconfigureerd, dan is verhuizen niet zo moeilijk meer.
Los hiervan mis ik een beetje wat je boodschap is ten opzichte van wat Ruud laatst al op een heldere wijze gemeld heeft over dit onderwerp.
Ik was in eerste instantie geneigd na 1/3 deel al af te haken. Als je mainframe beschouwt als een enkelvoudig systeem voor een enkelvoudige taak, heb je mijns inziens geen idee waarover je het hebt. Eén fysieke mainframe kan meerdere virtuele machines bevatten, die verschillende klanten en/of doelen dienen.
Voor de rest sluit ik me aan bij Reza; het verhaal is behoorlijk abstract en theoretisch.
Wat je bij veel infrastructuren ziet gebeuren is dat het goed ontworpen en doordacht neer wordt gezet (en op dat moment ook eenvoudig verhuisd zou kunnen worden) maar dat het in de loop der tijd organisch groeit tot een wirwar van servers, NAS’sen en allerhande andere ict-gerelateerde componenten. Ik ben ze al meerdere malen tegen gekomen, van die consultants die ‘er even een servertje bij willen hebben’ om hun dingen op te kunnen draaien. Langs de officiële kanalen duurt het ze te lang, dus wordt er ergens onder een bureau wat ruimte gemaakt.
Wil je vervolgens dat stukje netwerk gaan verhuizen, dan blijkt er ineens van alles om te vallen.
Het is met infrastructuren net als met architectuur: het op papier zetten en uitrollen is één; het in stand houden is een heel ander verhaal…
Vrienden van Computable,
Het is duidelijk dat ik in het bovenstaande stukje één van mijn stelregels losgelaten heb, namelijk om helder en duidelijk, in Jip & Janneke taal te schrijven. Ga ik in het vervolg weer doen.
Een paar reacties op jullie stellingen / vragen:
@Reza: De automonteur klaagt niet… Vast niet, ik ook niet. Mijn doel met dit (en andere stukjes) is om een stapje opzij te doen en te beschouwen waar we met zijn allen mee bezig zijn.
De it is een gebied bij uitstek waar de veranderingen zeer snel gaan en zeer divers zijn. Soms hebben veranderingen (zoals het ontstaan van ketens van systemen) ook onbedoelde gevolgen (zoals voor verhuizen).
@Maarten: Onderwerpen die ik aan de orde wil(de) stellen zijn onder andere hoe lang verhuizen in de fysieke zin van het woord nog aan de orde zal zijn en dat je, om verhuizen eenvoudiger te maken, je ict complex kunt opdelen in gelijksoortige groepen.
@PaVaKe: Dank voor het volhouden 🙂
Hoe beheersbaar is de ict? Terug grijpend naar een vorig verhaaltje van me, wordt het niet steeds eenvoudiger om buiten de formele ICT organisatie om ict te bedrijven? Dit soort ongecontroleerde it verhuist lastig (want onbekend) maar misschien is ‘gebeun’ in de cloud dan weer beter?
@Guido … ‘Wordt het niet steeds eenvoudiger om buiten de formele ict- organisatie om ict te bedrijven.’
Hier zit de angel van het probleem. Ict is vandaag de dag zo toegankelijk geworden dat iedereen denkt dat ze ict kunnen bedrijven. Nog even en we hebben, naast 15 miljoen voetbalcoaches, ook vijftien miljoen ict’ers.
Voor veel mensen is ict iets wat als het ware uit de muur komt, net als gas, water en licht. Dat daar nog een hele infrastructuur achter zit ziet en weet men vaak niet.
Maar net zoals er thuis van alles mis kan gaan wanneer je zelf gaat lopen hobbyen aan het gas/water/licht, zo kan het ook misgaan als je zelf in je ict- netwerk gaat lopen knutselen.
Ik zou willen pleiten voor ‘verhuizen onder architectuur’ en vooral niet opportuniteit gedreven methoden. Je hebt niet vaak de kans om ict-zaken op de nieuwe omgeving goed in te richten. Begin dus vooral goed na te denken over wat je wilt op de nieuwe locatie. Bepaal daarna de drempel om systemen wel of niet te verhuizen en begin direct, dus niet wachten tot het laatste moment om systemen die niet worden verhuisd te bevriezen, geen wijzigingen meer tenzij.
Het ontvlechten van systemen of het in kaart brengen van alle koppelingen is tijdrovend en weinig zinvol, zorg dat de nieuwe netwerkarchitectuur de oude niet uitsluit op basis van koppelingen. Koppel de netwerken in vroegtijdig stadium en breng systemen alvast over als het kan, op basis van workload, de minst risicovolle systemen eerst.
Complexiteit kan je vermijden door altijd te spiegelen aan de doelarchitectuur en faseer uit wat kan, ik zie bedrijven faxen, telefoons, systemen, printers en pc’s één-op-één verhuizen, nadenken over nut en noodzaak wordt niet of nauwelijks gedaan. Verhuizen is een kans en geen bedreiging.
Zucht. Wanneer gaan we eens snappen dat infrastructuur vele malen eenvoudiger te vervangen, migreren, verhuizen is dan software?
Prachtige verhalen over applicaties en kennisteams… door infra-deskundigen (let wel: ik waardeer deze kennis).
Ook in de mainframetijd was het geen monolytisch applicatielandschap.
Informatietechnologie is meer dan apparaten in een netwerk waar toevallig ook nog ergens software op draait.
@Guido
Je bos lijkt me meer een biotoop waar naast bomen nog andere flora groeit en welke gelijk ook de habitat is van een uitgebreide fauna. Dat lijkt me namelijk tot uiting te komen in de reacties. En hoewel het makkelijker is om oude bos om te zagen en een nieuwe ergens anders aan te planten is dat vaak niet toegestaan omdat er ook nog beschermde flora en fauna in zit.
Er is bijna nooit sprake van een ‘greenfield’ situatie, een blanco vel papier op een tekentafel. Want techniek is misschien eenvoudig buiten de deur te plaatsen maar software zonder hardware functioneert niet en hardware zonder software is niet functioneel, het één kan dus niet zonder het ander. Maar hoe alles in verhouding tot elkaar staat is toch vaak onduidelijk zoals ik al een geschreven heb in: “Release of relatiemanagement”
Doeltreffend en doelmatig worden ook nog weleens door elkaar gehaald, PaVaKe stelt dan ook terecht dat meesten niet eens benul hebben van de onderliggende infrastructuur met alle verschillende protocollen en systemen. Zo maakt het gebruik van persistent en non-persistent connecties namelijk nogal wat verschil in de response want iedereen kan dan misschien wel mail versturen maar weet iedereen ook het verschil tussen SMTP en POP/IMAP?
Want naast hoe dingen met elkaar verbonden zijn is ook inzicht door wie het gebruikt wordt en hoe ook geen overbodige luxe. Aannames leiden namelijk nog weleens tot verrassingen zoals we konden lezen met bericht over het Openbaar Ministerie waar de 6.000 spookambtenaren blijkbaar het gevolg van achterstallig onderhoud op de Active Directory waren. Of er nu wel of niet teveel betaald is blijft onduidelijk maar het maakt wel duidelijk dat “Het zorgpremiestelsel van de ICT” nog lang niet optimaal is.
In dat opzicht is voorbeeld van BMW wel leuk want zolang deze onderhouden wordt en er reserveonderdelen voor te verkrijgen zijn zoals richtingaanwijzers e.d. dan levert dat oude brik de functionaliteit waarvoor het ooit eens aangeschaft is, namelijk mobiliteit. Of het economisch verstandig is om erin te blijven rijden hangt af van de onderhoudskosten, de MTBF die door ouderdom meestal ongunstiger wordt. Want de monteur klaagt dan niet maar is wel langer bezig met de MTTD omdat diagnose module ontbreekt.