Hoe vlieg je systeemontwikkeling aan? Met een bottom-up-benadering of juist top-down? Op een Agile ontwikkelwijze of toch de ‘good old’ waterval-aanpak? In dit vierde artikel over systeemontwikkeling bij het COA proberen we een antwoord te formuleren op deze jarenoude vragen.
In ons eerste artikel hebben we beschreven wat de gevolgen zijn als op een sterke bottom-up-manier informatieanalyse en systeemontwikkeling wordt gedaan. Daarbij bleek dat dit leidt tot tevreden en betrokken gebruikers, maar dat andere belangen, zoals die van ICT, nogal eens uit het oog verloren worden. Vandaar ook dat, toen de resulterende tijdelijke applicatie uit dat project vervangen moest worden, een meer hybride benadering is gekozen, die beschreven is in ons tweede artikel. Een uitgebreide beschouwing en vergelijking van beide wijzen hebben we in ons derde artikel uitgevoerd.
Volgende uitdaging
Op het moment van schrijven inmiddels enige tijd geleden staat het COA voor de volgende, nog grotere uitdaging. Het bestaande bewonersinformatiesysteem, IBIS, is aan vervanging toe. Dit is uitdagend omdat:
• Het systeem het kloppend hart is van de ICT-ondersteuning van het primaire proces. Het oude systeem moet dan ook blijven draaien terwijl het nieuwe systeem geïntroduceerd wordt: een open-hart-operatie dus.
• Het systeem groot en complex is en gekoppeld is aan een flink aantal andere applicaties.
• Een hoop kennis over het oude systeem verloren is gegaan. Het zat in de hoofden van analisten of ontwikkelaars die sinds lange tijd niet meer bij het COA in dienst zijn.
Los van deze COA-specifieke uitdagingen zijn er ook algemene redenen waarom het traject van de ontwikkeling van een informatiesysteem niet zomaar kan worden gekozen. Dit kan niet omdat de aanleiding voor het maken van een nieuw systeem sterk kan verschillen, de omvang van het nieuwe systeem sterk kan variëren, het aantal betrokken groot of klein kan zijn, etc. Afhankelijk van de opgave kan het traject dus op veel verschillende manieren worden afgelegd. Om een antwoord te geven op de uiteenlopende vraag hoe die ontwikkeling het best gedaan kan worden, zijn door de jaren heen veel verschillende manieren van systeemontwikkeling bedacht.
Invalshoeken
In het kader van dit artikel onderscheiden we twee dominante invalshoeken die bij systeemontwikkeling te onderscheiden zijn.
Allereerst de invalshoek van de gekozen aanpak. Grofweg zijn bij de gekozen aanpak twee ideaaltypische vormen te onderscheiden: de aanpak waarbij top-down de ontwikkeling van een systeem wordt aangepakt en de aanpak waarbij vooral bottom-up wordt gewerkt. In het eerste geval staat merendeels de visie op bedrijfsvoering centraal en in het tweede geval wordt gewerkt vanuit de dagelijkse werkprocessen van de gebruiker. Natuurlijk zijn er vele overgangsvormen te zien tussen deze twee ideaaltypische vormen.
De tweede invalshoek betreft de wijze waarop het systeem wordt ontwikkeld. We onderscheiden bij deze invalshoek twee vormen van systeemontwikkeling. In de eerste plaats de zogenaamde watervalmethode. Hierbij worden eerst alle specificaties in beeld gebracht en wordt daarna het systeem in zijn geheel gebouwd en getest. In de tweede plaats de zogenaamde Agile-methode. In dit geval worden gelijktijdig de specificaties verzameld en het systeem gebouwd waarbij bijvoorbeeld elke twee weken een deel van het nieuwe systeem wordt opgeleverd. Ook bij de tweede invalshoek zijn natuurlijk veel tussenvormen te onderscheiden.
Op basis van deze twee invalshoeken is het volgende analysekader ontwikkeld:
Overwegingen bij de keuze voor een ontwikkelmethode
De keuze voor een manier van ontwikkelen wordt beïnvloed door een veelheid van factoren. We onderscheiden hierbij een viertal overwegingen:
• Functionele overwegingen. Gedacht kan hierbij worden aan overwegingen die een organisatie heeft over het relatieve voordeel van de vernieuwing, zichtbaarheid van de vernieuwing, de mate waarin aangesloten wordt bij eerdere ervaringen, de complexiteit, mogelijkheid om vernieuwing aan te passen op de eigen situatie etc.
• Strategische overwegingen. Gedacht kan hierbij worden aan de mate waarin gunstige omstandigheden aanwezig zijn (het zogenaamde policy window), mate waarin ruimte is of gecreëerd wordt voor alternatieve oplossingen, katalyserende gebeurtenissen, personen die binnen een organisatie de geesten rijp maken.
• Institutionele overwegingen. Gewezen kan hierbij worden aan druk die een organisatie ondervindt van buiten, nieuwe regelgeving, aanwezigheid van een succesvol voorbeeld, deelname aan professionele netwerken
• Organisatorische overwegingen. Gedacht kan worden aan de omvang van de organisatie, beschikbaarheid van tijd en geld en personeel, structuur van de organisatie (waaronder geografische spreiding) etc.
Keuzes van het COA
Ten aanzien van de ontwikkeling van het nieuwe IBIS is zichtbaar dat met name strategische overwegingen een rol hebben gespeelt bij de keuze voor de ontwikkelmethode. Dit waren:
1. De sterke groei van de organisatie
2. De voortrekkersrol van sleutelfiguren in de organisatie
3. De ruimte die werd gecreëerd voor alternatieve oplossingsmogelijkheden
4. De noodzaak om meer uniform te werken
Op basis van deze overwegingen is de keuze gemaakt voor een top-down aanpak waarbij Agile wordt gewerkt, met een oplevering van eenmaal per jaar. In het hierboven ontwikkelde referentiekader is dit als volgt te visualiseren.
Beschouwen we vanuit dit analysekader de systeemontwikkeling bij het COA, dan zijn de andere systeemontwikkelingen die beschreven zijn in artikelen 1 en 2 als volgt te plotten:
Hoe heeft de gemaakte keuze uitgepakt?
De keuze heeft ertoe geleid dat er een grootschalig traject is gestart om de juiste kaders en uitgangspunten voor de vervanging van IBIS boven water te krijgen. Allereerst is het standpunt ingenomen dat IBIS vervangen zou moeten worden en dat nadere kaders en uitgangspunten nodig waren om te bepalen hoe en wanneer de vervanging plaats zou moeten vinden. Belangrijke argumenten voor de vervangen waren: de veroudering van de software, doorontwikkeling is te kostbaar, datakwaliteit is onvoldoende en nieuwe techniek is nodig om sneller te voldoen aan veranderende behoefte.
Vanuit dit vertrekpunt is een overzicht opgesteld van vragen die hiervoor zouden moeten worden beantwoord. Om de vragen te beantwoorden zijn een 30-tal workshops gehouden. Daarbij zijn de volgende onderzoeksgebieden onderscheiden: Omgeving, Enterprise architectuur, functionaliteit, ontwikkeling en implementatie. Het vooronderzoek is afgerond waarbij werd geconcludeerd dat nog een aantal aanvullende basisdocumenten nodig waren. Deze documenten betroffen: de inhoud van de zogenaamde doelarchitectuur, de platformstrategie en de vraag make or buy?
Bij het maken van een nieuw systeem dat gebruikt wordt door de gehele organisatie, komt meer kijken dan de bouw van het systeem zelf: zo wordt ook de gehele informatie-infrastructuur geraakt. Hierdoor is het nodig om te weten hoe de informatiearchitectuur van de gehele organisatie op termijn is opgebouwd. Deze architectuur wordt aangeduid als de doelarchitectuur. Meer op technisch gebied is het nodig om te weten welke platformen voor welke functies worden gebruikt. Voor de realisatie is het van belang hoe de keuze wordt gemaakt tussen kopen of bouwen. De basis voor de informatie-infrastructuur wordt bepaald door de zogenaamde i-visie. In de i-visie wordt een vertaling gemaakt tussen de doelstellingen en de missie van de organisatie en de informatie die nodig is om de missie en doelen te realiseren. In de periode na de afronding van het vooronderzoek is tijd besteed aan het opstellen van deze basisdocumenten.
Na afronding van de basisdocumenten heeft besluitvorming plaatsgevonden waarbij aanvullende vragen werden gesteld. Deze vragen werden gesteld gelet op functionele en organisatorische overwegingen. Gelet op de doorlooptijd van het onderzoek was het ook nodig om de strategische overwegingen te bezien ten opzichte van de actuele situatie. De resultaten hiervan en de gevolgen voor de weg die het COA nu is ingeslagen, zullen worden behandeld in een vervolgartikel.
Lessons learned
Bij een top-down aanpak wordt gewerkt vanuit het geheel. Gestart wordt bij de missie en vanuit de allerhoogste doelstelling wordt een verband gelegd naar de dagelijkse werkzaamheden. Hiervoor is het nodig dat beleid, werkprocessen en techniek naadloos op elkaar aansluiten. Dit geheel bleek in de praktijk niet aanwezig te zijn.
Veel tijd is besteed om de ontbrekende basisdocumenten te maken. Het is waardevol dat deze documenten er nu zijn. Het opstellen van deze documenten is niet eenvoudig geweest omdat de meer technische documenten niet begrepen werden door de eindgebruikers en de beleidsgerichte documenten niet goed begrepen werden door de technici.
Veel tijd is ook besteed aan het op orde brengen van de documenten die nodig zijn om een robuuste informatiehuishouding op te bouwen. Eindgebruikers hebben daarvan tot nu toe niet de vruchten kunnen plukken. Dit komt omdat alle tijd is gaan zitten in het maken van documenten en geen tijd is besteed aan het realiseren van gebruikerswensen.
Als gevolg van de vele tijd die nodig was om de ontbrekende documenten op te stellen is in de omgeving zoveel gebeurd dat gesteld kan worden dat het antwoord op de oorspronkelijke vraag achterhaald is door de tijd. Top-down werken in zijn uiterste vorm blijkt dus in dit geval niet mogelijk te zijn geweest.
Op basis van het werk dat is verricht en de basisdocumenten die nu bestaan is een goede uitgangspositie bereikt om bottom-up verder te gaan. Geprofiteerd kan daarbij worden van goede ervaringen die hiermee zijn opgedaan (zie artikel 1 en 2). De institutionele overwegingen lijken hierbij nu een belangrijke rol te gaan spelen.
Lars Wortel is consultant bij Capgemini. Johan van Wamelen is beleidsadviseur bj het COA en richt zich in zijn werkzaamheden op het slaan van een brug tussen gebruikers en aanbieders van ICT voorzieningen. Zijn interesse ligt bij vraagstukken op het gebied van de organisatie van de informatievoorziening in grote publieke organisaties.
