IT Infrastructuur management

Infrastructuur Management omvat de zorg voor de IT infrastructuur (de techniek van hardware en software), zowel het tot-stand-brengen (ontwikkelen) als het in-stand-houden (beheren). Op deze pagina gaat JAVAL in op het in stand houden van ontwikkelde IT infrastructuur; de beheerkant van infrastructuur management. JAVAL beschouwt alle automatiseringsmiddelen (computersystemen, netwerken, operating systems en virtualisatie, middleware, DBMS’sen, applicaties, security-inrichting, handleidingen, enz.) als IT infrastructuur. Daarbij kun je eventueel onderscheid maken in bedrijfsspecifieke infrastructuur (bv. zelf ontwikkelde applicaties) en niet-bedrijfsspecifieke infrastructuur (bv. operating systems, “commodities”). Aangeschafte applicatiepakketten die in beginsel niet-bedrijfsspecifiek zijn kunnen dat wel worden door aanzienlijke aanpassingen van bedrijfsspecifieke aard, zowel door het aanpassen van programmacode als het aanbrengen van functionele instellingen.

Beheer in de IT betekent in feite het handhaven van de service-eigenschappen zoals vastgelegd in de Service Beschrijving en de SLA. Dit gebeurt door het handhaven van de gedocumenteerde specificaties, en daarmee het gedrag, van de IT infrastructuur. Maar óók het volgen van aanpassingen in de SLA wegens veranderende gebruiksomstandigheden; denk aan meer of minder gebruik van de service, gebruikers, netwerkbandbreedte, nieuwe lokaties, etc. En ook het vergroten of verkleinen van het service-window en applicatieve wijzigingen waardoor de onderneming nieuwe wetgeving kan volgen of nieuwe markten kan aanboren.

In grote ondernemingen is meestal veel IT infrastructuur operationeel en worden duizenden applicaties gebruikt. Daarbij zijn honderden tot duizenden medewerkers betrokken alsmede leveranciers, met elk hun eigen belang, rol en expertise. Uitgangspunt is dat elke betrokkene een verantwoordelijkheid heeft t.a.v. de te leveren IT services en dat die verantwoordelijkheid geconcretiseerd wordt door een bepaalde invloed op de IT infrastructuur (en niet andersom!). Hoe organiseer je het nu zo dat elke medewerker precies weet voor welke aspecten van welke services hij of zij verantwoordelijk is? Laten we de verschillende expertises eens onderverdelen in ontwikkelaars, beheerders en operators (jawel, deze zijn er ook nog, denk maar aan grote rekencentra van banken, en de mensen die printers en enveloppeerstraten bedienen die voorwaardelijk zijn voor het invullen van een SLA). Elke expertise heeft een bepaalde invloed op een service, door het beïnvloeden van de erbij behorende service-eigenschappen middels het beïnvloeden van de daarvoor voorwaardelijke IT infrastructuur.

Bijvoorbeeld de service-eigenschap functionaliteit wordt sterk beïnvloed door de ontwikkelaar. En de service-eigenschap beschikbaarheid wordt sterk beïnvloed door de operator die de service dient te starten. En de service-eigenschap continuïteit wordt sterk beïnvloed door de beheerder die ervoor dient te zorgen dat er bv. voldoende schijfruimte aanwezig is en de software-licenties op tijd worden verlengd.

Meestal hebben alle disciplines invloed op meerdere infrastructuurcomponenten en daarmee op de service-eigenschappen. Je zou kunnen stellen dat elk infrastructuurcomponent één of meer van onderstaande kenmerken heeft:

Intrinsieke kenmerken (inrichting)

Deze liggen vast in de infrastructuur en kunnen alleen worden gewijzigd door wijziging van de constructie van het betreffende component. Functionaliteit heeft sterke intrinsieke kenmerken, als je het wilt wijzigen dien je bv. de programmacode aan te passen. Intrinsieke kenmerken worden voornamelijk tot stand gebracht door de ontwikkelaar.

Operationele kenmerken (instellingen)

Deze kunnen worden aangepast zonder een component te “openen”, denk aan een maximale waarde voor het aantal gelijktijdig aangesloten gebruikers, de maximale hoeveelheid beschikbare opslagcapaciteit (diskquota), een datum-instelling in een applicatieve stuurtabel, of de geldigheidsduur van de licentie van een softwarepakket. Operationele kenmerken worden voornamelijk bepaald door de beheerder, maar ook de eindgebruiker kan hierin een rol spelen als het gaat om specifieke bedrijfsgerelateerde gegevens (bv. een kortingspercentage).

Actuele kenmerken (status)

Deze reflecteren de actuele status van een service, bv. als de service niet beschikbaar is omdat verzuimd is een onderliggend systeem of netwerkcomponent op de overeengekomen tijd op te starten. Ook een operationele storing, bv. een netwerkrouter die uitvalt, is een actueel kenmerk. Actuele kenmerken behoren tot het verantwoordelijkheidsgebied van de systeem-operator.

De verantwoordelijkheid voor de operationele én actuele kenmerken wordt in veel organisaties gecombineerd in de verantwoordelijkheid van de beheerder.

Op deze wijze kom je tot een matrix van kenmerken en disciplines die kan worden gebruikt als leidraad bij het toekennen van verantwoordelijkheden aan medewerkers en afdelingen. En vervolgens kun je met medewerkers resultaatgerichte afspraken maken over hun functioneren. Die afspraken luiden dus niet “de server is 100% van het afgesproken service window beschikbaar” maar bv. “de operationele en actuele kenmerken van de bij een service horende IT infrastructuur zijn gedurende de afgesproken perioden volledig in overeenstemming met de afgesproken service-eigenschappen”. Hierdoor is een prestatie-afspraak volledig dekkend voor de service zonder opsomming van allerlei technische details, percentages, tijden, etc.

Reacties kunnen niet achtergelaten worden op dit moment.