Visie IV-Tooling

Visie op een Toekomstbestendig IV-Tooling Portfolio voor Rijkswaterstaat

Inleiding

Voor het IV proces is zowel bij het beheren en ontwikkelen van applicaties en andere IV assets als platformen en infrastructuur een goede set aan IV-Tooling onmisbaar. Als definitie van IV-Tooling hebben we: 

Als we het hebben over IV-Tooling, hebben we het over de tooling die de functionaliteit levert die nodig is ter ondersteuning van het IV proces. Deze tooling speelt geen directe rol in de ondersteuning van de bedrijfsprocessen van RWS, alleen via het IV-proces.

Bij de creatie van een efficiënt en toekomstbestendig IT-landschap voor Rijkswaterstaat is een eenduidig IV-Tooling portfolio essentieel. Ook de digitale transformatie en de groeiende afhankelijkheid van IT vragen om een zorgvuldig samengesteld IV-tooling portfolio.

Dit document beschrijft een visie voor de samenstelling van een IV-tooling portfolio en definieert een doelportfolio voor de RWS organisatie. Hiervoor worden de volgende 3 stappen doorlopen:

1. Definiëren & modeleren behoefte stelling, wat is er nodig?
2. Bepalen uitgangspunten voor toolingkeuze, waarom kiezen we voor bepaalde tools?
3. Vaststellen doelportfolio IV-Tooling, welke tools behoren tot het doelportfolio?

De impact van de vaststelling van dit portfolio op het bestaande tooling landschap en de aanpak om via Life Cycle Management (LCM) een gecontroleerde migratie naar dit portfolio te realiseren worden in een apart document verder uitgewerkt.

Dit document richt zich op de vorming van de visie en het vaststelling van het doelportfolio.

1. Behoeftestelling

Binnen RWS zijn veel verschillende teams bezig met IV werkzaamheden. Ondanks dat Agile ontwikkeling in verschillende vormen (scrum, lean, kanban, SAFe enz), momenteel de grootste stroming is wordt er ook nog gewerkt conform de waterval methodiek en zijn varianten als ITIL/ITSM en dev/ops veel in gebruik binnen het IV proces.

Binnen deze werkmethodieken kun je een aantal duidelijke processtappen onderscheiden die samen de volledige software development lifecycle (SDLC) vormen – van idee tot productie en monitoring. Deze indeling van stappen voor de volledige SDLC geldt in grote lijnen óók voor het beheer van ICT-voorzieningen, zoals datacenters, netwerken, platformen of een cloudinfrastructuur, zij het met enkele aanpassingen in focus en invulling. Diezelfde stappen zijn ook toepasbaar specifiek gericht op infrastructuurbeheer (IT Operations, Netwerkbeheer, Platformbeheer en Systeembeheer).

Gecombineerd komen we tot een invulling van deze processtappen conform onderstaand IV model waarbij de 'I' meer de beheerkant invult met monitoring, reporting en logging en de 'V' conform het V model met Specificatie, Ontwerp, Realisatie, Testen en Acceptatie de applicatie ontwikkelingscyclus ondersteund. Dit in een overkoepelend veld van Beveiliging.

Het IV-proces wordt voor de ondersteunende tooling behoefte opgedeeld in 4 waardestromen: 

Voor deze 9 categorieën wordt in dit document een doelportfolio vastgesteld. Per functiecategorie kunnen meerdere functionele vragen ingevuld worden. Het is echter de bedoeling om per functie maximaal 1 tool in het doelportfolio te hebben. 

Uniformering van tooling is van belang voor:

• Duidelijkheid portfolio, snelle levering dienst
• Verlagen beheer last
• Bundeling kennis
• Efficient gebruik capaciteit beheer en ontwikkelteams
• Verzamelen informatie over het IV proces

2. Randvoorwaarden en Uitgangspunten

