Home Architectuur De duivel zit in de details

De duivel zit in de details

368

Het is de spreekwoordelijke open deur intrappen door te stellen dat huidige IT-architecturen steeds  complexer worden. Door organische groei, waarbij oplossingen gestapeld worden is het moeilijker om inzicht te behouden en de werking transparant te maken. In de aansturing van de IT zijn we dan ook te afhankelijk geworden van een instrumentarium dat niet gericht is op het delen van kennis. Integendeel zelfs, als ik kijk naar de vele puntoplossingen met legacy in allerlei proprietary repositories.

De duivel heeft vele namen

IT is in werkelijkheid een verzameling deeloplossingen met vele functies, methodieken en processen met elk hun eigen vakjargon om daarmee de Babylonische spraakverwarring nog wat groter te maken. Leuk voor een spelletje buzzword bingo maar feitelijk verbetert de aansturing van de IT er niet mee. Zeker niet als architectuurraamwerken en beheermethodieken niet aansluiten bij de techniek en zelfs dus ook maar deeloplossingen zijn. Zo ziet Enterprise Architectuur de infrastructuur nog als onderdeel van het implementatie niveau en laat de infrastructuur in haar modellen buiten beschouwing. Deze modellen zijn dus ook niet meer dan een foto die misschien een overzicht geeft maar zeker nog niet het nodige inzicht.

En die tekortkoming zorgt er steeds vaker voor dat er foute beslissingen worden genomen waardoor er uiteindelijk weer verstoringen optreden. Binnen beheer wordt dat de menselijke fout (layer 8 error) genoemd, in ontwikkeling een bug en in de business gewoon voortschrijdend inzicht. Maar welke naam je er  aan geeft is niet belangrijk, wel dat ze opmerkelijk vaak te herleiden zijn tot:

  • Kennis gebrek; (deel)oplossingen richten zich op specifiek probleem en negeren relaties.
  • Kennis ontoegankelijk; informatie ligt besloten in systemen en wordt niet gedeeld.
  • Kennis wordt genegeerd; door de overvloed zien we door de  bomen het bos niet meer.
  • Kennis is geblokkeerd; met de scheiding van functies zijn er ‘koninkrijkjes’ ontstaan.

Advocaat van de duivel

Om vanuit de vele puntoplossingen een compleet plaatje te maken wordt vaak gebruik gemaakt van niet-relationele ‘Excel interfaces’ die nogal onbetrouwbaar zijn. Die leveren wel leuke grafieken op maar helpen niet echt bij het voorkomen van incidenten. Rapportage achteraf blijft namelijk de koe in de kont kijken en de verrassing van ‘shit happens’ te geven. Maar een cross-check van gegevens levert wel inzicht op en verruimt de blik door niet naar één punt, maar naar de horizon te kijken.
Wie bekend is met ITILv3 weet dat bovenstaande precies is waar Service Knowledge Management om draait. Door de verminderde afhankelijkheid van de hardware, waarbij zelfs de grenzen van het datacenter vervagen, gaat het nu allemaal om de service. De behoefte aan informatie over de infrastructuur is daarmee niet minder geworden. Alleen gaat het hierbij meer om de relaties, dan het wat en waar van configuratie items. Het gaat dus om een relationele database, die toestaat om data uit verschillende bronnen, die niet altijd in eigen beheer hoeven te zijn, te consolideren. Dat maakt het mogelijk om op de metadata van de infrastructuur een soort ‘data mining’ uit te voeren. Door correlatie van gegevens kunnen zodoende patronen herkend worden die helpen in de besluitvorming.

Versimpelen van infrastructuur door steeds meer ‘wolkjes’ te tekenen in modellen zorgt ervoor dat we telkens verrast worden door de ‘duivel-uit-het-doosje’ omdat de infrastructuur is opgebouwd uit vele doosjes. Maar deze leveren wel allemaal data die helpen bij de sturing ervan, tenminste als we de vele management protocollen en interfaces weten te rationaliseren.

Ewout Dekkinga  Infrastructure Architect  |  S&T  |  ESS RTI bij Unisys

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in