IT die wél verandering ondersteunt

De complexiteit en fluïditeit van hedendaagse veiligheidskwesties stijgen door digitalisering en mondiale verwevenheid. De Defensievisie 2035 benadrukt het belang van informatiegestuurd en flexibel optreden en de hoogwaardige IT die daaraan ten grondslag ligt. Flexibiliteit van de eigen informatievoorziening vergt zowel adaptief vermogen van de eigen systemen als interoperabiliteit met IT-systemen van partners. Het huidige IT-landschap van Defensie, met zijn grotendeels centrale aansturing, schiet tekort en moet veranderen om te kunnen voldoen aan deze nieuwe eisen.

Jelle Wouters, Mariel van Staveren, Bas van Hulst en Toon Abcouwer*

Veel veranderingen vinden momenteel geen doorgang door beslissingsangst en inflexibiliteit in de (centrale) IT-keten. De maatschappelijke en technologische ontwikkelingen (zoals gerelateerd aan de coronapandemie in 2019, de oorlog in Oekraïne in 2022 of de doorlopende aandacht voor klimaatverandering) gaan zo snel dat traditionele systeemontwikkelingsmethodes niet meer voldoen. Ons beeld is dat de gehele defensieorganisatie kampt met dit probleem. In dit artikel bespreken we dit probleem enkel vanuit het perspectief van de Koninklijke Marechaussee (KMar), maar de standpunten die we aandragen zijn in onze ogen voor heel Defensie relevant.

Het huidige IT-landschap van Defensie, met zijn grotendeels centrale aansturing, schiet tekort en moet veranderen. Foto MCD, Hille Hillinga

De technologie staat niet stil

Hedendaagse maatschappelijke ontwikkelingen vertonen in toenemende mate een disruptief karakter.[1] Het wordt daarbij steeds moeilijker te voorspellen welke eisen aan de informatievoorziening worden gesteld. Voortborduren op het verleden, en dus incrementeel verbeteren, werkt steeds minder. Aangezien waterval- en agile-benaderingen (respectievelijk stapsgewijze aanpak: eerst plannen en ontwerpen, dan bouwen en pas in gebruik nemen als alles af is, en sprintgewijze aanpak: iedere keer kleine stapjes ontwikkelen, in gebruik nemen en daarop voortbouwen) vooral gebaseerd zijn op historische inzichten, voldoen deze steeds minder in het licht van de huidige dynamiek. Of je bijvoorbeeld van een Nokia 3310-telefoon via incrementeel ontwikkelen een iPhone kan maken is daarom ook zeer de vraag. Steve Jobs, de voormalige CEO van Apple, zei in dit verband eens dat ‘Most people don’t even know what they want until they see it. So sometimes you have to give people what they need, not what they’re asking for’. 

Daarnaast gaan ook technologische ontwikkelingen in het IT-domein razendsnel. Belangrijke ontwikkelingen zijn bijvoorbeeld:

• Grootschalige inzet van sensoren en mobiele sensorplatformen/robotische systemen op wapensystemen (zoals patrouillerobots) waarmee arbeidsextensiever kan worden geopereerd.
• Kunstmatige intelligentie voor grootschalige data-analyse (zoals ChatGPT, dat zichzelf zo snel ontwikkelt dat semi-autonome conversaties tegenwoordig zonder tussenkomst van de mens mogelijk zijn en dat zowel voor ons als tegen ons kan worden gebruikt).
• Lowcode waardoor het voor Defensie mogelijk wordt sneller IT te ontwikkelen én in gebruik te nemen.
• Robotic Process Automation (RPA) voor kantoorautomatisering waarmee er een grotere efficiëntie in de bedrijfsvoering kan worden behaald.
• Big data-technologieën waarmee Defensie (en haar opponenten) meer informatie kunnen gebruiken om operaties te ondersteunen.
• Extended Reality (zoals Virtual en Augmented Reality) die technologisch volwassen genoeg is om in te zetten in operationele context zoals plaats-delictmanagement of voor trainingsdoeleinden.

Deze technologische ontwikkelingen leiden tot nieuwe uitdagingen. De huidige problemen in de informatievoorziening zijn als volgt te beschrijven:

• Maatschappelijke en technologische ontwikkelingen dwingen Defensie richting een zelfsturende en flexibele manier van optreden.
• Traditionele methodes voor systeemontwikkeling en organisatieverandering voldoen niet meer.
• Er is een disbalans tussen de centrale IT-infrastructuur en decentrale wensen, wat zorgt voor inflexibiliteit in de IT-keten.
• Er bestaat een grote druk op de IT-keten door de enorme behoefte aan nieuwe IT-oplossingen.
• De hoge (bestuurlijke) complexiteit in de centraal georiënteerde IT-keten leidt tot traagheid.
• Specialistische kennis, bijvoorbeeld op het gebied specifieke toepassing van kunstmatige intelligentie en robotica in de defensieonderdelen (DO’en) is onvoldoende aanwezig in de centrale IT-keten.

