RIS316878 bijlage

VERTROUWELIJK

§ Keycloak ondersteunt single sign-on, waardoor gebruikers slechts één keer hoeven in te loggen om toegang te krijgen tot meerdere applicaties. Dit verhoogt de efficiëntie en vermindert de complexiteit van het applicatielandschap door het consolideren en standaardiseren van authenticatie- en autorisatiemechanismen, waardoor het onderhoud en beheer ober meerdere applicaties eenvoudiger wordt. § 11 libraries bevatten gekende security kwetsbaarheden met een hoog risico (tot 9.8 CVSS). 6 libraries met een medium risico en 3 met een laag risico. Volgende risico’s; niet valideren van server certificaten in HTTPS, ongecontroleerde resource consumptie, zichtbare gevoelige informatie, en meer. 227 libraries hebben al meer dan een jaar een nieuwe versie beschikbaar, maar zijn niet up to date.

46

// SAMENVATTING

GZAC is boven marktgemiddeld onderhoudbaar, testbaarheid van de generieke oplossing een uitdaging Hoofdbevindingen

Risico classificatie: laag

Onderhoudbaarheid HHHHI (3.5)

GZAC is een open-source applicatie geïnitieerd door 10 Nederlandse gemeenten en is gebaseerd op Valtimo (een low-code case management oplossing). GZAC wordt gebruikt voor het afhandelen van zaken binnen de gemeente.

Volume

HHHHI

4.1

§ Duplication: 13% van de code is gedupliceerd,

Duplication

HHHII

3.4

Unit size

HHHII

3.2

GZAC is een modern systeem dat gebaseerd is op open standaarden; de architectuur is gebaseerd op het Common Ground principe. Dit zorgt voor een schaalbaar, flexibel en aanpasbaar landschap van componenten, waarbinnen de component GZAC communiceert met andere componenten via plugins.

Unit complexity

HHHII

3.2

§ Unit size & unit complexity: 42% van de code bevindt zich in lange units en 32% van de code is complex.

Unit interfacing

HHHII

3.4

Module coupling

HHHHI

4.2

Component independence

HHHHI

4.2

Component Entanglement

HHIII

2.1

Aandachtspunten; het gebruik in representatieve gemeentelijke processen is nog niet bewezen; er zijn geen NF-requirements en NF tests beschikbaar. De architectuur (indeling) van de interne softwarecomponenten is onduidelijk en zorgt voor een groot aantal afhankelijkheden.

§ Unit interfacing: 3% van de code is onderdeel van units met meer dan 4 parameters § Component entanglement: De architectuur bevat vooral binnen Valtimo Backend veel afhankelijkheden

Stabiliteit en performance efficiency

Efficiency en toekomstvastheid

§ Er zijn geen NF requirements en richtlijnen om een hoge stabiliteit, of performance te garanderen. Er worden geen performance testen door de leverancier uitgevoerd.

§ Het gebruik van GZAC/Valtimo in representatieve (qua aantal en complexiteit) gemeentelijke processen is pas recent gestart. Gegeven de gewenste eindsituatie waarbij GZAC wordt ingezet als gemeente breed zaak-afhandelingsplatform is het cruciaal om de NF requirements in de eindsituatie tijdig te definiëren. Deze NF-requirements kunnen worden gebruikt om keuzes voor de huidige implementatie t.o.v. de eindsituatie te (blijven) verifiëren.