Voor het bepalen worden de volgende uitgangspunten gebruikt.  Deze komen uit kader stellende documenten als de ICT strategie, de EAR, de NORA ed:

1. Installed-base als uitgangspunt
2. Integratie en minimalisatie overlap functionaliteit
3. Open Source en Soevereiniteit
4. On-premise deployment

5. Ondersteuning verschillende werkwijzen RWS

6. NORA-compliance
7. Minimaal 5% marktaandeel

In de volgende paragraven worden bovenstaande uitgangspunten toegelicht en wordt duidelijk waarom deze van belang zijn. In hoofdstuk 3 wordt de gekozen tooling gescoord op deze uitgangspunten.

2.1 Installed-Base en Behoud van Continuïteit

De bestaande installed-base binnen Rijkswaterstaat is de belangrijkste factor. Tools die reeds breed in gebruik zijn en goed functioneren, moeten waar mogelijk behouden blijven of indien noodzakelijk geleidelijk worden uitgefaseerd en vervangen door beter passende tools.

Waarom is dit belangrijk?

• Vermijden van verstoring van lopende processen.
• Beperken van adoptieproblemen bij nieuwe tools.
• Beheersbare overgangskosten en trainingsbehoeften.
• Continuïteit in dienstverlening en ondersteuning.
• Aansluiting bij bestaande werkprocessen en cultuur.

2.2 Integratie en minimalisatie van Overlap

Tools moeten onderling goed integreren en redundantie in functionaliteit moet worden vermeden. Voor het IV-Tooling portfolio ligt de nadruk op standaardisatie en interoperabiliteit.

Voordelen integratie:

• Efficiëntere samenwerking tussen teams en systemen.
• Verkleinen van technische schuld en onderhoudslasten.
• Verbeterde gebruiksvriendelijkheid door gestroomlijnde processen.
• Lagere kosten door consolidatie van tooling en licentiebeheer.
• Beter beheer van gebruikersrechten en securitystandaarden door uniforme tooling.

 2.3 Open Source en Soevereiniteit

In lijn met de principes van digitale autonomie en datasoevereiniteit wordt tooling geselecteerd die voldoet aan Europese wet- en regelgeving, zoals de GDPR/AVG. Data en kritische processen mogen niet afhankelijk zijn van buitenlandse partijen zonder controle over eigenaarschap en hosting.

Open Source tooling draagt bij aan digitale soevereiniteit door vendor lock-in te voorkomen en controle te behouden over data en functionaliteit. De voorkeur gaat uit naar tools met actieve gemeenschappen en ondersteuning vanuit overheden of bedrijven. Bovendien zorgt Open Source ervoor dat de code transparant en controleerbaar blijft, waardoor de veiligheid en betrouwbaarheid van software wordt vergroot.

Waar mogelijk wordt closed-source tooling vervangen door open-source alternatieven die breed worden gedragen binnen de markt.

Belang Open Source voor de rijksoverheid:

• Beperking van afhankelijkheid van commerciële aanbieders.
• Betere aanpasbaarheid en integratie met bestaande systemen.
• Versterking van interoperabiliteit door het gebruik van open standaarden.
• Lagere kosten op lange termijn door het vermijden van licentiegebonden software.
• Verhoogde innovatie door open samenwerking met andere overheden en marktpartijen.

2.4 On-Premise Deployment

Voor maximale controle en beveiliging wordt tooling primair on-premise geïmplementeerd of binnen een soevereine cloudomgeving gehost. Dit voorkomt dat gevoelige data onderhevig is aan buitenlandse jurisdictie en waarborgt naleving van nationale en Europese richtlijnen.

Public cloud oplossingen kunnen voordelen bieden op het gebied van schaalbaarheid en beheer, maar voor de rijksoverheid wegen veiligheid en controle zwaarder. We kiezen dan ook bij voorkeur voor een on-premise installatie op basis van cloud technologie. Dit betekent bijvoorbeeld wel gebruik maken van Kubernetes voor de deployement van applicaties maar dit doen we dan het liefst in onze Private Cloud. Eventueel kan dat ook in de Rijkscloud en alleen als het echt niet anders zouden we gebruik kunnen maken van een Commerciele of Public Cloud, in welke vorm dan ook(Azure/AWS/Google, oid).

