Oktober 2001: Functioneel Beheer

Deze maand een stelling die te maken heeft met de overlap in het werk van beheerders van informatie infrastructuren en van informatie architecten. De stelling luidt:

---
“Functioneel beheer is een logisch onderdeel van het takenpakket van de in-formatie architect.”
---

De term Functioneel beheer wordt in combinatie met de termen Applicatie beheer en Technisch be-heer gebruikt. Technisch beheer gaat over het beheer van de ingezette techniek en omvat:

• de technische ondersteuning van de gebruiker,
• operationele besturing,
• het onderhoud van de technische infrastructuur en de operationele ondersteuning en
• technische dienstverlening.

Applicatie beheer houdt zich bezig met het onderhoud van applicaties en Functioneel beheer wordt gezien als gebruiksbeheer en functioneel onderhoud. Applicatie en Functioneel beheer hebben dus allebei te maken met het bekijken en/of aanpassen van aan gebruikers geboden functionaliteit. Voor meer informatie verwijs ik hier naar het boek over beheer van Maarten Looijen[1].

In de praktijk is het aanpassen van applicaties feitelijk een “gevaarlijke” activiteit voor organisaties. Bij dat aanpassen is de software, we noemen het ook wel applicaties, informatiesystemen, objecten, componenten enz., die op een bepaald moment gemaakt en ingevoerd is natuurlijk het uitgangspunt. Applicatie onderhoud is niets anders dan het aanpassen van die operationele software. En daar ligt precies het gevaar. Het aanpassen van software betekent immers dat deze anders wordt. De problemen liggen dan niet bij het doorvoeren van correcties die nodig zijn om de software alsnog te laten doen wat die had moeten doen. Het gevaar ligt in de toevoegingen en de modificaties, de plaatsen waar de software anders wordt dan bij invoering. Geen probleem als je alle consequenties van die aanpassingen in het geheel van de informatie infrastructuur hebt vastgesteld en geaccepteerd. Dat gebeurt in de praktijk echter meestal niet.

Dit gevaar kent vele oorzaken. Zo wordt software in de loop van de tijd vaak door allerlei verschillende mensen met eigen ideeën aangepast. Zo zij al documenteren doen ze dat vaak op hun eigen wijze. De originele documentatie wordt daarbij vaak niet aangepast, want “wat heb je daar nu aan?”. Op den duur ontstaan daardoor nauwelijks gedocumenteerde applicaties waar allerlei toeters en bellen aan toegevoegd zijn en waarvan we niet goed (meer) weten hoe ze passen in onze informatie infrastructuur. Daardoor wordt niet alleen verder onderhoud progressief moeilijker, we verliezen ook het overzicht en krijgen te maken met een uiteindelijk onhanteerbare legacy. Onderhoud kost daarbij meer geld. En dat terwijl we al ongeveer 80% van voor een informatievoorziening beschikbaar gesteld geld aan exploitatie en beheer besteden. In combinatie met het gegeven (uit onderzoek) dat investeringen in een informatievoorziening over het algemeen een verhoging van de exploitatiekosten wordt het duidelijk dat verkeerd uitgevoerd applicatie onderhoud gevaarlijk kan zijn organisatie. Kennelijk zijn we daarna niet meer in staat om onze bestaande applicaties te vervangen door nieuwe.

Eén van de belangrijkste redenen waarom onderhoud een probleem blijkt te zijn, is dat we applicaties per ontwikkelingsproject blijven documenteren. Het gaat om het bekende proces van specificeren-ontwerpen-realiseren-invoeren van een gewenste hoeveelheid software zoals we dat al jaren met methoden als SDM en DSDM doen. De resultaten van dit soort projecten geven weinig aanleiding om onderhoud voortaan in alle aspecten uit te voeren. De resultaten worden vanaf het begin al als een min of meer zelfstandige eenheid gezien. Dus waarom zou je de resulterende documentatie aanpassen als je die toch nooit meer hoeft te gebruiken? Dat kost alleen maar moeite, tijd en geld. En later zien we toch wel weer?

