Dat (een deel) van de geschetste problematiek in mijn bijdrage ‘Release of relatie management’ voor meerdere herkenbaar is blijkt uit de reacties die ik heb ontvangen. Ik pretendeer daarin niet de alles passende oplossing te hebben maar vroeg vooral aandacht voor een aantal tekortkomingen. Op uitnodiging van Wilko Visser van ValueBlue, heb ik nog eens van gedachten gewisseld over deze problematiek.
Tijdens deze ‘pizzasessie’ ging de discussie over een aantal mogelijkheden om ICT inzichtelijk(er) te maken. Eén van die mogelijkheden is de discipline Enterprise Architectuur welke modellen gebruikt om de ICT beschrijven. Een plaatje zegt tenslotte meer dan 1000 woorden en hiermee wordt dus overzicht en inzicht gegeven. Vervolgens kunnen deze modellen gebruikt worden om een toekomstige situatie te modelleren welke zich vervolgens laat vertalen in architectuur principes.
Meten is weten, gissen is missen
Veel populaire Enterprise Architectuur hulpmiddelen hebben echter nog weinig mogelijkheden om aan te sluiten op de aanwezig beheertools. De meeste lijken zelfs de rol van beheer (service support) te negeren wat opmerkelijk is omdat zonder goed gemanagede infrastructuur uiteindelijk alles stil staat. Hoogstens wordt er gerefereerd naar de informatie zoals opgeslagen in de CMDB. Modelleren met aannames heeft het risico dat de uitgangssituatie niet correct is. Dat maakt dat deze modellen dus op zijn best een vereenvoudigde weergave van de werkelijkheid worden.
De techniek gaat tegenwoordig zo snel dat architectuur modellen soms al achterhaald zijn voordat de inkt droog is. Hierdoor worden de architectuur principes dan vaak ook als voorschrijvend en voortgang belemmerend ervaren door beheer. Architectuur ziet de infrastructuur en haar beheer als zorg voor het implementatie niveau, en laat het in haar modellen buiten beschouwing. Ergo, meer dan voldoende grond om in de realiteit voor ernstige problemen en extra kosten te zorgen.
Efficiëntie op alle lagen
Wie Enterprise Architectuur weet aan te sluiten op de vele beheertools bereikt een inzichtelijkheid die dichter bij de waarheid ligt. Want deze ligt door allerlei wijzigingen in de infrastructuur bij de meeste organisaties allang niet meer in de CMDB. De opmerking van Cogmios op Release of relatie management dat er meerdere uitgangspunten of perspectieven zijn is misschien wel de voornaamste reden waarom de afstemming van IT met de business zo moeilijk is. Uiteindelijk is het niet de techniek die dat doet maar zijn het de mensen en processen die deze gebruiken.
De taalbarriere tussen de verschillende lagen, waarbij beheer zich vaak ‘hexadecimaal‘ uitdrukt en de business ‘binair’ denkt, zorgt voor wederzijdse spanning en frustratie. Wie uitgaat van aannames ziet dat het glas half leeg is maar wie kijkt naar de cijfers ziet dat het juist half vol is. Op die manier wordt de architectuur nooit een doorgestikte ‘lappendeken’ en is het resultaat van veel veranderingen alleen maar een verschuiving van de CAPEX naar de OPEX, en daarmee louter een boekhoudkundige winst.
Angst is een slechte raadgever waar veel (technologie) leveranciers gebruik van maken. De fouten die voortvloeien uit onwetendheid over de infrastructuur zoals verkeerde wijzigingen, onnodige inzet van middelen en slecht Root Cause Analysis zorgen voor slechte service, verspilling en frustratie. De weg blijven bewandelen van nog meer techniek inzetten zal dus uiteindelijk dit probleem niet oplossen.
Intellectual Property of Proprietary
Op alle lagen van de IT worden dus hulpmiddelen ingezet die zich helaas vaak op een specifiek doel richten. Niet zelden werpen leveranciers van deze producten daarbij allerlei hindernissen op om uitwisseling van gegevens te bemoeilijken. Bedoeld om de intellectual property te beschermen worden bijvoorbeeld proprietary databases, schema’s en encryptie gebruikt. Zoals PaVaKe als reactie op eerder stuk terecht opmerkte blijven hierdoor verschillende repositories bestaan. En als er al enige uitwisseling plaats vindt hiertussen dan hebben ze opmerkelijk vaak een menselijke interface in de vorm van een consultant nodig.
Als er door de hele IT organisatie wat beter naar de behoefte gekeken wordt is het misschien mogelijk om hiermee te breken. Een selectie van hulpmiddelen op herbruikbaarheid vraagt dat er verder gekeken wordt dan de ‘spiegeltjes en kraaltjes’ van de gebruikers interface. Als data makkelijker uit te wisselen is kan deze ook makkelijker gebruikt worden om bijvoorbeeld meerwaarde te geven aan Enterprise Architectuur. Helaas blijkt dat een gekozen oplossing vaak slecht met andere producten samenwerkt en zit je aan modulaire uitbreiding van eerder gekozen leverancier vast.
Tot slot
Eerder artikel ‘Release of relatie management’ is geschreven vanuit een aantal niet limitatieve praktijkvoorbeelden binnen de infrastructuur. Deze is door alle nieuwe mogelijkheden tegenwoordig meer een film dan een foto. De term hacken krijgt misschien in dit eerdere schrijven een negatieve klank en verdient dan ook enige bijstelling. Een hacker is namelijk ook iemand die op een creatieve en onorthodoxe manier aan technische beperkingen weet te ontsnappen.
