1. Architectuurontwikkeling

Binnen IRN wordt de ICT-infrastructuur gestuurd op basis van architectuurprincipes. Dit houdt in dat alle activiteiten die plaatsvinden binnen IRN moeten aansluiten op de gedefinieerde architectuurbouwblokken (ABBs) en solutionbouwblokken (SBBs). De bouwblokken worden ontwikkeld in samenhang met het portfolio zoals deze binnen de IV-Governance stuurlijn wordt vormgegeven. Deze bouwblokken vormen de basis van de ICT producten en haar productgroepen en de sturing hierop en zorgen ervoor dat de gehele infrastructuur consistent en efficiënt beheerd wordt. Enkel activiteiten die direct gelinkt zijn aan een ABB of SBB worden beschouwd als gerechtvaardigd, met uitzondering van organisatorische werkzaamheden. Dit voorkomt dat er buiten de architectuur om gewerkt wordt en zorgt voor heldere kaders. 

1.1. Architectuurbouwblokken (ABBs) en Solutionbouwblokken (SBBs)

ABBs en SBBs zijn de fundamentele bouwstenen van de architectuur binnen IRN:

• Architectuurbouwblokken (ABBs): Dit zijn generieke bouwblokken die bepaalde architecturale principes en structuren vertegenwoordigen. Een ABB beschrijft de algemene componenten, functies en verantwoordelijkheden binnen de infrastructuur. Voor elk ABB moet documentatie worden opgesteld waarin belangrijke informatie wordt vastgelegd, zoals landingslocaties, beschikbare SBBs, roadmaps, en koppelvlakken. Het vormt de functionele beschrijving van een dienst.
• Solutionbouwblokken (SBBs): Dit zijn de specifieke oplossingen die worden afgeleid van de ABBs. Elk SBB beschrijft de concrete implementatie en het beheer van de producten die binnen een ABB worden gedefinieerd. Voor elk SBB wordt beschreven wat de inrichting is en wat de specificaties zijn binnen de dienstbeschrijving. 

1.2. Documentatie en Verantwoordelijkheden

Voor zowel ABBs als SBBs is uitgebreide documentatie nodig. Dit biedt duidelijkheid over de verwachte prestaties, verantwoordelijkheden en lifecycle management van diensten. Hieronder wordt een overzicht gegeven van wat per blok nodig is. Belangrijk doel is om de informatievoorziening over producten en diensten te linken aan de architectuurbouwblokken. Dat betekent dat onder de bouwblokken ook onderdelen worden beschreven die door andere rolgroepen worden beschreven. 

Voor ABBs worden de volgende onderdelen gedocumenteerd:

• • Capabilities en Constraints: De basis van een architectuur bouwblok. Hierin staat:
    • Capabilities: Hierin staat wat de oplossing moet kunnen. Dit kan heel algemeen, maar kan ook in detail, afhankelijk van de behoefte van de architect om het doel en de kwaliteit van het solution bouwblok te beïnvloeden.
      • Deze capabilities kunnen bestaan uit functionele, technische, security- en kwaliteitseisen aan de oplossing.
    • Constraints: Hierin staat aan welke voorwaarde een oplossing moet voldoen. Dit kan gaan van:
      • De oplossing moet aan deze SAKs voldoen
      • De oplossing mag absoluut niet...
      • De oplossing moet juist gebruik maken van...
  • Landingslocaties: Waar de architectuuronderdelen landen binnen de infrastructuur, dit kan bijvoorbeeld een externe commerciële cloud zijn, een private cloud of een Rijkscloud. Hiervoor wordt de definitie in de ICT Strategie gebruikt.
  • Dienstbeschrijving: Het beschrijft wat voor dienstverlening wordt geleverd met deze ABB. 
  • Beschikbare SBBs: Een overzicht van de oplossingen die beschikbaar zijn vanuit dit ABB en de beschrijving van de diensten die daarmee worden geleverd.
  • Roadmaps: Plannen voor de toekomst en ontwikkeling van de betreffende ABB.
  • Koppelvlakken: Interfaces en afhankelijkheden tussen verschillende architectuurelementen. Dit zijn bijvoorbeeld de protocollen die kunnen worden gebruikt door andere bouwblokken die gebruik maken van het ABB.
  • Afhankelijkheden: Beschrijving waar dit ABB van afhankelijk is of welke ABBs afhankelijk zijn van het ABB. Dit geldt ook voor de verschillende serviceketens.
  • EIRA Koppeling: Vanuit de Enterprise architectuur wordt gevraagd om bij elke ABB een koppeling te maken met de EIRA.