§ De hosting wordt geregeld door de Gemeente Den Haag. Er zijn geen richtlijnen /voorwaarden voor installatie voor de gemeente Den Haag aangetroffen. Ritense kan wijzigingen pushen naar de Kubernetes omgeving van Den Haag, maar de hosting is onder controle van Den Haag zelf (incl. hoeveel resources nodig per service). First line support is ook de verantwoordelijkheid van Den Haag. § Logging is mogelijk in Camunda, maar staat niet standaard aan en geeft geen infra-gerelateerde inzichten zoals latency. § Er zijn momenteel 2 versies in beheer en elke 2 weken is er een nieuwe release. § Er zijn 4 libraries met gekende security kwetsbaarheden gevonden, daarnaast zijn worden er een aantal outdated en ‘beta’ libraries gebruikt. § Kennis van het maken en toewijzen van low-code componenten ligt voornamelijk bij Ritense. De gebruikte standaarden zijn nog in ontwikkeling, eigenaarschap van de ZGW-standaarden ligt bij VNG. G4 plus Dimpact gebruiken een koploperstrategie. // SOFTWARE IMPROVEMENT GROUP VERTROUWELIJK

§ De gebruikte technologieën binnen GZAC en Valtimo zijn modern. GZAC is gebaseerd op open standaarden (zoals BPMN, DMN en JSON-schemas). § De hoeveelheid testcode is met 25% t.o.v. de productiecode laag; voor een test coverage van 80% wordt een 1:1 verhouding productiecode vs testcode verhouding verwacht. Door de generieke use cases is het moeilijk om basisimplementatie te voorzien om tegen te testen. § Valtimo past binnen het strategische Common Ground initiatief, wat zorgt voor onafhankelijkheid van componenten op landschapsniveau. Binnenin de code (Valtimo Backend) is deze rationale niet duidelijk te vinden en zijn er veel afhankelijkheden. § Op de roadmap staat o.a.: versionering van externe systemen, stroomlijnen plugins, het definiëren van basisprocessen voor gemeenten. Het aantal front-end ontwikkelaars (momenteel 1) wordt uitgebreid.

47

// SAMENVATTING

DenHaag.nl - Houd grip op de kwaliteit, en toets regelmatig op de actualiteit van bibliotheken Hoofdbevindingen

Risico classificatie: gemiddeld

Onderhoudbaarheid: HHHII (3.3)

De onderhoudbaarheid is lager dan voor een nieuwbouw systeem wenselijk is. Met name de grote hoeveelheid lange en complexe code in het maatwerk is opvallend. De code is hierdoor lastig geautomatiseerd te testen, wat zich manifesteert in de afwezigheid van unit tests.

Volume

HHHHI

4.3

Duplication

HHIII

2.4

Unit size

HIIII

0.9

Het maatwerk is verspreid over de codebase en staat tussen de standaard Wordpress componenten, dit is een risico bij upgrades van Wordpress.

Unit complexity

HIIII

0.8

Unit interfacing

HHHHI

3.5

Voor security wordt geleund op externe PenTest rapporten; er is geen ‘Security by Design’ toegepast, wat resulteert in bijv. verouderde bibliotheken met bekende kwetsbaarheden.

Module coupling

HHHHH

5.2

Component independence

HHHHH

5.4

Component Entanglement

N/A

N/A

Stabiliteit en performance efficiency

Efficiency en toekomstvastheid

§ Capacity planning en performance tests op de productie omgeving ontbreken

§

§ De maatwerk code op het Wordpress platform heeft een volume van 9 mensjaar § 18% van de code is onderdeel van een code duplicaat § 72% van de code is onderdeel van lange units § 61% van de code is complex § Een aantal architectuur metrieken worden positief beïnvloed doordat de koppeling via het Wordpress platform niet zichtbaar wordt in de meting van het enkel het maatwerk. Dit geeft een te positief beeld van de applicatie.

Het maatwerk is niet te onderscheiden van standaard opensource Wordpress componenten,

en staat door en naast elkaar, dit is een risico bij upgrades van Wordpress

§ Het draaien op een Kubernetes kluster biedt mogelijkheden voor schaalbaarheid en redundantie, echter die zijn nog niet uitgewerkt

§ De custom code bevat veel lange en complexe units, wat het testen hiervan bemoeilijkt

§ Het doelplatform is nog niet duidelijk (Azure vs. Acato preferred hosting oplossing)