Gebaseerd op onze ervaringen binnen de praktijk van de KMar dragen we in dit artikel enkele zienswijzen en oplossingen aan voor deze problemen. We beginnen met theoretische beschouwingen die helpen om de complexe problematiek te duiden. Vervolgens bespreken we verschillende oplossingen in de vorm van standpunten.

Een theoretisch perspectief: organisatiedynamiek en leiderschap

Alle hiervoor genoemde ontwikkelingen dwingen organisaties tot het doorlopen van een veranderproces. Het goed begrijpen van dit veranderproces helpt ons beter hierop in te spelen. Het Adaptive Cycle of Resilience-model (ACoR)[2] biedt aanknopingspunten om de fasen in verandering te begrijpen, maar misschien nog wel belangrijker maakt het model mogelijk de overgangen met de daarbij bestaande risico’s te herkennen.

Figuur 1 De Adaptive Cycle of Resilience

Het ACoR-model volgt een standaardroute, een cyclische ontwikkeling waar elke organisatie doorheen gaat. Het proces start vanuit een veronderstelde evenwichtsfase (linksonder in de cyclus: ‘Evenwicht’). In een evenwicht doen zich regelmatig relatief kleine verstoringen voor, die gemakkelijk worden opgelost door eerder bewezen succesvolle interventies.

De stapeling van deze verstoringen kan echter mede door externe invloeden uitgroeien naar ernstige verstoringen met vergaande invloed op de bestaande evenwichten. Deze dwingen de organisatie naar het zogenaamde ‘Uitdaging’-kwadrant. Herkent de organisatie deze invloeden niet of te laat dan dreigt het risico van ‘Lock-in’. Het te laat onderkennen ervan kan eenvoudig leiden tot een daadwerkelijke crisis waarbij niet meer adequaat op de ontwikkelingen kan worden ingespeeld.

In de fase Uitdaging moet een zoekproces worden gestart naar nieuwe oplossingen en passende competenties, vaardigheden en houdingen. Maar dit vergt veel van de organisatie als geheel. Oude zekerheden moeten worden losgelaten en creatieve oplossingen moeten de weg naar de toekomst verkennen. Het is de vraag of de organisatie hiertoe in staat is. Het ontbreken hiervan wordt wel aangeduid als ‘Poverty’, de creatieve armoede die het liefst de organisatie bij het oude wil laten.

Inspiratie en ‘out of the box’-denken moet dan leiden tot het zogenaamde ‘Nieuwe Combinaties’-kwadrant. Het biedt potentiële oplossingen, maar het implementeren ervan vergt wel lef en overtuigingskracht binnen de organisatie. Een goede oplossing voor een uitdaging die niet binnen de organisatie wordt geaccepteerd plaatst de ontwikkelaars ervan in een situatie van ‘Isolation’. De ‘roepende in de woestijn’ is een figuur die dreigt te stranden in onbegrip, wat eventueel zelfs tot verstoting kan leiden. Daarbij komt het probleem dat uit de vastgestelde opties de meest geschikte oplossing moet worden gekozen. Dat betekent dat niet alle oplossingen worden geïmplementeerd, zodat er altijd creatieve medewerkers in ‘Isolation’ zullen achterblijven. Wanneer de organisatie dit niet goed opvangt is het risico aanwezig dat de verantwoordelijken voor de afgewezen opties gaan tegenwerken, wat zelfs afbreuk kan doen aan de wél geaccepteerde interventies/veranderingsprojecten. De overgang naar het vierde kwadrant ‘Operationalisering’ is daarom vaak de moeilijkste, waar vaak de ‘definitieve’ keuze moet worden gemaakt zonder zekerheid over het succes ervan. Een dergelijke beslissing is vaak gebaseerd op intuïtie en buikgevoel. In deze fase wordt dus niet meer gezocht naar nieuwe initiatieven, maar wordt alle energie gestoken in het verwerven van draagvlak en het voorbereiden van de implementatie.

In de operationaliseringsfase gaat het om het implementeren en opschalen van de gekozen oplossing naar een nieuwe evenwichtstoestand. Implementatie is echter ook de fase waarin de rigiditeit van de organisatie tot uitdrukking komt. Weerstand tegen veranderen, maar ook onvoldoende aanpassingsvermogen kunnen de belemmering vormen voor het bereiden van een nieuwe evenwicht. Let wel, het veranderingsproces is oneindig, na het doorlopen van de cyclus start het opnieuw. Het verandertraject vormt op die manier een continuüm van zich herhalende cycli.

Defensie heeft, net als bij militaire operaties, geprobeerd opdrachtgerichte commandovoering te gebruiken bij IT-projecten. In de praktijk bleek decentrale uitvoering praktisch niet haalbaar. Foto MCD, Eva Klijn