Voor SBBs worden de volgende onderdelen gedocumenteerd:

• • SLA's: Specificaties van afspraken over de prestaties en beschikbaarheid van de diensten.
  • Responstijden en Oplosgroepen: Hoe snel er gereageerd moet worden op incidenten en wie verantwoordelijk is voor het oplossen van problemen.
  • Aansluitvoorwaarden: De technische en organisatorische eisen waaraan afnemers moeten voldoen om een dienst te gebruiken.
  • Kosten en Verantwoordelijkheden: Specificaties van welke kosten er verbonden zijn aan het gebruik van de dienst en hoe de verantwoordelijkheden zijn verdeeld (bijv. tussen product managers, solution architects, technisch en functioneel beheer).
  • Life cycle management: Het lifecycle management van de producten, waaronder status en verwachte vervangingen of upgrades. Maar ook waar kan de samenhang van LCM van de producten en de serviceketen die er effect van hebben. 
  • Technische architectuur: Beschrijving van de solution architectuur van de oplossing die wordt ingezet.
  • Technische documentatie: Beschrijving van de technische inrichting van het product (HLD en LLD).
    • Implementatie Security en IAM: Beschrijving wat de relatie is met de architectuurkaders zoals deze zijn vastgesteld in de Security architectuur en IAM architectuur.
  • Roadmap: Een door de Product Manager beschreven roadmap.
  • Afhankelijkheden: Beschrijving waar dit SBB van afhankelijk is of welke SBBs afhankelijk zijn van het SBB

1.3. Besluitvorming en Governance

De besluitvorming omtrent ABBs en SBBs vindt plaats via een gelaagde overlegstructuur binnen IRN. Het architectuurstuur is de centrale autoriteit die verantwoordelijk is voor het vaststellen van wijzigingen in de architectuur, met name op het niveau van ABBs. Voorbereidende overleggen worden gehouden op basis van de verschillende architectuurdomeinen, zoals platform en infrastructuur, werkplek en werkomgeving, en security en IAM.

• Architectuurstuur: Het hoogste architectuur besluitvormingsorgaan binnen IRN, verantwoordelijk voor de uiteindelijke vaststelling van wijzigingen in ABBs en het bepalen van de richting van de architectuur. Hierin nemen plaats: de IRN architect, CTO/plv CTO, voorzitters van de voorbereidende overleggen, en een vertegenwoordiging van het Portfoliomanagement. 
• Voorbereidende architectuur overleg: Hierin worden wijzigingen besproken en voorbereid voor besluitvorming. Dit overleg wordt voorgezeten door een domeinarchitect, die ook de rest van de domein en solution architecten vertegenwoordigt in het architectuurstuur. Dit overleg is niet besluitvormend en bevat alleen architecten. 
• Beheeroverleggen: Voor ABB- en SBB-beheerders om specifieke wijzigingen binnen hun bouwblokken te bespreken. Hierin zitten solution architecten en productmanagers.

De domein architecten fungeren als ABB-beheerders en dragen de verantwoordelijkheid voor de inhoud en ontwikkeling van hun respectieve bouwblokken. Ze moeten ervoor zorgen dat wijzigingen goed gedocumenteerd worden en dat er afstemming plaatsvindt met relevante stakeholders binnen IRN en daarbuiten. Voor de SBBs moeten de ABB-beheerders ervoor zorgen dat de solution architecten de architectuurdocumentatie op orde maken.

