Logisch ontwerp

Beschrijving

Identity and Access Management

Type

SAML, LDAP, oAuth

Functie

• Authentiseren gebruikers
• Autorisatie gebruikers
• Gebruikers beheer
• Security Groepen beheer

Eigenaar

BOS (eHerkenning, Webportaal), Infra (Active Directory)

Aantal gebruikers

Onbekend

Aantal transacties

Onbekend

Frequentie van de transacties

Onbekend

Hoeveelheid data

Onbekend

Toegepaste security

Service account voor applicatie API en eHerkenning voor GDR

Beschrijving

De Geo Dataruimte is de omgeving welke Geo data ontsluit als services voor Rijkswaterstaat. De services zijn met WCS bevraagbaar.

Type

HTTPS : AGS en OGC services (WFS,WMS) en Catalogus

Functie

Beveiligen service voor niet open data met RWS IAM oplossing

• applicatie koppelingen met TLS authenticatie (certificaten)
• Webservices voor cliënt applicaties met eHerkenning (IAM derden)

Eigenaar

DMC, IGA

Aantal gebruikers

Onbekend

Aantal transacties

Onbekend

Frequentie van de transacties

Onbekend

Hoeveelheid data

Onbekend

Toegepaste security

TLS authenticatie en Active Directory (in de toekomst IAM broker)

Beschrijving

File opslag

Type

SMB/NFS

Functie

• Opslag bestanden

Eigenaar

Infra

Aantal gebruikers

Onbekend

Aantal transacties

Onbekend

Frequentie van de transacties

Onbekend

Hoeveelheid data

Onbekend

Toegepaste security

Active Directory groepen

Beschrijving

Diverse RWS applicaties.

Type

API
Server naar server communicatie

Functie

Afnemende en aanleverende Rijkswater applicaties voor protocol en berichttransformaties

Eigenaar

RWS

Aantal gebruikers

Onbekend

Aantal transacties

Onbekend

Frequentie van de transacties

Onbekend

Hoeveelheid data

Onbekend

Toegepaste security

Voor gesloten data TLS authenticatie en AD service accounts, in sommige gevallen ook IPsec VPN tunnel

Beschrijving

Diverse applicaties voor monitoring

Type

HTTPS, forwarder (agent)

Functie

Rijkswaterstaat applicaties voor monitoring en dashboarding, voor diverse doelgroepen (beheerders, klanten, management)

Eigenaar

IV Platformen, Infra

Aantal gebruikers

Onbekend

Aantal transacties

Onbekend

Frequentie van de transacties

Onbekend

Hoeveelheid data

Onbekend

Toegepaste security

Active Directory groepen

Beschrijving

Berichtenafhandeling en queueing ten behoeve van ODS, onderdeel van Industriele Automatisering (IA)

Type

HTTPS met TLS authenticatie en AMQP via TCP

Functie

Klaarzetten van berichten voor ophaal

Eigenaar

IV Platformen

Aantal gebruikers

Onbekend

Aantal transacties

Onbekend

Frequentie van de transacties

Onbekend

Hoeveelheid data

Onbekend

Toegepaste security

AD service accounts

Beschrijving

Koppeling met CI/CD oplossing

Type

HTTPS met TLS authenticatie

Functie

Centrale source repository (Azure Repos/Github), artifact repository (Azure Artifact), orchestrator en deployment tool (Azure DevOps)

Eigenaar

IV Platformen

Aantal gebruikers

Onbekend

Aantal transacties

Onbekend

Frequentie van de transacties

Onbekend

Hoeveelheid data

Onbekend

Toegepaste security

AD service accounts

Beschrijving

Koppeling naar I&W centraal aansluitpunt

Type

API's

Functie

Centraal ontsluiten kernregistraties naar RWS datacenter applicaties

Eigenaar

IV Platformen

Aantal gebruikers

Onbekend

Aantal transacties

Onbekend

Frequentie van de transacties

Onbekend

Hoeveelheid data

Onbekend

Toegepaste security

Haagse ring, PKI certificaten

Beschrijving (Rol)

Personen met de rol voor Technisch onderhoud via management console

Taken

Functioneel onderhoud via applicatie interface waar onder:

• Patchen systemen
• Configureren omgeving
• Monitoren omgeving
• Support

Type

RDP voor Technisch onderhoud via server console

Eigenaar

IV Platformen

Aantal gebruikers

Onbekend

Aantal transacties

Onbekend

Frequentie van de transacties

Onbekend

Hoeveelheid data