De kracht van het ACoR-model ligt in de focus op verandering als een voortdurend proces, waarbij iteratief de behoefte aan management en leiderschap ontstaat. Management richt zich op het aanpakken van de problemen van vandaag. Omgaan met uitdagingen aan de linkerkant van het ACoR-model, leidt tot de behoefte aan controle en ‘de dingen goed doen’, maar ook tot de noodzaak van het herkennen van cruciale potentiële uitdagingen. Aan de rechterkant van ACoR zien we een grotere behoefte aan creativiteit, samenwerking met collega’s en het verwoorden van een visie op een onvoorziene toekomst. Nieuwe oplossingen moeten worden ontdekt en het kunnen toepassen ervan vergt dat ze ook daadwerkelijk worden gemaakt. De uiteindelijke implementatie vergt dan ten slotte het stabiliseren ervan. Deze vier activiteiten, herkennen, ontdekken, maken en stabiliseren vragen om aansturing door een leider in plaats van door een manager. Er is een werkwijze denkbaar waarbij onderscheid gemaakt wordt in de aard van (IT-)projecten, zodat de meest geschikte leiders gekoppeld kunnen worden aan specifieke onderdelen van de beoogde transformatie. Leiderschap (ter onderscheiding van management) speelt hierbij een belangrijke rol.

De huidige aanpak van IT-projecten bij Defensie

Militaire operaties worden vaak uitgevoerd aan de hand van opdrachtgerichte commandovoering. Dit concept begint met een oogmerk van de commandant. In dit oogmerk staat het beoogde effect van de operatie, maar de invulling van hoe dit effect wordt behaald wordt aan de uitvoerende partij overgelaten.[3] Omdat de praktijk van militaire operaties weerbarstig is - situaties veranderen zo snel dat overleg met de commandant niet altijd mogelijk is - moet een afwijking van het vooropgestelde plan mogelijk zijn. Dit betekent dat decentraal op de actuele situatie moet worden gereageerd. In een dynamisch veranderende context moet het paradigma van centrale aansturing dus soms worden verlaten.

Binnen de IT van Defensie is geprobeerd opdrachtgerichte commandovoering in te zetten bij de samenwerking met het JIVC. Het DO geeft een oogmerk af (het ‘wat’), en het JIVC bepaalt hoe het dat invult (het ‘hoe’). Het DO begint met een functionele vraag, die vervolgens door het JIVC wordt geanalyseerd. Daarvoor gebruikt het JIVC het beleid dat door de Chief Information Officer (CIO) wordt gemaakt. De CIO is verantwoordelijk voor het beleid rondom IT en maakt keuzes over de Defensiebrede IT. Zodra de analysefase is voltooid, vertelt het JIVC aan het DO wat het gaat doen (de ‘commanders backbrief’). Als het DO akkoord is start het JIVC met de ontwikkeling. Dit gebeurt in de basis onafhankelijk van het DO, dat wordt geïnformeerd als het nodig is. Ook dit is in lijn met de opdrachtgerichte commandovoering: sturen op het wat, maar niet op het hoe. Als het product af is volgt de overdracht naar het DO. Zij nemen het product vervolgens in gebruik. Tussen deze fases zit vaak een aantal jaren.

In een dynamische omgeving maken snelle veranderingen het echter onmogelijk voor het JIVC om de noodzakelijke expertise te leveren. Decentrale uitvoering is dus praktisch onuitvoerbaar. De operationele werkvloer herkent vaak sneller de actualiteit en kan daar op reageren. Het JIVC, als hoog-professionele IT-organisatie, heeft over het algemeen minder ervaring met de operatie van de DO’en. Daardoor is het voor het JIVC lastig om tot de kern van de vraag te komen, en worden er soms implementatievoorstellen geschreven die goed in elkaar zitten qua IT, maar niet passen op de operationele realiteit. Dat maakt de analysefase vaak onnodig complex en traag, omdat veel mensen van buiten het JIVC expertise moeten leveren en ze dus niet zelfstandig de opdracht kunnen uitvoeren. Daardoor komt het vaak voor dat zowel het JIVC als de operatie gefrustreerd raakt: het JIVC ervaart een grillig DO dat zijn behoefte te vaak verandert waardoor er geen IT voor te ontwikkelen is, en het DO ervaart dat het JIVC nooit (precies) levert wat er gevraagd wordt.

De gewenste situatie bij Defensie

De organisatie roept steeds meer om snellere IT. Van het JIVC wordt verwacht dat het sneller goede producten oplevert. Capaciteitsproblemen die daarbij ontstaan worden op dit moment vooral opgelost door extra analysecapaciteit binnen het JIVC aan te trekken of door prioriteitsstelling waardoor er netto minder gebeurt. Door de DO’en meer te betrekken in het ‘hoe’ en de regie over de uitvoering weer deels bij de DO’en te leggen, wordt beter gebruik gemaakt van de expertise die de verschillende partners inbrengen. DO’en kunnen immers weer actief meedoen met het ontwikkelproces in plaats van passief te wachten op resultaat. Dat komt de eindproducten die worden opgeleverd ten goede.

