Introductie

In dit hoofdstuk staan de volgende onderdelen:

Doel van het HLD

Het doel van dit HLD is het beschrijven van 'architectural solution baseline' voor de infrastructuur voor het Integratie Platform van Rijkwaterstaat. De beschreven oplossing bevat voldoende informatie voor het maken van het detailed design, het implementatie plan, etc.

Management Samenvatting

De missie van Rijkswaterstaat (RWS) is samenwerken aan een veilig, leefbaar en bereikbaar Nederland. Hiertoe is het noodzakelijk om betrouwbare en bruikbare informatie ter beschikking te hebben. Met behulp van accurate gegevens is het mogelijk om nieuwe inzichten te krijgen om de doestelling van RWS te waarborgen (zie de Unresolved page: 1 RWS, “i-Strategie Rijkswaterstaat - Robuust en slagvaardig datamanagement”, Aug-2015).
Deze sectie bevat de uitwerking daarvan in de RWS applicatie-doelarchitectuur Integratie Platform.
Voor Rijkswaterstaat is een (centraal) integratie platform ontwikkeld om dataverkeer tussen verschillende partijen te reguleren en beheren. Hiervoor is een service georiënteerde oplossing gekozen: de Enterprise Service Bus (ESB). Het platform richt zich op de realisatie van services.
Door het gebruik van een centraal integratie platform in de RWS architectuur wordt een standaardisatie en centralisatie gerealiseerd voor de manier waarop afnemers en aanbieders data kunnen aanbieden en/of afnemen. Het is de taak van het platform om informatie (zoals berichten, databestanden, rapportages) om te zetten in het gewenste formaat/protocol (transformatie) en de informatie gegarandeerd aan of door te leveren. In Figuur 1 is de gewenste data flow aangegeven.

Figuur 1: DataFlow met gebruik van een centraal Integratie Platform - Overzicht

Vanuit Rijkswaterstaat blijft de wens een redundant, schaalbaar, eenvoudig beheersbaar integratie platform aan klanten te kunnen aanbieden. Dit kan gevonden worden in de vorm van Mulesoft RTF: een gecontaineriseerd kubernetes (K8s) platform die verschillende applicatie versies gescheiden naast elkaar kan draaien op 'pods' met iedere 'pod' een eigen cpu en memory, die schaalt naar behoefte, zonder impact op andere pods bij downtime.
Voor Rijkswaterstaat is bij het integratie platform implementatie op K8s, door de beperkingen vanuit de leverancier, voor de volgende opzet gekozen:

• Het centrale management gedeelte in de cloud;
• Runtime (op virtuele machine in plaats van op K8s, management stuk voor het operationeel managen van de runtimes, aansturen van runtimes en communicatie met AnyPoint Control Plane, en de runtimes zelf) in de vertrouwelijke zone (intern bij RWS) op virtual machines. De door leverancier beschikbare K8s landingzones werkt niet samen met de bij RWS aanwezige implementaties. Gebruik van RTF van de leverancier is alleen in combinatie met de management gedeelte in de cloud af te nemen.
• Daarnaast zijn de tools in dezelfde zone geplaatst, die de functionaliteiten van ESB mogelijk maken, namelijk message queueing (tool RabbitMQ) en sFTP.
• (Data)transport vanaf het internet naar binnen loopt voor veilige protocollen altijd via de route internet --> Netscaler --> intern: er is geen direct transport vanuit de niet-vertrouwde zone naar de vertrouwde zone (ontkoppeling). Alleen die poorten zijn opengezet die noodzakelijk zijn (volgt het beleid 'Dicht, tenzij..'). Voor protocollen waar het niet toegestaan is, loopt het (data)transport via de route internet --> DMZ --> intern. In dit geval zijn de tools hiervoor in de DMZ zone geplaatst.

De leverancier heeft de ambitie uitgesproken op termijn K8s implementatie onafhankelijk te worden. Zodra de leverancier deze ambitie heeft gerealiseerd, kan worden overgestapt naar runtime fabric op de op dat moment standaard implementatie van K8s bij RWS. Tot die tijd is de gekozen opstelling een exceptie en dient er regelmatig getoetst worden op de mogelijkheid om dit naar de gewenste architectuur te brengen.
De argumentatie voor alsnog deze keuze is te vinden in Ontwerp beslissingen; OB-IP (ESB)-002, OB-IP (ESB)-003, OB-IP (ESB)-004, OB-IP (ESB)-005 en OB-IP (ESB)-009.

Structuur van het HLD

Pagina Functionele Requirements beschrijft de functionele requirements en de standaarden noodzakelijk voor de componenten 'solution building blocks (SBB)' in scope van dit document. 
Pagina Non-Functionele Requirements beschrijft de non-functionele requirements. Deze geven de randvoorwaarden aan waaraan het systeem moet voldoen, zoals de gevraagde service levels voor de systemen, de eigenschappen van het systeem en de beperkingen die waaraan het systeem (of delen van het systeem) moet voldoen.
Pagina Logisch Ontwerp geeft een logisch overzicht en beschrijft de ontwerp besluiten ('architectural decisions') die gebruikt zijn bij het ontwerp van de oplossing. 
Pagina Technology Layer beschrijft het technisch ontwerp van de oplossing. 

Out of scope

De volgende zaken zijn buiten scope van dit HLD en de afdeling:

• Data management en manipulatie;
• Applicaties die op het Integratie Platform landen;
• Processen en procedures voor aanvraag, onderhoud en configuratie;
• Governance model.