§ Er zijn geen unit tests beschikbaar op het maatwerk

§ Security PenTest is positief maar wordt niet regelmatig uitgevoerd

§ Statische web content wordt op meerdere plekken binnen de gemeente aangeboden, het is aan te bevelen om overal het zelfde platform te (gaan) gebruiken

§ OpenSource libraries worden niet actief gemanaged , zijn verouderd en bevatten kwetsbaarheden

// SOFTWARE IMPROVEMENT GROUP

VERTROUWELIJK

48

// SAMENVATTING

DigiDOC is beneden marktgemiddeld onderhoudbaar, onderliggende ODW versie is verouderd Hoofdbevindingen

Risico classificatie: Middel/hoog

Onderhoudbaarheid: HHIII (2.4)

DigiDOC bestaat uit een Fat Client, draaiende binnen de Citrix omgeving, waarmee documenten kunnen worden gezocht, ingezien en opgeslagen. De backend is een Oracle DB instantie; DigiDOC is gebouwd in PL/SQL en Java technologie en grotendeels gebaseerd op een verouderd ODW (V3) framework, waarvan de broncode niet is ontvangen.

Volume

HHHHH

4.7

§ Duplication: 45% van de code is gedupliceerd,

Duplication

HHIII

1.5

Unit size

HIIII

0.9

Unit complexity

HHIII

2.1

§ Unit size & unit complexity: 71% van de code bevindt zich in lange units en 19% van de code is complex.

SIG heeft enkel de maatwerk onderdelen op ODW ontvangen. De onderhoudbaarheid van dit maatwerk is onder marktgemiddeld (HHIII).

Unit interfacing

HIIII

1.0

Module coupling

HIIII

1.1

Component independence

HHHHI

4.2

Component Entanglement

HHHHH

5.5

Binnen Den Haag zijn meerdere Document Management Systemen (DMS) van verschillende leveranciers operationeel, hierdoor bestaan er mogelijkheden om te rationaliseren.

§ Unit interfacing: 11% van de code is onderdeel van units met meer dan 4 parameters § Module coupling: 22% van de code is sterk gekoppeld, en is gecentraliseerd in 3 core packages

Stabiliteit en performance efficiency

Efficiency en toekomstvastheid

§ Het lastig gebleken om de verschillende omgevingen goed te beheren. OIS heeft beperkt toegang tot de hosted servers bij ITB.

§ Er wordt weinig gebruik gemaakt van 3rd party libraries (dit is een eigenschap van de gebruikte PL/SQL technologie). De libraries die gevonden zijn, zijn up-to-date gehouden

§ Elke ochtend worden alle servers herstart om eventuele memory leaks ongedaan te maken § Er is actieve (Zabbix) monitoring om de beschikbaarheid van de services te meten en weer te geven op een dashboard

§ Het gebruikte onderliggende platform is verouderd. De upgrade van ODW versie 3 naar 4 wordt nu wel uitgevoerd, maar de cloud mogelijkheden (beschikbaar in versie 5) kunnen niet benut worden

§ Voor het doen van een root cause analyse, is de logging beschikbaar in de database

§ DigiDOC onderschrijft de CommonGround architectuur principes § Er is al een vernieuwingsslag bezig om DigiDOS te vervangen door HERMES; waarbij de user interface web-based wordt. Later zullen ook DigiDOC en de andere ODW implementaties over gaan naar HERMES

// SOFTWARE IMPROVEMENT GROUP

VERTROUWELIJK

49

// SAMENVATTING

Centric Burgerzaken: enkele verouderde technologieën, onderhoudbaarheid backend onder gemiddeld 1 MAR 2023 Hoofdbevindingen

Risico classificatie: gemiddeld