De ambitie om de ontwikkeling van nieuwe IT meer in samenspraak met de operatie van de DO’en te laten plaatsvinden, vergt dat aanvullende competenties en kwaliteiten binnen de decentrale IT-afdelingen worden ontwikkeld. Daarbij moeten voorzieningen worden getroffen om kennisdeling tussen DO’en en JIVC te initiëren/stimuleren. In de praktijk hebben er echter jaren van bezuinigingen en centralisering van de IT binnen Defensie plaats gevonden. Dit heeft ervoor gezorgd dat de IT-afdelingen van de diverse DO’en op dit moment vooral goed zijn in de begeleiding van de procesactiviteiten die – niet altijd tot tevredenheid – tot door JIVC uitgevoerde IT-projecten leiden. Deze specifieke (meer bedrijfskundige) expertise van de DO’en moet dus worden aangevuld door DO-specifieke technisch inhoudelijke IT-medewerkers. Hierbij valt te denken aan AI-specialisten, data scientists, robotica experts, elektrotechnici, gamedevelopers, et cetera. Omdat de werkzaamheden van deze mensen vaak meer op het vlak van creatie liggen dan op het vlak van besturing, vergt de aansturing en begeleiding van deze mensen andere vaardigheden van leidinggevenden.

Standpunten ten aanzien van een nieuwe relatie tussen DO’en en JIVC

Om de lijn van denken verder te operationaliseren hebben we drie standpunten geformuleerd over de relatie tussen de centrale IT organisatie en de DO’en. We bespreken ze hier achtereenvolgens.

Standpunt 1: JIVC moet zich meer richten op de infrastructuur en de generieke IT-services die de hele organisatie raken

De rol van het JIVC staat niet ter discussie, maar verdient meer focus. In onze visie moet JIVC zich meer richten op generieke IT-services, in plaats van DO-specifieke voorzieningen. Er zijn projecten die een overduidelijk paars (die over alle DO’en worden gebruikt) karakter hebben en daarmee niet onder één DO kunnen worden geschaard. Denk bijvoorbeeld aan de vervanging van PeopleSoft, het vernieuwen van SAP en het uitrollen van nieuwe werkplekhardware. Dat zijn projecten waarbij alle DO’en een rol spelen, en dan is het niet handig als één DO de kar trekt. In dat soort projecten is het niet meer dan logisch dat het JIVC deze projecten leidt, hoewel de input van de verschillende DO’en natuurlijk wel goed moet worden meegenomen. We duiden deze faciliteiten aan als generieke voorzieningen.

Figuur 2 Generiek, specifiek en infrastructureel

Daarnaast hebben de DO’en ook niet zoveel met de IT-infrastructuur van doen. In figuur 2 noemen we deze voorzieningen Infrastructure.[4] Servers, kabels, firewalls en andere apparaten zijn natuurlijk essentieel voor het slagen van IT-projecten, maar raken niet direct de IT-projecten waar de DO’en mee te maken hebben. In grote organisaties (zowel commercieel als bij de overheid) wordt er steeds meer gewerkt met dergelijke ‘services’. Die kunnen dan door IT-teams van DO’en worden afgenomen en zorgen ervoor dat complexiteit tot op een bepaalde hoogte wordt uitbesteed (denk aan ‘Infrastructure-as-a-service’).[5]

Dit standpunt pleit er dus voor dat DO’en zelf invulling geven aan de voor hen specifieke informatievoorzieningen. Denk hierbij aan eigen applicaties, AI-oplossingen, en IT in wapensystemen.

Op die manier kunnen DO’en zelf (kleine) IT-projecten en innovaties ontwikkelen en deze, geborgd en conform standaard, binnen het defensiedomein laten landen. Het JIVC neemt in deze situatie meer een rol van facilitator en integrator aan. Het zorgt bijvoorbeeld voor figuurlijke stopcontacten (API’s) waar DO’en hun stekkers in kunnen steken. Een deel van het huidige werk van JIVC komt dus bij de DO’en te liggen. Dit verlicht de grote last op de schouders van JIVC.

Deze verschuiving vindt overigens nu ook al plaats: steeds meer DO’en nemen een gedeelte van de IT-voorziening weer voor hun eigen rekening (zie kader). Zo heeft het CLSK zijn volledige Data Science Cell in eigen beheer (voor specifieke oplossingen) en werken steeds meer DO’en met Platform-as-a-Service SharePoint (als generieke/infrastructurele voorziening geleverd door JIVC), waarbinnen ze hun eigen IT-oplossingen kunnen ontwikkelen. Daarin treedt het JIVC ook al meer als facilitator op. Dit zorgt voor een snellere doorlooptijd maar het kan niet gebruikt worden voor operationeel zware applicaties, omdat de huidige platformen van het JIVC voor deze doeleinden niet geschikt zijn.