Werken onder architectuur eist dat deze manier van werken drastisch anders wordt. Om een afgestemde verzameling applicaties te kunnen hebben is het niet meer mogelijk om adaptief of modificatief onderhoud per applicatie te plegen zonder vooraf de consequenties te kennen. Zou je dat wel doen, dan is de kans groot dat de afstemming van applicaties onderling in gevaar komt. Daarvoor is een basis nodig. Die basis dient niet alleen afstemming mogelijk te maken, maar zal ook de mogelijk-heid moeten bieden om bereikte afstemming te bewaren en te vergroten. Daarbij hebben we het niet alleen over de afstemming tussen applicaties onderling, maar ook (en vooral) over de afstemming (“alignment”) met de gebruiker. Die basis hiervoor vinden we in de informatie architectuur.

Daarmee is de term Functioneel beheer achterhaald. We dienen immers niet alleen de functionaliteit van een ICT-infrastructuur te beheren. Een organisatie zou niet primair geïnteresseerd moeten zijn in functionaliteit. Zij dienen geïnteresseerd te zijn in het feit dat informatie van de juiste kwaliteit op het juiste moment op de juiste plaats beschikbaar is en minder in de manier waarop die informatie aange-reikt wordt (wat natuurlijk wel op een acceptabele manier moet gebeuren).

Een goede informatie architectuur brengt alles rond de factor informatie in beeld. Als je weet welke gegevens informatie zijn voor een (deel van een) organisatie en welke randvoorwaarden, uitgangs-punten, eisen en wensen daaraan door die organisatie verbonden worden weet je ook welke functionaliteit geboden dient te worden en waar deze aan zal moeten voldoen. En nog veel meer. In feite introduceert het werken met een informatie architectuur een simpele regel: veranderingen van een infrastructuur kunnen alleen doorgevoerd worden als de consequenties van die veranderingen voldoende vastgesteld zijn. Ongeacht of het om nieuwbouw, aanschaf of onderhoud gaat.

Hoe ziet dat er in de praktijk uit? Simpel. Zorg ervoor dat alle gewenste veranderingen (en andere ideeën) rond informatie verzameld worden. De informatie architect dient in staat te zijn om binnen het beeld dat de informatie architectuur biedt de consequenties van die veranderingen vast te stellen. Zo ontstaat een werklijst die op gezette tijden omgezet kan worden naar een (informatie)plan.
Werk kan dan starten met wat we al weten. Door daar gebruik van te maken kunnen we bijvoorbeeld het specificeren en documenteren tot een minimum beperken. We hoeven immers “alleen nog maar” uit te schrijven wat specifiek te maken heeft met de manier van oplossen zelf? Dat voorkomt veel ex-tra en zelfs dubbel werk.

Een vaak gehoord probleem in dit kader is dat de slagvaardigheid van het veranderen van een infra-structuur vermindert. Als je onderhoud alleen nog zou kunnen uitvoeren via een informatieplan dan is het niet meer mogelijk om “kleine” aanpassingen snel door te voeren. Wat, logisch en terecht, leidt tot ontevreden gebruikers en organisaties. Dit kan je oplossen door een budget voor het doorvoeren van kleinere veranderingen aan te houden. Ja, een onderhoudsbudget, maar dan wel één die ingepast is in een andere aanpak.

Dat andere ligt in de voorbereiding. Als een verandering doorgevoerd dient te worden laat je de in-formatie architect eerst bepalen wat de consequenties zijn. Als deze hanteerbaar zijn, voer de veran-deringen dan op de snelle manier door waarbij de aanwijzingen van de informatie architect gevolgd dienen te worden. Accepteer dan wel dat sommige veranderingen toch meer consequenties blijken te hebben dan op het eerste gezicht misschien lijkt. Een goed informatie architect is in staat om dat duidelijk te maken en zal voorstellen de lange(re) weg van het informatieplan te bewandelen. En daarmee wordt dan voorkomen dat allerlei “simpele” aanpassingen tot grote problemen leiden, zoals hiervoor omschreven.

Werken onder architectuur betekent dat het wezen van functioneel beheer een heldere vorm en inhoud krijgt. De informatie architect beheert immers de informatie architectuur en functioneel beheer is een onderdeel van dat beheer. Deze manier van aanpak geeft niet alleen een wezenlijk andere inhoud aan wat we functioneel beheer noemen, het verandert ook de governance, het onderhoud, het beleid, alignment en ga zo maar door. De stukjes van de puzzel blijken zo wel een eigen plaats te hebben, logisch en helder.