Onbekend

Toegepaste security

Active Directory groepen

Beschrijving (Rol)

Personen met de rol om de nieuwe API's te ontwikkelen met de integratie platform ontwikkel software

Taken

Ontwikkelen, onderhouden, analyseren en documenteren van API's

Type

Web, voor platform API management (library, testen en monitoren)
REST, Publish API to CI/CD oplossing
Lokaal, ontwikkel applicatie

Eigenaar

OSR domein

Aantal gebruikers

Onbekend

Aantal transacties

Onbekend

Frequentie van de transacties

Onbekend

Hoeveelheid data

Onbekend

Toegepaste security

Active Directory groepen

ID

Aandachtsgebied

Operationeel

Status

Genomen

Onderwerp

Configureren platform

Ontwerp besluit

Maak gebruik van API's

Probleem Omschrijving

Wat is de beste manier om het integratie platform te configureren en hergebruik te bevorderen.

Aannames

Geen

Motivatie

Standaardisatie en hergebruik

Opties

1. Configureer per applicatie (project)
2. Ontwikkel herbruikbare API's

Onderbouwing genomen besluit

Optie 2 is gekozen
Met herbruikbare API's wordt API-Led connectivity bedoeld. De API-Led connectivity betekent dat applicaties gekoppeld worden via herbruikbare blokken (API's). De API-led connectivity vormt een belangrijke schakel in de integratie strategie, waarbij het gebruik van API's het onderhoud en complexiteit van connecties kan reduceren.
Om efficiency en flexibiliteit te verkrijgen is een multi-tier architectuur framework ontwikkeld voor API-Led connectivity. Er kunnen een drietal lagen worden onderscheiden:

• Systeem API's: Ontsluiten van backend en/of legacy systemen. Deze API's kunnen door vele gebruikers worden gebruikt zonder specifiek de onderliggende systemen te hoeven kennen.
• Proces API's: Toepassen van generieke business logica. Voorbeeld: het ophalen van data uit verschillende sources of het oppakken data(flows) waarbij het protocol omgezet moet worden naar een ander protocol.
• Experience API's: Presentatie naar de (eind-)gebruiker. Hierbij kan bijvoorbeeld een zelfde dataset op verschillende methoden worden aangeboden aan een gebruiker (afhankelijk van de requirements; bijv. mobile-app en web-app)

Gevolgen besluit

Adapteer API-Led connectivity techniek binnen RWS. Beschikbaar stellen van de aanwezige API's (Exchange).

Afgeleide requirements

Geen

Gerelateerde OB's

Geen

ID

IP (ESB)-002

Aandachtsgebied

Security

Status

Genomen

Onderwerp

RIVA bouwstenen

Ontwerp besluit

Neem de management omgeving als SaaS a

Probleem Omschrijving

Vanuit de leverancier zijn er twee opties voor de management omgeving: in de cloud (SaaS) of on premise. Is SaaS veilig voor een zeer vertrouwelijk component zoals management omgeving voor het integratie platform

Aannames

De management omgeving in de cloud geeft risico's die we overzien en voldoende kunnen afdekken en mitigeren.
Voorkeur voor eigen cloud/K8s oplossingen in de RIVA werkt ook op technologie-niveau, mits aan veiligheidseisen wordt voldaan.

Motivatie

Afname van COTS i.p.v. eigen maatwerk.

Opties

1. Managed server
2. Unmanaged server
3. Cloud

Onderbouwing genomen besluit

Optie 3 is gekozen. Door de leverancier van het Integratie platform wordt de keuze aangeboden de management module vanuit de cloud af te nemen of een complete standaard installatie te leveren.

De beperking vanuit de leverancier betekent voor Rijkswaterstaat dat er een architectuur afwijking is en we geen gebruik kunnen maken van de standaard managed server bouwsteen (optie 1). Ondanks dat de oplossing on premise uit docker containers bestaat inclusief Kubernetes is dit in de installatie niet te ontvlechten om op de toekomstige bouwsteen PKS te installeren. De enige manier is installatie door de leverancier op unmanaged servers (optie 2). En is hiermee de enige andere optie op het moment dat optie 3 alsnog niet veilig genoeg blijkt te zijn (A06).

De optie 3 is een harde voorwaarde voor het gebruik van een COTS Runtime fabric oplossing voor ESB runtimes in K8s (zie OB-IP (ESB)-003). In een PoC wordt er gekeken of aanname A06 gestaafd kan worden.

Gevolgen besluit