Kortom: dit standpunt bepleit dat generieke en infrastructurele voorzieningen de primaire verantwoordelijkheid voor JIVC blijven, terwijl specifieke voorzieningen meer onder de verantwoordelijkheid van de direct betrokkenen worden verschoven. Deze oplossing is relatief eenvoudig te implementeren: het vergt enkel een aanpassing aan beleidskaders, afspraken en autorisatiestructuren: aan de onderliggende techniek verandert er niets.

Standpunt 2: Er is een toenemende noodzaak voor een alternatieve kijk op de werkstroom 4-projecten

De doorlooptijd van IT-projecten is vaak een struikelblok. Door onvoorziene omstandigheden en/of gewijzigde behoeftes kosten IT-projecten geregeld meer geld en tijd dan van tevoren gepland. Dit vraagt om een herziening van de werkprocessen. Het JIVC werkt momenteel met vier werkstromen. Werkstroom 1 en 2 zijn aanschaf van middelen die het JIVC al in het assortiment heeft zitten (vooral generieke en infrastructurele middelen). Deze processen duren dus maar enkele weken. Werkstroom 3 zijn middelen die nog niet in het assortiment zitten, maar die relatief eenvoudig van de markt te halen zijn en een generiek of infrastructureel karakter hebben. Denk bijvoorbeeld aan een specifieke barcodescanner die we nog niet voeren. Deze doorlooptijd is meestal enkele maanden. Werkstroom 4 zijn projecten die door hun specifieke en/of specialistische karakter niet zomaar uit te voeren zijn, bijvoorbeeld de aanschaf van een nieuw IT-systeem van een leverancier of de volledige in-house ontwikkeling van iets nieuws. Voor het realiseren van werkstroom 4-projecten wordt standaard gekozen voor een projectmatige aanpak volgens de PRINCE2-projectmanagementmethodiek. Binnen deze methodiek is er ruimte om te kiezen tussen een beheersmatige of een flexibele aanpak. Deze keuzeruimte lijkt echter nauwelijks te worden benut. Er lijkt namelijk steevast te worden gekozen voor de meest beheersmatige en dus minst flexibele aanpak. In de praktijk duren werkstroom 4 projecten daarom op dit moment erg lang.

Marechaussees controleren op Schiphol Plaza. Kleine IT-verzoeken, zoals een KMar-kiosk op de luchthaven, zouden ‘quick wins’ kunnen zijn. Foto MCD, Sjoerd Hilckmann

Dit heeft tot gevolg dat JIVC alleen bezig kan zijn met de grote projecten, en dat de kleintjes worden geparkeerd. Jammer, want voor de DO’en zijn de kleine verzoeken juist vaak de ‘quick wins’. Denk bijvoorbeeld aan een kiosk die de KMar op Schiphol Plaza kan neerzetten zodat burgers alvast een intake kunnen doen voordat ze met hun aangifte aan de balie verschijnen. Een dergelijk project wordt door de KMar niet eens ingediend bij het JIVC, omdat dit het vanwege capaciteitsgebrek binnen het JIVC niet zal redden. Terwijl de ontwikkeling helemaal niet zo lang hoeft te duren. DO’en willen innoveren, en daardoor worden dit soort innovaties nu regelmatig in eigen beheer uitgevoerd. Daardoor ontstaan er niet-geborgde IT-applicaties waarvan sommigen nu zo bedrijfkritisch zijn geworden dat uitval geen optie meer is.

Dit standpunt bepleit dat we de PRINCE2-methodiek anders invullen binnen werkstroom 4-projecten. Een meer flexibele invulling zou bijvoorbeeld zijn om eerder in het proces, in samenwerking met het DO, een prototype te maken. Daarmee kan er een betere discussie worden gevoerd over wat men nu precies wil, en verlagen we het afbreukrisico als het toch niet precies is wat we zoeken.

Standpunt 3: Binnen defensie moeten alternatieve methodes voor Software Ontwikkeling (SO) kunnen worden gekozen die aansluiten bij de aard van het ontwikkelingsproject

Waar het eerste standpunt betrekking had op het toepassingsveld van de betreffende Informatievoorziening en het tweede standpunt aandacht vroeg voor het type ontwikkelingstraject richten we ons in standpunt 3 op de ontwikkelmethodiek.

Figuur 3 De traditionele watervalbenadering