Centric Burgerzaken bestaat uit 5 systemen die beheerd worden door Centric. Er wordt gewerkt aan een migratie van legacy (Oracle Forms) naar moderne technologie (Angular), de business logica blijft legacy technologie (PL/SQL, Cobol). De basis (Key2Burgerzaken) scoort onder-marktgemiddeld (2.2H), De E-diensten en Portaal scoren marktgemiddeld (3.3H) en de nieuw ontwikkelde Nieuwe frontend en Riskprofiles scoren boven-marktgemiddeld (4.0H). ‘Nieuwe frontend’ gaat bestaande Oracle Forms schermen vervangen en zou binnen 0,5 jaar afgerond kunnen worden. De onderhoudbaarheidsscores geven aan dat de nieuwe code die wordt geschreven beter onderhoudbaar is. Centric heeft een aantal verbeteringsdoelen: inclusief testplan, sneller kunnen releasen, oude logica afsplitsen van de nieuwe code.

Onderhoudbaarheid Volume (MJ)

Test code ratio

Maintainability

7,0

109%

3,32

Key2Burgerzaken

159,2

0%

2,18

Portaal Key2Burgerzaken

38,5

175%

3,26

Riskprofiles

3,6

157%

3,96

‘Nieuwe frontend’

18,9

51%

4,07

Systeem E-diensten Key2Burgerzaken

FOCUS AREAS §

Component entanglement in E-diensten Key2Burgerzaken (1.3H), Portaal Key2Burgerzaken (2.1H ), Riskprofiles (2.2H)

§

Duplication in E-diensten Key2Burgerzaken (3.2H), Portaal Key2Burgerzaken (3.2H) en Nieuwe frontend (3.2H)

SIG raadt niet aan om de legacy delen te verbeteren naar 4H, maar minimaal de kwaliteit stabiel te houden.

Stabiliteit en performance efficiency

Efficiency en toekomstvastheid

§ Stabiliteit wordt met name bepaald door de on-premise deployment bij DenHaag. Er zijn geen betrouwbaarheidstesten bij Centric om de impact van codewijzigingen in kaart te brengen.

§ Aantal ontwikkelaars Key2Burgerzaken: 63 FTE (incl. Roemenië), waarvan een deel beheer doet en een deel conversie (ongeveer 10 multidisciplinaire teams – bv. altijd minimaal 1 tester). Ontwikkeling volgens SCRUM, maar waterval proces na elke increment om te testen, documenteren en uit te leveren.

§ Performance: Centric gaat een project starten voor performance testen. Security testing (pen-testing) gebeurt reeds 2 keer per jaar. § eDiensten draait als een multi-tenant schaalbare SaaS oplossing voor Den Haag. Andere (nonOracle) diensten worden zowel geleverd als on-premise als SaaS oplossing. De SaaS omgevingen van Centric hebben voor meer nadruk op performance testen gezorgd. Bij non-SaaS oplossingen ontbreken inzichten/mogelijkheden voor optimalisaties voor Centric. § Er is een testplan per team en nieuwe applicaties vereisen minstens 80% unit test coverage. Oracle stack heeft geen units tests, maar draait al jaren stabiel met weinig wijzigingen. § Er zijn 18 libraries gedetecteerd met gekende security kwetsbaarheden. 9 hiervan bevatten een hoog risico (CVSS > 7.5). Nieuwe Frontend libraries zijn up to date en bevatten geen gekende security kwetsbaarheden. § Momenteel zijn er performance problemen geconstateerd in de nieuwe release van portaal, deze problemen worden onderzocht samen met de leverancier // SOFTWARE IMPROVEMENT GROUP

§ Versie code: v25.4 centricburgerzaken, v3.99 Database (Oracle forms en tabellen datamodel) Er zijn 2 releases in beheer (n en n-1). Bij wetswijzigingen moet er een nieuwe release worden gemaakt, waardoor de afnemers bijna altijd op de laatste release zitten. § SIG heeft inschattingen gemaakt voor Frontend migratie en Centric bevestigt dat deze schattingen correct waren. Momenteel wordt Portaal omgezet naar de nieuwe architectuur. § Doelen Centric: 1. Algemene teststrategie bepalen voor heel Centric Burgerzaken. 2. Eind 2023: op elk moment kunnen releasen. 3. Applicatie verticaal splitsen om de oude logica beter te kunnen scheiden. (businessarchitectuur opbouwen) 50

