Wat verandert er aan de BiSL processen als er gebruik wordt gemaakt van bijvoorbeeld Cloud en Agile?
De BiSL processen zijn, net als die van ASL en ITIL, onder meer opgezet met het idee dat door duidelijk beleggen van taken, verantwoordelijkheden en bevoegdheden een professionelere invulling van die taken mogelijk wordt. In het kielzog daarvan zien we een aantal principes die de procesinrichting vaak sterk beïnvloeden.
Zo wordt vaak een beroep gedaan op een duidelijke scheiding van vraag en aanbod, waarbij de vraag-processen focussen op het “wat” en de aanbod processen op het “hoe” en “waarmee”. Een ander voorbeeld van zo’n scheiding is die tussen “beheer” en “ontwikkeling”.
Bij al deze voorbeelden van scheiding in processen is het echter niet zo dat daarmee de processen ook volledig onafhankelijk kunnen worden uitgevoerd. Recentelijk raken er methoden en technieken in zwang, die de noodzaak tot samenwerking over procesgrenzen heen extra zichtbaar maken.
Cloud
Een eerste voorbeeld hiervan is Cloud. Onder die naam verstaan we IT-faciliteiten, die flexibel en schaalbaar worden aangeboden via Internet. Daarbij kan men denken aan hardware als schijfruimte en rekenkracht. Ook applicaties worden echter steeds vaker op deze manier aangeboden. Daarbij krijgt de gebruiker de beschikking over functionaliteit, alsof de schijf in zijn eigen PC zat of de applicatie op zijn eigen laptop was geïnstalleerd.
Op het eerste gezicht gaat dit over “waarmee”, misschien over “hoe” en zeker niet over “wat”. Een aanbod-vraagstuk dus. Toch kan de keuze voor gebruik van Cloud voorzieningen vergaande gevolgen hebben voor het wat. Een aantal voorbeelden van zulke gevolgen:
De fysieke locatie van de schijfruimte kan belangrijk zijn vanuit een business-vraagstuk als privacy – waar worden de persoonsgegevens van mijn klanten opgeslagen en mag dat wettelijk gezien?
Het kan extra belangrijk zijn om al bij de keuze voor een aanbieder van Cloud diensten na te denken over een eventueel afscheid van die aanbieder. Waar zijn mijn gegevens opgeslagen en in welke vorm? Kan ik ze terughalen en zo ja hoe? En uiteindelijk – hoe kan een nieuwe aanbieder de dienstverlening overnemen en (naadloos?) voortzetten?
De keuze voor een Cloudtoepassing is dus niet alleen een technische, aanbod-keus. De keuze voor Cloud, en daarmee de verantwoordelijkheid voor die keuze, is ook nauw verbonden met de business-behoefte.
Agile en Scrum
Als tegenhanger van de bekende “waterval”-methoden voor softwareontwikkeling zien we een opkomst van nieuwe methodes, waarmee wordt gepoogd kortere ontwikkelcycli en meer interactiviteit te bewerkstelligen. Onder de noemer Agile is een aantal principes gedefinieerd die kan worden samengevat tot:
Mensen en hun onderlinge interactie boven processen en hulpmiddelen
Werkende software boven allesomvattende documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven het volgen van een plan
Een van de meest gebruikte Agile technieken is Scrum: een multidisciplinair team heeft de volledige verantwoordelijkheid, van specificeren tot implementatie en beheer, over het op te leveren product en onderhoudt hiervoor een hechte, dagelijkse samenwerking.
Gebruik van Agile in het ontwikkel-proces kan niet zonder de inbreng van gebruikers. Die gebruikers kunnen zich niet beperken tot de “wat” vraag, maar zullen ook betrokken raken bij “hoe” en “waarmee” keuzes. Dat betekent het nodige voor zowel de vraag- als de aanbodorganisatie. Gebruikers zullen actief betrokken raken bij technische keuzes en hun consequenties en delen in de verantwoordelijkheid daarvoor. En leveranciers zullen die inbreng van gebruikers een plek moeten geven in hun ontwikkelproces.
Devops
Binnen het derde voorbeeld van nieuwe ontwikkelingen wordt gepoogd de moeilijkheden die gepaard gaan met grote veranderingen te verzachten door te werken aan een bijna continue stroom van kleine verandering. Door de veranderingen te laten sturen vanuit zowel de ontwikkelteams als de beheerorganisaties kunnen kleine veranderingen vaak moeiteloos, zelfs ongemerkt worden doorgevoerd.
Ook dit wordt vorm gegeven met multidisciplinaire teams, ditmaal van ontwikkelaars en beheerders. En net als bij Agile kan gebruik van deze techniek niet ongemerkt blijven voor de gebruikersorganisatie – ook daar zal men merken dat de processen van Gebruiks- en Functionaliteiten-beheer sterk naar elkaar zullen toegroeien. Het vaak gebruikte beeld van een stroom wijzigingsverzoeken, die zich opstapelen in het proces Wijzigingenbeheer , dat vandaaruit ontwikkelingen initieert en volgt, om te resulteren in de afgebakende implementatie van een reeks veranderingen, gaat hier niet op. Veel meer nog dan in het verleden lopen taken uit al deze processen parallel om de continue veranderingen vorm te geven.
Conclusie
De hier behandelde nieuwe technieken en methodieken veranderen niets aan de BiSL processen (of de andere beheermodellen). Deze technieken maken echter wel duidelijk dat de inrichting van de processen, het beleggen van taken, verantwoordelijkheden en bevoegdheden, een kwestie is van samenwerken. Samenwerken tussen vraag en aanbod, strategie en operatie en tussen beheer en ontwikkeling.
Die samenwerking was natuurlijk altijd al cruciaal voor succes. De nieuwe technieken maken dat meer dan ooit expliciet.