1.3.1. Architectuurontwikkeling

Architectuurontwikkeling begint met het signaleren van een behoefte aan verandering, opheffing of uitbreiding van de bestaande architectuur. Dit kan het gevolg zijn van strategische veranderingen binnen IRN, zoals nieuwe bedrijfsdoelstellingen of operationele eisen. Ook technologische innovaties kunnen de noodzaak creëren voor aanpassingen of de introductie van nieuwe bouwblokken. Daarnaast kan feedback van (interne)afnemers aanleiding geven tot verbeteringen in de architectuur, bijvoorbeeld wanneer gebruikers behoefte hebben aan nieuwe functionaliteiten of betere integratie van systemen. De ontwikkeling van nieuwe architectuur vindt nooit in isolatie plaats, maar altijd in samenwerking met betrokken partijen (zoals afnemers, Enterprise Architectuur, informatiehuishouding, etc.) .

1.3.1.1. Besluitvorming en overlegstructuur

Om te zorgen dat architectuurveranderingen op een gestructureerde manier worden geïmplementeerd, zijn er verschillende overlegstructuren ingericht. Deze overleggen zijn verdeeld per domein en hebben elk hun eigen focus, zoals Infra en Platformen, Werkplek en Werkomgeving, en Security en Identity & Access Management (IAM). Binnen deze domeinen worden voorgestelde wijzigingen of nieuwe architectuurcomponenten besproken, geëvalueerd en voorbereid voor besluitvorming. Elk hoofdonderdeel heeft een eigen voorbereidend overleg, waarin architecten en beheerders samenkomen om de behoeften, impact en haalbaarheid van veranderingen in kaart te brengen.

De besluitvorming over architectuurwijzigingen gebeurt in het architectuurstuur van IRN. Dit is een centraal orgaan dat wordt voorgezeten door de CTO of plaatsvervangend CTO, en bestaat uit de voorzitters van de voorbereidende overleggen, de IRN-architect, en vertegenwoordigers van het portfoliomanagement . Hier worden de voorstellen uit de voorbereidende overleggen besproken en worden beslissingen genomen over de implementatie van wijzigingen op het niveau van Architectuurbouwblokken (ABBs). Het architectuurstuur, en de voorbereidende overleggen vergaderen 6 keer per jaar en zijn het enige moment om wijzigingen van ABBs vast te stellen in samenwerking met het portfoliomanagement.

Naast het architectuurstuur zijn er specifieke beheeroverleggen die frequenter plaatsvinden en zich richten op het beheer en de doorontwikkeling van bestaande Solutionbouwblokken (SBBs). Deze overleggen worden geleid door ABB-beheerders en richten zich op de operationele kant van architectuurbeheer, zoals wijzigingen in de SLA’s, technisch ontwerp of andere aanpassingen die nodig zijn om de diensten actueel te houden.

1.3.1.2. Documentatie

Alle ABBs en SBBs binnen IRN worden gedefinieerd in de tool Enterprise Architect, waar de technische en functionele (capabilities) aspecten van de Architectuurbouwblokken (ABBs) en Solutionbouwblokken (SBBs) worden vastgelegd. Gedetailleerde documentatie van elk bouwblok is toegankelijk voor iedereen binnen IRN, waar alle componenten en hun onderlinge relaties worden beschreven. Dit zorgt voor transparantie, betrouwbaardere dienstverlening, het maakt het inwerken van nieuwe medewerkers beter en eenvoudiger en het zorgt er daarmee voor dat er een hogere overdraagbaarheid van kennis is.

1.3.1.3. Architectuurprincipes

