Om allerlei redenen worden apparatuur, systeem- of applicatiesoftware zonder geïntegreerde (hulp)middelen voor beheer afgeleverd. De beheerder grabbelt dan maar in zijn toolbox en past iets van een vorig systeem aan voor het beheer van het nieuwe component. Ook kan hij kiezen uit het enorme aanbod van tools van derden. Als de keuze gemaakt is, moet hij de software ook nog eens vertellen hoe het systeem beheerd moet worden. Er zit te weinig kennis en ervaring in beheertools. Het rendement blijft laag door het vele handwerk. De levensduur is kort, de overdraagbaarheid slecht. Beheer wordt daardoor steeds duurder en kost over de gebruiksduur vele malen meer dan de aanschafwaarde van het systeem zelf. Wat kan een systeemarchitectuur met geïntegreerd beheer hier aan doen?
Maar weinig ontwikkelaars van hardware, applicatie- of systeemsoftware denken aan adequate voorzieningen voor het technisch beheer. Zelfs de bekende ict-beheersystemen beheren zichzelf niet. Een automatische installatie wil nog wel lukken, maar die wordt dan ook te pas en te onpas geadviseerd als oplossing bij foutmeldingen. SNMP voor netwerkbeheer is, wat de naam al zegt, te simpel. Zoek het maar uit met je toepassingen, servers en netwerk, beste systeembeheerder!
Het is niet mogelijk met beperkte inspanning en tegen redelijke kosten actuele documentatie van systemen bij te houden. Al eerder is op dit forum geschreven over een mooie kast met handboeken, die niet bijgewerkt wordt. Versiebeheer en verspreiding van nieuwe software is handwerk. Voor veel wijzigingen moet een project opgetuigd worden om alles en iedereen in toom te houden. Een procesgerichte benadering, zoals ITIL die biedt, houdt het handwerk in stand. ITIL is op dit moment desondanks belangrijk, omdat de techniek ons niet voldoende helpt.
We zien hardware en netwerken zich in hoog tempo ontwikkelen, terwijl beheer erg arbeidsintensief werk blijft, wat de ontwikkeling van nieuwe toepassingen enorm remt. Beheer is niet voor niets al lang de grootste kostenpost van ict.
Mijn utopia
Wanneer systemen en componenten zichzelf zouden kunnen beheren en zich daarmee ook zouden kunnen aanpassen aan de veranderende omgeving, kan ict pas echt in een stroomversnelling komen. Op basis van een architectuur kunnen systemen de benodigde interfacedetails zelf verzamelen, plug, play & unplug. Compleet lifecycle management zonder (technisch) beheerder.
'Fouten', nu vaak het gevolg van mismatch van componenten, zullen sterk in aantal afnemen en kunnen vrijwel altijd automatisch opgelost worden. Statusmeldingen worden automatisch geclassificeerd en zo nodig op een dashboard gevisualiseerd. Externe koppelingen worden veel eenvoudiger door een goed gedefinieerde interface. Zo zijn er veel meer voorbeelden te geven. Het werk van de beheerder verschuift van handmatig routinewerk naar ondersteuning van functionaliteit.
De ontwikkelaar van een besturingssysteem of een softwarecomponent weet als geen ander op welke manier beheerd moeten worden. Het ontbreekt hem echter aan een internationaal erkend standaard framework voor beheer, waar elke nieuwe component ingepast wordt.
Er zijn allerlei instanties, die zich ten doel gesteld hebben een architectuur met een open karakter te ontwikkelen. Alle ontwikkelaars kunnen er gebruik van maken. ToGAF (The Open Group Architecture Framework) heeft specificaties opgesteld, maar verwijst daarin nog naar zo'n tien andere concepten. Het hoofdstuk Beheer wordt echter nauwelijks ingevuld en dan nog slechts in de vorm van een aantal checklists. Inmiddels is een aanvulling verschenen, die opnieuw veel aandacht heeft voor de proceskant, maar heel beperkt aandacht heeft integratie van beheer in de technische architectuur. Er is nog een lange weg te gaan.
Brengt ToGAF de oplossing voor de diversiteit aan beheermiddelen en -methodieken? Utopia of niet…
Zie ook: http://www.opengroup.org/
The Open Group Architecture Framework versie 8.x, Enterprise Edition.
20th Enterprise Architecture Practitioners Conference in Munchen op 20-22 oktober.
Kijk toch uit met TOGAF! Dat is een enorme moloch die vooral geld kost, en vrijwel niets kan opleveren dat je anders ook niet zou hebben. Vooral goed voor de omzet van de commerciele it-bedrijven die samen The Open Group vormen.
Dit vraagstuk houd me ook al tijden bezig. Hoe kan het toch zo zijn dat bestaande ontwikkel- en architectuur methoden relatief weinig focus hebben op beheer terwijl de operationele kosten het leeuwendeel van het totale IT budget opsnoepen? Biedt beheer architectuur een oplossing? Kunnen we leren van de automobiel industrie waar men wel operationele aspecten meeneemt in het ontwerp om de garage kosten voor de klant te minimaliseren? Waar onderdelen zo geplaatst zijn dat een monteur er gemakkelijk bij kan? Waar een monteur de auto kan uitlezen om de oorzaak van een storing te achterhalen?
Er zal ongetwijfeld een aantal factoren meespelen waarom dit in de digitale wereld nog geen gemeengoed is. Een van de belangrijkste factoren lijkt me dat het vaak ontbreekt aan beleidsdoelstellingen op gebied van beheer die zich laten vertalen in architectuur principes voor projecten. Als er op beheer bezuinigd moet worden kijkt men naar de installed base, en niet zozeer naar innovatie. Beheer is in tegenstelling tot innovatie niet “sexy” en iets voor het niveau vaan “verrichten”. Het blijft daarom voorlopig dweilen met de kraan open vrees ik.