Redenen voor on-premise deployment:

• Volledige controle over data en infrastructuur.
• Minimalisering van risico’s op datalekken en ongeautoriseerde toegang.
• Voldoen aan wet- en regelgeving zoals AVG en BIO.
• Vermijden van afhankelijkheid van cloudleveranciers en potentiële prijsstijgingen.
• Verminderen van de afhankelijkheid van geopolitieke en economische invloeden op cloudproviders.

2.5 Ondersteuning verschillende werkwijzen RWS

De tools moeten alle bovengenoemde werkwijzen binnen RWS ondersteunen door middel van o.a. CI/CD-integratie, automatisering, samenwerking en flexibiliteit. Dit betekent dat tools automatisering, monitoring en iteratieve ontwikkeling mogelijk maken zonder de operationele overhead te verhogen.

Waarom is dit belangrijk?

• Agile en Scrum verbeteren de flexibiliteit en wendbaarheid van softwareontwikkeling.
• DevOps zorgt voor snellere en betrouwbaardere opleveringen van software.
• Automatisering van testen en deployment vermindert handmatige fouten en verhoogt de efficiëntie.
• Continu leren en verbeteren wordt gestimuleerd door feedbackloops tussen ontwikkeling en operations.
• Ondersteunt het minimaliseren van time-to-market voor overheidsdiensten en producten.

2.6 NORA-Compliantie

De Nederlandse Overheid Referentie Architectuur (NORA) stelt richtlijnen voor IT-oplossingen binnen de overheid. De gekozen tools moeten aansluiten bij deze principes om uniformiteit en samenwerking tussen overheidsinstanties te bevorderen. Dit betekent dat ze bijdragen aan interoperabiliteit, beveiliging en herbruikbaarheid.

Kernprincipes van NORA:

• Open standaarden en interoperabiliteit. Waar mogelijk moet gebruik worden gemaakt van open standaarden of open-source. Tevens moeten systemen goed integreerbaar en uitbreidbaar zijn.
• Herbruikbaarheid van bestaande oplossingen.
• Transparantie en controleerbaarheid. Logging, inzicht in systeemgedrag en rapportage zijn essentieel. Ook moeten systemen goed te auditen zijn.
• Modulariteit en flexibiliteit voor veranderende eisen en technologieën.
• Gebruik van bewezen en gestandaardiseerde referentiecomponenten.

• Beveiliging, data moet veilig en integer verwerkt worden.

2.7 Minimaal 5% Marktaandeel

Tooling moet breed worden toegepast binnen de publieke sector of markt om voldoende ondersteuning, updates en doorontwikkeling te waarborgen. Een minimaal marktaandeel van 5% garandeert stabiliteit en toekomstbestendigheid.

Waarom een drempel van 5%?

• Breed gebruik impliceert een actieve community en lange-termijn levensvatbaarheid.
• Betere beschikbaarheid van expertise en ondersteuning.
• Voorkomen van investeringen in niche-tools met beperkte toekomst.
• Verhoogde kans op compatibiliteit en integratie met andere veelgebruikte systemen.

3. Vaststellen doelportfolio IV-Tooling

Tooling vergelijking per Functiegroep

I.Monitoring

Voor monitoring zijn verschillende applicaties momenteel in gebruik binnen CIV. Voor het maken van een keuze in deze tooling is het noodzakelijk om een meer inhoudelijke evaluatie toe te voegen aan de 7 punten uit hoofdstuk 2.

NORA compiancy