Traditionele systeemontwikkelingsprojecten volgen veelal een zogenaamde watervalbenadering. Na een requirements-analyse wordt een ontwerp gemaakt van het te realiseren informatiesysteem. Vervolgens wordt het gebouwd en in gebruik genomen. Veelal blijkt dat de behoeften dan alweer zijn gewijzigd. Hierdoor voldoet het gerealiseerde systeem direct niet meer aan de eisen. In dit type ontwikkelmethodiek is weinig aandacht voor hoe er in de toekomst afscheid kan worden genomen van het systeem (in figuur 3 ‘Euthanasie’ genoemd). Het afscheid nemen van delen van de informatievoorziening vergt veel meer dan het ontwikkelen van een nieuw vervangend systeem. Een goed voorbeeld hiervan is de beoogde beëindiging van het gebruik van netwerkschijven (P:, Q:, et cetera) bij de introductie van het SharePoint als platform voor informatie-uitwisseling. De introductie van een nieuw systeem verandert niet automatisch de cultuur van gegevensdeling binnen de organisatie.

In de tegenwoordige tijd wordt dikwijls gepropageerd dat er ‘agile’ gewerkt moet worden. Het nauwer betrekken van de gebruiker zou de fouten van de watervalmethodiek moeten voorkomen. Korte ontwikkelcycli zouden de flexibiliteit van de ontwikkeling verhogen. Toch kenmerken agile projecten zich vaak als kort-cyclische watervallen. Evolutionair ontwikkelen gebaseerd op bekende gebruikerswensen is dan het motto. Het uitgaan van geformuleerde gebruikerswensen leidt in principe tot dezelfde problemen als de grootschalige traditionele ontwikkeltrajecten. Agile kan ingezet worden om flexibel in te spelen op nieuwe gebruikerswensen, mits de methodiek op de juiste manier gebruikt wordt.

Figuur 4 De ‘agile’-benadering

Naast PRINCE2 en agile zijn er ook andere systeemontwikkelingsbenaderingen. Een van de nieuwere ontwikkelingen zijn de zogenaamde ‘low-code’-platformen. Met dit soort platformen zijn niet-IT-ers (met een beetje hulp) in staat een programma in elkaar te klikken. Programmeren is niet nodig (maar kan wel): alles gaat visueel. Daarnaast kunnen professionele IT’ers wél programmeren en bouwstenen voor anderen klaarzetten. JIVC’ers kunnen daarmee bijvoorbeeld bouwstenen voor koppelvlakken met andere applicaties ontwikkelen, die iedereen kan gebruiken. Deze maatregel valt meteen te implementeren en daar wordt inmiddels ook aan gewerkt. Technisch is het vrij eenvoudig te realiseren: KIXS (de experimentenafdeling van het JIVC) heeft al eerder succesvol een low-codeomgeving op MULAN geïmplementeerd, maar omdat het een pilot was moest die helaas ook weer worden uitgezet.

Een andere ontwikkeling (die buiten Defensie al veel gebruikt wordt) is containerisatie van software. Het principe is dat alles voor een applicatie in een virtuele container wordt gestopt die daardoor makkelijk op het netwerk te plaatsen is en zo onafhankelijk van de onderliggende technologie in verschillende omgevingen gebruikt kan worden. Defensie doet dit al: het Basis Cloud Platform (BCP) van het JIVC is erop gebaseerd. DO’en mogen daar echter niet zelfstandig gebruik van maken. Door DO’en (die aan de aansluitvoorwaarden voldoen) toegang te geven tot dit platform is het mogelijk om experimenten en innovaties die wél daadwerkelijk geprogrammeerd moeten worden makkelijker op MULAN te laten landen. Op die manier is het makkelijker om van standalone experiment naar een geborgd product te komen. Ook deze maatregel is eenvoudig te implementeren: het vergt alleen een beleidsaanpassing aangezien het BCP hiervoor al geschikt is. Wel is er zodra dit fenomeen verder gaat groeien een infrastructuur-aanpassing nodig.

Voor het kiezen van een systeemontwikkelingsmethode is geen eenduidige aanpak en het hangt af van het type project, de benodigde expertise, en randvoorwaardelijke factoren zoals opgelegde deadlines en budgetten om een project te laten slagen.

De juiste keuze van systeemontwikkelingsmethode biedt voor Defensie veel mogelijkheden. Het JIVC kan de DO’en hierin ondersteunen door meer ontwikkelmogelijkheden te bieden aan collega’s die bij de DO’en werken. Deze mogelijkheden kunnen door JIVC én DO’en zelf gebruikt worden voor prototyping. DO’en kunnen zo kleinere projecten zelf oppakken. Het is natuurlijk niet zo dat DO’en dan zelf maar alles mogen doen. Een begeleidingsteam van het JIVC kan in de gaten houden of alle door het DO gemaakte software wel aan de door het JIVC gestelde eisen voldoet. Zo moet de software voldoen aan beveiligings- en privacy-eisen en moeten ingewikkeldere projecten alsnog als klassiek PRINCE2-project (mét prototyping) worden aangelopen. Door JIVC kunnen zo bepaalde regels over privacy en beveiliging centraal worden aangestuurd, waardoor producten in low-code ‘by design’ aan het beveiligingsbeleid voldoen. Daarnaast heeft het JIVC één overzicht van alle door de DO’en ontwikkelde software, zodat het op tijd kan bijspringen als een oplossing toch een betere projectsturing nodig heeft.