Jaarlijks worden principes herijkt en vastgesteld om consistentie, interoperabiliteit, en flexibiliteit te waarborgen binnen de gehele architectuur, zodat deze aansluiten bij de organisatiedoelen en toekomstbestendig zijn. Deze worden afgeleid van de ICT Strategie en van de Enterprise Architectuur en de architectuurkaders van Security en IAM. De vaststelling gebeurt in het architectuurstuur. Eenmaal vastgesteld, bieden de architectuurprincipes een kader voor besluitvorming en helpen zij bij het prioriteren van IT-investeringen en het beheersen van complexiteit binnen de organisatie.

1.3.1.4 HLD, LLD, PSA

Voor elk bouwblok wordt minimaal 1 HLD en LLD gemaakt. Waar voorheen voor projecten een Project Start Architectuur (PSA) werd gemaakt, wordt dat niet meer gedaan. Als de documentatie van een ABB, SBB en HLD compleet zijn, volgens de standaarden en templates die zijn vastgesteld, bevat dit voldoende informatie. Daarbij wordt daarmee de ontwikkeling van bouwblokken directer onder de architectuursturing gebracht en wordt zo de documentatiedruk verlaagd. 

Dit geldt voor ontwikkelingen binnen IRN. Er is een uitzondering voor de ontwikkelingen binnen het netwerk, omdat contractueel is vastgelegd dat de leverancier van het netwerk met PSAs moet werken.

1.3.2. Innovatie

Innovatie speelt een belangrijke rol binnen de architectuurontwikkeling. Wanneer nieuwe oplossingen of technologieën niet binnen de bestaande architectuur passen, kan een tijdelijke ABB (via het architectuurstuur) of SBB (via een ABB beheerder) worden opgezet. Dit stelt IRN in staat om nieuwe ideeën te testen zonder dat dit ten koste gaat van de bestaande architectuur. Als een innovatie succesvol blijkt, kan de tijdelijk bouwblok doorgroeien tot een volwaardig ABB of SBB dat wordt geïntegreerd in de formele architectuur. Hiermee heeft innovatie een plaats in de architectuur, zonder veel extra bureaucratische vertraging. 

Bij de ontwikkeling van een tijdelijke bouwblok naar uiteindelijk een definitief bouwblok gaan de interne activiteiten van de Project Start Architectuur (PSA), het High Level Design (HLD) en het Low Level Design (LLD) in elkaar op. Er wordt geen PSA meer gemaakt, maar enkel een HLD en LLD die onderdeel zijn van de SBB. Omdat ook de tijdelijke bouwblokken en de bijbehorende ontwikkeling direct beschikbaar is in de architectuur, kan er op die manier worden meegekeken met de ontwikkeling van een innovatie. Voor de start van een tABB of tSBB worden een aantal spelregels gedefinieerd. 

Tijdelijke bouwblokken bevatten in ieder geval de onderstaande onderdelen.

Voor tABBs:

• Landingslocaties: Waar de architectuuronderdelen landen binnen de infrastructuur.
• Beschikbare SBBs: Een overzicht van de services die beschikbaar zijn vanuit dit ABB.
• Koppelvlakken: Interfaces en afhankelijkheden tussen verschillende architectuurelementen.

Voor tSBBs:

• Oplosgroepen: Wie er verantwoordelijk is voor het oplossen van problemen, zowel technisch als functioneel.
• Life cycle management: Het lifecycle management van de diensten, waaronder status en verwachte vervangingen of upgrades. Indien van toepassing wordt ook beschreven welk bouwblok of welke bouwblokken de tSBB gaat vervangen. 
• Technische architectuur: Beschrijving van de solution architectuur van de oplossing die wordt ingezet.
• Technische documentatie: Beschrijving van de technische inrichting van het product.
• Roadmap: Een door de Product Manager beschreven roadmap.
• Implementatie Security en IAM: Beschrijving wat de relatie is met de architectuurkaders zoals deze zijn vastgesteld in de Security architectuur en IAM architectuur.
• Plan voor productie: Wat zijn de stappen die nog moeten worden gedaan om de tSBB door te laten groeien tot een volwaardige SBB.

