Artikel

ITIL v3 en Enterprise Architectuur: zonder architectuur geen geslaagde ITIL implementatie?

In de vorige editie van XR Magazine heb ik zeven stellingen geponeerd over de relatie tussen ITIL v3 [1] en Enterprise Architectuur. In dit artikel geef ik voor elke stelling mijn beschouwing. Deze beschouwingen zijn gebaseerd op het gedachtegoed ‘beheren onder architectuur’ zoals deze gedefinieerd is in het gelijknamige boek [2].

Stelling 1

ITIL v3 positioneert architectuur in de Service Design fase (ontwerp van services) en impliceert dat architectuur ook een rol heeft in de Service Strategy fase (Demand Management en Portfolio Management). Service level managers moeten voortaan dus bij de Business-, Informatie-, en Technische Architecten (BITA) te raden gaan om de servicedefinities die in hun SLA moeten komen te laten bepalen.

Beschouwing:

Vanuit de enterprise architectuur gezien is architectuur verantwoordelijk voor alle aspecten van de organisatie inclusief bedrijfsprocessen, business services, ICT-services en technologie. Architecten zullen in hun architectuurontwerpen dus invulling moeten geven aan aspecten die rechtstreeks invloed hebben op de levenscyclus van de ICT-services. Dit wordt binnen ITIL v3 terecht dan ook onderkend als een architectuuraangelegenheid. Er zijn echter twee issues die hierbij geadresseerd moeten worden.

De eerste issue heeft betrekking op de positionering van architectuur binnen ITIL v3. Architecten zijn gewend om architectuur te zien vanuit een architectuurproces en vanuit een raamwerk van architectuurdomeinen, -principes en -modellen. Een service levenscyclus fasering is een andere benadering. Het is dan ook flink zoeken naar de samenwerking tussen beheer en architectuur zoals ITIL v3 deze beoogt. Ook vult ITIL v3 de rol van architect niet in. Dit is een generieke eigenschap van ITIL v3, want testen en ontwikkelen van software worden ook in scope verklaard, maar niet compleet uitgewerkt zoals we dat van TMAP, RUP en dergelijke gewend zijn. Dat kan ook niet met zo’n allesomvattend model. Architectuur moet dan ook gezien worden als een separaat vakgebied dat raakvlakken heeft met ITIL v3. ITIL v3 is dus niet een nieuw architectuurraamwerk, of een vervanger voor bestaande raamwerken.

De tweede issue heeft betrekking op de overlap van verantwoordelijkheden van beheer en architectuur. Doordat ITIL v3 architectuur wel betrekt, maar niet positioneert, zal elke organisatie zijn eigen integratiemodel gaan zoeken. Dit is erg lastig omdat beide werelden van nature autonoom functioneren. Aan beide kanten van de lijn zal dan ook een toenadering gezocht moeten worden door het verkennen van elkaars werkgebied. Hierbij kan het niet anders dan dat de start van de levenscyclus van een service vanuit architectuur wordt opgepakt en dat gaandeweg beheer een belangrijkere rol krijgt toebedeeld. Hierbij zal er een duidelijke splitsing van taken, verantwoordelijkheden en bevoegdheden tussen architectuur en beheer moeten worden afgesproken. In ieder geval ligt het voor de hand dat de portfoliosamenstelling en het architectuurontwerp van de services bij architectuur komen te liggen evenals het beheer daarvan. De architect zal als één van de stakeholders het ontwerp, de realisatie, het testen en het in productie nemen volgen en toetsen aan de gestelde kaders.

Stelling 2

ITIL v3 positioneert de services in de Configuration Management Database (Service & Asset Management). De BITA moeten dus kaders stellen aan de inrichting van de CMDB qua scope en detailleringniveau. Ook moeten de BITA de architectuurontwerpen leveren van de services en de componenten waaruit deze zijn opgebouwd.

Beschouwing:

Gezien vanuit de beschouwing bij het eerste punt is architectuur verantwoordelijk voor het portfolio van services, applicaties en infrastructuur alsmede het architectuurontwerp van services. Het is dan ook logisch dat zowel de scope als het detailleringniveau van de CMDB mede bepaald worden door de architect, zo niet een onlosmakelijk deel vormen van de service architectuur. Het architectuurontwerp van de autogarage is immers net zo goed een aspectgebied van architectuur als dat van de auto zelf. Waarom zou dit binnen de wereld van de ICT dan niet het geval zijn?

Stelling 3

ITIL v3 onderkent CSI (Continual Service Improvement) als fase in de levenscyclus van een service om vast te stellen of voldaan wordt aan alle eisen die aan de service gesteld worden. Deze eisen moeten ook de eisen vanuit architectuur bevatten zoals architectuurprincipes, architectuurmodellen en high level requirements. Dit impliceert dat de BITA tevens betrokken zijn bij het toetsen van de ICT-services in de CSI fase.

Beschouwing:

Normaal gesproken heeft architectuur niet veel op met de beheerfase van een gerealiseerde service of product. In de CSI fase van ITIL v3 zal dit niet anders liggen. Alleen zal architectuur zijn rol wel moeten laten gelden in geval er geconstateerd wordt dat het niet realiseren van doelen veroorzaakt wordt door architectuuraspecten zoals constructiefouten en vraagstukken die de inzet van architecten vereisen. Ook in de service strategie en service design fasen zullen de architecten vanuit hun rol informatie moeten inwinnen bij de betrokkenen uit de CSI fase.

Stelling 4

ITIL v3 stelt dat nieuwe en toekomstige behoeften van de business in de Service Strategy fase worden onderkend. Als een organisatie ITIL v3 toepast en BITA medewerkers heeft aangesteld, dan moeten deze BITA medewerkers ITIL v3 expert worden en hun rol innemen.

Beschouwing:

De samenwerking tussen beheer en architectuur zal hechter worden nu ITIL v3 twee fasen in de levenscyclus van een service architectuur nadrukkelijk heeft onderkend. Dit wil nog niet zeggen dat beheer en architectuur elkaars vakgebied moeten beheersen. Een ITIL-opleiding op ITIL-expertniveau is dan ook niet realistisch. Een architect blijft vanuit een innovatief perspectief redeneren en een beheerder vanuit een continuïteit perspectief. Deze krachten moeten elkaar in balans houden om beheerst de Nolan-cycli te doorlopen. Wel moeten beiden op foundation niveau elkaars begrippenkader goed leren kennen teneinde effectief en efficiënt met elkaar te kunnen communiceren.

Stelling 5

ITIL v3 onderkent drie architectuurdomeinen die in andere architectuurmodellen niet worden gebruikt te weten: management architectuur, product architectuur en environment architectuur. Deze domeinen moeten in het TOGAF architectuurproces worden opgenomen en in de TOGAF subprocessen worden verwerkt. Dit maakt het mogelijk om van BITA die TOGAF omarmen bekwame ITIL experts te maken.

Beschouwing:

Het feit dat ITIL v3 deze architectuurdomeinen onderkent zegt meer over de onwil of het onvermogen van beheer om het gedachtegoed van architectuur te adapteren dan over het gebrek aan domeinen binnen bestaande architectuurraamwerken. Zo is managen (besturen / beheren) geen zelfstandig naamwoord maar een werkwoord en kan per definitie geen architectuurdomein omvatten omdat het geen object betreft. Product architectuur valt binnen technische architectuur (infrastructuur) / informatie architectuur (applicaties). Environment architectuur zou een plek moeten vinden binnen de technische architectuur. Willen architectuur en beheer beter samenwerken, dan is het verstandig om binnen ITIL v3 de regulier onderkende architectuurdomeinen te hanteren. Het hanteren van dezelfde taal is de eerste stap tot delen van kennis en kunde.

Stelling 6

ITIL v3 claimt, net als andere beheermodellen zoals ASL en BISL, de wereld van architectuur, maar geeft geen invulling aan het architectuurproces en de rol van architectuur in het geheel. Zonder aanvullend architectuurraamwerk als TOGAF, DYA, Dragon 1 etc. zal elke implementatie van ITIL v3 een mislukking worden.

Beschouwing:

ITIL v3 onderkent de rol van architectuur, maar vult die niet adequaat in, net zoals feitelijk test management en development management. Als een organisatie ITIL v3 experts inhuurt en alle architecten, systeemontwikkelaars en testers ontslaat, dan zal dat niet bevorderlijk zijn voor deze organisatie. Het feit dat ITIL v3 deze raakvlakken adresseert moet gezien worden als een toenadering om de vakgebieden te integreren. Helaas heeft ITIL v3, voor zover als ik dat kan nagaan, hier geen integratiestrategie voor gedefinieerd. Elke organisatie zal dan ook de diverse vakgebieden en de bij behorende mensen, methoden en middelen op één lijn moeten brengen.

Stelling 7

Zonder rekening te houden met ITIL v3 en modellen als ASL, BiSL en het BEA-model (beheren onder architectuur model) zal architectuur niet de gewenste beheerbare oplossingen opleveren.

Beschouwing:

Het behoeft geen betoog dat de ervaring over het gebruik en beheer van services sterker vertegenwoordigd is in de beheerwereld dan in de wereld van innovatie. Het betrekken van beheer vanaf de strategische fase van een service is dan ook een must. Deze kennis en kunde dient al in het architectuurontwerp van de service te worden ingebracht om de beheerbaarheid van de service te borgen. Daarnaast kan de beheerorganisatie als geen ander aangeven wat de impact van nieuwe of aangepaste services is op de bestaande beheerorganisatie.

Categorie:   
Auteur(s)
afbeelding van bartdebest
Bart de Best
dbmetrics - Beheerarchitect

Drs. Ing. B. de Best RI is werkzaam als beheerarchitect bij de top-100 organisaties in Nederland en daarnaast is hij docent bij IIR om zijn ervaringen te delen met vakgenoten.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.