11. Risico’s en Technical Debt

De onderstaande onderwerpen vormen bekende risico's, beperkingen of architectuurschuld binnen de huidige platformarchitectuur.

11.1 Herijking externe samenwerkingsarchitectuur

De huidige architectuur voor externe samenwerking is gebaseerd op ArcGIS Online (ADR-GIS-009).

Deze keuze dient opnieuw beoordeeld te worden in het licht van:

• ontwikkelingen rondom digitale soevereiniteit;
• wijzigingen in Rijks- en Rijkswaterstaat-cloudbeleid;
• mogelijke realisatie van een Portal-oplossing in de DMZ;
• licentie- en exploitatiekosten.

Daarnaast dient de definitieve URL-strategie (ADR-GIS-014) verder uitgewerkt te worden om toekomstige migraties en publicatiepatronen te ondersteunen.

11.2 OpenShift- en containerisatietransitie

Rijkswaterstaat ontwikkelt haar platformstrategie richting containerisatie en cloud-native platformdiensten.

De toekomstige positionering van ArcGIS Enterprise binnen een OpenShift-gebaseerd platformlandschap is nog niet volledig uitgewerkt.

Openstaande aandachtspunten zijn onder andere:

• migratiestrategie van VMware naar OpenShift;
• impact op beheerprocessen;
• deployment- en automatiseringspatronen;
• ondersteuning van ArcGIS Enterprise-componenten;
• integratie met bestaande platformdiensten.
• integratie met FME en GeoWeb Modules.

11.3 Tight coupling tussen platformcomponenten

De huidige GIS-platformarchitectuur bevat een aantal sterke technologische afhankelijkheden tussen platformcomponenten.

Voorbeelden hiervan zijn:

• GeoWeb-modules die nauw geïntegreerd zijn met ArcGIS Enterprise;
• FME-workflows die afhankelijk zijn van ArcGIS-functionaliteit;
• gebruik van een ArcGIS Server-licentie ten behoeve van ST_GEOMETRY-functionaliteit;
• afhankelijkheden tussen gegevensopslag, services en productspecifieke technologieën.

Deze afhankelijkheden leiden tot:

• verhoogde beheercomplexiteit;
• grotere impact van wijzigingen en upgrades;
• hogere migratiekosten;
• verminderde flexibiliteit bij vervanging van componenten;
• verhoogde vendor lock-in.

Daarnaast kan deze verwevenheid toekomstige platformontwikkelingen, waaronder containerisatie en migratie naar OpenShift, complexer maken.

De architectuur streeft daarom naar verdere ontkoppeling van componenten door:

• servicegebaseerde integratie;
• vermindering van directe databaseafhankelijkheden;
• beperking van ArcPy-afhankelijkheden;
• toepassing van open standaarden waar mogelijk;
• verdere scheiding van platform- en applicatieverantwoordelijkheden.

Figuur 11.1 - Kritieke afhankelijkheden binnen de huidige GIS-platformarchitectuur

De huidige architectuur bevat sterke afhankelijkheden tussen GeoWeb Modules, ArcGIS Enterprise, FME, ArcPy en ST_GEOMETRY. Deze afhankelijkheden vergroten de impact van wijzigingen, lifecycle management en toekomstige migraties naar een containerplatform. Verdere ontkoppeling van deze componenten vormt een belangrijk aandachtspunt voor toekomstige platformontwikkeling.

11.4 Historische non-federated implementaties

Hoewel federated ArcGIS Enterprise de standaardarchitectuur vormt, zijn nog niet alle bestaande diensten gemigreerd naar deze doelarchitectuur.

Hierdoor ontstaat tijdelijke technische schuld in de vorm van:

• meerdere architectuurpatronen naast elkaar;
• aanvullende beheerlast;
• afwijkende IAM-integraties;
• extra migratie-inspanningen bij toekomstige platformvernieuwing.

11.5 Beperkte horizontale schaalbaarheid

De huidige platformarchitectuur is primair ontworpen voor beheerbaarheid en lifecycle management.

De gekozen segmentatie-aanpak biedt voordelen ten aanzien van beheer en isolatie, maar kent beperkingen ten aanzien van:

• horizontale schaalbaarheid;
• elastisch opschalen van capaciteit;
• cloud-native deploymentpatronen.

Dit aandachtspunt wordt relevanter naarmate het aantal gebruikers, datasets en diensten verder toeneemt.

11.6 On-premise beheerlast

Een belangrijk deel van de platformfunctionaliteit wordt on-premise geleverd.

Hierdoor blijft sprake van:

• lifecycle management van infrastructuur;
• patch- en upgradeactiviteiten;
• capaciteitsbeheer;
• operationeel beheer van platformcomponenten.

Hoewel automatisering deze beheerlast beperkt, blijft deze hoger dan bij vergelijkbare volledig beheerde SaaS-oplossingen.

11.7 Open vraagstukken rondom geodatabeheer

De architectuur streeft naar gebruik van open standaarden en beperking van vendor lock-in.

De huidige productieomgeving maakt echter nog gebruik van Esri-specifieke technologieën zoals ST_GEOMETRY.

Openstaande vraagstukken zijn:

• toepasbaarheid van database-native geometrieformaten;
• impact op beheerprocessen;
• gevolgen voor interoperabiliteit;
• aansluiting op toekomstige Esri-roadmaps.