Afwijking van huidig beleid rondom de cloud toepassingen. Mogelijk hierdoor herijking van het beleid.
Nieuwe aanvraag voor BIO nodig.

Afgeleide requirements

Geen gebruik van monitoring vanuit de management omgeving, alleen de RWS monitoring tools.

Gerelateerde OB's

OB-IP (ESB)-003

ID

IP (ESB)-003

Aandachtsgebied

Implementatie

Status

Genomen

Onderwerp

RIVA bouwstenen

Ontwerp besluit

De runtimes implementatie op standard VM's

Probleem Omschrijving

De runtimes zorgen voor het daadwerkelijk draaien van API's. Deze moeten een stabiele omgeving, goede connectie naar de juiste omgevingen toe, goede connectie met de management omgeving. Schaalbaarheid (meerdere instanties van dezelfde applicatie) en hoog beschikbaarheid spelen ook een rol. Met welke implementatie kan RWS hieraan het beste voldoen?

Aannames

Acceptatie van de management omgeving in de cloud (OB-IP-002)

Motivatie

Eenduidige oplossing voor Rijkswaterstaat

Opties

1. Kubernetes van CNAP
2. Kubernetes van Azure
3. VM's (geen K8s)
4. IVA van K8s van leverancier op VM's

Onderbouwing genomen besluit

Optie 3 is gekozen. Door het accepteren van de management omgeving in de cloud (OB-IP-002) en terughoudendheid in maatwerk voor vervanging van standaard Runtime Fabric in containers valt optie 1 automatisch af. Optie 2 verdient de voorkeur maar is nog niet uitvoerbaar (AKS is wel beschikbaar, maar nog niet in de on-premises variant). Optie 4 (RTF Appliance) wordt niet langer ondersteund. Optie 3 is de enige andere mogelijkheid op het moment dat de aannames niet gestaafd kunnen worden (HA Clusters).

Gevolgen besluit

Voordelen van cloud native en cloud friendly implementatie. Voor een consistente omgeving ook migratie van ActiveMQ (en MFT?) naar CNAP. Minimale aanpassingen in monitoring en tooling (CI/CD) nodig. Op termijn migratie naar een bij RWS in de RIVA opgenomen implementatie van K8s.

Afwijking architectuur, verzoek bij de leverancier om de implementatie aan te passen zodat deze op het CNAP platform, PKS en/of Cloud Foundry, geïnstalleerd kan worden. Hiermee ontlasten we het Integratie Platform team van het beheren van de VM's, telkens installeren van de door leverancier aangeboden images (IVA) en (het ontwikkelen en beheren) van maatwerk voor het geautomatiseerde container beheer in operatie (nabouw van Runtime Fabric).

Afgeleide requirements

Geen

Gerelateerde OB's

OB-IP-004, OB-IP-006, OB-IP-009, OB-IP-010

ID

IP (ESB)-004

Aandachtsgebied

Security

Status

Genomen

Onderwerp

Zonering

Ontwerp besluit

Maak gebruik van DMZ voor ontsluiting naar internet

Probleem Omschrijving