Of een monitoringtool “compliant” is aan NORA, hangt niet zozeer af van de tool zelf, maar van hoe je die tool implementeert binnen een architectuur die de NORA-principes volgt. De tools kunnen onderdeel zijn van een NORA-conforme architectuur. Belangrijk is hoe je ze configureert: logging, toegang, integriteit en beschikbaarheid moeten correct zijn geregeld. Voor cloud of SaaS-gebruik (zoals bij sommige versies van Ymonitoring) moet je extra kritisch zijn op data-opslaglocatie en eigendom (denk aan AVG/GDPR).

Samenvatting

• Zabbix: Goed voor organisaties die een krachtige, flexibele en volledig geïntegreerde monitoringoplossing willen met veel mogelijkheden, maar die bereid zijn om tijd te investeren in configuratie.

• Ymonitoring: Geschikt voor bedrijven die snel en zonder veel configuratie aan de slag willen met monitoring, met een focus op gebruiksgemak en standaardfuncties.

• Checkmk: Ideaal als je een hybride oplossing wilt met sterke automatische detectie en uitgebreide functionaliteiten, geschikt voor zowel kleine als zeer grote IT-omgevingen.

• Prometheus: Perfect voor cloud-native omgevingen en ontwikkelteams die metrics-gebaseerde monitoring willen, met veel flexibiliteit maar technisch veeleisender.

Gezien de migratie van RWS omgevingen naar cloud technologie, K8s, is Prometheus de meest logische keus voor monitoring

V. GITlab

GITlab is een goed voorbeeld van een tool die voor meerdere functies inzetbaar is. Daar waar het initieel gemaakt is voor versiebeheer bevat het momenteel ook onderstaande mogelijkheden en integraties.

Beveiliging

Het beveiligingsportfolio bestaat uit 16 applicaties geselecteerd door het Security Center. Deze applicaties worden alleen gebruikt door het Security Center voor deze functionaliteiten bepaalt het security center het doelportfolio. Rationalisatie of uniformering is hierbij dan ook niet nodig evenals een evaluatie op basis van de uitgangspunten van H2.

Doelportfolio:

______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Impact(in onderzoek)

A. Azure DevOps

Op basis van de in hoofdstuk 2 geformuleerde uitgangspunten voor het IV-tooling portfolio van Rijkswaterstaat is Azure DevOps niet de meest geschikte keuze. Hieronder volgt een onderbouwing waarom Azure DevOps uitgefaseerd dient te worden en vervangen moet worden door een alternatief dat beter aansluit bij de strategische doelen.

A.1 Open Source en Soevereiniteit

Azure DevOps is een gesloten, propriëtaire oplossing van Microsoft. Dit betekent dat Rijkswaterstaat afhankelijk is van Microsoft voor updates, functionaliteiten en licentiemodellen. Dit beperkt de controle en flexibiliteit, en verhoogt de kans op vendor lock-in.

Impact:

• Geen volledige controle over de code en functionaliteiten.
• Afhankelijkheid van Microsoft voor productontwikkeling en beveiligingsupdates.
• Beperkte mogelijkheid om de software aan te passen aan specifieke overheidsbehoeften.

Alternatieven zoals GitLab (self-hosted) of Jenkins + ArgoCD bieden volledige open-source codebases en ondersteunen aanpassingen zonder afhankelijkheid van commerciële partijen.

A.2 On-Premise Deployment

Azure DevOps is primair een cloudgebaseerde oplossing (Azure Cloud). Hoewel er een on-premise variant bestaat (Azure DevOps Server), is deze minder krachtig dan de cloudversie en wordt deze minder frequent bijgewerkt.

Impact:

• Data wordt opgeslagen op infrastructuur van Microsoft, mogelijk buiten de EU.
• Beperkte controle over data, compliance en beveiliging.
• Inconsistentie tussen cloud en on-premise versies maakt migratie lastig.

Een on-premise DevOps-oplossing biedt volledige controle over data en infrastructuur, waardoor het beter aansluit bij de eisen van de RWS ICT-Strategieoverheid.