// SAMENVATTING

Open-zaak / Open-notificaties / Open-forms / Open-klant / Objecten en ObjectTypen Hoofdbevindingen

Onderhoudbaarheid

OpenZaak is een open-source API implementatie voor “Zaakgericht Werken (ZGW)”. De implementatie volgt de VNG standaard “API’s voor Zaakgericht Werken”. Alle ‘Open-systemen’ zijn open source en volgen het Common Ground model.

Risico classificatie: laag

De systemen in scope zijn markt-gemiddeld tot boven-marktgemiddeld onderhoudbaar. Open-forms biedt mogelijkheden voor verbetering op zowel code- als architectuurniveau. De technische beheerinspanning (15%) van deze applicatie bedraagt ±1 mensjaar (per jaar). De specifieke klantinvulling heeft een grote impact op stabiliteit, prestaties en efficiëntie. Klantomgevingen zijn niet gestandaardiseerd, het gebruik van objecten is niet gestandaardiseerd. Het beperken van de manier waarop formulieren worden gemaakt kan een positieve impact hebben.

Systeem

Herbouw waarde (PM)

Test code Maintainability ratio

Open-forms

73

74%

3,27

Open-zaak

39,68

168%

3,45

Open-notificaties

4,28

60%

3,72

Open-klant

7,02

89%

3,78

Objects-api

7,2

133%

3,86

4,61

48%

4,08

Objecttypes-api

§

Duplication: 18% van de code is gedupliceerd, 62% tussen systemen. Meeste in open-zaak.

§

Unit size & unit complexity: 34% van de code bevindt zich in lange units en 10% van de code is complex, vnml. front-end code. Meeste in openforms.

§

Unit interfacing en module coupling zijn bovenmarkt gemiddeld.

§

Component entanglement: De componenten binnen open-forms zijn hevig verweven en bevatten throughput code.

Stabiliteit en performance efficiency

Efficiency en toekomstvastheid

§ By design kunnen notificaties falen. (geen gegarandeerde delivery)

§ De systemen zijn opgebouwd vanuit het Common Ground model en hebben elk hun specifieke (en herbruikbare) rationale in het landschap.

§ Bij niet-SaaS omgevingen heeft de ontwikkelpartij (Maykin) geen controle over de deployment omgeving en geen controle over het uitrollen van nieuwe versies. Dit kan voor moeilijkheden zorgen als er iets misloopt bij het uitrollen van nieuwe versies. Omgevingen kunnen verschillen tussen klanten. § Maykin Media werkt test driven, heeft quality gates (unit tests, keten en integratie tests, linters) met hoge kwaliteitseisen (coverage > 90%) § Performance scenario’s worden met de hand getest. Inzichten in performantie kan met Elastic APM. Klantspecifieke oplossingen kunnen impact hebben op performance. Aggregatie van klantspecifieke inzichten is er nog niet.

§ Objecten en objecttypen hebben standaardisatie nodig voor gebruik in heel Nederland. De systemen zijn algemeen opgezet en afnemers moeten zelf de structuur bepalen. § Er is geen duidelijke landschapsarchitectuur die de implementatie van de systemen in kaart brengt. De systemen worden beheerd onder verschillende organisaties in Github. § Mogelijkheden tot verbetering (volgens Maykin Media): 1.

Landelijke databank met objecttypen.

2.

Knop om nieuwe versie te deployen van een formulier, zodat deze standaard door alle pipelines en kwaliteitschecks gaat naar productie en een makkelijke manier om terug te migreren naar een vorige versie.

3.

Formulier genereren vanuit een objecttype en later aanpassen OF mapping maken in een formulier met specifiek object in een attributen API. Dit zou gebruik van ’any’ attribuut moeten minderen om te streven naar standaardisatie.