Het is belangrijk in te zien dat niet alle projecten geschikt zijn voor een low-code-oplossing of bring-your-own container. Grote, operationele applicaties met veel koppelingen naar de buitenwereld verdienen nog steeds een aanpak die we nu ook toepassen. De winst voor de DO’en zit bij deze aanpak dan ook vooral in relatief simpele applicatieontwikkeling en een beter begrip van wat het JIVC bij grote projecten gaat opleveren. Dat zorgt voor een versnelde ontwikkeling en daar worden het JIVC én de DO’en beter van.

Met een dergelijke meer flexibele benadering van systeemontwikkeling is het mogelijk dit soort projecten experimenteel tot behoeften te laten komen, fouten te maken, en al lerende tot een oplossing te komen. Dit proces laat zich lastig ‘besturen’. Niet alle ontwikkelingen in een organisatie laten zich vooraf tot in het kleinste detail voorspellen. Leiding geven aan een ‘spelende organisatie’, waarin bewust ruimte wordt gegeven aan innovatieve manieren van IT-ontwikkeling, verdient meer aandacht binnen Defensie.

Specialistische kennis, bijvoorbeeld op het gebied van specifieke toepassing van kunstmatige intelligentie en robotica, is onvoldoende aanwezig in de centrale IT-keten. Foto MCD, Jarno, Kraayvanger

De impact van onze standpunten als probleemoplossing binnen de IT van Defensie

De drie standpunten bespreken een positie van de DO’en in relatie tot de IT-leverancier die naar ons inzicht de IT-ontwikkelingen kunnen versterken. De problemen zoals we die in de inleiding hebben gesignaleerd kunnen op die manier grotendeels worden opgelost. Samengevat bieden de standpunten op de volgende wijze oplossingen voor de gesignaleerde problemen.

• Maatschappelijke en technologische ontwikkelingen dwingen Defensie richting een zelfsturende en flexibele manier van optreden. De technologische ontwikkelingen gaan zo snel dat de verschillende DO’en niet van een centrale IT-leverancier mogen verwachten dat die voldoende specifieke kennis en inzicht genereert. De DO’en hebben specialistische kennis in huis, en voor de flexibiliteit en het aanpassingsvermogen is het noodzakelijk om deze capaciteit in te zetten. Door een duidelijk onderscheid te maken tussen generieke en infrastructurele voorzieningen en voorzieningen die zijn toegespitst op de specialistische toepassingen van IT (standpunt 1) kunnen we beter inspelen op de eisen die de DO’en stellen. Het voorkomt ook dat prioriteitskeuzes alleen op centraal niveau worden gemaakt, waardoor er meer geprofiteerd kan worden van decentrale kennis en inzichten.
• Traditionele methodes voor systeemontwikkeling en organisatieverandering voldoen niet meer. In standpunt 2 bepleiten we dat de gebruikelijke indeling van werkstroom 1 t/m 4 van waarde is, maar ook dat deze indeling verschillende manieren van werken vereist. Door het onzekere en innovatieve karakter van werkstroom 4-projecten past een strikt procesmatige manier niet. Toch wordt de PRINCE2-methodiek voor werkstroom 4-projecten meestal zeer beheersmatig, in plaats van flexibel, ingevuld. Door het specifieke karakter van werkstroom 4-projecten is centrale aansturing niet aan te bevelen. Dit inzicht loopt parallel aan de indeling die we in standpunt 1 propageren. Werkstromen 1 t/m 3 sluiten nauw aan bij generieke en infrastructurele voorzieningen. Werkstroom 4-projecten vereisen een hoge mate van specialistische kennis en moeten daarom decentraal worden belegd. Nieuwe methoden van systeemontwikkeling en systeemrealisatie zouden dan ook vooral bij dergelijke projecten moeten worden toegepast. In standpunt 3 hebben we gewezen op nieuwe manieren van werken. We noemden daar onder andere prototyping, werken met low-code-omgevingen en containerisatie van systeemontwikkelingen. Dit leidt tot een nieuwe manier van samenwerken tussen de DO’en en JIVC, waarbij iedereen zijn eigen rol speelt. Zo ontstaat er ruimte voor de DO’en om hun eigen ontwikkelingen te initiëren en uit te voeren.
• Er is een disbalans tussen de centrale IT-infrastructuur en decentrale wensen, die zorgt voor inflexibiliteit in de IT-keten. Doordat binnen defensie onvoldoende onderscheid wordt gemaakt tussen generieke en specifieke toepassingen, met de ondersteunende infrastructuur (standpunt 1), en de neiging alle systeemontwikkeling projecten op dezelfde manier (namelijk zeer beheersmatig) uit te voeren (standpunt 2), wordt de flexibiliteit van de IT-keten belemmerd. Het kunnen kiezen tussen verschillende ontwikkelingsmethoden kan dit deels oplossen (standpunt 3).
• Er bestaat een grote druk op de IT-keten door de enorme behoefte aan nieuwe IT-oplossingen. De noodzaak tot vernieuwing in de informatievoorziening neemt in de nabije en langere toekomst zeker niet af. Vasthouden aan traditionele processen draagt niet bij aan het adaptieve vermogen van de organisatie. Het maken van een onderscheid in toepassingsgebieden (standpunt 1), het type ontwikkelingstraject (standpunt 2) en de bijbehorende keuze van ontwikkelingsmethoden (standpunt 3) biedt naar ons inzicht mogelijkheden tot een veel flexibelere IT binnen defensie.
• De hoge (bestuurlijke) complexiteit in de centraal georiënteerde IT-keten leidt tot traagheid. Binnen de overheid heeft na het parlementair onderzoek naar ICT-projecten bij de overheid een bureaucratiseringslag plaats gevonden van IT-ontwikkelingen.[6] AC-ICT (adviescollege ICT)-beoordelingen eisen dat de bijdrage van ontwikkelingstrajecten worden gekwantificeerd, met het risico op afwijzing van innovatieve initiatieven die niet aan deze eis kunnen voldoen. Dit werkt vooral nadelig voor innovatieve projecten (veelal werkstroom 4). De ambitie om complexe projecten te standaardiseren schaadt het aanpassingsvermogen en flexibiliteit. Het doen van experimenten, met het bijbehorende risico van falen, is in het licht van de hedendaagse dynamiek een noodzaak. Ook moeten quick-wins worden aangemoedigd. De drie standpunten dragen hier aan bij.
• Specialistische kennis, bijvoorbeeld op het gebied van specifieke toepassing van kunstmatige intelligentie en robotica in de DO’en, is onvoldoende aanwezig in de centrale IT-keten. Hoewel bij de centrale IT-keten een hoogwaardig kenniscentrum (KIXS) aanwezig is, kan niet worden verwacht dat alle specialistische kennis van de verschillende DO’en daar kan worden ontwikkeld. De rol van het kenniscentrum binnen JIVC zou gericht moeten zijn op kennisuitwisseling en -deling. Dit vergt tweerichtingsverkeer. In de huidige situatie wordt er veel vanuit een centralistisch perspectief gedacht. KIXS zou generieke (door JIVC ontwikkelde) en specialistische (op DO-niveau) kennis bij elkaar kunnen brengen. De drie standpunten bieden daar aanknopingspunten voor ten aanzien van de keuze voor structuur, type ontwikkelingsproject en methode.