A.3 NORA-Compliantie

De Nederlandse Overheid Referentie Architectuur (NORA) benadrukt het gebruik van open standaarden en interoperabiliteit. Hoewel Azure DevOps diverse integraties biedt, is het sterk verweven met het Microsoft-ecosysteem, wat integratie met open-source tooling lastiger kan maken.

A.4 Agile/Scrum en DevOps

Azure DevOps ondersteunt Agile en DevOps, maar de meeste functionaliteiten zijn geoptimaliseerd voor Microsoft-producten. Dit maakt het moeilijker om flexibel te werken met alternatieve open-source tools.

Impact:

CI/CD-functionaliteiten zijn minder uitbreidbaar in niet-Microsoft omgevingen.

Beperkte compatibiliteit met open-source DevOps-tools zoals ArgoCD en Ansible.

Minder transparantie in hoe pipelines worden uitgevoerd en beheerd.

Alternatieven zoals GitLab CI/CD, Jenkins, en ArgoCD ondersteunen Agile en DevOps op een flexibele en open manier zonder beperkingen.

A.5 Minimaal 5% Marktaandeel & Installed Base

Azure DevOps heeft een aanzienlijk marktaandeel, maar binnen de open-source gemeenschap en overheden groeit de adoptie van alternatieven zoals GitLab, Jenkins en ArgoCD. Daarnaast zijn veel overheidsinstanties al overgestapt naar GitLab als alternatief voor Azure DevOps.

A.6 Samenwerking en Minimalisatie van Overlap

Azure DevOps bevat verschillende functionaliteiten (zoals issue tracking, CI/CD en repository management), maar overlapt sterk met andere tools in het beoogde portfolio zoals GitLab, Jira en ArgoCD. Door Azure DevOps uit te faseren en GitLab als centrale tool in te zetten voor repository management, CI/CD en issue tracking, wordt overlap geminimaliseerd en kosten gereduceerd.

A.7  Conclusie en Aanpak voor Uitfasering

Gezien de nadelen van Azure DevOps op het gebied van open-source, soevereiniteit, on-premise mogelijkheden en integratie met andere tools, is uitfasering noodzakelijk. Dit gebeurt geleidelijk via Life Cycle Management (LCM) en is afhankelijk van het aanbieden van robuste, beheerde alternatieven die Bio compliant zijn.

B. Aanpak voor Migratie via Life Cycle Management (LCM)

De overgang naar het nieuwe IV-tooling portfolio wordt gerealiseerd via LCM. De volgende stappen worden genomen en kunnen worden gekwantificeerd voor de Businesscase:

B.1 Inventarisatie en Analyse

• Bepalen welke tools in de huidige installed base worden gebruikt.
• Vergelijken met de beoogde tools in het nieuwe portfolio.
• Identificeren van afhankelijkheden en integratiebehoeften.

B.2 Categorisatie van Legacy Tools

• Behoud en doorontwikkeling: Tools die voldoen aan de criteria en goed functioneren.
• Gefaseerde migratie: Tools die vervangen moeten worden waar een overgang noodzakelijk is.
• Uitfasering: Tools met te veel overlap of onvoldoende ondersteuning.

B.3 Opstellen van een Migratieplan

• Quick Wins: Overgang naar eenvoudig vervangbare tools (bijv. -> ).
• Gefaseerde uitrol: Stapsgewijze migratie van CI/CD- en ontwikkeltools met pilotprojecten.
• Training en Adoptie: Trainingen voor teams om soepel over te stappen naar nieuwe tools.

B.4 Evaluatie en Optimalisatie

• Feedback verzamelen uit de organisatie over de nieuwe tooling.
• Bijsturen op basis van verzamelde gebruikerservaringen en performance monitoring.
• Continue innovatie om up-to-date te blijven met technologische ontwikkelingen.

Bijlage C, Referentie documenten