Dit hoeft tijdens de ontwikkeling nog niet volledig uitgewerkt te zijn, maar moet wel continu worden bijgehouden en een correcte afspiegeling zijn van het ontwikkelproces.

1.3.3 Praktische samenwerking tussen architectuurlagen

De architectuursturing kent drie niveaus die in samenhang opereren. In de praktijk roept dit vragen op over verantwoordelijkheden en volgordelijkheid. Deze paragraaf verduidelijkt hoe de samenwerking in de praktijk werkt.

1.3.3.1 Van strategie naar ontwerp

De Lead Architect IRN bepaalt op basis van de ICT Strategie de richting voor de ICT-infrastructuur. Bij een nieuw onderwerp, bijvoorbeeld een open source storage platform, geeft de Lead Architect aan welke eigenschappen gewenst zijn: software defined, ondersteuning voor meerdere storage-typen, schaalbaarheid en dergelijke.

De ICT-domeinarchitect vertaalt deze richting naar ABBs. Daarin staan de functionele, technische, security- en kwaliteitseisen beschreven op een merk- en productonafhankelijke wijze. Het ABB beschrijft bijvoorbeeld wat de organisatie bedoelt met file-, block- en object-storage, welke protocollen ondersteund moeten worden, de performance-eisen, redundantie-eisen en security-kaders.

De solution architect definieert vervolgens het SBB: de concrete oplossing die aan de ABB-kaders voldoet. Dit omvat het opstellen of toetsen van het HLD en LLD, het voorstellen van roadmap-items en het bewaken van de technische samenhang.

1.3.3.2 Volgordelijkheid en pragmatiek

In de ideale situatie zijn ABBs volledig uitgewerkt voordat solution architecten aan SBBs beginnen. Aan het begin verloopt dit nog parallel, zeker bij nieuwe domeinen of innovaties. Solution architecten hoeven niet te wachten tot alle ABBs volledig zijn uitgewerkt. Wel is afstemming met de betreffende ICT-domeinarchitect noodzakelijk om te borgen dat de SBB past binnen de richting die voor het ABB wordt uitgewerkt. Het makkelijkste is wel om de ICT-domeinarchitect te vragen zo snel mogelijk de ABB af te ronden, daarmee kan de solution architect en de productteams sneller en zelfstandiger aan de slag. Als de architectuur ver genoeg is uitgewerkt wordt het niet meer toegestaan om met een solution te beginnen, voordat er een architectuurbouwblok aanwezig is.

Meerdere ABBs kunnen naar één SBB verwijzen. Een product kan bijvoorbeeld diensten leveren die onder meerdere ABBs vallen. De solution architect hoeft geen aparte SBB te maken voor elk ABB dat het platform raakt, je geeft dan in de ABB aan welke SBB invulling geeft aan de ABB.

1.3.3.3 Mandaat en beslisruimte

De solution architect heeft mandaat om binnen de kaders van de ABBs beslissingen te nemen over de technische invulling. Dit mandaat omvat de keuze voor specifieke technologieën, de inrichting van componenten en de technische architectuur van oplossingen. De solution architect hoeft niet voor elke detailbeslissing terug te koppelen, mits de beslissing past binnen de vastgestelde ABB-kaders.

Beslissingen die buiten de ABB-kaders vallen, of die impact hebben op andere domeinen, worden voorgelegd aan de betreffende ICT-domeinarchitect of het architectuurstuur. Dit geldt ook voor wijzigingen die consequenties hebben voor de sourcingsstrategie.

Uiteindelijk kan er op deze manier de architectuur ook op een agile manier worden ontworpen, als de uitvoerende teams ook in agile werken.

1.3.3.4 Aansturing en organisatie