Conclusie

Dit artikel beoogt een visie te schetsen op een toekomstbestendig IT-landschap. De aanleiding is dat het IT-landschap de komende jaren sterk gaat veranderen. Daarnaast moeten we meebewegen met het complexe en gedigitaliseerde veiligheidsdomein. Dit artikel beschouwt deze uitdaging vanuit het perspectief van de Koninklijke Marechaussee (KMar). We hopen dat de inzichten ook de andere DO’en kunnen helpen.

In het artikel zijn zes problemen benoemd die deze verandering hinderen. Vervolgens is een theoretisch kader geschetst over complexe organisatorische veranderingen, waaruit blijkt dat het onderscheid tussen management en leiderschap belangrijk is. Er zijn drie standpunten ingenomen die beschrijven hoe de problemen opgelost kunnen worden. Het eerste standpunt is dat er onderscheid gemaakt moet worden tussen generieke en infrastructurele voorzieningen enerzijds, en specifieke voorzieningen anderzijds. Dit onderscheid maakt het mogelijk een andere verhouding tussen DO’en en de IT-organisatie vorm te geven, waarbij de centrale IT-organisatie enkel zorg draagt voor de generieke en infrastructurele voorzieningen. Standpunt 2 bepleit dat we de PRINCE2-projectmanagementmethodiek anders invullen voor innovatieve en onzekere IT-projecten (dat wil zeggen werkstroom 4-projecten). Binnen deze methodiek wordt er te vaak gekozen voor de beheersmatige, in plaats van de flexibele aanpak. Innovatieprojecten moeten anders aangestuurd worden dan de traditionele going-concern-projecten. Ten slotte bepleit standpunt 3 dat er voor alternatieve ontwikkelingsmethodes gekozen moet kunnen worden, zodat de methode beter aansluit bij het project. Door deze drie standpunten te combineren sluiten implementatievoorstellen beter aan op de operationele realiteit, wordt de snelheid verhoogd door capaciteiten te bundelen en krijgt de centrale IT-leverancier van Defensie, JIVC, een duidelijkere focus. Meer flexibiliteit in de projectmethode leidt tot een meer flexibele IT. Het geheel biedt een concrete visie op het realiseren van een toekomstbestendig IT-landschap bij de Nederlandse krijgsmacht.