§ Klanten kunnen formulieren maken die een grote negatieve impact hebben op performantie. § Systemen zijn verdeeld over verschillende version control systemen van de organisaties

// SOFTWARE IMPROVEMENT GROUP

CONFIDENTIAL

51

// SAMENVATTING

IBS is marktgemiddeld onderhoudbaar, kennis moet geborgd worden Hoofdbevindingen

Risico classificatie: gemiddeld

Onderhoudbaarheid

IBS is een groot COBOL systeem draaiend op het IBM i platform. IBS heeft een herbouwwaarde van 164 mensjaar, en heeft een marktgemiddelde onderhoudbaarheid (2.9). De marktgemiddelde technische beheerinspanning (15%) van een dergelijke applicatie bedraagt ±25 mensjaar.

Volume

HHIII

Duplication

HHHHI

Unit size

HHHII

Het systeem is geheel in COBOL gebouwd. De code bevat lange en complexe secties. Ook bevat de architectuur een groot aantal cyclische afhankelijkheden.

Unit complexity

HHHII

Unit interfacing

HIIII

Module coupling

HHHHI

Component independence

HHHHI

Component Entanglement

HIIII

Sinds de vorige meting in 2019 is het systeem 4 mensjaar kleiner geworden. OTS heeft een negatieve impact op de onderhoudbaarheid. In de volgende stap van de WOZ migratie zal een deel van OTS uitgefaseerd worden. Door de afhankelijkheden van de rest van IBS op OTS kan dit een uitdaging zijn.

2.0 § Duplication: 11% van de code is gedupliceerd, waarvan een derde over de componenten heen. 3.7 2.6 § Unit size & unit complexity: 20% van de code bevindt zich in lange units en 19% van de code is 2.7 complex. 1.4 § Unit interfacing: 30% van de code is is onderdeel van units met meer dan 4 parameters 4.4 § Component entanglement: IBS bevat veel 4.3 cyclische afhankelijkheden tussen de deelsystemen. 1.0

Stabiliteit en performance efficiency

Efficiency en toekomstvastheid

§ De huidige omgeving en implementatie van IBS draait stabiel.

§ Het uitfaseren van WOZ functionaliteit (uit OTS) kan leiden tot een reductie van de omvang van OTS. Aangezien de meeste technische schuld zich bevindt in OTS kan dit een positieve impact hebben om de onderhoudbaarheid. Door de afhankelijkheden van de rest van IBS op OTS kan dit een uitdaging zijn.

§ Er is geen fail-over strategie (maar in de praktijk zijn er weinig issues). 1x per jaar is er een uitwijk test. De uitwijk duurt minder dan een uur. § Er zijn geen eisen gedefinieerd voor stabiliteit en performance en er zijn geen monitoring inzichten. Er zijn wel eisen dat er geen data mag kwijtraken. Dit is tweeledig opgelost; met een shared filesysteem over twee datacenters, en backups van de data § Teststrategie is manueel. § De verschillende lagen om het systeem te gebruiken kunnen voor onbeschikbaarheid van IBS zorgen. (Haagse netwerk, Virtuele Citrix omgeving, Windows programma, terminal simulatie)

§ Het uitfaseren van de WOZ module uit IBS is een voorbeeld van een verbetertraject dat jaren kan duren § Er is een Java schil rond IBS gebouwd om het berichtenverkeer naar de buitenwereld af te handelen. Deze schil is niet in scope, maar is gelimiteerd in grootte en functionaliteit. § De ontwikkelpartij werkt nauw samen met de gebruikers van het systeem. § Overdracht van kennis van oudere programmeurs naar jongere programmeurs is een risico

// SOFTWARE IMPROVEMENT GROUP

VERTROUWELIJK

52

.com GETTING SOFTWARE RIGHT

// SOFTWARE IMPROVEMENT GROUP