Et sted derude i en større dansk virksomhed sidder en it-chef og tænker sit.
Han har været i gang med en større implementering af ITIL og er nu gået i gang med at finde ud af, hvad han dog skal bruge al den rare struktur og dokumentation til.
Han er måske oven i købet startet 'rigtigt' med at se på processer, før han så på software.
Men det er stadig svært at måle effekten af implementeringen, så tvivlen nager: Var det bare endnu en hype, han skulle have ventet en omgang med at investere i?
Travle it-chefer
It-chefen har haft travlt de sidste par år. Han har nemlig også fundet tid og ressourcer til at få gjort noget ved et andet af tidens varme it-emner: SOA.
Han har service-
orienteret en række af sine centrale systemer og sidder nu med en fleksibel arkitektur og en lang række services, der skal vedligeholdes – og frem for alt driftes.
Der har i al SOA-snakken været en tendens til at glemme, at den forkromede, løst koblede, ultra-fleksible løsning også skal fungere, når enterprise-arkitekten og hans hær af udviklere er gået hjem, og driftsafdelingen står tilbage med ansvaret for at holde løsningen i luften.
Egentlig mærkeligt, når man tænker efter: Det er sjældent, det er decideret livstruende for en virksomhed, hvis et udviklingsprojekt går galt i testfasen og forsinker idriftsætningen et halvt år.
SOA: Problematisk, dyrt og kompliceret
Problematisk? Absolut. Dyrt? Ja uha. Men sammenlignet med bare et par dages kollaps i et forretningskritisk system, med datatab, prestigetab og kundetab til følge, er knas i udviklingsfasen til at overse. Når vi er gået drift, kan vi for alvor tale om livstruende problemer, som det er værd at bruge mange flere kræfter på at få styr på.
For det er næppe, fordi SOA er piece of cake at drifte, at vi ikke har talt om det endnu.
SOA er blandt andet karakteriseret ved sin løst koblede struktur, der betyder, at vi har at gøre med flere små 'systemer' i stedet for ét samlet system. De skal hver for sig holdes i live, vedligeholdes og kunne udskiftes løbende – men samtidig hænger de sammen.
Det, der på arkitekturtegningen ser ud som en forenkling, kan i driftsafdelingen være en væsentlig mere kompliceret affære at holde i luften. Det giver øgede krav til dokumentation, til proces- og kvalitetskontrol og til klare service level agreements.
ITIL bidrager med struktur og dokumentation
Og det er ikke overraskende her, ITIL kommer ind i billedet som et svar på, hvordan man kan gribe det an.
SOA stiller skarpt på genbrug af komponenter, compliance mod standarder, identifikation og kategorisering af services – alle områder, der adresseres af ITIL-rammeværket, hvor continuity management holder det samlede system i luften, IT security management holder styr på it-sikkerheden, change management og release management holder styr på ændringer i systemerne, og configuration management sørger for, at vi bevarer overblikket.
Med andre ord: ITIL (eller et tilsvarende rammeværk) kan bidrage med struktur og dokumentation. Og det er lige præcis det, vi skal bruge det til.
PS. Har I lagt mærke til, at mange (og her må jeg indregne mig selv) er lidt i tvivl om, hvordan ITIL skal udtales? Enten kan man udtale det på nydansk 'aj-till' med tryk på første stavelse, eller man kan udtale det mere jysk 'i-tiil' med tryk på anden stavelse. Det kunne være skægt med en rask lille afstemning…
Karsten Fogh Ho-Lanng er corporate vice president og chief technology officer hos NNIT A/S
