Met het huidige ‘geweld’ van Agile development lijkt het er in veel organisaties op dat de aandacht alleen gericht is op de ontwikkeling van nieuwe bedrijfsoplossingen (nieuwe features), veelal in de vorm van ondersteunende informatievoorziening. Natuurlijk moet snel en adequaat ingespeeld worden op veranderende bedrijfsbehoeften, maar dat wil nog niet zeggen dat er geen aandacht meer nodig is voor de wijze waarop bijvoorbeeld het operationele beheer en de dagelijkse ondersteuning plaatsvindt.
Binnen organisaties is als gevolg van het voorgaande een strijd gaande tussen het loslaten van de ITIL-kaders en het adopteren van de Agile-kaders.
Zijn de processen zoals binnen ITIL gedefinieerd overbodig? Mijns inziens niet. Er dient nog steeds nagedacht te worden welke minimaal noodzakelijke processen uitgevoerd dienen te worden en vervolgens dient gezorgd te worden voor duurzame verbetering (continual improvement). De processen dienen een zo min mogelijke overhead te hebben, oftewel een minimaal levensvatbaar proces respectievelijk een minimaal werkbaar proces dat ‘net voldoende’ gedefinieerd is met ‘net genoeg’ controle en structuur (minimum viable process).
Bij het iteratief en incrementeel ontwikkelen (de kern van Agile development) blijft het nog steeds van belang om aandacht te geven aan allerlei factoren die team-overstijgend zijn, al dan niet als gevolg van compliance- of governance-regels en -structuren, en allerlei geldende security-regels.
Op welke wijze een willekeurig ontwikkelteam (of een aantal teams) gevolg geeft aan bepaalde regels, naast de uitvoerende ontwikkelwerkzaamheden zelf, vraagt de nodige aandacht.
Ter illustratie positioneert ITIL ‘de controle op de ontwikkelwerkzaamheden’ binnen de levenscyclusfase service design. Dit werkt over de hele service-lifecycle heen, inclusief diverse feedback-loops en lessons learned for improvement. Service design gaat over ‘de controle’ op software engineering (development) en niet over de uitvoerende ontwikkelwerkzaamheden zelf. Service design ondersteunt bijvoorbeeld de samenwerking om te komen tot de ‘bouwen of kopen’ beslissingen. Als de beslissing is de oplossing te bouwen, werken de verschillende service-activa (middelen en/of artifacten), met inbegrip van de mensen, samen als leden van het ‘service design’-team. Het doel is de inspanningen te coördineren en een service design package (SDP) of een plan met de servicevereisten. De vorm en omvang is aan het development-team zelf, zolang alle aspecten van de IT-service en de vereisten ervan maar duidelijk zijn (minimum viable design).
Een SDP definieert alle relevante aspecten van een IT-service. Het omvat onder andere applicatie-gerelateerde uitkomsten (outcomes) en natuurlijk de bedrijfsrelevantie, evenals alle onderliggende activiteiten en capaciteiten die nodig zijn voor beheer en ondersteuning.
Een SDP is een groeipad-beschrijving (op hoofdlijnen), mogelijk in de vorm van epics (grote user-stories, vaak in de vorm van een complete workflow) en/of user-stories (een korte beschrijving wat de klant en/of gebruiker wil) of themes (samengestelde user-stories). Het verzamelen, definiëren en prioriteren van servicelevel vereisten (service level requirements) wordt onderdeel van het opstellen van een (user) story. Het geldt ook voor de servicelevel doelen (service level targets), de verplichting waaraan de IT-service moet voldoen om te zorgen dat de service ondersteunend is aan de bedrijfsdoelstellingen. Een SDP geeft de basis voor het iteratief en incrementeel ontwikkelen.
De noodzaak voor het opstellen van een servicelevel overeenkomst (service level agreement) komt deels te vervallen. De nieuwe wijze van werken ‘garandeert’ op zich al dat wat wordt geleverd (het increment) aan de vereisten voldoet. Dit is, als onderdeel van de Agile-werkwijze, gedefinieerd met de Definition of Done. Het opstellen van SLA’s blijft evenwel voor veel organisaties nog steeds belangrijk. Het vastleggen van afspraken tussen de IT-serviceprovider en de Business en het definiëren wat de verantwoordelijkheid is van de IT-serviceprovider, is en blijft houvast geven in de reguliere (en vaak complexe) interne en externe communicatie.
Het ITIL-kader, ondanks dat dit sinds de 2011-release zeer omvangrijk is, geeft nog steeds de nodige handvatten, kaders, checklist en wat dies meer zij, waarmee een organisatie haar wijzigingen in de bedrijfsprocessen kan afstemmen op de rol van IT en waarmee de nieuwe IT-services afgestemd kunnen worden op de bedrijfsvereisten.
Download het ITIL-kader als totaaloverzicht (PDF-formaat): ITIL Detailed Overview