De ICT-domeinarchitect is verantwoordelijk voor de functionele aansturing van solution architecten binnen het betreffende ICT-domein. Dit omvat het toewijzen van ABBs die uitgewerkt moeten worden, het toetsen van SBBs aan de ABB-kaders en het bewaken van de samenhang binnen het domein.

Wie de solution architect is, hangt af van de sourcingskeuze. Bij interne uitvoering is dit een medewerker van IRN. Bij uitbesteding kan de solution architect bij de leverancier zitten, maar blijft de ICT-domeinarchitect verantwoordelijk voor de toetsing aan de ABB-kaders. De productmanager bepaalt in afstemming met de ICT-domeinarchitect welke sourcingsvorm wordt gehanteerd.

1.4. Raakvlakken met de ICT Strategie en Enterprise Architectuur

De architectuursturing van IRN wordt gebruikt om invulling te geven aan de ICT Strategie van RWS. De architectuur volgt namelijk de strategie, omdat het invulling geeft aan de strategische doelstellingen van RWS. Belangrijk ander raakvlak is de Rijkswaterstaat Enterprise Architectuur (REA), deze vormt een kader waarmee de IRN architectuur wordt ontwikkeld.

Rijkswaterstaat breed wordt de IRN architectuur gecommuniceerd en afgestemd binnen de architectuurberaad van het CIO-Office. Daarin verenigen de architecten zich. In dit overleg worden de volgende onderdelen vanuit IRN besproken of vastgesteld:

• • Besproken/afstemming van de volgende onderdelen van ABBs en tABBs:
    • Roadmaps
    • Koppelvlakken
    • Landingslocaties
  • Vaststelling van kaderstellende architecturen Security en IAM.

Voorafgaand aan de vaststelling van de kaderstellende architecturen wordt er het architectuurstuur goedkeuring gegeven voordat het kan worden vastgesteld in het architectuurberaad van RWS. Dit om de haalbaarheid binnen de infrastructuur te borgen. Dit gebeurt binnen het architectuurstuur van IRN.

Onderstaande plaat beschrijft de relaties tussen de verschillende architectuurdocumenten en gremia. 

1.5. Aansluiting bij de RIVA

Binnen Rijkswaterstaat worden de IV aansluitvoorwaarden beschreven. Dit gebeurt in de RIVA. De beschrijving van de ABBs en SBBs vormen de basis van de input die IRN geeft voor de doorontwikkeling van de RIVA. De RIVA wordt door de CTO vastgesteld. 

De ontwikkeling en vaststelling van de RIVA valt buiten de architectuuroverleggen van IRN. Het kan direct worden vastgesteld door de CTO, hier is geen vaststellingsgremium voor nodig.

1.6. Wijzigingen door afnemers

Mogelijk worden er wijzigingen van bepaalde bouwblokken (ABBs of SBBs) gevraagd door (interne) afnemers. Hoewel dit in een aanbod gedreven dienstverlening beperkt zou moeten zijn, is de situatie niet uit te sluiten. Hiervoor worden wijzigingen bij de Lead architect en de ICT domein architect aangevraagd. Deze wordt beoordeeld door de architecten op impact voor andere bouwblokken en impact op de organisatie. Wijzigingen worden eerst in een ABB opgenomen en een architectuurbesluit. Het resultaat wordt teruggekoppeld aan het architectuurstuur. 

Uitgangspunt is dat een wijziging of een nieuwe ABB/SBB die door een enkele afnemer is gevraagd per definitie wordt afgekeurd. Door het werken naar een aanbod gedreven dienstverlening, moeten wijzigingen in de architectuur gevraagd worden door meerdere afnemers. Uiteindelijk kunnen meerdere PSA’s dan ook leiden tot een wijziging in de architectuur. Dit is echter een uitzondering. Normaliter wordt er vanuit de architecten en het portfoliomanagement standaard dienstverlening samengesteld.