Hoe kunnen we de interne data connecties (API's) ontsluiten naar internet

Aannames

Vervanging van fysieke ESB in DMZ door een netscaler is niet voor alle protocollen toegestaan.

Motivatie

Toepassen security zonering model

Opties

1. Maak gebruik van zonering en de DMZOntsluit interne zone via reverse proxy (netscaler)

Onderbouwing genomen besluit

Optie 2 is gekozen om enkel alle verzoeken via de netscaler (https, sftp) af te handelen. Er wordt nog onderzocht hoe andere verzoeken waarbij afwijkende protocollen nodig zijn alsnog via de netscaler kunnen verlopen.

Gevolgen besluit

Enkel interne omgeving is nodig voor het verkeer van en naar internet dat via de netscaler kan; geen RTF in DMZ nodig.
Firewall rule om verkeer tussen interne runtime en management in de cloud te koppelen.

Afgeleide requirements

Een netscaler is beschikbaar en de juiste poorten (voor de juiste protocollen) zijn open gezet.

Gerelateerde OB's

OB-IP-006

ID

IP (ESB)-005

Aandachtsgebied

Implementatie

Status

Genomen

Onderwerp

Beschikbaarheid

Ontwerp besluit

Dubbel uitgevoerde Productie omgeving.

Probleem Omschrijving

Door migratie naar DC1.5 en RTF ontstaat de vraag over noodzaak van een uitwijklocatie voor de productie omgeving vanwege de nieuwe hoge beschikbaarheid van de omgeving. Daarnaast heeft RTF een naderende EndOfLife situatie, waardoor een nieuwe omgeving benodigd is. Doordat hardware lange doorlooptijden met zich meebrengt ontstaat de vraag in hoeverre er extra hardware voor het bestaande platform aangevraagd wordt t.b.v. uitwijk als vervanging van de uitwijk in DC1.0. Alternatief is deze uitwijk omgeving niet apart, maar bij de nieuwe hardware aanvraag voor de nieuwe omgeving mee in te nemen zoals beschreven in OB-IP (ESB)-003.

Aannames

Een hoge beschikbaarheid van 99.5% van de productie omgeving in AM4 is toereikend voor MKS-klanten.
Twee apart uitgevoerde productie omgevingen creëert extra complexiteit.

Motivatie

Ontwerpen voor kunnen blijven bedienen van bestaande klanten en beperken van extra complexiteit

Opties

1. Alleen Productie in AM4 op RTF
2. Zowel Productie in AM4 als AM2 op RTF
3. Zowel Productie in AM3 als AM2 op HA Clusters

Onderbouwing genomen besluit

Optie 3 is gekozen. Onderbouwing is te kunnen voldoen aan de klantwens van LMW2 als MKS zijnde om uit te kunnen wijken naar een tweede ESB set-up, waarbij de klant handmatig fail-over kan doen naar een ander datacenter voor hun API. Hierbij wordt dezelfde set-up geïmplementeerd als de primaire productie omgeving, om zo de complexiteit te beperken.

Gevolgen besluit

Extra kosten voor hardware, beheer en minimale extra complexiteit door het faciliteren van MKS klanten.

Afgeleide requirements

Geen.

Gerelateerde OB's

OB-IP (ESB)-003

ID

IP (ESB)-006

Aandachtsgebied

Implementatie

Status

Genomen/herzien

Onderwerp

Tooling

Ontwerp besluit

RabbitMQ op CloudFoundry via het CNAP team voor intern verkeer, RabbitMQ op VMs in DC1.0 voor extern verkeer via DMZ

Probleem Omschrijving

Message Queueing is een noodzakelijk onderdeel van het ESB platform. Er zijn meerdere opties mogelijk voor Message Queueing. Uitdaging is opzet en beheer complexiteit overzichtelijk te houden.

Aannames

Geen

Motivatie

Ontwerpen voor performance en continuering van klantbediening

Opties

1. RabbitMQ op CloudFoundry
2. RabbitMQ op kubernetes
3. ActiveMQ behouden
4. RabbitMQ op VMs

Onderbouwing genomen besluit

Optie 1 en 4 zijn gekozen. RabbitMQ is opgenomen in de RIVA en wordt binnen RWS als product aangeboden. Performance en functionele testen hebben aangetoond dat het product zeer geschikt is voor het beoogde doel. RabbitMQ sluit naadloos een bij het IP2 en IP3 ontwerp waar gebruik wordt gemaakt van containers per klant of zelf per API. Ook RWS MKO klanten zoals Landelijk Meetnet Water, maken al langere tijd gebruik van deze omgeving. Optie 4 is uit noodzaak erbij gekomen, doordat Netscaler in DC1.5 geen MQ-verkeer naar buiten blijkt aan te kunnen. Als gevolg van dit voortschrijdend inzicht zijn VMs aangemaakt in de DMZ van DC1.0, zodat klanten als ODS bediend kunnen blijven na uitfasering van Mule 3.9 en ActiveMQ.

Gevolgen besluit

Herschrijven van de bestaande applicaties, zodat deze hiermee om kunnen gaan. Vergroting van complexiteit en beheerlast van de omgeving, doordat RabbitMQ op zowel containers in CloudFoundry als op VMs in DC1.0-DMZ landt.

Afgeleide requirements

Controle op IP ranges bij gebruik van zowel intern als in DMZ.

Gerelateerde OB's

OB-IP (ESB)-003 & OB-IP (ESB)-007

ID

IP (ESB)-007

Aandachtsgebied

Implementatie

Status

Genomen

Onderwerp

Zonering

Ontwerp besluit

Setup met een Interne en een DMZ versie van MQ

Probleem Omschrijving

Door migratie naar DC1.5 ontstaat de vraag over noodzaak van een DMZ omgeving voor MQ van het platform.

Aannames

SSL verbindingen naar interne setup op Cloudfoundry (CF) zijn niet mogelijk, omdat dan alles binnen interne CF omgevingen via SSL certificaten moet gaan werken en niet alleen ESB.
Lange Security trajecten om routering door Netscalers naar interne netwerk goed gekeurd te krijgen.

Motivatie

Ontwerpen voor kunnen blijven bedienen van bestaande klanten en vermijden van lange security trajecten

Opties

1. Alleen Intern
2. Zowel DMZ als Intern

Onderbouwing genomen besluit

Optie 2 is gekozen. Zolang er geen verbetering komt op de Netscaler waarbij SSL verbindingen naar interne setup mogelijk worden, blijft de urgentie om een MQ in DMZ te hanteren. DMZ vraagt echter twee extra instances van RabbitMQ en daardoor extra beheerlast. Zolang verkeer via interne CF omgevingen via SSL certificaten moet verlopen blijft de noodzaak voor een DMZ. De huidige DMZ in DC1.5 wordt door Infra ongeschikt geacht voor MQ verkeer. Zodoende moet gebruik worden gemaakt van de DMZ van DC1.0.

Gevolgen besluit

Extra kosten voor CloudFoundry, beheer en extra complexiteit door het faciliteren van externe klanten.

Afgeleide requirements

Geen.

Gerelateerde OB's

OB-IP (ESB)-004 en OB-IP (ESB)-006

ID

IP (ESB)-008

Aandachtsgebied

Implementatie

Status

Open

Onderwerp

Tooling

Ontwerp besluit

Managed File Transfer via dedicated product

Probleem Omschrijving

Managed File Transver verloopt via Mule APIs op het API Platform. Het verplaatsen van bestanden via deze APIs is resource intensief, aangezien bestanden voor verplaatsing in het RAM geheugen ingeladen moeten worden. Bij verplaatsing van meerdere bestanden tegelijkertijd kan het API platform overbelast raken en down gaan indien het RAM geheugen vol is. Dit is onwenselijk voor de overige APIs op het API platform die ten alle tijden benaderbaar moeten zijn. Om die reden zijn in de huidige MFT APIs een maximale toegestane bestandsgrootte afgedwongen. Hierdoor kan slechts een beperkte set aan klanten bediend worden via deze MFT oplossing. Er kan geen afleverbevestiging gegenereerd worden.

Aannames

SolarWinds Serv-U is te duur/ te weinig budget voor
Cohesity s3 heeft geen MFT plugin voor geautomatiseerde push en pull van en naar bron- en doellocaties
Data Inwin Module biedt geen ondersteuning aan RHEL 10
Maatwerk oplossing is te duur/ te weinig budget voor
Er is geen beter alternatief dan de huidige MFT constructie, alle argumenten meegewogen

Motivatie

Bredere doelgroep kunnen voorzien van Managed File Transfer met grotere maximale bestandsgrootte in stand-alone opstelling, voorzien van keten monitoring, verzendbevestiging, RBAC en OAuth/OIDC authenticatie, waarbij het risico op downtime van het API platform ingeperkt is.

Opties

1. Continuering huidige MFT constructie via sFTP en Mule APIs
2. MFT via Cohesity s3 en MFT plugin vanuit RWS infra en leverancier Cohesity
3. MFT via bestaande Data Inwin Module software vanuit OSR-WaterManagement en leverancier Deltares
4. MFT via SolarWinds Serv-U als dedicated MFT commercial off-the-shelf product vanuit inkooptraject en afdeling RWS-Inkoop
5. Maatwerk MFT oplossing via RAP leverancier zoals RWS-LOL-project

Onderbouwing genomen besluit

Optie 3 is gekozen om te onderzoeken.

Gevolgen besluit

Potentiële afhankelijkheid met afdeling OSR-Watermanagement, aangezien contacten verlopen tussen leverancier Deltares en OSR-WM.

Afgeleide requirements

Geen.

Gerelateerde OB's

Geen

ID

IP (ESB)-009

Aandachtsgebied

Implementatie

Status

Open

Onderwerp

Configuratie

Ontwerp besluit

Maak gebruik van de RWS brede IAM component voor de toegangscontrole

Probleem Omschrijving

Het platform bevat zo min mogelijk business logica en gebruikersbeheer. Hoe regelen we de toegangscontrole voor het platform en voor de op het platform ontsloten API's?

Aannames

IAM component levert alle benodigde manieren van toegangscontrole, in de juiste protocollen.
Het gebruik van het IAM component is mogelijk zowel voor toepassingen on-premises (in eigen datacenter) als in de cloud (SaaS).

Motivatie

Het Integratie Platform is zelf een beveiligingsmaatregel. Hierin is de toegangscontrole een belangrijke onderdeel. Tegelijkertijd is een centraal beheerde toegang- en gebruikerscontrole een belangrijke principe binnen RWS.

Opties

1. Toegangscontrole gebruikers binnen het platform
2. Toegangscontrole gebruikers via centrale IAM component

Onderbouwing genomen besluit

Optie 2 is gekozen. Centraal beheren van gebruikersbeheer en toegangsrechten verhoogt de betrouwbaarheid en kwaliteit van de gegevens en vermindert en uniformeert sterk het werk. Ook vergemakkelijkt dit het aansluiten op nieuwe mogelijkheden zoals eHerkenning of DIGID.

Gevolgen besluit

Koppeling met het IAM component.

Afgeleide requirements

De functie voor automatic user provisioning zoals met Active Directory blijft gelijk bij gebruik IAM.

Gerelateerde OB's

Geen

ID

IP (ESB)-010

Aandachtsgebied

Implementatie

Status

Genomen

Onderwerp

Tooling

Ontwerp besluit

Gebruik eigen CI/CD oplossing volgens Mulesoft best practices

Probleem Omschrijving

Voor een goede en snelle uitrol naar de ontwikkel, test, acceptatie en productie omgeving is een CI/CD tool nodig. Kan er aangesloten worden op een generieke Rijkswaterstaat bouwsteen?

Aannames

Geen

Motivatie

Eenduidige oplossing voor Rijkswaterstaat

Opties

1. Koppelen aan Rijkswaterstaat bouwsteen voor CI/CD
2. Implementeren best practice vanuit de integratie bedrijfstak

Onderbouwing genomen besluit

Optie 2 is gekozen. Op dit moment is er nog geen uitgewerkte RWS bouwsteen voor continuous integration en continuous delivery (CI/CD) en heeft het de voorkeur de best practice van Microsoft te volgen. Deze oplossing bestaat uit Centrale source repository (Azure Repository/GitHub), artifact repository (Azure Artifacts), orchestrator en deployment tool (Azure DevOps).

Gevolgen besluit

Wanneer Rijkswaterstaat hier een bouwsteen voor heeft ontwikkeld moet onderzocht worden hoe hier op aangesloten kan worden.

Afgeleide requirements

LCM en BIO compliance van de tooling is geborgd.

Gerelateerde OB's

Geen

ID

IP (ESB)-011

Aandachtsgebied

Implementatie

Status

Genomen

Onderwerp

Tooling

Ontwerp besluit

Setup met in de bouwstraat geïntegreerde repository voor artifacts

Probleem Omschrijving

Door migratie naar DC1.5 ontstaat de vraag over welke artifact repository het beste aansluit bij de huidige functionele wensen bij de nieuwe omgeving. Daarbij moet rekening gehouden worden met de huidige gebruikers van de bestaande artifact repository, Nexus, namelijk IVP-IP en IVP-GIS. De hardware van de oude artifact repository moet worden ingeleverd.

Aannames

Alleen code voor APIs van de bouwstraat hoeft opgeslagen te worden in een artifact repository. De artifacts uit de oude omgeving worden niet langer gebruikt en kunnen verwijderd worden.

Motivatie

Ontwerpen voor eenvoud, goede integratie en het gebruik van SaaS

Opties

1. Nexus van VM overnemen
2. Migreren naar Nexus van WM, samen met GIS
3. In gebruik nemen Azure Artifacts

Onderbouwing genomen besluit

Optie 3 is gekozen. Zowel optie 1 als optie 2 brengt afhankelijkheden met zich mee van een externe partij als beheerder, zonder dat de Nexus als dienst afgenomen wordt. Deze manier van gebruik maken van de Nexus van een andere afdeling maakt het team afhankelijk van het beleid van die afdeling. Dit is ongewenst. Tijdens de doorontwikkeling van de bouwstraat in Azure DevOps komt als optie Azure Artifacts naar voren. Dit blijkt goed te integreren met overige functionaliteit van de bouwstraat. Azure Artifacts bezorgd een gecentreerde oplossing die goed integreert met de complete bouwstraat-oplossing.

Gevolgen besluit

GIS moet zelfstandig, in plaats van gezamenlijk, een alternatieve Nexus vindt waarnaar men kan migreren.

Afgeleide requirements

Geen.

Gerelateerde OB's

OB-IP (ESB)-002 en OB-IP (ESB)-010