Ministerie van Infrastructuur en Milieu IenM Enterprise Architectuur

Document D-7 Ministerie van Infrastructuur en Milieu IenM Enterprise Architectuur Versie 0.2

Datum Status

15 juli 2014 Definitief

Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2

Colofon

Versie

0.2

Contactpersoon

Paul Leunissen M 06 - 5250 6691 [email protected] Ministerie van Infrastructuur en Milieu Hoofddirectie Financiën, Management en Bedrijfsvoering Directie Concern Informatievoorziening Afdeling Architectuur en Informatie Management Team Architectuur Koningskade 4 Postbus 20906 2500 EX Den Haag

Auteurs

Paul Leunissen Peter Visser Stephen Oostenbrink

Pagina 2 van 57


Inhoud

Voorwoord ..................................................................................................................... 5 1

IenM Enterprise Architectuur ............................................................................... 6

1.1 1.2 1.3 1.3.1 1.3.1.1 1.3.1.2 1.4 1.4.1 1.4.2 1.4.3 1.4.3.1 1.4.3.2 1.4.3.3 1.5 1.6 1.6.1 1.6.2 1.6.3 1.7 1.8 1.9

Inleiding ...................................................................................................................... 6 Waarom een Enterprise Architectuur? ................................................................................ 6 Werken onder architectuur .............................................................................................. 7 Wat levert de IenM Enterprise Architectuur op? ................................................................... 7 Architectuur voor besluitvorming projectportfolio ............................................................. 7 Architectuur als kader voor projecten ............................................................................. 8 Werken aan Architectuur ................................................................................................. 9 Totstandkoming IMEA ................................................................................................... 10 Opbouw van IMEA........................................................................................................ 10 Onderhoud IMEA ......................................................................................................... 12 Uitbreiden en aanpassen ........................................................................................... 12 Methoden, technieken en hulpmiddelen ........................................................................ 13 Frequentie en vaststelling .......................................................................................... 13 Scope van IMEA .......................................................................................................... 13 Doelstelling IMEA ......................................................................................................... 14 Toekomst(vast) ........................................................................................................... 15 Kwaliteit .................................................................................................................... 15 Communicatie ............................................................................................................. 15 Doelgroep .................................................................................................................. 15 Leeswijzer .................................................................................................................. 15 Geraadpleegde documenten en bronnen .......................................................................... 15

2

Bedrijfsarchitectuur .......................................................................................... 17

2.1 2.2 2.2.1 2.2.1.1 2.2.1.2 2.2.1.3 2.2.2 2.2.3 2.3 2.4 2.5 2.6

Inleiding .................................................................................................................... Organisatie ................................................................................................................. Missie van IenM........................................................................................................... Vlot - Veilig - Leefbaar .............................................................................................. Keuzes maken ......................................................................................................... Van buiten naar binnen ............................................................................................. Informatieplannen ....................................................................................................... Directie Concern Informatievoorziening............................................................................ Processen................................................................................................................... Producten en Diensten .................................................................................................. Bedrijfsarchitectuur Principes ......................................................................................... Service Gerichte Architectuur .........................................................................................

3

Informatiearchitectuur ...................................................................................... 27

3.1 3.1.1 3.1.2 3.2 3.3 3.3.1 3.4 3.4.1 3.5 3.5.1 3.5.2

Inleiding .................................................................................................................... Scope ........................................................................................................................ Doelstelling ................................................................................................................ Informatie-architectuur principes .................................................................................... Medewerkers en Applicaties ........................................................................................... Principes .................................................................................................................... Berichten en Gegevens ................................................................................................. Principes .................................................................................................................... Informatie-uitwisseling ................................................................................................. Achtergrond................................................................................................................ Integratiefuncties ........................................................................................................

4

Technische Architectuur .................................................................................... 35

4.1 4.2 4.3 4.4 4.5 4.5.1 4.5.1.1 4.5.2 4.5.3 4.6 4.6.1 4.6.2 4.7 4.8 4.8.1 4.8.2

Inleiding .................................................................................................................... Meerdere ICT infrastructuren ......................................................................................... Kwaliteit .................................................................................................................... Modellering................................................................................................................. Technische Componenten .............................................................................................. Verwerkingslaag .......................................................................................................... Enterprise Service Bus (ESB) en het Centraal Aansluitpunt............................................... Presentatielaag ........................................................................................................... Distributielaag ............................................................................................................. Gegevens Opslag ......................................................................................................... Online Storage ............................................................................................................ Offline Storage ............................................................................................................ Netwerk ..................................................................................................................... Beveiliging ................................................................................................................. Identity Management (IdM) ........................................................................................... Beveiliging van de informatie-uitwisseling ........................................................................

17 17 18 18 19 19 20 21 22 23 24 26

27 27 27 28 29 29 30 30 31 31 33

35 35 35 36 37 38 38 40 41 41 42 42 42 44 44 45

Pagina 3 van 57


4.8.3 4.8.4 4.9

Inbraakdetectie d.m.v. IDS (Intrusion Detection System).................................................... 45 Security Services ......................................................................................................... 45 Beheer....................................................................................................................... 45

5

Architectuur Principes ....................................................................................... 47

5.1 5.2 5.3 5.4 5.5 5.6 5.6.1 5.6.2 5.6.3 5.7 5.7.1 5.7.2 5.7.3 5.7.4 5.7.5

Indeling van de architectuurprincipes .............................................................................. Scope van de principes ................................................................................................. Principes versus Aansluitvoorwaarden.............................................................................. Leeswijzer principes ..................................................................................................... Bedrijfsarchitectuur principes ......................................................................................... Informatiearchitectuur principes ..................................................................................... Medewerkers en Applicaties ........................................................................................... Berichten en Gegevens ................................................................................................. Informatie-uitwisseling ................................................................................................. Technische principes .................................................................................................... Technische Componenten .............................................................................................. Gegevensopslag .......................................................................................................... Netwerk ..................................................................................................................... Beveiliging ................................................................................................................. Beheer.......................................................................................................................

47 47 47 47 48 49 49 49 50 51 51 54 54 55 56

Pagina 4 van 57


Voorwoord

Op weg naar een flexibele en efficiënte Informatievoorziening Evenals andere organisaties binnen de overheid streeft het Ministerie van Infrastructuur en Milieu (IenM) naar de verwezenlijking van politieke en bestuurlijke doelstellingen en dit leidt tot een welhaast continue stroom aan veranderingen. Het succesvol doorvoeren van deze veranderingen, vaak in de vorm van projecten, vraagt om een inzichtelijke samenhang en samenwerking van (het ontwerpen van) weten regelgeving, organisaties, processen en ondersteunende voorzieningen, waaronder ICT, gericht op de gewenste nieuwe producten en diensten. Hoe groter, ambitieuzer en complexer een project, hoe groter de noodzaak tot afspraken en sturing. Voor u ligt het document met een beschrijving van de IenM Enterprise Architectuur (hierna aangeduid met IMEA), waarin deze afspraken en sturing zijn opgenomen in de vorm van uitgangspunten, richtlijnen en kaders. Het ‘Werken onder Architectuur’ maakt de complexiteit beheersbaar en maakt het mogelijk noodzakelijke en gewenste veranderingen in de vorm van projecten op te knippen, waarbij de samenhang behouden blijft en hergebruik van bestaande (delen van) oplossingen mogelijk wordt. Daar steeds meer diensten en producten van de (Rijks)overheid tot stand komen door samenwerking tussen verschillende organisaties zijn multilaterale afspraken en standaarden noodzakelijk. Op architectuurgebied wordt hier door de Nederlandse Overheid Referentie Architectuur (NORA) en de Model Architectuur Rijksdienst (MARIJ) invulling aan gegeven. Voorliggend document sluit dan ook nauw aan bij deze documenten. De aanpak van het “Werken onder Architectuur” vertoont grote gelijkenis met die van de organisatieverandering binnen het Rijk. Geconcretiseerd zijn de kenmerken van de aanpak van werken onder architectuur: Geen blauwdruk maar richtinggevende principes en modellen; Stapsgewijs veranderen. Denk Groot, realiseer klein en snel; Architectuur voor projecten wordt eerst uitgewerkt in een Globale Architectuur Schets (GAS) en vervolgens in een Project Start Architectuur (PSA); Just in Time en Just Enough Architectuur; Geen theoretische beschouwingen maar concrete architectuur voor lopende en actuele ontwikkelingen; Een stimulerende, faciliterende, activerende rol van de architecten.

Pagina 5 van 57


1

IenM Enterprise Architectuur

1.1

Inleiding Om in een wereld waarin verandering de enige constante is invulling te kunnen blijven geven aan de doelstellingen van IenM, zullen continu processen worden herontworpen, taken en rollen van medewerkers worden veranderd en zullen informatiesystemen moeten worden vernieuwd. IenM staat voor de uitdaging - om naast de interne reorganisaties - al deze veranderingen in samenhang aan te sturen, om op die manier een samenhangend geheel aan oplossingen te implementeren. Het is een uitdaging om de toenemende complexiteit die daarbij hoort het hoofd te bieden en overzicht te behouden op dit geheel van ontwikkelingen, factoren, afhankelijkheden en invloeden. De architectuurbenadering, oftewel het ‘werken onder architectuur’, is daarbij een belangrijk hulpmiddel.

1.2

Waarom een Enterprise Architectuur? Een Enterprise Architectuur vormt een samenhangend fundament voor het opbouwen en in stand houden van een omgeving. Daarbij strekt de ‘omgeving’ zich verder uit dan de techniek en omvat ook de inrichting van de organisatie, de processen, de informatievoorziening, de infrastructuur en de onderlinge samenhang. Dit is vergelijkbaar met het realiseren van een complete woonwijk, waarbij de architectuur op verschillende niveaus (streekplan, bestemmingsplan, ontwerpplan) zorgt voor ordening van de functies van de woonwijk, de infrastructurele voorzieningen, de oplossingen en de samenhang tussen deze onderdelen. Het bovenliggende niveau voorziet het onderliggende niveau van kaders waarbinnen het ontwerp kan plaatsvinden. Op die manier maakt architectuur de complexiteit beheersbaar.

Figuur 1: Architectuur op verschillende niveaus De architectuurbenadering zorgt ook dat de informatievoorziening in lijn is met de bedrijfsdoelstellingen. Informatiesystemen – en ook architectuur - zijn geen doel op zich, maar zijn ondersteunend aan de bedrijfsstrategie. De architectuurbenadering helpt zo om de veranderingen van bovenaf aan te sturen. Ook ondersteunt architectuur - met onder andere uitgangspunten, richtlijnen, kaders, principes, modellen en taalafspraken - de communicatie met alle betrokkenen.

Pagina 6 van 57


1.3

Werken onder architectuur Werken onder architectuur is niet alleen noodzakelijk voor het gecontroleerd uitvoeren van wijzigingen, het zorgt ook voor grip op de al bestaande en verder toenemende complexiteit en helpt bij de besluitvorming. Of het nu gaat om veranderingen in de organisatie, een gewijzigde informatiebehoefte of het toepassen van innovatieve technieken, de wens is en blijft om “in control” te zijn. Werken onder architectuur is dus niet een doel op zich, het is het (stuur)middel om grip op de situatie te houden. Tenslotte is werken onder architectuur een belangrijke randvoorwaarde voor samenwerking. Afspraken over standaarden en referentiemodellen zijn onontbeerlijk waar meerdere partijen samenwerken en informatie uitwisselen om voor de klant – burger, bedrijf en maatschappelijke organisaties – de gewenste producten en diensten te leveren.

1.3.1

Wat levert de IenM Enterprise Architectuur op? De informatievoorziening van IenM ondersteunt het realiseren van de doelstellingen van het departement. De IenM Enterprise Architectuur, IMEA, draagt bij aan het op een passende, efficiënte en flexibele wijze vormgeven van deze informatievoorziening. In voorliggend document kunt u lezen op welke wijze IenM het werken onder architectuur heeft ingericht c.q. in wil gaan richten. Architectuur is hierbij een ondersteuningsinstrument voor sturing. Het geeft aan hoe verschillende ontwikkelingen met elkaar samenhangen. Met behulp van IMEA kunnen ontwikkelingen op het gebied van informatievoorziening in samenhang worden beschouwd. Dat biedt de volgende voordelen voor opdrachtgevers, management en proceseigenaren: Hergebruik van de kennis en ervaringen die reeds opgedaan zijn bij soortgelijke vraagstukken. Adviezen en beslissingen kunnen beter worden onderbouwd. Er kan gebruik gemaakt worden van voorzieningen die er al zijn, zodat er niet voor elk vraagstuk een nieuwe oplossingen wordt bedacht, Er worden geen wijzigingen doorgevoerd, die (zonder dat dat helder is) afbreuk kunnen doen aan de resultaten van andere processen (voorkomen van problemen door suboptimalisatie van processen). Impact bepalen van (externe) ontwikkelingen en veranderingen (o.a. wetgeving), waardoor zij beter zijn voorbereid op de benodigde organisatieverandering. Handvatten om prioriteiten te stellen in het projectportfolio. Inzicht en samenhang in de huidige informatievoorziening en het huidige applicatielandschap door middel van Applicatie Portfolio Management (APM). Visie op toekomst van de informatievoorziening, hierdoor is het mogelijk te sturen met een heldere richting en te gaan van ad hoc naar gestructureerde sturing. Vertaalde visie naar concrete richting voor de inrichting van processen en de informatievoorziening. Besturing over het gehele (ICT) projectenportfolio vindt mede plaats door te bepalen of een voorgesteld project past binnen de kaders van IMEA. Het geeft architectuurkaders waarbinnen projecten hun ontwerpen inrichtingsbeslissingen moeten nemen. IMEA geeft kaders, richtlijnen en richting aan projectresultaten. Samengevat is ‘Werken onder architectuur’: Gebruik van architectuur in besluitvorming over het projectportfolio. Gebruik van architectuur als kader voor projecten. Opstellen en onderhouden van architectuur (zie ook 1.4).

1.3.1.1

Architectuur voor besluitvorming projectportfolio

Architectuur strekt in het kader van besluitvorming rondom het projectenportfolio verder dan ICT infrastructuur of applicaties en gaat ook in op de

Pagina 7 van 57


informatiehuishouding, gegevensuitwisseling en de verandering aan de bedrijfsprocessen. Bij goedkeuring van een project wordt op de volgende inhoudelijke aspecten getoetst (naast uiteraard aspecten als financiën en resources): Hoe past het project in de overige lopende en geplande ontwikkelingen? (afbakening, scope, relaties); Hoe past het beoogde projectresultaat in de architectuur? (oplossingsrichting). Veel veranderingen binnen IenM vinden plaats in de vorm van projecten. Een goed inzicht en overzicht van het projectportfolio door middel van Project Portfolio Management (PPM), is noodzakelijk om een afweging te kunnen maken welke projecten IenM - binnen de context van de bestaande projecten – moet uitvoeren. Dit houdt in dat het projectportfolio up to date moet zijn. Het gebruik van een business case is, binnen de gekozen methodiek van projectmanagement (Prince) noodzakelijk. Een business case legt de afwegingen, waaronder de kosten-batenanalyse op basis waarvan het management beslissingen neemt, vast. Een business case moet gedurende de looptijd van een project voortdurend onderhouden worden, omdat de factoren die de business case beïnvloeden kunnen wijzigen. Architectuur draagt hier in bij door scherp te krijgen wat de oplossingsrichting is, in welke context de verandering plaats vindt en door het wegnemen van (een deel van de) onzekerheden. Hiermee verbetert de kwaliteit van de business case. Architectuur geeft daarnaast inzicht in de huidige situatie, de scope van de veranderingen en schetst een beeld van de gewenste toekomstige situatie. Dit zorgt er voor dat er gefundeerde keuzes gemaakt worden. 1.3.1.2

Architectuur als kader voor projecten

De regie voor de uitvoering op ICT projecten ligt in handen van de Directie Concern Informatievoorziening (DCI). Figuur 2 hieronder bevat een vereenvoudigde weergave van het ketenproces, zoals dit door DCI bij ICT projecten wordt gevolgd. De diverse architectuurproducten zijn herkenbaar aan de blauwe kleur en worden in het navolgende beschreven. De wijze waarop in dit proces met de architectuurproducten wordt gewerkt en de rol die architectuur hierin vervult, wordt aangeduid met ‘Werken onder Architectuur’.

Figuur 2: Context IMEA Producten

Pagina 8 van 57


De Globale Architectuur Schets (GAS) is de eerste globale verkenning naar een inhoudelijke oplossingsrichting, behorend bij de vraag van de opdrachtgever. De GAS is dan ook vooral bedoeld om de opdrachtgever inzicht te geven in deze oplossingsrichting en wijze van realisatie. Daarbij wordt weliswaar gestuurd op basis van de relevante architectuurprincipes, maar om te voorkomen dat de doelgroep afhaakt, worden deze in de vorm van begrijpelijke en heldere uitgangspunten benoemd. Voor elk systeemontwikkelingsproject wordt, zonder uitzondering, een GAS opgesteld. Ook in die gevallen waarin een GAS (bijvoorbeeld vanwege de beperkte omvang of complexiteit van een traject) niet nodig is. In dat geval zal de GAS slechts bestaan uit een motivatie waarom er geen GAS is vereist. Hiermee wordt voorkomen dat de GAS stap al dan niet bewust wordt genegeerd. De GAS helpt hiermee het project de kaders van IMEA te hanteren en is samen met het Projectvoorstel de eerste mijlpaal van het projectproces van DCI. Een GAS wordt vastgesteld door de opdrachtgever. In het geval er sprake is van projectgeoriënteerde realisatie, dan geeft de GAS expliciet en gemotiveerd uitsluitsel over het al dan niet opstellen van een PSA. In de Project Start Architectuur (PSA) worden de in de GAS gemaakte keuzen verder uitgewerkt. Daarbij worden de van toepassing zijnde kaders, richtlijnen en principes uit IMEA naar voor het project relevante en concrete inrichtingskeuzes vertaald, waarmee de PSA de leidraad vormt voor de oplossing gedurende het project. Een PSA zorgt er voor dat de architectuur een verbinding maakt met de strategische doelen en keuzes van de opdrachtgever. Een PSA is een uitwerking door architectuur waarin de voorwaarden worden aangegeven waaraan een te realiseren ICT voorziening moet voldoen. Dit betekent dat er na het opstellen van een PSA geen volledige ontwerpvrijheid is voor het project; het project dient zich te houden aan de kaders c.q. spelregels die in de PSA zijn vastgelegd. De PSA wordt als onderdeel van het Werken Onder Architectuur gemaakt om te bewerkstellen dat veranderingen zodanig gerealiseerd worden dat zij samenhang hebben met andere veranderingen en passen binnen de gewenste toekomst vaste informatievoorziening. De PSA wordt door architectuur opgesteld, in samenwerking met de opdrachtgever en domein experts. Review wordt gedaan door stakeholders en collega architecten om daarmee te komen tot een gedragen en kwalitatief hoogwaardige architectuur. Het document Aansluitvoorwaarden beschrijft, als hulpmiddel bij het Werken onder Architectuur, niet-functionele eisen waaraan informatiesystemen, welke door DCI in beheer worden genomen en/of binnen de (IenM) ICT Infrastructuren beschikbaar worden gesteld, dienen te voldoen. Deze aansluitvoorwaarden gelden niet enkel bij het selecteren c.q. het (laten) ontwikkelen van nieuwe applicaties en de overdracht hiervan naar beheer, maar ook gedurende de exploitatieperiode (het beschikbaar houden). De aansluitvoorwaarden gelden zowel voor applicaties die in de IenM infrastructuur landen, als applicaties die extern gehost worden. 1.4

Werken aan Architectuur Zoals in het voorgaande aangegeven, creëert architectuur duidelijkheid, kent het duidelijke samenhangende modellen voor elk van de onderdelen, zorgt het voor overzicht en inzicht, begrip en het adresseren van de juiste discussies. Daarbij is het wel noodzakelijk de in de architectuur gebruikte termen, begrippen en hun onderlinge samenhang te begrijpen. In deze paragraaf worden de referentie modellen, raamwerken (frameworks), methoden, technieken, tools en talen toegelicht, die worden toegepast bij de totstandkoming, opbouw en onderhoud van IMEA.

Pagina 9 van 57


1.4.1

Totstandkoming IMEA IMEA is gebaseerd op een aantal voorgaande documenten op het gebied van de architecturen van vmVenW en vmVROM en is in die zin een doorontwikkeling. Zo werd bij vmVROM de Enterprise VROM Architectuur (EVA) gehanteerd en kende vmVenW concernkaders ten aanzien van de inzet van ICT voorzieningen. Werkwijzen en producten waarvan het ontstaan mede werd ingegeven door de veranderde omgeving en Rijksbrede ontwikkelingen op het gebied van architectuur, zoals (Nederlandse Overheid Referentie Architectuur) en MARIJ (Model Architectuur Rijksdienst). Na de samenvoeging van beide departementen en de inrichting van de Directie Concern Informatievoorziening (DCI) zijn de krachten ook op architectuurvlak gebundeld en is een start gemaakt met de inrichting van het Werken onder Architectuur en de bijbehorende instrumenten zoals IMEA.

1.4.2

Opbouw van IMEA Figuur 3 geeft aan hoe IMA zich verhoudt tot NORA en MARIJ. NORA wordt beïnvloed door internationale standaarden en richtlijnen vanuit de EU. Zowel NORA als MARIJ hebben hun invloed op de generieke bouwstenen e-overheid en de Rijksbrede projecten, door deze ontwerprichtlijnen en een toetsingskader mee te geven en ze te positioneren in een groter geheel. NORA doet dit voor de gehele overheid, MARIJ voor de Rijksdienst. MARIJ is daarnaast richtinggevend voor de architecturen bij de departementen, zoals IMEA bij IenM en bijvoorbeeld DEAL bij ELenI.

Figuur 3: Relatie NORA, MARIJ en IMEA IMEA is dusdanig opgebouwd dat wordt aangesloten bij NORA en MARIJ. Zo wordt de architectuur beschreven aan de hand van het architectuurraamwerk zoals dit in de NORA is gedefinieerd (zie Figuur 4), het zogenaamde 9+2-vlaks model. Het model bestaat uit 3 lagen, te weten Bedrijfs-, Informatie en Technische Architectuur, met elk 3 vlakken en in iedere architectuur laag komen de aspecten Beveiliging en Beheer aan bod.

Pagina 10 van 57


Figuur 4: Architectuurraamwerk NORA Om te voorkomen dat de IenM Enterprise Architectuur wordt beschreven in één lijvig en daarmee onoverzichtelijk, moeilijk hanteer- en verteerbaar document, is er gekozen voor het creëren van een IMEA dossier, een verzameling IMEA documenten met een onderlinge samenhang. Figuur 5 bevat een grafische presentatie van het IMEA dossier. In het voorliggende hoofddocument, wordt de IenM Enterprise architectuur beschreven aan de hand van de NORA indeling, wordt nut en noodzaak van architectuur voor IenM behandeld en worden de richtinggevende en kader stellende principes gepresenteerd waarbinnen bij het werken onder architectuur geacteerd wordt. In domeinarchitecturen worden specifieke domeinen binnen de organisatie beschreven die – vaak vanwege de omvang en complexiteit - een nadere detaillering behoeven. Een domeinarchitectuur beschrijft op hoofdlijnen de processen, activiteiten en informatie die een rol spelen in het betreffende domein en bevat, indien nodig, ook aanvullende domein specifieke kaders en principes. In IMEA katernen zijn architectuurbegrippen en –concepten nader uitgewerkt en toegelicht. Voor de realisatie van oplossingen in de vorm van informatiesystemen gelden aansluitvoorwaarden, gebaseerd op de IMEA architectuurprincipes (zie ook 1.3.1.2). Tenslotte bevat het IMEA dossier een template voor het opstellen van een Globale Architectuur Schets (GAS) en een Project Start Architectuur (PSA).

Pagina 11 van 57


Figuur 5: IMEA Dossier 1.4.3

Onderhoud IMEA Architectuur is nooit af. Er zijn technische en organisatorische ontwikkelingen, voortschrijdend inzicht, wijzigingen in strategie en er zijn altijd delen die verder uitgewerkt kunnen worden. IMEA is daardoor zelf altijd in ontwikkeling en wordt, mede op basis van terugkoppeling door besluitvormers en projecten, aangescherpt. Kortom, de architectuur moet onderhouden worden. De verantwoordelijkheid voor het correct, actueel en bruikbaar maken en houden van de architectuur ligt bij het architectuurteam van DCI/Ontwikkeling. Dit is een continu proces, wat ook onderdeel uitmaakt van het jaarplan van DCI. Op basis van nieuwe ontwikkelingen en feedback uit projecten worden wijzigingen op de architectuur verzameld en verwerkt tot een volgende versie van IMEA. Uiteraard rekening gehouden met de IenM visie ten aanzien van de informatievoorziening die mede invulling moet geven aan de I-Strategie van het Rijk en worden ontwikkelingen in de markt, overheid en organisatie gevolgd. Deze input, in Figuur 2 weergegeven met de groene lijnen, biedt een relatief statische basis voor de IenM Enterprise Architectuur.

1.4.3.1

Uitbreiden en aanpassen

Werken aan architectuur betreft het telkens verder invulling geven aan en aanpassen van deze architectuur met kaders en richtlijnen voor actuele onderwerpen, waarvoor vanuit architectuur richting gegeven moet worden. Deze onderwerpen zijn onder meer afkomstig uit ontwikkelingen in de markt, de overheid en de eigen organisatie. Daarnaast ontstaan nieuwe inzichten door de werkzaamheden in het ketenproces en het opstellen van de architectuurproducten GAS en PSA. Zo worden bijvoorbeeld nieuwe domeinen (bijvoorbeeld Eenvoudig Pagina 12 van 57


Beter) in kaart gebracht, of worden concepten generiek uitgewerkt in katernen (bijvoorbeeld Service Gerichte Architectuur). Deze invloeden zijn met de rode stippellijnen in Figuur 2 weergegeven. Het IMEA dossier is dan ook een groeiende set documenten waaraan nieuwe domeinen en katernen worden toegevoegd. 1.4.3.2

Methoden, technieken en hulpmiddelen

Ter ondersteuning van het werken aan architectuur wordt (pragmatisch) gebruik gemaakt van standaard methodieken, zoals het architectuur procesmodel van TOGAF (The Open Group Architecture Framework). TOGAF biedt niet alleen handvatten voor het opstellen en onderhouden van een architectuurdocument, maar ook voor het werken onder architectuur. Voor het beschrijven van de architectuur wordt gebruik gemaakt van generieke KA applicaties zoals Word, Powerpoint en Visio en specifieke architectuur applicaties zoals Archi voor het modelleren van schema’s, tekeningen en overzichten in de diverse lagen van de architectuur. Voor dit modelleren wordt de architectuurtaal Archimate toegepast. Al deze toegepaste raamwerken, methoden en technieken zijn Rijksbreed omarmd en voor het merendeel zelfs vastgesteld als rijksstandaard.

1.4.3.3

Frequentie en vaststelling

1.5

Scope van IMEA De architectuur principes zijn het belangrijkste middel om bij het werken onder architectuur de ontwikkeling van de informatievoorziening te sturen. Ondanks dat een aantal IenM organisatieonderdelen, waaronder RWS, KNMI en PBL, een eigen koers varen ten aanzien van de invulling c.q. operationalisering van informatievoorziening, gelden de IMEA Architectuur Principes voor geheel IenM.

Het Architectuurteam zal het IMEA hoofddocument ten minste één maal per jaar actualiseren en opnieuw laten vaststellen in de Stuurgroep IV. Domeinarchitecturen en eventuele additionele katernen worden toegevoegd indien beschikbaar.

Het IMEA dossier beschrijft daarentegen niet een allesomvattende Enterprise Architectuur voor alle organisatieonderdelen van IenM. IMEA bevat een globale beschrijving van de Bedrijfsarchitectuur, waarin de taken van IenM worden afgedekt. Deze Bedrijfsarchitectuur wordt gebruikt om de Informatiearchitectuur en de Technische architectuur verder inhoud te geven. ILT hanteert een zelf opgesteld informatieplan en valt derhalve voor wat betreft de Business Architectuur buiten scope. Dit geldt om eerder genoemde redenen voor alle architectuurlagen voor RWS, KNMI en PBL. Voorzieningen ontwikkeld onder verantwoordelijkheid van IenM, waarvan de uiteindelijke realisatie, uitvoering en/of het gebruik buiten de IenM organisatie liggen, vallen onder het domein ‘Extern’. Voorbeelden hiervan zijn het Omgevingsloket Online (OLO) en het Landelijk Asbest Volg Systeem (LAVS). De beschreven scope afbakening is in navolgende figuur met de kleuren van de bollen weergegeven. De percentages waarmee de diverse bollen zijn ingevuld, geven aan in hoeverre er ten aanzien van architectuur op genoemd tijdstip inzicht bestaat en/of gestuurd wordt op de (ontwikkeling van de) diverse architectuuronderdelen en voorzieningen.

Pagina 13 van 57


Figuur 6: Scope IMEA Q1 2013 Het inzicht in en de besturing van de bedrijfsvoering van de diverse IenM organisatieonderdelen neemt een wat bijzondere plaats in dit geheel in. Dit vanwege het besluit om een aantal bedrijfsvoering processen binnen geheel IenM op eenzelfde wijze c.q. met dezelfde informatiesystemen te ondersteunen. Dit is weergegeven in onderstaande figuur.

Figuur 7: Scope IMEA in relatie tot Bedrijfsvoering 1.6

Doelstelling IMEA Het voorliggende document is een beschrijving van de IenM Enterprise Architectuur en de daarin geldende uitgangspunten, richtlijnen, kaders en principes, inclusief de onderlinge samenhang. Het document dient diverse doelen, te bundelen op basis van de volgende kenmerken.

Pagina 14 van 57


1.6.1

Toekomst(vast) IMEA draagt bij aan de verdere ontwikkeling en realisatie van een flexibele en wendbare informatievoorziening van IenM. IMEA ondersteunt bij het prioriteren van (investeringen ten behoeve van) projecten. Projecten en de daarmee te realiseren doelstellingen en producten worden getoetst aan IMEA. Gefundeerde keuzes met betrekking tot de informatievoorziening maken, die aan de strategische doelstellingen van IenM bijdragen, zodat er gefundeerd besluitvorming over wijzigingen plaatsvindt. Zorgen dat er een informatievoorziening ontstaat die niet alleen de actuele behoefte afdekt, maar ook adaptief is voor de toekomstige eisen, wensen en innovaties.

1.6.2

Kwaliteit Een informatievoorziening ontwikkelen die maximaal aansluit op de eisen, wensen en principes van IenM. Bevorderen van de kwaliteit, professionaliteit, effectiviteit en efficiency van de informatievoorziening en van iedereen die hierbij is betrokken. IMEA draagt richtlijnen, principes en standaarden aan voor de ontwikkelingen van informatiesystemen, onder andere de zogenaamde ‘Aansluitvoorwaarden’.

1.6.3

Communicatie Samenhang definiëren en bewaken van alle componenten binnen de informatievoorziening van IenM. Het document dient als communicatiemiddel en biedt als zodanig inzicht in de wijze waarop de informatievoorziening binnen IenM is en wordt vormgegeven en stelt de diverse doelgroepen (zie 1.7) in staat om diverse besluiten en activiteiten met elkaar in verband te brengen, te synchroniseren en te begrijpen.

1.7

Doelgroep De doelgroepen waarvoor IMEA primair van belang is, zijn: (Leden van de) Stuurgroep Informatievoorziening (StIV); (Informatiemanagers van de) IenM organisatieonderdelen; IenM ICT Architecten; Architecten in ICT projecten; Directie Concern Informatievoorziening (DCI); Leveranciers.

1.8

Leeswijzer Hoofdstuk 1 bevat een introductie en beschrijft de doelstelling, de totstandkoming, context en scope van IMEA en geeft inzicht in (nut en noodzaak van) het Werken onder en aan Architectuur, Hoofdstuk 2 bevat een beschrijving van de Bedrijfsarchitectuur; Hoofdstuk 3 bevat een beschrijving van de Informatiearchitectuur; Hoofdstuk 4 bevat een beschrijving van de Technische Architectuur; Hoofdstuk 5 bevat een overzicht en onderbouwing van de architectuur principes zoals deze in de voorgaande hoofdstukken bij de beschrijving van de architectuur lagen zijn gebruikt.

1.9

Geraadpleegde documenten en bronnen [NORA]: Nederlandse Overheid Referentie Architectuur, versie 3.0 [MARIJ]: Model Architectuur Rijksdienst, versie 1.0 [EVA]: Enterprise IenM Architectuur, versie 3.0; [ISTRAT]: I-Strategie Rijk; [IDCI]: Inrichtingsdocument DCI, januari 2012; [FDA]: Functionele Doelarchitectuur DWR – TBGI, oktober 2012; [KSGA]: IMEA Katern – Service Gerichte Architectuur; [VWI]: IMEA Domeinarchitectuur – Visie Werkplekconcept IenM, dec 2012; Pagina 15 van 57


[TOGAF]: The Open Group Architecture Framework; [NVR]: Nota “Vernieuwing Rijksdienst” [KeB]: Kleiner en Beter [BIRTNK]: Baseline informatiebeveiliging Rijksdienst - Tactisch Normenkader [SRIDM]: Stappenplan Rijksbreed IdM, 15 mei 2007 [NKIDM]: Gemeenschappelijk Normenkader Rijksoverheidbreed IdM – componenten 1 t/m 4, 26 maart 2008 [GART]: Gartner research; [FORR]: Forrester research.

Pagina 16 van 57


2

Bedrijfsarchitectuur

De Bedrijfsarchitectuur betreft de invulling van de bovenste laag van het architectuurraamwerk in de NORA. 2.1

Inleiding Dit hoofdstuk geeft een beschrijving - op hoofdlijnen - van de huidige bedrijfsarchitectuur van IenM. De bedrijfsarchitectuur kent momenteel in IMEA een beperkte diepgang. Normaliter worden in de Bedrijfsarchitectuur de onderwerpen organisatie, producten en diensten en de processen uitgewerkt. Deze onderwerpen zijn inhoudelijk voor de diverse domeinen waarbinnen IenM c.q. delen van haar organisatie acteren, dusdanig uiteenlopend van aard dat in voorliggend document enkel de generiek van toepassing zijnde aspecten worden beschreven. De specifieke aspecten hebben c.q. krijgen hun plek in de betreffende domeinarchitectuur. Dit zal gebeuren op basis van behoefte en actuele vraag. De Bedrijfsarchitectuur richt zich in IMEA met name op de generieke aspecten als organisatie, haar doelstellingen, de geldende principes, de bedrijfsfuncties en de impact die zij hebben op de Informatievoorziening. De Bedrijfsarchitectuur wordt ontwikkeld vanuit de doelstellingen en het beleid van IenM, die op hun beurt weer worden geconcretiseerd in de producten, diensten en de inrichting van de processen van IenM. In het kader van de Bedrijfsarchitectuur kan het Ministerie, conform een bedrijf, als volgt worden beschouwd: “Het Ministerie van IenM produceert producten en diensten. Voor het produceren van deze producten en diensten zijn bedrijfsprocessen ingericht. Voor het uitvoeren van deze processen is een organisatie ingericht”. In de beschrijving van de Bedrijfsarchitectuur worden de ‘Organisatie’, de ‘Processen’ en de ‘Producten en Diensten’ belicht.

2.2

Organisatie Het ministerie van Infrastructuur en Milieu (IenM) is in 2010 ontstaan door de samenvoeging van de ministeries van Volkshuisvesting, Ruimtelijke Ordening en Milieu (VROM) en Verkeer en Waterstaat (VenW). Het ministerie van IenM heeft de zorg voor verkeer, ruimtelijke indeling, water- en milieubeheer. IenM heeft 3 primaire hoofdfuncties: beleidsontwikkeling, uitvoering en inspectie. De beleidsontwikkeling is georganiseerd in 3 directoraten-generaal, namelijk het DG Milieu en Internationaal, het DG Ruimte en Water en het DG Bereikbaarheid. Beleidsuitvoerende taken zijn binnen IenM belegd bij de agentschappen: KNMI; Rijkswaterstaat; de Inspectie voor Leefomgeving en Transport (ILT).

Pagina 17 van 57


Daarnaast maken de volgende zelfstandige bestuursorganen (ZBO) deel uit van het ministerie: Nederlandse Emissieautoriteit (NEa); Rijksdienst Wegverkeer (RDW); Kadaster; Planbureau voor de Leefomgeving (PBL). 2.2.1

Missie van IenM Er is een perspectief dat richting geeft aan de keuzes die IenM maakt. Dit zijn de hoofdlijnen van de missie van het ministerie; het geeft richting aan de verdere ontwikkeling en vormt tevens de basis voor de richtinggevende architectuur zoals deze voorligt. De missie geeft invulling aan de vragen: waarom bestaat IenM, waar gaat en staat IenM voor en welke onderscheidende kwaliteiten heeft IenM? H ET

MINISTERIE VAN

I NFRASTRUCTUUR

EN

MILIEU

ZET IN OP LEEFBAARHEID EN

BEREIKBAARHEID , MET EEN GOEDE DOORSTROMING IN EEN SCHONE EN VEILIGE

OMGEVING .

H ET

MINISTERIE WERKT AAN KRACHTIGE VERBINDINGEN OVER DE WEG ,

HET SPOOR , HET WATER EN DOOR DE LUCHT , BESCHERMT TEGEN WATEROVERLAST EN

BEVORDERT DE KWALITEIT VAN LUCHT EN WATER .

I NFRASTRUCTUUR

2.2.1.1

EN

VLOT , VEILIG MILIEU .

EN LEEFBAAR : DAT IS

Vlot - Veilig - Leefbaar

IenM verbindt deze begrippen en belangen. In concrete situaties kunnen deze belangen op gespannen voet staan met elkaar; IenM zal zich telkens moeten presenteren in heldere waardeoriëntaties en afwegingen. De samenhangende benadering van ‘infrastructuur en milieu’ dwingt daartoe. Vlot Bereikbaarheid is een voorwaarde voor economische en sociale ontwikkeling. Bereikbaarheid is een nationale opgave, maar IenM maakt daarbinnen regionaal maatwerk mogelijk. IenM zorgt samen met andere private en publieke partijen voor verbetering van verbindingen in het vervoer van personen en het transport van goederen. IenM houdt Nederland in beweging. Bij de bereikbaarheid is de samenhang tussen weg, spoor, water en lucht van belang. IenM investeert met name in de gebieden waar de meeste mensen wonen en werken. Daarnaast is een betere benutting van de capaciteit van de netwerken nodig. Veilig IenM investeert in het veilig leven met water, veiligheid op de weg, het spoor, het water en in de lucht. De (rijks)overheid kan de burger niet tegen elk risico beschermen, IenM zal in bepaalde mate normen stellen en handhaven zodat risico’s worden beperkt. Uiteindelijk zijn dat politieke keuzes. Veiligheid heeft ook te maken met toezicht. Toezicht zal steeds meer op basis van vertrouwen worden ingericht. Goed presterende bedrijven kunnen rekenen op een lagere frequentie van inspecties, terwijl slechte nalevers extra in de gaten gehouden worden. Leefbaar IenM werkt aan de leefbaarheid van het land en zet zich in voor schoon water, schone lucht en bodem en een acceptabel geluidsniveau. IenM stelt normen en handhaaft die. Bij alle beslissingen over ruimte, infrastructuur, mobiliteit en waterbeheer zoekt IenM naar een goede balans met de leefbaarheid van Nederland. Immers schone lucht, water en bodem zijn een basis voor welzijn en welvaart. Leefbaarheid is gebaat bij maatwerk. De regionale ruimtelijke verschillen nemen toe. De verschillende ontwikkelingen leiden tot variërende ruimtelijke opgaven in de regio’s. Een ’one size fits all’-benadering is niet meer toereikend. IenM geeft daaraan een vervolg met de omslag naar decentralisatie en deregulering.

Pagina 18 van 57


2.2.1.2

Keuzes maken

IenM schept ruimte voor inbreng van anderen; IenM werkt samen, laat zaken over aan anderen omdat die er beter toe in staat zijn. IenM wil kracht tonen en moet tegelijk haar organisatie goedkoper maken. Daarom is IenM selectiever in wat er wel en niet gedaan wordt. Er worden keuzes gemaakt. En daarbij wordt maximaal gebruik gemaakt van de synergie die in het IenM-beleidsdomein voorhanden is. Het betekent dat IenM haar rol, positie en bijdrage in het beleidsveld scherper zal kiezen. En dat IenM soms zaken niet meer doet en de contacten en relaties met sectoren in het beleidsveld zal herijken. Er wordt ingezet op het voorkomen en waar mogelijk opruimen van bestuurlijke drukte in de maatschappelijke stelsels waar IenM een rol in speelt (bijv. omgevingsrecht). Ook binnen het departement wordt dit principe toegepast. In de IenM-organisatie zijn en worden verantwoordelijkheden helder een eenduidig belegd zodat duidelijk is ‘wie erover gaat’. In de opzet van de organisatie worden allerlei vormen van interne coördinatie zo veel als mogelijk vermeden.

2.2.1.3

Van buiten naar binnen

IenM is er voor de Nederlandse samenleving en maatschappij. IenM staat in een voortdurende, levendige en veelvormige verbinding met die samenleving. Oog en oor voor burgers, ondernemers en gebruikers van de ruimte. Sensitief voor trends en ontwikkelingen. Scherp en helder in het formuleren van de maatschappelijke vraagstukken en problemen in het beleidsveld. Uitnodigend en ontvankelijk voor inzichten en oplossingsbijdragen van ‘buiten’. De rol van de (rijks)overheid verandert. Er komt meer betrokkenheid van private partijen in publieke zaken of burgers en bedrijven nemen verantwoordelijkheden over. De overheid is niet alleen verantwoordelijk voor maatschappelijke vraagstukken en kan deze zeker niet alleen oplossen. IenM gaat meer sturen op doelen en een scherpe formulering van het maatschappelijke vraagstuk of probleem. De kracht en kennis van anderen wordt benut voor het formuleren van oplossingen. Er wordt samen gewerkt met bedrijven, burgers, andere overheden en andere landen. De maatschappelijke doelen en problemen worden concreet gemaakt en (markt)partijen wordt de mogelijkheden geboden om mee te praten en oplossingen aan te dragen. Van eOverheid naar iOverheid Het biometrische paspoort, de Verwijsindex Risicojongeren, het Elektronisch Patiëntendossier, nationale en internationale gegevensuitwisseling tussen organisaties en het gebruik van digitale profielen van burgers: deze en vele andere toepassingen staan beleidsmakers en uitvoerders ter beschikking dankzij de inzet van ICT. Maar wat betekent de inzet van ICT in beleid en uitvoering voor de relatie tussen overheid en burgers? Wat zijn de gevolgen voor het functioneren van de overheid zelf? Hoe wordt in het proces van voortgaande digitalisering een afweging gemaakt tussen beginselen als veiligheid, privacy, efficiëntie en transparantie? De alomtegenwoordige inzet van ICT heeft ervoor gezorgd heeft dat niet langer sprake is van een eOverheid, gericht op dienstverlening en gebruikmakend van techniek, maar van een iOverheid, naast dienstverlening met informatiestromen en netwerken ook gericht op controle en zorg. Deze iOverheid heeft vergaande gevolgen en vraagt om een paradigmawisseling van eOverheid naar iOverheid. Andere overheden IenM geeft ruimte aan andere overheden en is helder over verantwoordelijkheden en verwachtingen. Er wordt professioneel samen gewerkt en informatie gedeeld, zonder elkaar voor de voeten te lopen. Internationaal IenM is een deel van de Nederlandse rijksdienst. De inspanningen zijn dus in de eerste plaats gericht op resultaten voor Nederland. Maar hiervoor is een internationale oriëntatie cruciaal; geen enkel beleidsveld is beperkt tot de Pagina 19 van 57


landsgrens. Een leefbaar Nederland is alleen mogelijk in een leefbare wereld; bereikbaarheid heeft ook een mondiale betekenis. De internationale context van IenM is onmiskenbaar en veelzijdig. Maar ook in internationaal verband is IenM selectief; er zal meer gebruik worden gemaakt van de inzet van andere landen en IenM zal niet meer op alle momenten in alle relevante internationale fora aanwezig zijn. Samengevat leidt dit tot de volgende keuzes: IenM kiest en concentreert zich op de kernbegrippen: bereikbaarheid, veiligheid en leefbaarheid IenM maakt ruimte voor anderen en creëert ruimte om met belangen om te gaan. IenM maakt maximaal gebruik van de synergie in het IenM beleiddomein IenM is selectief in wat we doen en niet meer doen. IenM zet in op voorkomen en waar mogelijk opruimen van bestuurlijke drukte in de maatschappelijke stelsels waar IenM een rol in speelt. IenM heeft oog en oor voor burgers,ondernemers en gebruikers van de ruimte. IenM is uitnodigend en ontvankelijk voor inzichten en oplossingsbijdragen van ‘buiten’ IenM gaat meer sturen op doelen en een scherpe formulering van het maatschappelijke vraagstuk of probleem. IenM benut de kracht en kennis van anderen voor oplossingen IenM werkt samen met bedrijven, burgers en andere overheden IenM geeft ruimte aan andere overheden en is helder over verantwoordelijkheden en verwachtingen IenM hanteert concrete efficiëntie maatregelen waaronder het opheffen van dubbele functies en taken, versoberen van taken en elders beleggen van taken wanneer nodig: o internationaal niet meer overal en altijd aanwezig (‘lege stoel’) o meer overlaten en overdragen aan andere overheden (‘decentralisatie ruimtelijk beleid’) o markt: geen zorg voor iedereen en een selectief sectorbeleid o betrek markt bij oplossingen voor gestelde doelen o burger: keuze en/of risico bij burger (buitendijks wonen) Naast deze doelstellingen gelden concrete efficiëntie maatregelen die richtinggevend zijn voor IenM: Opheffen van dubbele functies en taken; Versoberen van taken; Taken elders beleggen (bijvoorbeeld bij gemeente en provincie). 2.2.2

Informatieplannen Kennis en informatievoorziening wordt steeds belangrijker. De informatievoorziening vormt steeds meer een integraal onderdeel van het primaire proces en is niet meer los te koppelen van de beleidsontwikkeling. Daarbij neemt het aantal toepassingsmogelijkheden van ICT nog altijd toe. Een goede informatievoorziening, die slim en doelmatig wordt toegepast, kan helpen om de beleidsontwikkeling en realisatie efficiënter en effectiever te maken. Maar een goede informatievoorziening wordt ook steeds complexer en duurder. Een goede sturing op informatievoorziening is dus vereist. Per DG is daartoe een Coördinerend Directeur Informatievoorziening (CDI) aangesteld. Een CDI coördineert de informatievoorziening en zet de lijnen uit naar de toekomst. De CDI is namens het DG deelnemer aan de Stuurgroep IV onder leiding van de CIO. Per DG is ook een Informatiemanager aangesteld. Een informatiemanager adviseert en ondersteunt het DG bij het inzetten van informatievoorziening om beleidsdoelen te realiseren. De informatiemanager beheert het portfolio aan I-Activiteiten en stemt deze maandelijks af met de CDI als voorportaal richting de Stuurgroep IV. De Top-I Pagina 20 van 57


projecten van het directoraat worden afgestemd met de CIO van de Bestuurskern en over de grootste en meest risicovolle Top-I projecten wordt aan de Minister gerapporteerd. Per DG wordt een Informatiebeleidsplan voor een periode van ca. 3 jaar opgesteld. Het informatiebeleidsplan geeft een overzicht van projecten en beschrijft hun onderlinge samenhang. Daarnaast worden de randvoorwaarden, kaders en richtlijnen op het gebied van informatievoorziening benoemd en wordt beschreven waar de DG met haar informatievoorziening over een paar jaar wil staan. In het plan worden ook in- en externe invloeden beschreven en keuzes voorgelegd waar prioriteit aan kan worden gegeven. 2.2.3

Directie Concern Informatievoorziening Binnen de Rijksoverheid is een trend naar het inzetten van de markt gaande. Hierin worden externe bedrijven ingezet voor de taken die zich daarvoor lenen. Ook op het gebied van informatievoorziening is deze beweging al geruime tijd zichtbaar. Optimaal benutten van de markt is complex en vergt inspanning en expertise. Binnen IenM wordt deze regierol vervuld door de Directie Concern Informatievoorziening. De gebruikersorganisatie moet daarbij aangehaakt blijven om haar behoefte aan te geven en business cases vast te stellen. De missie van DCI is als volgt geformuleerd: DCI

DRAAGT BIJ AAN DE DOELSTELLINGEN VAN

I EN M

DOOR HET REALISEREN VAN DE

BENODIGDE INFORMATIEVOORZIENING EN BIJPASSENDE

ICT

OPLOSSINGEN

Voor dit realiseren van de benodigde informatievoorziening en de bijpassende ICT oplossingen wordt gebruik gemaakt van het ‘Werken onder Architectuur’, zoals dit is beschreven in paragraaf 1.3. Het werken onder architectuur wordt gedreven vanuit de volgende architectuurvisie. A RCHITECTUUR

MAAKT EEN PASSENDE , FLEXIBELE EN EFFICIËNTE

INFORMATIEVOORZIENING VOOR

I ENM,

HAAR MEDEWERKERS EN KETENPARTNERS

MOGELIJK

Passende informatievoorziening voldoet aan de eisen, wensen en verwachtingen van medewerkers en ketenpartners van IenM en nodigt uit tot gebruik in plaats van dit af te dwingen. Flexibiliteit heeft, naast een informatievoorziening die snel aangepast kan worden aan veranderde omstandigheden, betrekking op aspecten als plaats-, tijd- en apparaatonafhankelijk werken en het kunnen verzamelen, ordenen en delen van alle relevante informatie. Efficiëntie geldt zowel voor de inzet van de beschikbare tijd, geld en capaciteit, als voor het optimaal gebruik van de geboden voorzieningen door de medewerkers en de ketenpartners. Op basis van deze visie wordt door het Architectuurteam van DCI de volgende strategie bij het werken onder architectuur gehanteerd: Architectuur creëert en onderhoudt het inzicht in de informatievoorziening van IenM; Architectuur brengt de samenhang en afhankelijkheden in de bestaande informatievoorziening van IenM en de ontwikkelingen die daarop van invloed zijn in beeld; Architectuur geeft sturing aan veranderingen in de informatievoorziening (in de vorm van projecten) van IenM.

Pagina 21 van 57


Met het oog op de in paragraaf 1.5 beschreven scope van IMEA vindt dit in overleg en afstemming met de architectuurrol binnen de diverse organisatieonderdelen van IenM plaats. 2.3

Processen Zoals in het voorgaande is beschreven bestaat het doel van IenM uit het sturen van het gebruiken en veranderen van de fysieke leefomgeving en het voorkomen van de schadelijke gevolgen voor mens en milieu door het gebruiken en veranderen. In het het proces waarbinnen dit plaatsvindt staat IenM niet alleen, maar vormt het een schakel in dit ‘ketenproces’. Op het beleidsterrein van de fysieke leefomgeving zijn binnen Nederland naast IenM tal van organisaties betrokken, zoals ministeries, provincies, gemeenten, waterschappen en RUD’s. Binnen een beleidsterrein worden twee hoofdtaken onderscheiden: het stellen van doelen, de beleidsbepaling en het realiseren van gestelde doelen, de beleidsrealisatie. De toedeling van deze taken aan organisaties is in de wet geregeld. De beleidsbepaling Nederland-breed is toebedeeld aan IenM. Beleidsbepaling is ook toegedeeld aan andere ministeries, provincies, gemeenten en waterschappen, maar dan beperkt tot de hen binnen dit beleidsterrein gegeven beleidsruimte en het eigen ambtsgebied. Tijdens de beleidsbepaling wordt nieuw beleid ontwikkeld en worden keuzes gemaakt welke beleidsinstrumenten worden ingezet om dat nieuwe beleid te realiseren. Die instrumenten zijn onder andere communicatie, subsidie, certificering, convenanten, wettelijke regeling, meldingen en vergunningen. De toedeling van de beleidsbepaling Nederland-breed betekent dat IenM ook verantwoordelijk is voor de beleidsbepaling en beleidsrealisatie binnen haar beleidsterrein. De taak beleidsrealisatie is een samenstel van drie andere taken: uitvoering, toezicht en handhaving. Ook deze taken zijn toebedeeld aan IenM, andere ministeries, provincies, gemeenten en waterschappen, maar beperkt tot de eigen taak en het eigen ambtsgebied. Wat handhaving betreft heeft genoemde toedeling betrekking op de bestuursrechtelijke handhaving, de strafrechtelijke handhaving is belegd bij het Openbaar Ministerie, de Politie en bijzondere opsporingsdiensten. In de uitvoering worden de gekozen beleidsinstrumenten toegepast, in het toezicht wordt beoordeeld of de regels en instrumenten goed worden toegepast en in de handhaving wordt zo nodig een goede toepassing afgedwongen. De taken beleidsbepaling, uitvoering, toezicht en handhaving zijn zowel onafhankelijk als afhankelijk van elkaar. Onafhankelijk omdat de taken in de wet aan organisaties zijn toebedeeld, afhankelijk vanwege het feit dat wanneer er voor nieuw beleid geen beleidsinstrumenten worden ingezet, er ook geen uitvoering, toezicht en handhaving nodig is. Andersom is er geen goede uitvoering, toezicht en handhaving (mogelijk) wanneer het nieuwe beleid niet of ten dele gerealiseerd wordt. In de volgende afbeelding is het proces van beleidsbepaling, uitvoering, toezicht en handhaving, de onderlinge samenhang en de taken daarbinnen weergegeven.

Figuur 8: Ketenproces Pagina 22 van 57


De volgende taken worden binnen een beleidsterrein onderscheiden: Beleidsbepaling. Stellen van doelen en bepalen van de instrumenten en de organisatie om de gestelde doelen te realiseren. Uitvoering. Beoordelen op basis van de ingediende informatie of een handeling of zaak voldoet aan de gestelde eisen en het daarna nemen van een besluit daarover. Toezicht. Verzamelen van informatie over de vraag of een handeling of zaak voldoet aan de gestelde eisen en het daarna vormen van een oordeel daarover. Handhaving. Een keten van activiteiten gericht op het (alsnog) laten voldoen van een handeling of zaak aan de gestelde eisen. 2.4

Producten en Diensten Vanuit de verantwoordelijkheid voor beleidsrealisatie binnen haar beleidsterrein biedt IenM producten en diensten aan burgers, bedrijven, bevoegd gezag organisaties en medebehandelende organisaties. Aan de hand van het voorbeeld Omgevingsloket Online (OLO), is in de volgende figuur weergegeven waar het aanbieden van dergelijke producten en diensten een ‘plek’ heeft en wordt dit vervolgens toegelicht.

Figuur 9: Producten en Diensten Voorbeeld Omgevingsloket Burgers en bedrijven kunnen in het Omgevingsloket nagaan (checken) of er op basis van de Waterwet en de Wabo een vergunning en/of melding nodig is en, als dat het geval is kunnen ze deze in het loket opstellen en digitaal indienen (groen gearceerd). Bevoegd gezag organisaties en de mede-behandelende organisaties kunnen uit de OLO samenwerkingsruimte ingediende aanvragen en meldingen overhalen naar het eigen behandelsysteem. De samenwerkingsruimte kunnen zij ook gebruiken voor het uitwisselen van aanvragen, meldingen en bijbehorende bijlagen (rood gearceerd). De producten die in dit voorbeeld en rol spelen zijn: Uitkomst check. Document met alle tijdens checken beantwoorde vragen en ingevulde antwoorden en de daarop gebaseerde conclusie of en voor welke handelingen een vergunning en/of melding nodig is. Concept Vergunningaanvraag. Nog niet ingediend verzoek om toestemming om voorgenomen handelingen te mogen verrichten. Concept Melding. Nog niet ingediende mededeling voorgenomen handelingen te gaan verrichten. Vergunningaanvraag. Ingediend verzoek bestaande uit een ingevuld formulier en bijbehorende bijlagen.

Pagina 23 van 57


Melding. Ingediende mededeling bestaande uit een ingevuld formulier en bijbehorende bijlagen. 2.5

Bedrijfsarchitectuur Principes Zoals in paragraaf 1.4.2 beschreven is IMEA gebaseerd op NORA en MARIJ. NORA bevat tien basisprincipes die betrekking hebben op dienstverlening. Het begrip 'dienst' omvat hier alle activiteiten waarmee dienstverleners publieke taken uitvoeren. Het uitgangspunt is dat de afnemers (burgers, bedrijven en andere overheidsorganisaties) in de dienstverleningsrelatie centraal staan. NORA P RINCIPES Burgers, bedrijven en overheidsorganisaties (afnemers); N1: ...krijgen de dienstverlening waar ze behoefte aan hebben; N2: ...kunnen de dienst eenvoudig vinden; N3: ...hebben eenvoudig toegang tot de dienst; N4: ...ervaren uniformiteit in de dienstverlening door het gebruik van standaardoplossingen; N5: ...krijgen gerelateerde diensten gebundeld aangeboden; N6: ...hebben inzage in voor hen relevante informatie; N7: ...worden niet geconfronteerd met overbodige vragen; N8: ...kunnen erop vertrouwen dat informatie niet wordt misbruikt; N9: ...kunnen erop vertrouwen dat de dienstverlener zich aan afspraken houdt; N10: ...kunnen input leveren over de dienstverlening.

In MARIJ zijn deze principes verder geconcretiseerd en van toepassing op IenM en de andere departementen als onderdeel van de Rijksdienst. De fundamentele principes uit MARIJ zijn:

MARIJ P RINCIPES M1: De bestuursdepartementen ontwikkelen zich in de richting van een ‘concern’, bestaande uit meerdere divisies; M2: Doelmatigheid en doeltreffendheid staan voorop; M3: Informatie wordt – voor zover wettelijk mogelijk – op een transparante, actuele en betrouwbare wijze ontsloten voor publiek gebruik (aandacht voor de beschikbaarheid, exclusiviteit en integriteit); M4: De informatiehuishouding dient aan te sluiten op de afspraken over de informatiehuishouding van de Europese Unie; M5: Waar mogelijk worden gemeenschappelijke voorzieningen ontwikkeld en exclusief toegepast; M6: In de organisatie wordt gestreefd naar optimale aansluiting met het betreffende beleidsterrein en de gewenste uitvoering door de betreffende uitvoeringsorganen; M7: Flexibele inzetbaarheid en mobiliteit van ambtenaren wordt optimaal ondersteund; M8: Overdaad aan regels wordt teruggedrongen.

Pagina 24 van 57


Op basis van de beoogde bijdrage aan de realisatie van de doelstellingen van IenM en de wijze waarop dit in de visie van DCI en het daarvan onderdeel uitmakende architectuurteam worden de volgende richtinggevende Bedrijfsarchitectuur principes voor de informatievoorziening van IenM gehanteerd: Duurzaam (BP1) De informatievoorziening van IenM is duurzaam - flexibel en toekomstvast vormgegeven. Kostenefficiënt (BP2) IenM richt haar informatievoorziening op een kostenefficiënte manier in. De kosten moeten in verhouding staan met (de kwaliteit van) de geleverde diensten en producten en daarnaast marktconform zijn. Doelmatig (BP3) De informatievoorziening van IenM is op een doelmatige en veilige wijze vormgegeven. Milieubewust (BP4) Milieubewustzijn is vanzelfsprekend. Ook binnen de informatievoorziening van IenM worden milieubewuste eisen gesteld en keuzes gemaakt. Plaats-, tijd- en apparaatonafhankelijk (BP5) De informatievoorziening van IenM biedt zo veel mogelijk ondersteuning voor het plaats-, tijd- en apparaatonafhankelijk werken. Deze Bedrijfsarchitectuur principes vormen in feite de basis, het vertrekpunt voor de wijze waarop de Informatie en Technische Architectuur is vormgegeven en welke principes daarin leidend zijn. De onderstaande figuur geeft deze samenhang tussen de principes in de diverse architectuurlagen van IMEA weer.

Figuur 10: Samenhang Architectuurprincipes De principes worden in hoofdstuk 5 verder uitgewerkt en onderbouwd.

Pagina 25 van 57


2.6

Service Gerichte Architectuur Flexibiliteit, wendbaarheid, efficiency, kostenbesparing en hergebruik zijn belangrijke kernwoorden bij het realiseren van de informatievoorziening die bijdragen aan de doelstellingen van IenM. Een belangrijke voorwaarde om dit doel te bereiken is het zodanig ontwerpen en realiseren van informatiesystemen, dat het mogelijk wordt om (delen van) deze informatiesystemen te hergebruiken ter ondersteuning van meerdere, verschillende processen, of voor andere voorzieningen en applicaties. Applicaties kunnen in drie delen (lagen) omschreven worden: • Een presentatielaag (dat wat je ziet op je apparaat). • Een functionele laag of servicelaag (dat wat je niet ziet maar onder de motorkap van de applicatie allemaal plaatsvindt). • Een technische laag (waar o.a. dataopslag plaatsvindt). Het overgrote deel van de applicaties binnen IenM (en de Rijksoverheid) zijn als monolithisch systeem gebouwd: de presentatie, functionele en technische laag zitten in ‘black box’ opgesloten. Daarmee is het onmogelijk om delen van de applicatie, bijvoorbeeld bepaalde functionaliteiten of gegevens, ook voor andere applicaties te (her)gebruiken of op andere apparaten beschikbaar te stellen. De gewenste flexibiliteit kan worden gerealiseerd door toepassing van de Service Gerichte Architectuur (SGA). In een Service Gerichte Architectuur wordt het proces losgekoppeld van de functionaliteit en is deze functionaliteit weer ontkoppeld van de technologie. Een informatiesysteem wordt niet langer ontwikkeld en gezien als een op zichzelf staand geheel dat los van andere informatiesystemen functioneert, maar als een samenstel van zogenaamde services. Een service is een zelfstandig stukje functionaliteit, met een goed gedefinieerd en gestandaardiseerd koppelvlak en is technologie neutraal, waardoor informatiesystemen met verschillende onderliggende technieken samen kunnen werken. Door die onafhankelijkheid kan in een afnemend systeem een service eenvoudig vervangen worden door een nieuwe versie van dezelfde service of door een nieuwe service. Dit geeft flexibiliteit bij het inrichten en aanpassen van systemen. Daar het te ver voert om dit onderwerp in het IMEA hoofddocument uitgebreid te bespreken, is in een IMEA katern [KSGA] een uitgebreide beschrijving en toelichting op het Service Gerichte Architectuur concept opgenomen. Bij toekomstige applicatieontwikkelingen wordt met behulp van IMEA uitdrukkelijk gestuurd op het toepassen van de principes van de service gerichte architectuur. In de navolgende hoofdstukken zullen kort de invloeden hiervan op de Informatie en de Technische Architectuur worden belicht.

Pagina 26 van 57


3

Informatiearchitectuur

De Informatiearchitectuur betreft de invulling van de middelste laag van het architectuurraamwerk in de NORA. 3.1

Inleiding In dit hoofdstuk richten we ons op de bedrijfsmatige (functionele) aspecten van de applicaties ofwel informatiefuncties. De zogenaamde ‘wie’ dimensie. Er wordt onderscheid gemaakt tussen primaire applicaties en ondersteunende applicaties. Daarnaast zijn er steeds meer applicaties opgebouwd uit kleine modulaire onderdelen, zogenaamde software componenten, die middels webservices ofwel API’s (Application Programming Interface) ontsloten worden. Bij de ‘wat’ dimensie ligt de focus op de informatie en de betekenis hiervan. Hierbij wordt onderscheid gemaakt tussen gestructureerde informatie en minder gestructureerde informatie. In beide gevallen gaat het om de semantiek (begrippen, definities, classificaties) en syntax (vorm, structuur, opmaak) van de informatie en de meta-informatie (informatie over informatie). Een verzameling geformaliseerde begrippen en hun relaties voor een bepaald domein is een informatiemodel. Een informatiemodel maakt het eenduidig vastleggen en uitwissel van elektronische berichten mogelijk. ‘Hoe’ is de derde en laatste dimensie. Hier gaat het om de wijze waaop de informatie-uitwisseling plaatsvindt. Dit is vaak afhankelijk van het bedrijfsdomein. Ieder domein heeft een eigen model c.q. standaarden of voorschriften, zoals bijvoorbeeld ebXML en UBL voor e-facturen.

3.1.1

Scope De Informatie-architectuur is gericht op de inrichting van de informatievoorziening middels informatiefuncties, gegevens en de informatie-uitwisseling op een zodanige wijze dat deze inrichting flexibel - eenvoudig aanpasbaar en/of uitbreidbaar – is, zodat deze past en blijft passen bij de dagelijkse werkzaamheden van IenM. Zowel voor de afzonderlijke organisaties als ook voor de ketens die door de diverse samenwerkingsvormen ontstaan (zie ook 2.3) worden specifieke architecturen opgesteld. Een dergelijke architectuur vereist de betrokkenheid van (keten)partijen buiten IenM.

3.1.2

Doelstelling In de bedrijfsarchitectuur is de inrichting van de primaire bedrijfsprocessen van IenM beschreven, waarbij de verschillende DG’s als zodanig herkenbaar zijn, maar waarbij tevens overeenkomsten zijn onderkend. Als basisgedachte geldt dat in essentie de verschillende DG’s vergelijkbare processtappen van de beleidscyclus doorlopen, waarbij de verschillen vooral bepaald worden door de inhoudelijke (beleids)aspecten. Voor deze stappen zijn informatiesystemen1 onderkend, waarmee de beleidsmedewerkers ondersteund kunnen worden. Op basis van de overeenkomsten zijn een aantal generieke informatiesystemen als zodanig onderkend en worden niet meermaals in de specifieke domeinen gepositioneerd, maar in een generiek domein. Op eenzelfde manier wordt in deze indeling omgegaan met belangrijke gegevensverzamelingen.

1

Informatiesystemen kunnen beschouwd worden als nog niet benoemde functionele applicaties. Pagina 27 van 57


Er bestaan een aantal knelpunten in de huidige IenM informatievoorziening en de ontwikkeling daarvan. Met IMEA, in de vorm van sturing op basis van de architectuur principes die in de navolgende paragrafen aan bod komen, worden deze knelpunten aangepakt. Eenduidige data ontbreekt Dezelfde gegevens worden in verschillende systemen bijgehouden. Gegevens zijn voortdurend in beweging. Als deze gegevens op verschillende plekken worden gemuteerd veroorzaakt dit inconsistenties. Het is noodzakelijk om eenduidige data te garanderen (de waarheid) door het inrichten van kernregistraties. Kernregistraties zorgen voor het eenduidig vastleggen en beheren van de kerngegevens van IenM. Deze kerngegevens krijgen hiermee een centrale plaats in de organisatie wat voordelen heeft bij hergebruik en het toewijzen van een eigenaar. Bestaande systemen schieten te kort De bestaande informatiesystemen schieten in veel gevallen tekort om de huidige en nieuwe dienstverlening en bedrijfsprocessen adequaat te ondersteunen. Bij IenM is in de afgelopen jaren een landschap van applicaties ontstaan dat als geheel niet optimaal functioneert. De complexiteit is enorm toegenomen. Het ontbreekt aan openheid, (op)deelbaarheid en koppelbaarheid waardoor de informatiesystemen niet goed geïntegreerd kunnen worden. Dat staat flexibiliteit en innovatie van dienstverlening en werkprocessen in de weg. Er is iets nodig om deze complexiteit te beheersen zodat IenM de wendbaarheid kan vergroten om de dienstverlening af te stemmen en betrouwbare informatie te leveren. Steeds complexere samenwerking Overheidsorganisaties richten zich steeds meer op hun eigen kerntaak, waarbij niet kerntaken afgenomen worden van andere overheidsorganisaties of -diensten. Dit geldt ook voor IenM (zie ook 2.2.1). Dit betekent dat steeds meer ontwikkelingen op afstand worden geplaatst. Dit vraagt om een andere manier van aansturen. Waar tot op heden vaak gestuurd werd op het inrichten van informatiesystemen verschuift de verantwoordelijkheid van IenM richting het bepalen hoe verschillende uitvoeringspartijen in de keten maximaal samenwerken en informatie uitwisselen. Een belangrijk aspect hierbij is hoe de interoperabiliteit wordt gewaarborgd. Interoperabiliteit is het vermogen van organisaties om effectief en efficiënt informatie te delen met elkaar en hun omgeving. Het gaat hierbij om informatiedeling tussen overheidsorganisaties, burgers en bedrijven. Interoperabiliteit werkt alleen als de gegevens ofwel uitgewisselde informatie aan kwaliteitskenmerken voldoen. Standaardisatie draagt bij aan interoperabiliteit. 3.2

Informatie-architectuur principes In de onderstaande tabel worden de Informatie-architectuur principes weergegeven. Deze worden in de navolgende paragrafen voor elk van de 3 dimensies uit de Informatie-architectuur laag gebruikt ter onderbouwing van de gemaakte keuzes. Afkortingen: IA = Medewerkers en Applicaties, IG = Berichten en Gegevens, IU = Informatie-uitwisseling.

IA01

Informatiesystemen zijn modulair samengesteld

IA02

Hergebruik voor kopen, voor ontwikkelen

IG01

Voor elk gegeven bestaat een eenduidige definitie

IG02

Elk gegeven heeft een eigenaar

IG03

Gegevens zijn voorzien van een locatie

IU01

Informatiesystemen worden ontsloten op basis van webservices

IU02

Koppelvlakken maken gebruik van open standaarden

Pagina 28 van 57


3.3

Medewerkers en Applicaties

3.3.1

Principes IA01: Informatiesystemen zijn modulair samengesteld

De informatievoorziening van IenM moet snel en eenvoudig aangepast kunnen worden aan veranderende behoeften (wendbaarheid), waarbij de nadruk ligt op hergebruik (kostenbesparing). De belangrijkste voorwaarde om deze doelen te bereiken is dat informatiesystemen zodanig opgebouwd zijn dat hergebruik van (delen van) de informatiesysteem ook daadwerkelijk mogelijk is.

Figuur 11: Van monolieten naar systemen samengesteld uit webservices Er moet daarom een verschuiving plaatsvinden van alles omvattende systemen, naar systemen samengesteld uit services. Dit zijn systemen opgezet op basis van servicegerichte architectuur (SGA) principes. In een SGA wordt gedacht in en gewerkt met services en is het denken in monolithische systemen losgelaten (zie ook 2.6). Een belangrijke voorwaarde is dat informatiesystemen zodanig opgezet zijn, dat hergebruik van (delen) hiervan mogelijk is en informatiemanagement en applicatiemanagement zodanig ingericht zijn dat de verschillende functionaliteiten herkenbaar zijn. Deze herkenbaarheid wordt vergroot door het vinden en hergebruiken van informatiefuncties zo laagdrempelig mogelijk te maken. IenM streeft ernaar om alle2 informatiefuncties als API beschikbaar te maken in een API store. Bij de aanschaf van nieuwe functionaliteit wordt niet alleen rekening gehouden met de specifieke probleemstelling van dat moment. De functionaliteit wordt ook als generieke oplossing, voor een algemener geformuleerd probleem beschouwd, zodat toekomstig hergebruik zonder aanpassingen mogelijk wordt. Dat betekent dat van tevoren al nagedacht wordt over (ont-)koppelpunten. Een belangrijk aspect hierbij is het servicecontract. Dit is een contract van een webservice waarin de afspraken zijn vastgelegd. Het contract is opgesteld in begrijpelijke taal en beschrijft een webservice in termen van: wat de webservice doet, input, output, mogelijke foutmeldingen, semantiek, service level agreement (SLA) en quality of service (QoS). Een contract kan elementen bevatten die specifiek zijn voor een bepaalde afnemer. Er staan ook niet-functionele eisen in zoals maximale responsetijd, beschikbaarheid, betrouwbaarheid, hoe de webservice omgaat met transacties en de intensiteit waarmee de webservice gebruikt mag worden. Vanuit het perspectief van een webservice afnemer beschrijft een contract alles wat de afnemer moet weten om de webservice te kunnen gebruiken. Informatiesystemen volgen dus een afbakening. Deze afbakening vereist dat de informatiesystemen op de (ont)koppelvlakken open interfaces aanbieden op een service georiënteerde wijze, zodat de onderlinge informatie-uitwisseling op basis van webservices kan plaatsvinden. Via deze (ont)koppelvlakken moeten ook de in de informatiesystemen geïmplementeerde informatiefuncties als zodanig onderscheiden kunnen worden. De informatiefuncties worden volgens het transactiemechanisme 2

In de praktijk betekent dit dat nieuwbouw of vernieuwing van een informatiesysteem plaatsvindt conform het servicegerichte architectuur concept, wanneer dit een bijdrage levert aan de genoemde doelstellingen zoals hergebruik, wendbaarheid en kostenbesparing. Deze afweging vindt bij elke nieuwbouw of vernieuwing plaats. Pagina 29 van 57


ontworpen, zodat ze als geheel succesvol kunnen worden afgerond (o.a. ten behoeve van consistentie van de gegevens) en zonder dat dat effect heeft op de andere informatiefuncties. Dit betekent onder meer dat alle mutaties van gegevens belegd moeten worden binnen één informatiesysteem. Door naar informatiesystemen te kijken als verzamelingen van informatiefuncties wordt het hergebruik gefaciliteerd, de integratiemogelijkheden vergroot en kostenbesparingen gerealiseerd zonder afbreuk te doen aan de gevraagde flexibiliteit en wendbaarheid van de informatievoorziening. Het beheer van deze informatiefuncties vraagt wel aandacht. Door het maken van een mapping van de bekende informatiefuncties op de bestaande informatiesystemen kunnen deze verder ontvlochten worden en wordt inzicht verkregen in de interne consistentie en redundantie in het huidige informatiesysteem landschap. IA02: Hergebruik voor kopen voor ontwikkelen

Bij ontwikkeling van een nieuw informatiesysteem wordt vanuit architectuur bewust gestuurd op hergebruik van bestaande informatiefuncties. Ook bij vernieuwing van informatiesystemen wordt functionaliteit pas ontwikkeld als hergebruik of kopen niet mogelijk is. Bij hergebruik wordt eerst gekeken of (passende) bestaande functionaliteit beschikbaar is als landelijk overheidsbouwsteen en dan als IenM informatiefunctie.

3.4

Berichten en Gegevens

3.4.1

Principes

IG01: Voor elk gegeven bestaat een eenduidige definitie

Voor alle gegevens bestaat een eenduidige definitie waarover overeenstemming is binnen de organisatie. Hierbij wordt gebruik gemaakt van een gemeenschappelijk uitwisselingsmodel, dat de gegevensdefinities beschrijft. Een uitwisselingsmodel ontkoppelt applicaties omdat alleen vertaling nodig is tussen een applicatie en het model. Voor het uitwisselen van informatie tussen applicaties is geen kennis nodig van elkaars gegevensdefinities en gegevensmodellen, omdat communicatie plaatsvindt op basis van het gemeenschappelijke uitwisselingsmodel. Dus geen vertaling tussen alle individuele formaten, maar een vertaling tussen elk formaat en het uitwisselingsformaat. Webservices ondersteunen het uitwisselingsmodel. Een domein kan een eigen uitwisselingsmodel hanteren. Voor het uitwisselen van gegevens tussen domeinen wordt vertaald tussen de verschillende uitwisselingsmodellen. Daarnaast zijn er domein overstijgende objecten die gelijk zijn voor elk domein. Domein specifieke objecten kunnen een uitbreiding zijn op domein overstijgende objecten. Objecten uit het specifieke domein refereren naar domein overstijgende objecten op basis van een unieke identificatie. IG02: Elk gegeven heeft een eigenaar (=bronhouder)

Gegevens zijn belangrijk voor IenM. Op het moment dat gegevens gebruikt worden is het van belang dat er vertrouwd kan worden op kwaliteitsaspecten zoals de actualiteit, betrouwbaarheid en integriteit van de gegevens. Het moet transparant zijn wie aangesproken kan worden op c.q. verantwoordelijk is voor de kwaliteit van de gegevens. Hiertoe wordt een eigenaar benoemd. Dit zorgt ervoor dat er bewuster wordt omgegaan met gegevensverzamelingen binnen de organisatie. De eigenaar heeft een proces ingericht dat het mogelijk maakt om te gaan met terugmeldingen over de kwaliteit.

Pagina 30 van 57


De afnemer kiest zijn gegevensbronnen en stelt eisen aan waardering en kwaliteit. Het is helder door wie welke gegevens worden gebruikt en voor welk doel. Eigenaarschap moet voor gegevensgebieden expliciet worden benoemd en belegd. Met een generieke invulling ten aanzien van wat dit betekent voor taken verantwoordelijkheden, procedures, e.d. Dit is vergelijkbaar met inrichten van functioneel beheer, maar dan op gegevens. IG03: Gegevens zijn voorzien van een locatie

Voor veel gegevens die in de informatievoorziening van IenM worden gebruikt, geldt dat deze locatie gebonden zijn. Op basis van de locatie is voor elke locatie inzichtelijk te maken welke processen daar actief zijn, bijvoorbeeld welk beleid er geldt, welke vergunningen ervoor zijn afgegeven en welke inspecties er zijn uitgevoerd. Processen kunnen op deze wijze beter op elkaar afgestemd en efficiënter ingericht worden. Ook is inzichtelijk welke gegevens over een bepaalde locatie beschikbaar zijn in de diverse informatiesystemen en -bronnen. De informatie op basis van deze gegevens kan zo beter worden benut. Locatie is dus een essentiële ingang tot het genereren van informatie uit verschillende processen en informatiesystemen. Bovendien is locatie een krachtig middel om de gegevens te visualiseren en daarmee toegankelijk te maken. Er zijn verschillende mogelijkheden om gegevens te voorzien van een locatie: Directe ruimtelijke referentie (georefereren): Informatie over een locatie koppelen aan de kaart op basis van coördinaten; Indirecte ruimtelijke referentie (geotaggen): informatie over een locatie koppelen aan de kaart, door deze te koppelen aan informatie met een indirecte ruimtelijke referentie, bijvoorbeeld aan postcode-huisnummer; Geen ruimtelijke referentie: Aan gegevens zonder ruimtelijke referentie kan bijna altijd een ruimtelijke referentie worden toegekend. Van vrijwel ieder cijfer kan een “gemiddelde per gemeente, provincie of land” worden gemaakt. Door gegevens te georefereren of geotaggen kan aangegeven worden op welk gebied deze betrekking hebben. Hierdoor wordt het wordt mogelijk om gegevens gebiedsgericht te ontsluiten. Op basis van het gebied wordt het mogelijk om gegevens (van verschillende bronhouders) die betrekking hebben op dit gebied terug te vinden en te tonen. Door gebruik te maken van geocoderen en reverse geocoderen is het mogelijk om tussen directe en indirecte ruimtelijke referenties te vertalen: Geocoderen: Het vinden van geografische coördinaten op basis van indirecte geografische informatie zoals straat, postcode, provincie. Op basis van geografische coördinaten kan informatie aan een gebied gekoppeld worden. Reverse geocoderen: Het vertalen van een geografische coördinaat naar indirecte geografische informatie zoals straat, postcode, provincie.

3.5

Informatie-uitwisseling

3.5.1

Achtergrond Systemen wisselen steeds vaker geautomatiseerd informatie uit met andere systemen, bijvoorbeeld met de basisregistraties. Een dergelijke informatieuitwisseling vindt plaats binnen de context van een proces. Een proces bestaat vrijwel altijd uit deelprocessen en interactieprocessen tussen deze deelprocessen. Het interactieproces tussen twee systemen wordt het koppelvlak genoemd. In de volgende figuur is een proces weergegeven met deel- en interactieprocessen, koppelvlakken en ondersteunende systemen.

Pagina 31 van 57


Figuur 12: Informatie-uitwisseling Bij de informatie-uitwisseling tussen overheidsorganisaties wordt gebruik gemaakt van overheidsstandaarden om de interoperabiliteit te waarborgen. Hierbij zijn afspraken nodig om te zorgen dat het koppelvlak interoperabel is, zoals Digikoppeling, Diginetwerk, PKIoverheid certificaten, StUF en informatie- en berichtmodellen. Digikoppeling is een overheidsbrede standaard voor informatie-uitwisseling tussen overheidsorganisaties. Het is gericht op de koppelvlakstandaarden en diverse ondersteunende diensten. Digikoppeling is verplicht bij informatie-uitwisseling tussen overheidsinstanties. Digikoppeling is geen centrale voorziening maar een set van afspraken; de implementatie van de informatie-uitwisseling op basis van de Digikoppeling afspraken is de verantwoordelijkheid van de partijen zelf.

Figuur 13: Overheidsstandaarden om interoperabiliteit te waarborgen IenM maakt onderscheid tussen interne en externe informatie-uitwisseling. Bij externe informatie-uitwisseling wordt aangesloten bij de overheidsstandaarden. Bij interne informatie-uitwisseling wordt gebruik gemaakt van een beperkte set van de overheidsstandaarden en waar nodig kan afgeweken worden om de berichtuitwisseling eenvoudiger te maken.

Figuur 14: Intern en extern koppelvlak Pagina 32 van 57


3.5.2

Integratiefuncties De informatiefuncties zorgen voor een modulaire opzet en ontkoppeling van informatiesystemen, waarbij gegevens worden uitgewisseld op basis van open standaarden. Dit leidt tot flexibiliteit, hergebruik, standaardisatie en efficientie. Wat bijdraagt aan een flexibelere informatievoorziening, die eenvoudiger aan te passen is aan een continue veranderende omgeving. De integratiefuncties richten zich primair op de logistiek van gegevensuitwisseling tussen systemen. IU01: Informatiesystemen communiceren op basis van webservices

Berichtuitwisseling gebeurt op basis van webservices. Door te communiceren op basis van webservices is de technologie waarmee deze webservices gerealiseerd worden niet van belang, omdat deze communiceren op basis van technologieneutraal protocol- en berichtenstandaarden. Dit zorgt voor ontkoppeling van informatiesystemen, vergroot de herbruikbaarheid van informatiefuncties en vereenvoudigd het uitwisselen van gegevens tussen informatiesystemen. IU02: Koppelvlakken maken gebruik van open standaarden

Alle applicaties en diensten spreken een gemeenschappelijke taal. Voor de koppelvlakken worden standaarden gebruikt voor zowel berichtformaat (bericht) als berichtinhoud (gegevensstructuren en definities). Dit zijn standaarden zoals het Referentiemodel Stelsel van Gemeentelijke Basisgegevens (RSGB) en Standaard Uitwisselings Formaat (StUF). Het gebruik van standaarden verhoogt de uitwisselbaarheid van gegevens tussen overheidsdiensten onderling en met derden. De keuze van standaarden kent de volgende volgordelijkheid: overheids-, open- en de facto standaarden. Bij het ontwerpen van systemen wordt rekening gehouden met een modulaire opzet van informatiefuncties en het gebruik van standaarden om ontsluiting en hergebruik te stimuleren. Bij gegevens moet rekening gehouden worden met definities en standaarden die binnen de overheid afgesproken zijn. Hierbij bieden de integratiefuncties ondersteuning bij de gegevensuitwisseling. De principes beschreven in paragraaf 3.3 en 3.4 zijn hierin leidend.

Figuur 15: Integratiefuncties

Pagina 33 van 57


De volgende integratiefuncties worden ondersteund: Protocollen: Ondersteuning voor zowel WUS (WSDL, UDDI en SOAP) als ebMS3 (Electronic Business Message Service). Bij interne communicatie wordt alleen WUS toegepast. Extern wordt WUS toegepast bij synchrone gegevensuitwisseling (vraag en direct antwoord) en ebMS voor asynchrone berichtuitwisseling (vraag en eventueel later een antwoord). Procescoordinatie: Het coordineren van het aanroepen van webservices, zodat het voor de afnemer als één samenhangend proces wordt ervaren (orkestreren). Transformeren: Vertalen tussen verschillende berichtstructuren (inhoud). Converteren: Vertalen tussen verschillende communicatieprotocollen (envelop). Routeren: Op basis van regels bepalen voor welk systeem een bericht bedoeld is (WS-Addressing). Betrouwbaarheid: Aflevergarantie zorgt er voor dat een bericht (eenmalig) en in de juiste volgorde wordt afgeleverd bij de juiste ontvanger (WS-RM). Transport: Verschillende transportprotocollen worden naast elkaar gebruikt. Afnemende systemen en webservices aanbiedende systemen kunnen verschillende transportprotocollen gebruiken. De integratiefunctie zorgt voor vertaling tussen de verschillende transportprotocollen. Beveiligen: Identificatie, authenticatie en autorisatie zorgen dat alleen geauthentiseerde en geautoriseerde afnemende systemen toegang hebben tot een webservice. Encryptie van gevoelige gegevens zorgt voor beveiliging op zowel transportniveau (SSL/TLS) als berichtniveau (WS-Security). Auditing: Informatie vastleggen zodat onweerlegbaar is dat een bericht is ontvangen van of verzonden naar een bepaalde organisatie. Integriteit: Tekenen van berichten zorgt dat de authenticiteit en integriteit van berichten gewaarborgd is en gecontroleerd kan worden dat een bericht onderweg niet gewijzigd is en afkomstig is van de juiste organisatie (WSSecurity). Monitoren: Event logging om het gebruik van services te monitoren en te rapporteren. Voor converteren en transformeren geldt dat interne systemen moeten voldoen aan de door IenM gehanteerde interne koppelvlakken. Dit betekent dat services afnemers en services aanbieders zelf moeten zorgen dat hun berichten hieraan voldoen.

3

ebMS is een protocol om de berouwbaarheid van berichtenuitwisseling te garanderen. Het regelt zaken zoals gegarandeerde aflevering, gegarandeerde volgorde van afhandeling en gegarandeerde eenmalige verwerking. Pagina 34 van 57


4

Technische Architectuur

De Technische Architectuur betreft de invulling van de onderste laag van het architectuurraamwerk in de NORA. 4.1

Inleiding In de technische architectuur wordt het functionele beeld, zoals dat in de Informatiearchitectuur is beschreven, vertaald naar een technisch beeld, een beschrijving van de technische vormgeving van de informatievoorziening van IenM. Het beschrijft hoe de ICT technologie is ingericht en wordt ingezet om de organisatieprocessen en de informatiebehoefte, zoals vastgelegd in de Bedrijfs- en Informatiearchitectuur, efficiënt en doelmatig te ondersteunen. Een beschrijving van de Technische Architectuur geeft inzicht en overzicht van het infrastructuur landschap. Toepassing van Technische Architectuur zorgt voor een gestructureerde, gestandaardiseerde en geconsolideerde set aan infrastructuurvoorzieningen. Tezamen maakt het een beoordeling mogelijk van nieuwe technologieën en de toegevoegde waarde en inpasbaarheid ervan, dient het als input voor oplossingsrichtingen en zorgt het voor beheersing van de kosten. Het biedt daarmee zowel management, projectleiders, leveranciers als technische specialisten en beheerders een goed handvat.

4.2

Meerdere ICT infrastructuren Het is goed daarbij bewust te zijn van het feit dat de informatiesystemen en ICT voorzieningen, waarmee de IenM informatievoorziening als geheel wordt vormgegeven, zijn gehuisvest in meerdere ICT infrastructuren, zelfs binnen de scope van IMEA (zie 1.5). De ICT dienstverlening en het beheer van deze ICT infrastructuren is uitbesteed bij meerdere partijen en leveranciers, zowel binnen als buiten de (rijks)overheid. De standaarden, technieken en methoden die ten aanzien van ICT technologie worden gehanteerd zijn niet bij c.q. voor al deze partijen gelijk en liggen ook niet altijd (geheel) in lijn met de Technische Architectuur in IMEA. Neemt niet weg dat IMEA – in ieder geval voor nieuwe ontwikkelingen - leidend is en er ook in bestaande c.q. ontstane situaties op basis van de inzichten uit IMEA nadrukkelijk op optimalisatie wordt gestuurd.

4.3

Kwaliteit Een belangrijk aspect van componenten uit de Technische Architectuur zijn de kwaliteitsattributen die beschrijven waar de componenten aan moeten voldoen c.q. welke prevaleren bij inrichtingskeuzes voor een IenM infrastructuur. De kwaliteitsattributen die grote invloed hebben op te maken keuzes zijn: Flexibiliteit (aanpasbaarheid en schaalbaarheid) Betrouwbaarheid (beschikbaarheid en beveiliging) Exploiteerbaarheid (beheerbaarheid en af- c.q. verrekenbaarheid) Bruikbaarheid (efficiency, effectiviteit en tevredenheid) De aanpasbaarheid bepaalt hoe gemakkelijk een verandering kan worden doorgevoerd en wordt bevorderd door het modulair opbouwen van een systeem. Schaalbaarheid geeft aan hoe eenvoudig capaciteit kan worden afgestemd op de behoefte. Daarbij moet rekening gehouden worden met alle componenten uit de keten, inclusief de koppelvlakken omdat daar (nieuwe) knelpunten kunnen optreden.

Pagina 35 van 57


De beschikbaarheid van een systeem of oplossing zegt iets over de tijdigheid, correctheid en functioneren ervan. De werking wordt daarbij afgezet tegen de gespecificeerde prestaties (bijvoorbeeld performance en bereikbaarheid). Veiligheid geeft een indicatie over de wijze waarop misbruik van een systeem wordt voorkomen. Beheerbaarheid betreft het operationeel houden van een systeem. Standaardisatie van tooling en beheerinterfaces vergroten het gemak waarmee dat mogelijk is. De verrekenbaarheid van een systeem bepaalt hoe gemakkelijk de gebruikerskosten te meten zijn en doorbelast kunnen worden. Tezamen met flexibiliteit geeft beheerbaarheid ook een indicatie voor de ‘uitbesteedbaarheid’ van een infrastructuur, een voor IenM belangrijk kenmerk ervan. Bruikbaarheid betreft de mate waarin een systeem gebruikt kan worden om effectief, efficiënt en naar tevredenheid de gespecificeerde doelen te bereiken. Daarnaast zijn tijd en geld twee belangrijke factoren die de kaders vormen voor de kwaliteitsattributen. 4.4

Modellering De Technische Architectuur van IenM geeft een invulling aan de onderste laag uit het architectuurraamwerk zoals beschreven in NORA, ofwel het 9-vlaksmodel (zie Figuur 4 in paragraaf 1.4.2). Voor de navolgende beschrijving is de technische architectuur laag uit NORA vertaald naar en meerlagenmodel zoals weergegeven in Figuur 16.

Figuur 16: Meerlagenmodel Technische Architectuur In deze representatie wordt, gelijk aan NORA, de opdeling in Technische Componenten, Opslag en Netwerk aangehouden inclusief Beveiliging en Beheer. Door het op deze aangepaste wijze te presenteren wordt de samenhang tussen de bouwstenen inzichtelijker gemaakt en kan deze ook makkelijker uitgelegd worden. De bouwsteen Technische Componenten is opgedeeld in de lagen Verwerking, Presentatie en Distributie en bestaan uit een logische verzameling van services op basis van de functies die geboden worden. Door de opdeling in lagen zijn de Pagina 36 van 57


toepassingen hierin minder complex en kan flexibeler worden omgegaan met toevoegingen en wijzigingen. De lagen in het model zijn verbonden door middel van de koppelvlakken Connectivity, back-end LAN en SAN. Dit laatste koppelvlak vormt de verbindingslaag met de bouwsteen Gegevens Opslag. Samen met de generieke lagen Beheer en Beveiliging wordt een integraal beeld van de Technische Architectuur van IMEA geschetst. In de volgende paragrafen wordt de Technische Architectuur beschreven aan de hand van de genoemde bouwstenen, lagen en koppelvlakken. Per bouwsteen, laag of koppelvlak zijn de bijbehorende architectuurprincipes, de specifieke uitgangspunten en de belangrijkste kenmerken beschreven. 4.5

Technische Componenten Het bouwblok Technische Componenten is opgebouwd uit de lagen verwerking, presentatie en distributie en deze lagen zijn verbonden door middel van koppelvlakken uit het bouwblok Netwerk. De lagen in de technische architectuur zijn opgebouwd op basis van generieke inrichtingsprincipes en –keuzes die leiden tot een flexibele, betrouwbare, beheerbare en kostenefficiënte omgeving en worden tevens bepaald door het Service Gerichte Architectuur concept [KSGA]. TC01: Een IenM ICT infrastructuur is gebaseerd op het Server Based Computing (SBC) principe. Centralisatie, consolidatie en virtualisatie maakt het efficiënt gebruik van resources mogelijk. Het beheer wordt minder complex (verhoogde betrouwbaarheid), de omgeving is flexibeler en hergebruik van kennis en middelen zorgt voor kostenvoordelen. Door toepassingen web- of serverbased aan te bieden ontstaat een flexibele en gecentraliseerde omgeving waarin wijzigingen snel gerealiseerd kunnen worden. Functionaliteit kan eenvoudig beschikbaar gesteld, verwijderd en beheerd worden en medewerkers zijn niet afhankelijk van één fysieke werkplek, een apparaat. Door centralisatie wordt ook efficiënter gebruik gemaakt van de beschikbare verwerkingscapaciteit. TC02: Reken- en opslagcapaciteit binnen een IenM ICT infrastructuur wordt gecentraliseerd en geconsolideerd aangeboden vanuit één4 rekencentrum. Dit rekencentrum is buiten een IenM locatie gehuisvest. Het gemeenschappelijk gebruik van algemene voorzieningen als beveiliging, ruimtes, opslag en backup leidt tot schaalvoordelen en het optimaal benutten van ingezette resources Ook het beheer op deze voorzieningen kan hierdoor gecentraliseerd worden en dat leidt tot een hogere betrouwbaarheid van de omgeving en tot kostenvoordelen. Daarnaast zijn maatregelen in het kader van de continuïteitstrategie zijn eenvoudiger en efficiënter te implementeren. Deze aspecten zijn belangrijke drijfveren voor het consolideren van de datacenters binnen de rijksoverheid, zoals dit plaatsvindt als onderdeel van het programma Compacte RijksDienst (CRD). TC03: Voor alle componenten van de Technische Architectuur wordt gebruik gemaakt van rijks-, open en de facto standaarden en bewezen technieken. TC04: Voor één type werkplek wordt één type hardware (lijn) ingezet. TC05: Voor een specifieke voorziening (platform, applicatie, functionaliteit) wordt één softwareproduct aangeboden. Van dat product is slechts één versie in gebruik. 4

Eventuele uitwijklocatie c.q. split datacenter niet meegerekend. Pagina 37 van 57


Standaardisatie op hardware, software en protocollen leidt tot eenvoudiger en efficiënter beheer van de omgeving. Het gebruik van standaarden zorgt er niet alleen voor dat gegevens onderling en met derden eenvoudig uitwisselbaar zijn, het levert ook schaal- en kostenvoordelen op in aanschaf, beheer en opleiding. Standaardisatie levert i.t.t. maatwerk ook een flexibelere omgeving op, waarbij wijzigingen niet tot nieuw maatwerk leiden. Het (her)gebruik van kennis uit de markt is kostenefficiënt, waarbij ondersteuning in de markt gewaarborgd is. TC06: Bij gelijke geschiktheid gaat de voorkeur uit naar Open Source producten. Inzet van Open Source producten is een Rijksbrede verplichting. De overheid streeft daarmee naar lagere kosten van software producten. IenM kijkt daarbij niet enkel naar licentie-, maar ook naar exploitatiekosten. Dit vormt tezamen met de functionele aspecten en de voorwaarde dat er voldoende kennis en ondersteuning in de markt beschikbaar is, het begrip ‘gelijke geschiktheid’. 4.5.1

Verwerkingslaag In de verwerkingslaag bevinden zich de bedrijfstoepassingen en de voor toepassingen benodigde middleware. In deze laag worden gegevens gecontroleerd en bewerkt en worden bedrijfsregels toegepast. Onderdeel van deze laag zijn: File & Print Mail & Kalender Applicatieservices Netwerkservices Databaseservices ESB

IdM

Voorzieningen t.b.v. het opslaan en delen van bestanden en het genereren van afdrukken Elektronische post- en agendavoorzieningen Voorzieningen voor aanbieden van functionaliteit Netwerkvoorziening voor ondersteuning van connectiviteit en routering Bewaren en bewerken van gestructureerde gegevens Een Enterprise Service Bus (ESB) is een infrastructuur component en is de technische backbone voor de geautomatiseerde informatie-uitwisseling en de daartoe benodigde functionaliteiten zoals dit in paragraaf 3.5.2 is beschreven en wordt hieronder nader toegelicht. Voorziening t.b.v. identificatie, authenticatie en autorisatie van gebruikers (zie ook 4.8.1)

Door het centraal aanbieden van de services in de verwerkingslaag kan de medewerker deze vanaf een willekeurige werkplek gebruiken. TC07: Voor zowel hardware (rekencapaciteit), alsmede software wordt het principe ‘virtualisatie, tenzij…’ gehanteerd. Belangrijke kwaliteitsattributen in deze laag zijn flexibiliteit en betrouwbaarheid. Bij het aanbieden van de verwerkingscapaciteit wordt gebruik gemaakt van hardware en applicatie virtualisatie. Dit biedt voordelen met betrekking tot de schaalbaarheid, aanpasbaarheid en beschikbaarheid: Extra verwerkingscapaciteit kan dynamisch en zonder tijdverlies beschikbaar worden gesteld; Beschikbare hardware wordt efficiënt gebruikt doordat diensten (services) niet gekoppeld zijn aan de fysieke, maar aan logische grenzen van de hardware; Verschillende omgevingen (Ontwikkel, Test, Acceptatie, Productie en Opleiding) en softwareversies kunnen naast elkaar werken, zonder elkaar te beïnvloeden. De ‘tenzij’ uit dit principe geldt uitsluitend wanneer een systeem of applicatie (technisch) niet geschikt is voor virtualisatie. 4.5.1.1

Enterprise Service Bus (ESB) en het Centraal Aansluitpunt

Zoals in paragraaf 4.2 is beschreven, is er sprake van meerdere infrastructuren waarin de informatiesystemen en ICT voorzieningen van IenM zijn opgenomen. Een Enterprise Service Bus (ESB) is een infrastructuur component, met als primaire taak Pagina 38 van 57


de betrouwbare informatie-uitwisseling tussen systemen c.q. aanbieders en afnemers. De IenM infrastructuren beschikken dan ook over één of meerdere ESB’s. Samen vormen deze ESB’s een stelsel dat de interne informatie-uitwisseling verzorgt met behulp van berichten. Interne systemen en ESB’s worden afgeschermd van de complexiteit van het koppelen met externe services door middel van een centraal aansluitpunt. Het centraal aansluitpunt faciliteert de informatie-uitwisseling met externe services. Het betreft zowel informatie-uitwisseling van binnen naar buiten als van buiten naar binnen. Met een centraal aansluitpunt wordt als het ware de complexiteit van het aansluiten met externe services geconcentreerd en daarmee, over het geheel bezien, gereduceerd: Het ontsluiten van basisregistraties is doeltreffender en goedkoper, omdat een externe koppeling maar eenmaal gelegd hoeft te worden. In het centraal aansluitpunt worden kennis en expertise gebundeld over basisregistraties, Digikoppeling, StUF, Diginetwerk, Digipoort, informatie- en berichtmodellen, etc. De inspanning om individuele systemen te koppelen worden lager, omdat de leveranciers van deze systemen niet hoeven te beschikken over de kennis en expertise van alle externe services. In de volgende figuur is de basisopzet van het stelsel van ESB’s met een centraal aansluitpunt weergegeven.

Figuur 17: Stelsel van ESB's en Centraal Aansluitpunt Vanuit het centraal aansluitpunt wordt bijvoorbeeld de koppeling met de basisregistraties één keer gelegd. Interne systemen koppelen via het stelsel van ESB’s met het centraal aansluitpunt. De services waarmee interne systemen basisregistraties bevragen stelt een eenvoudige vraag “Geef mij de gegevens behorende bij postcode huisnummer”. Dit vraagbericht gaat via het stelsel naar het centraal aansluitpunt. Het centraal aansluitpunt vertaalt dit interne vraagbericht naar een extern vraagbericht. Het ontvangen externe antwoordbericht wordt door het centraal aansluitpunt vertaald naar een eenvoudig intern antwoordbericht. Intern wordt gebruik gemaakt van een eigen informatiemodel met bijbehorend berichtenmodel.

Pagina 39 van 57


Domein specifieke koppelingen Als het centraal leggen van een koppeling niet bijdraagt aan doelstellingen zoals het bundelen expertise, het verhogen van de beheerbaarheid en flexibiliteit en het beperken van de afhankelijkheden van wijzigingen in (externe) koppelvlakken, wordt deze koppeling niet vanuit het centraal aansluitpunt gelegd, maar vanuit een ESB in het specifieke domein. Het direct koppelen vanuit een specifiek domein kan ook gewenst zijn vanwege het beperken van afhankelijkheden tussen domeinen, het lokaal houden van communicatie (beperken van de latency), of wanneer specifieke domeinkennis vereist is. Functionaliteiten Centraal Aansluitpunt Het centraal aansluitpunt beschikt over verschillende adapters. Deze adapters ondersteunen de overheidsbrede Digikoppeling protocollen ebMS en WUS, aangevuld met de Digikoppeling Grote Berichtenstandaard. Een andere adapter vertaalt interne berichten naar het Digikoppeling en StUF protocol en visa versa. Externe koppelingen die gebruik maken van Digikoppeling of StUF lopen altijd via het centraal aansluitpunt.

Figuur 18: Functionaliteiten Centraal Aansluitpunt Het centraal aansluitpunt biedt daarnaast nog aanvullende functionaliteit zoals het bijhouden van audit informatie5, archiveren van berichten, monitoren en het centraal opslaan van een kopie van basisregistratie-informatie. Deze centrale kopie wordt gebruikt indien een basisregistratie niet beschikbaar is of als de reactietijd bij het bevragen te lang duurt. 4.5.2

Presentatielaag De presentatielaag is verantwoordelijk voor alle visuele aspecten van de gebruikte toepassingen en biedt de gebruikers de mogelijkheid tot interactie met functionaliteiten die geboden worden door de onderliggende lagen. De presentatielaag is dè toegang naar alle andere lagen: de applicaties worden ontsloten en gepresenteerd aan de gebruikers en de werkplekken en andere in- en uitvoerapparaten in de distributielaag. Omdat de presentatielaag voor de gebruiker het toegangsportaal is tot de gegevens en bijbehorende functionaliteiten, zijn beschikbaarheid en beveiliging (betrouwbaarheid) belangrijke kenmerken. De gebruiker moet op ieder gewenst moment en bij voorkeur op eenduidige wijze toegang kunnen krijgen tot de voorzieningen in een IenM ICT infrastructuur en daarbij beschikken over de gegevens en functionaliteiten passend bij de functie en locatie van die gebruiker.

5

Welk systeem en/of persoon bevraagt een basisregistratie. Pagina 40 van 57


De presentatielaag wordt vormgegeven met (web)applicaties en apps (voor mobiele apparaten zoals tablets en smartphones). Daarbij wordt voor (web)applicaties het architectuurprincipe TC01 gehanteerd, gebaseerd op het Server Based Computing concept. Dit biedt grote voordelen op het gebied van schaalbaarheid, beheerbaarheid en plaats, tijd en apparaat onafhankelijk werken. Door het centraliseren van de (werkplek)resources en data6 op één rekencentrum kan ook het beheer gecentraliseerd worden, is capaciteit eenvoudig uit te breiden en wordt netwerkverkeer richting de werkplekken beperkt. 4.5.3

Distributielaag De distributielaag verzorgt de distributie van gegevens en de beschikbaarstelling van applicaties naar de diverse typen werkplekken en (rand)apparatuur. Voor een uitgebreide beschrijving hiervan wordt verwezen naar de Domeinarchitecuur Werkplekconcept [VWI].

4.6

Gegevens Opslag TG01: Alle dynamische data in een IenM ICT Infrastructuur wordt centraal opgeslagen op een Storage Area Network en gebackupped. De backup media worden op een andere dan deze centrale locatie bewaard. In deze laag vindt alle fysieke opslag van gegevens plaats. In de opslag infrastructuur wordt gebruik gemaakt van heterogene virtualisatie: de mogelijkheid om dataopslag componenten van verschillende leveranciers aan elkaar te koppelen. De gevirtualiseerde opslagsystemen maken integraal deel uit van het centrale opslagsysteem. Hierdoor bestaat de mogelijkheid data te verplaatsen naar een opslagsysteem met bijvoorbeeld een andere beschikbaarheid. Op deze wijze is een flexibele en schaalbare dataopslag beschikbaar. De onderstaande figuur toont de diverse componenten welke een rol spelen in de gegevens opslag.

Figuur 19: Gegevens Opslag Er wordt onderscheid gemaakt in online storage voor data die direct opvraagbaar moet zijn, denk aan data voor de bedrijfstoepassingen en data voor de kantoorautomatisering, en offline storage voor back-up en archivering. Bij de online storage wordt een onderscheid gemaakt tussen centrale- en decentrale oplag. Op basis van de eisen die gesteld worden aan flexibiliteit en betrouwbaarheid wordt data primair centraal opgeslagen.

6

Zie ook Gegevens Opslag Pagina 41 van 57


4.6.1

Online Storage Op basis van de kwaliteitseisen die zijn gesteld aan: aanpasbaarheid: platform- en locatieonafhankelijkheid; schaalbaarheid: zowel groei als krimp; beschikbaarheid: continuïteit en betrouwbaarheid; beveiliging; performance en prestaties; beheer(s)baarheid: proactieve signalering, centrale monitoring; kostenefficiëntie, is gekozen voor een Storage Area Network (SAN) architectuur. Het SAN koppelt de centraal opgeslagen gegevens aan de verwerkingslaag. Deze architectuur biedt in combinatie met het SBC concept een optimale mix van exploitatie, betrouwbaarheid en flexibiliteit. Wanneer bij het gebruik van specifieke data één van de genoemde kwaliteitseisen niet gehaald wordt bij toepassing van centrale opslag, kan er gekozen worden voor het lokaal (decentraal) beschikbaar stellen van een opslagvoorziening. Dataopslag in deze omgeving verhoogt de beschikbaarheid, ontlast de netwerkverbindingen en verhoogt de performance. De voorkeursvolgorde voor het opslaan van gegevens is: Centrale opslag (rekencentrum); Decentrale opslag op een gecentraliseerd device (opslag op kantoor); Lokale opslag op de werkplek.

4.6.2

Offline Storage De back-up- en restorevoorziening biedt de mogelijkheid om verloren of corrupt geraakte gegevens te herstellen. Om de continuïteit en betrouwbaarheid van de gegevensvoorziening te waarborgen dient een implementatie te voldoen aan het ESNIB en Baseline Informatiebeveiliging. De backup gegevens worden bijvoorbeeld op een andere locatie bewaard, zodat deze bij een calamiteit niet tezamen met de originelen verloren kunnen gaan. Ten behoeve van gegevens die langdurig bewaard moet worden, maar niet direct toegankelijk hoeven te zijn (statische data) wordt gebruik gemaakt van archivering. Het gebruik hiervan ontlast de centrale opslag- en backupvoorziening en is kostenefficiënt. Naast het kostenaspect is voornamelijk de betrouwbaarheid een belangrijke kwaliteitseis. De snelheid (performance) waarmee de gegevens ontsloten worden is van ondergeschikt belang t.o.v. de betrouwbaarheid en kosten.

4.7

Netwerk De component Netwerk wordt in de technische architectuur van IMEA beschreven als het koppelvlak tussen de distributie-, presentatie, verwerkings- en opslaglaag. De rol of functionaliteit die de component Netwerk biedt verschilt per verbonden laag met bijbehorende verschillen in kwaliteitseisen. Zo zal in de SAN omgeving performance erg belangrijk zijn en bij het Connectivity onderdeel Remote Toegang de beveiliging meer aandacht vragen. TN02: Het netwerkverkeer van een systeem naar de productie-, beheeren backupomgeving is fysiek van elkaar gescheiden. Om de betrouwbaarheid van een IenM infrastructuur te waarborgen vindt het dataverkeer van een systeem t.b.v. productie, beheer en/of backup fysiek gescheiden plaats naar de respectievelijke (eventueel logisch) gescheiden omgevingen. Deze verkeersstromen kunnen elkaar daardoor niet nadelig beïnvloeden.

Pagina 42 van 57


TN01: Er is één koppelvlak gedefinieerd voor zowel inkomend als uitgaand verkeer van en naar een IenM ICT Infrastructuur, de DeMilitarized Zone (DMZ), waarbinnen diverse functionele zones zijn ingericht. In het koppelvlak Connectivity wordt de connectiviteit geboden gericht op gegevensuitwisseling, spraak en video communicatie. Onderdeel hiervan is de beveiliging tussen de ‘buitenwereld’ en een IenM ICT Infrastructuur. De volgende verbindingen worden hierin onderkend: Vaste en gestandaardiseerde verbindingen voor het ontsluiten van de verschillende locaties (regio’s) van IenM; Vaste verbindingen voor externe partijen en communicatie met andere departementen; Beveiligde remote toegang voor het ontsluiten van de in een IenM Infrastructuur beschikbare voorzieningen en diensten aan (IenM) medewerkers die vanaf huis, interdepartementaal of via mobiele werkplekken elders werken; Beveiligde remote toegang voor externe partijen ten behoeve van het beheer (onderhoud en monitoring) van systemen. Toegang is afgeschermd tot alleen de betreffende systemen en te gebruiken poorten; De internetkoppeling(en) voor ontsluiting van gegevens vanaf het internet; Het publieke telefonienetwerk voor klanten en externe partijen. Deze interface maakt gebruik van spraak mogelijk. In dit koppelvlak wordt onderscheid gemaakt tussen interne en externe verbindingen. Aan de interne verbindingen worden hoge eisen gesteld met betrekking tot schaalbaarheid en performance, terwijl bij externe verbindingen de factor beveiliging in het algemeen belangrijker is. Door het beperken van het in- en uitgaand verkeer van een infrastructuur tot één koppelvlak kan daar maximaal controle over gehouden worden. Een schematische voorstelling van het hierboven beschreven Connectivity koppelvlak is opgenomen in de navolgende figuren.

Figuur 20: Schematische Voorstelling Connectivity Koppelvlak

Pagina 43 van 57


Omwille van de overzichtelijkheid is de internet connectiviteit in een apart figuur opgenomen.

Figuur 21: Schematische Voorstelling Internet Connectivity 4.8

Beveiliging Beveiliging is een integraal onderdeel van elke laag en koppelvlak. Dit uit zich ook in de manier waarop de technische architectuur gelaagd is opgezet. In alle lagen en koppelvlakken zijn beveiligingsservices, zoals bijvoorbeeld Identity Management, IDS inbraakdetectie en Security services, actief. TV01: Een gebruiker of systeem is geautoriseerd voor het gebruik van toepassingen en/of toegang tot gegevens die nodig zijn voor het uitvoeren van de functie.

4.8.1

Identity Management (IdM) Identity Management betreft het beheer van identiteiten ten behoeve van fysieke toegang tot gebouwen (Rijkspas) en logische toegang tot informatiesystemen en gegevens van IenM en beperkt zich daarbij niet enkel tot de technische voorzieningen, maar omvat ook de procedures en processen rondom dit beheer. Met deze voorziening zorgt IenM er voor dat, na identificatie en registratie van een persoon, alleen de juiste personen toegang hebben (authenticatie) en uitsluitend tot die delen waar de betreffende persoon recht op heeft (autorisatie). Naast de noodzaak voor de beveiliging van de interne organisatie en de informatievoorziening, is een goed ingevoerde Identity Management voorziening ook van belang in het kader van de interdepartementale samenwerking. Met de implementatie van de IdM voorziening geeft IenM invulling aan het interdepartementale IdM Stappenplan [SRIDM] en voldoet het aan het Rijksbrede Normenkader Identity Management [NKIDM].

Pagina 44 van 57


4.8.2

Beveiliging van de informatie-uitwisseling Ten aanzien van de beveiliging van de informatie-uitwisseling is het concept van vertrouwde domeinen van toepassing. Dit concept gaat er van uit dat een vertrouwd domein aan de informatiebeveiligingseisen voldoet door middel van beveiligingsmaatregelen waardoor aanbieders en afnemers van services, over de domeinen heen, elkaar kunnen vertrouwen. Voor de gegevensuitwisseling binnen haar domein kan iedere organisatie zelf bepalen welke beveiligingsmaatregelen zij neemt. Autorisatie en beveiligingsmaatregelen van de aanbieder bepalen welke services beschikbaar zijn voor een afnemend systeem. Per service wordt bepaald of deze naar buiten toe beschikbaar is en welke beveiligingsmaatregelen noodzakelijk zijn. Dat een afnemend systeem geautoriseerd is voor een service, betekent nog niet dat het afnemende systeem geautoriseerd is voor alle gegevens van die service. Een service moet garanderen dat een afnemend systeem alleen toegang heeft tot data waartoe dit afnemende systeem geautoriseerd is, dit wordt ook wel filteren genoemd. Filteren kan op basis van organisatie, rol en gebruiker gebeuren. Bij elke serviceaanroep geeft het afnemende systeem een unieke organisatie-, rolen gebruiker ID mee. De service roept een autorisatieservice aan met deze identificatie. De autorisatieservice bepaalt of het afnemende systeem geautoriseerd is om de service te gebruiken. Indien het services afnemende systeem geautoriseerd is, worden de gegevens gefilterd op basis van organisatie-, rolen gebruiker ID.

4.8.3

Inbraakdetectie d.m.v. IDS (Intrusion Detection System) Zoals in paragraaf 4.7 is beschreven, wordt logische toegang tot een IenM infrastructuur vanaf een fysieke locatie buiten een IenM kantoor ook ondersteund. Omdat een dergelijke locatie minder vertrouwd is, zijn extra beveiligingsmaatregelen getroffen. Logische toegang vanaf een externe locatie verloopt altijd via de eerder genoemde DeMilitarized Zone (DMZ). Er worden extra toegangscontroles uitgevoerd (bijvoorbeeld sterkte authenticatie o.b.v. token, certificaat of SMS), waarna medewerkers en/of derden gecontroleerd toegang krijgen tot (delen van) een IenM infrastructuur. Omdat de DMZ het enige koppelvlak met ‘de buitenwereld’ is, vindt hier continu monitoring op inbraakpogingen d.m.v. Intrusion Detection Systemen (IDS) plaats.

4.8.4

Security Services TV02: Componenten in een IenM ICT Infrastructuur worden zo snel mogelijk (na beschikbaar komen) en op gecontroleerde wijze voorzien van security patches, fixes en updates. Beheerde werkplekken en apparatuur waarop gebruik wordt gemaakt van lokale opslagcapaciteit worden daarnaast voorzien van anti-virus software. Om de stabiliteit van de infrastructuur niet te verstoren, dienen security patches, fixes en updates gecontroleerd geïmplementeerd te worden. Daartoe worden zij beoordeeld op relevantie voor en impact op (componenten en voorzieningen in) een IenM ICT Infrastructuur. Antivirus controle moet er voor zorgen dat de integriteit van de data en continuïteit van de dienstverlening gewaarborgd is. Door de bescherming van een IenM ICT Infrastructuur continu up-to-date te houden wordt aan deze eis voldaan. Componenten (werkplekken, servers) in de distributie-, presentatie- en verwerkingslaag, waarop gebruik wordt gemaakt van lokale opslagcapaciteit zijn daarom voorzien van antivirus software.

4.9

Beheer IenM heeft er voor gekozen om het beheer van de ICT infrastructuren uit te besteden. In een dergelijke situatie ontstaat de behoefte aan duidelijke beheerafspraken, een strikte scheiding van verantwoordelijkheden en transparantie Pagina 45 van 57


van de dienstverlening. In de laag Beheer worden generieke diensten (services) geboden ter ondersteuning hiervan. Zo zijn hierin, naast de beheerprocessen, services opgenomen ter bewaking en controle van de dienstverlening en de rapportage daarover. Voorbeelden van deze services zijn netwerk-, systeem- en service management. Met behulp van deze componenten wordt inzicht verkregen in de status van de beheerprocessen en -diensten die worden geleverd door een IenM ICT infrastructuur en de beheerder. Ondersteunend aan deze services is de Configuratie Management Database (CMDB) waarin alle aan informatiesystemen gerelateerde componenten (configuaratie items, CI) zijn opgenomen. In de CMDB worden per CI de meest belangrijke kenmerken, zoals technische details, eigenaarschap en onderlinge relaties vastgelegd. Het biedt daarmee inzicht in en overzicht van de beheerde omgeving. TB01: Het proces rondom het testen en accepteren van (wijzigingen op) voorzieningen in een IenM ICT Infrastructuur vindt releasematig en volgens een gestructureerde aanpak of methodiek plaats. Wijzigingen in en aan een IenM ICT Infrastructuur kunnen mogelijk leiden tot verstoringen van de stabiliteit en beschikbaarheid van de omgeving en dienen daarom gestructureerd en gecontroleerd uitgevoerd te worden. Het risico van een verstoring wordt daarmee beperkt. Binnen het proces is er een duidelijke rolverdeling tussen uitvoerenden, zowel inhoudelijk als proces, en opdrachtgever. Het inzetten van een centraal informatiesysteem voor wijzigingen zorgt voor overzicht en maakt afstemming en planning eenvoudig. TB02: Voorzieningen (platform, applicatie, services) moeten voldoen aan de Aansluitvoorwaarden om te worden geplaatst in of aangesloten te worden op een IenM ICT infrastructuur. Nieuwe informatiesystemen of voorzieningen die voor IenM worden ontwikkeld of wijzigingen aan bestaande systemen en voorzieningen moeten voldoen aan de Aansluitvoorwaarden en dienen dus bekend te zijn bij leverancier en functioneel beheerder. In de Aansluitvoorwaarden worden bijvoorbeeld eisen gesteld m.b.t. de inrichting van een informatiesysteem en de op te leveren documentatie. De Aansluitvoorwaarden zorgen er voor dat de architectuur in stand gehouden wordt, dat de implementatie van een nieuwe voorziening in een IenM infrastructuur soepel verloopt en dat de kennis over deze voorziening geborgd is.

Pagina 46 van 57


5

Architectuur Principes

De ontwikkeling van de Informatievoorziening van IenM wordt gestuurd met behulp van architectuur principes. De principes zijn in lijn gebracht met de strategische doelstelling van IenM waardoor zij een stuurmiddel worden voor het sturen van ontwikkelingen en projecten. Met behulp van principes wordt de ontwerpvrijheid bij de realisatie van projecten beperkt en in de gewenste richting gestuurd. In overleg en afstemming met de DCI Architectuur kan er, mits goed onderbouwd en met duidelijkheid over de condities waaronder, van principes afgeweken worden. Deze werkwijze wordt aangeduid met ‘comply or explain’. 5.1

Indeling van de architectuurprincipes Bij de beschrijving van de architectuur is gebruik gemaakt van de in paragraaf 1.4.2 beschreven NORA indeling in verschillende architectuurlagen (en de daarin opgenomen ‘vlakken’). De principes die worden gehanteerd binnen IMEA zijn ingedeeld in deze zelfde lagen en vlakken en zijn bij de uitwerking van de respectievelijke architectuurlagen in de voorgaande hoofdstukken behandeld: Business principes: principes ten aanzien van de bedrijfsvoering. Informatieprincipes: maatregelen met betrekking tot verwerving, vastlegging, veredeling en distributie van informatie Technische principes: kaders ten aanzien van de technische implementatie In dit hoofdstuk worden deze principes voorzien van een uitgebreide onderbouwing en worden de implicaties, de gevolgen van het hanteren van deze principes beschreven.

5.2

Scope van de principes Zoals eerder gesteld (zie 1.4) is IMEA niet alleen bedoeld om kaders te geven aan projecten (middels een Project Start Architectuur), maar ook ter ondersteuning van de pro- en reactieve besluitvorming ten aanzien van veranderingen. IMEA richt zich derhalve op aspecten waarop zowel architecten als opdrachtgevers kunnen en willen sturen. IMEA bevat derhalve geen ‘open deuren’, zaken die inmiddels door iedereen als ‘best practice’ worden beschouwd. Om deze zelfde reden zijn er ook geen principes opgenomen waar (nog) niet op gestuurd kan en wil worden.

5.3

Principes versus Aansluitvoorwaarden De principes in de architectuur lagen beschrijven de visie van IenM op de (ontwikkeling van de) informatievoorziening en leiden tot de realisatie van voorzieningen in een ICT infrastructuur volgens de Aansluitvoorwaarden.

5.4

Leeswijzer principes De in de navolgende paragrafen opgenomen principes zijn als volgt beschreven: Nummer: een nummer voor (latere) referentie aan het betreffende principe; Omschrijving: een omschrijving van het principe; Rationale: een onderbouwing van het principe; Implicatie: de impact, de gevolgen van het hanteren van het betreffende principe; Relatie: relatie met c.q. naar een ander architectuurprincipe, voor de bedrijfsarchitectuur principes is dit de relatie met de fundamentele principes uit MARIJ.

Pagina 47 van 57


5.5

Bedrijfsarchitectuur principes Num BP1

Beschrijving / Rationale / Implicatie De informatievoorziening van IenM is duurzaam: flexibel en toekomstvast vormgegeven. IenM is en blijft in beweging door politieke en organisatorische wijzigingen, (veranderingen in) (Europese) weten regelgeving, gewijzigde taakstellingen, veranderingen en ontwikkelingen in de techniek en de samenleving. De informatievoorziening van IenM moet in staat zijn deze veranderingen op te vangen.

Relatie M1, M4, M5, M6, M7, M8

Num BP2

Beschrijving / Rationale / Implicatie IenM richt haar bedrijfsvoering op een kostenefficiënte manier in. De kosten moeten in verhouding staan met (de kwaliteit van) de geleverde diensten en producten en daarnaast marktconform zijn.

Relatie M5, M7

Num BP3

Beschrijving / Rationale / Implicatie De informatievoorziening van IenM is doelmatig. Deze is op een doelmatige en veilige wijze vormgegeven. De informatie van en naar IenM wordt – voor zover wettelijk mogelijk – op een veilige, transparante, actuele en betrouwbare wijze ontsloten, zowel voor intern als extern gebruik. De vereiste inspanning (kosten) voor de informatievoorziening is in verhouding met de verwachte (efficiëntie) voordelen.

Relatie M2, M3, M4, M5, M8

Num BP4

Beschrijving / Rationale / Implicatie Milieubewustzijn is vanzelfsprekend. Ook binnen de informatievoorziening van IenM worden milieubewuste eisen gesteld en keuzes gemaakt. Er wordt niet alleen scherp gelet op verbruik, maar ook op fabricage(wijze) van toegepaste producten. Daarnaast is milieubewustzijn van de betrokken dienstverleners een vereiste.

Relatie M5

Num BP5

Beschrijving / Rationale / Implicatie De informatievoorziening van IenM is plaats-, tijd- en apparaatonafhankelijk. De informatievoorziening van IenM is zodanig georganiseerd dat plaats-, tijd- en apparaatonafhankelijk werken mogelijk is.

Relatie M7, M8

Pagina 48 van 57


5.6

Informatiearchitectuur principes

5.6.1

Medewerkers en Applicaties Num IA01

Beschrijving / Rationale / Implicatie Informatiesystemen zijn modulair samengesteld. Met deze modulaire opzet wordt gestreefd naar flexibiliteit, hergebruik, ontkoppeling en standaardisatie.

Relatie BP1, BP2, BP3

Informatiesystemen worden ontwikkeld op basis van het service gerichte architectuurconcept; Informatiefuncties worden in de vorm van API’s beschikbaar gesteld. Bij het onderkennen van de noodzaak van functionaliteit wordt gekeken naar mogelijk hergebruik. Bij de aanschaf van nieuwe functionaliteit wordt niet alleen rekening gehouden met de specifieke probleemstelling, maar wordt de functionaliteit als generieke oplossing (voor een algemeen geformuleerd probleem) beschouwd; Informatiesystemen bieden op de (ont)koppelvlakken open interfaces aan op een service georiënteerde wijze, zodat informatie-uitwisseling op basis van webservices kan plaatsvinden; De Informatiefuncties moeten volgens het transactieprincipe worden ontworpen zodat ze als geheel succesvol kunnen worden afgerond (o.a. t.b.v. consistentie gegevens); Faciliteert hergebruik, maar dit introduceert ook complexiteit.

Num IA02

5.6.2

Beschrijving / Rationale / Implicatie Hergebruik voor kopen, voor ontwikkelen Bij behoefte aan of vernieuwing van een nieuw informatiesysteem wordt bewust gestuurd op hergebruik van bestaande informatiefuncties. Hierbij wordt gekeken of reeds (passende) bestaande functionaliteit beschikbaar is als: Landelijke overheidsbouwsteen; IenM informatiefunctie; In te kopen informatiefunctie of systeem. Tot ontwikkeling c.q. maatwerk wordt pas overgegaan wanneer geen van bovenstaande methoden mogelijk zijn.


Berichten en Gegevens Num IG01

Beschrijving / Rationale / Implicatie Voor elk gegeven bestaat een eenduidige definitie Voor alle gegevens bestaat een eenduidige definitie, waarover overeenstemming bestaat binnen de organisatie. Hiervoor wordt gebruik gemaakt van een gemeenschappelijk uitwisselingsmodel. Een domein kan een eigen uitwisselingsmodel hanteren.

Relatie BP3

Pagina 49 van 57


Num IG02

Beschrijving / Rationale / Implicatie Elk gegeven heeft een eigenaar. Hierdoor wordt transparant wie kan worden aangesproken als de actualiteit, betrouwbaarheid en de integriteit van de gegevens niet voldoet; Bewust omgaan met gegevensverzamelingen.

Relatie BP1, BP3

De eigenaar van een gegeven is verantwoordelijk voor de kwaliteit, actualiteit, betrouwbaarheid en integriteit van een gegeven. Hij zorgt ervoor dat hij kan omgaan met terugmeldingen over de kwaliteit; De afnemer kiest zijn gegevensbronnen en stelt eisen aan waardering en betrouwbaarheid. Het is helder wie welke gegevens gebruikt en voor welk doel; Eigenaarschap moet voor gegevensgebieden expliciet worden benoemd en belegd. Met een generieke invulling van wat dat dan betekent voor taken verantwoordelijkheden, procedures, e.d. (inrichten functioneel beheer) Ontsluiting van gegevens wordt geautoriseerd door gegevenseigenaar. Autorisatiebeheer op de gegevensgebieden moet worden ingericht. Proceseigenaar definieert de informatiebehoefte voor uitvoering van zijn proces. Afspraken op het gebied van beschikbaarheid, tijdigheid, volledigheid van de aanlevering en verwerking van gegevens dienen te worden vastgelegd in SLA. De eigenaar is hierbij één van de partijen. Num IG03

5.6.3

Beschrijving / Rationale / Implicatie Gegevens zijn voorzien van een locatie Gegevens zijn locatie gebonden; Zorgt voor betere afstemming tussen en efficiëntere inrichting van processen; Maakt inzichtelijk welke gegevens over een bepaalde locatie beschikbaar zijn; Maakt gebiedgerichte ontsluiting van gegevens mogelijk.

Relatie BP3

Informatie-uitwisseling Num IU01

Beschrijving / Rationale / Implicatie Informatiesystemen communiceren (met elkaar) op basis van webservices. Door te communiceren op basis van webservices is de wijze waarop deze services gerealiseerd worden niet van belang, omdat deze communiceren op basis van afgesproken protocol en berichtformaat. Zodat eenvoudiger uitwisseling (onder de motorkap) gerealiseerd kan worden; Vergroten van de herbruikbaarheid van informatiefuncties; Informatiefuncties mogen zich niet bewust zijn van de werking/bestaan van andere informatiefuncties.

Relatie BP1, BP3

Focus moet worden gelegd op (afspraken over de) ontkoppelpunten: opstellen SLA’s Aansluiten op basis van abonneren (subscribe) Stelt eisen aan toekomstige projecten met betrekking tot de herbruikbaarheid van de oplossingen die gerealiseerd worden.

Pagina 50 van 57


Num IU02

Beschrijving / Rationale / Implicatie Voor koppelvlakken wordt gebruik gemaakt van open standaarden. Voor de koppelvlakken worden open standaarden gebruikt voor zowel berichtformaat (bericht) als berichtinhoud (gegevensstructuren en definities); Het gebruik van standaarden verhoogt de uitwisselbaarheid van gegevens tussen overheidsdiensten onderling en met derden; De keuze van standaarden kent de volgende volgordelijkheid: overheids-, open- en de facto standaarden.

Relatie BP1, BP3

Projecten zullen zich moeten richten op oplossingen die gebruik maken van standaard koppelvlakken; Systeemeigenaren zijn verantwoordelijk voor conversie en transformatie van berichten naar de door IenM gehanteerde standaarden (‘de vervuiler betaalt’). Communicatie tussen en naar systemen in een IenM infrastructuur vindt plaats volgens het gestandaardiseerde koppelvlak, een Enterprise Service Bus (ESB).

5.7

Technische principes

5.7.1

Technische Componenten Num TC01

Beschrijving / Rationale / Implicatie De IenM ICT infrastructuur is gebaseerd op het Server Based Computing (SBC) principe. Toepassingen worden web- of serverbased aangeboden, tenzij deze ook gebruikt moeten worden wanneer een werkplek geen verbinding heeft met de IenM ICT infrastructuur; IenM is een organisatie die in beweging is. Hierdoor kunnen er wijzigingen optreden in het aantal en de plaats van locaties. Een nieuwe locatie moet snel aangesloten kunnen worden op de ICT Infrastructuur en de daarop aangeboden dienstverlening; Functionaliteit kan snel en eenvoudig beschikbaar worden gesteld en verwijderd; Ontkoppeling van de afhankelijkheid tussen de aangeboden functionaliteit en de fysieke werkplek. Dit geldt voor zowel de vaste, mobiele, alsmede remote werkplekken; De exploitatie van lokaal geïnstalleerde toepassingen is duurder dan wanneer deze web- of serverbased worden aangeboden; Door functionaliteit centraal op een server aan te bieden worden de werkplekken gereduceerd tot in- en uitvoer middelen. Op de werkplekken worden geen dynamische gegevens bewaard; De werkplekken zijn identiek. Hierdoor vergt een werkplek een minimale beheer inspanning, zijn ze goedkoper in aanschaf, gaan langer mee en kunnen gemakkelijk en snel worden vervangen bij defecten; Het centraliseren van de verwerking van toepassingen leidt tot een efficiënter gebruik van beschikbare hardware (meer met minder). Dit levert milieuvoordelen op voor onder andere stroomverbruik en warmte uitstoot;

Relatie BP1, BP2, BP3, BP4, BP5

Pagina 51 van 57


Num

Beschrijving / Rationale / Implicatie Webbased toepassingen stellen minimale eisen aan werkplekken.

Relatie

Alle applicaties dienen geschikt te zijn voor dit concept; Applicaties die niet geschikt zijn voor dit concept, bijvoorbeeld 16-bit (legacy) applicaties of applicaties die onevenredig veel resources gebruiken, moeten worden vervangen; Maakt het toepassen van de ‘rip-and-replace’ werkwijze voor fysieke werkplekken mogelijk; Om dit concept kostenefficiënt te kunnen blijven toepassen, zal 80% van de gebruikerspopulatie gebruik moeten maken van dit concept. Dit vraagt om continue bewaking; Maakt toepassing van Bring Your Own Computing mogelijk.

Num TC02

Beschrijving / Rationale / Implicatie Reken- en opslagcapaciteit binnen een IenM ICT Infrastructuur wordt gecentraliseerd en geconsolideerd aangeboden vanuit één rekencentrum. Dit rekencentrum is buiten een IenM locatie gehuisvest. Centrale plaatsing van rekenen opslagcapaciteit. Er zijn schaalvoordelen te behalen door het gemeenschappelijk gebruik van beveiliging, beheer, ruimtes, opslag en back-up voorzieningen en het terugdringen van de complexiteit; Centralisatie biedt de mogelijkheid om de gebruikte middelen (servers, netwerk) te consolideren. Hierdoor kunnen deze middelen optimaal benut worden; Maatregelen in het kader van waarborgen van de continuïteit, bijv. d.m.v. uitwijk, zijn effectiever en efficiënter in te richten vanuit één locatie.


Voor rekenen opslagcapaciteit wordt gebruik gemaakt van een datacenter.

Num TC03

Beschrijving / Rationale / Implicatie Voor alle componenten van de Technische Architectuur wordt gebruik gemaakt van rijks-, open en de facto standaarden en bewezen technieken. Gebruik van standaarden verhoogt de uitwisselbaarheid van componenten en gegevens, onderling en met derden. Levert schaalvoordelen in aanschaf, beheer, opleiding etc. Betere ondersteuningsmogelijkheden (expertise) door ‘brede’ inzet in de markt. Hergebruik van kennis om (ontwikkel)kosten te reduceren.

Relatie BP1, BP3

Componenten dienen aantoonbaar gebaseerd te zijn op bewezen technieken en te voldoen aan rijks-, open en de facto standaarden. Waar mogelijk moet dit, op basis van certificatie, kunnen worden aangetoond; Componenten welke niet voldoen aan de rijks-, open of de facto standaarden worden niet toegepast; Bestaande componenten welke niet voldoen aan de rijks- open of de facto standaarden worden aangepast, vervangen of uit gefaseerd.

Pagina 52 van 57


Num TC04

Beschrijving / Rationale / Implicatie Voor één type werkplek wordt één type hardware (lijn) ingezet. Door standaardisatie wordt het beheer eenvoudiger en efficiënter.

Relatie BP2, BP3

De keuze voor de hardware en de daarop aangeboden software is beperkt; Voor afwijkende hardware wordt geen ondersteuning geboden.

Num TC05

Beschrijving / Rationale / Implicatie Voor een specifieke voorziening (platform, applicatie, functionaliteit) wordt één softwareproduct aangeboden. Van dat product is slechts één versie in gebruik. Door standaardisatie wordt het beheer eenvoudiger en efficiënter.


Updates en upgrades van applicaties worden IenM-breed, zowel voor alle gebruikers, alsmede voor alle typen beheerde werkplekken, uitgerold; Opleiding van gebruikers met betrekking tot gebruik van een applicatie kan uniform worden aangeboden.

Num TC06

Beschrijving / Rationale / Implicatie Bij gelijke geschiktheid gaat de voorkeur uit naar Open Source producten. Inzet van Open Source producten is een Rijksbrede verplichting; Licentiekosten voor Open Source producten zijn lager dan kosten voor commerciële (COTS) producten. IenM kijkt niet enkel naar licentie-, maar ook naar exploitatiekosten. Dit vormt tezamen met de functionele aspecten en de voorwaarde dat er voldoende kennis en ondersteuning in de markt beschikbaar is, het begrip ‘gelijke geschiktheid’.

Relatie BP2

Productkeuzes voldoen niet te allen tijde aan het ‘Actieplan Nederland Open in Verbinding’. Num TC07

Beschrijving / Rationale / Implicatie Voor zowel hardware (rekencapaciteit), alsmede software wordt het principe ‘virtualisatie, tenzij…’ gehanteerd. Door inzet van virtualisatie technologie wordt fysieke bronnen en componenten flexibel en efficiënt ingezet; Verschillende omgevingen (OTAP) en software versies kunnen naast elkaar werken, zonder elkaar te beïnvloeden.

Relatie BP1, BP3

Informatiesystemen en applicaties dienen geschikt te zijn voor virtualisatie.

Pagina 53 van 57


5.7.2

Gegevensopslag Num TG01

Beschrijving / Rationale / Implicatie Alle dynamische data in een IenM ICT Infrastructuur wordt centraal opgeslagen op een Storage Area Network en gebackupped. De backup media worden op een andere dan deze centrale locatie bewaard. Door de gegevens vanuit deze centrale opslagvoorziening veilig te stellen op een centrale backupvoorziening wordt op een efficiënte en effectieve wijze invulling gegeven aan de beveiligingseis ten aanzien van het veiligstellen van dynamische gegevens; Door gescheiden opslag van actuele data en backupmedia is de kans acceptabel klein dat deze voorzieningen getroffen worden door de gevolgen van dezelfde calamiteit.

Relatie BP3, BP5

Er wordt geen databeheer aangeboden voor de werkplekken; De gebruiker is verantwoordelijk voor het veiligstellen van data die op de mobiele werkplek wordt opgeslagen. Door de data te synchroniseren, kan de gebruiker data meenemen op de Mobiele werkplek en data veiligstellen op de centrale opslagomgeving; Centrale opslag impliceert dat op de werkplekken geen data opgeslagen wordt, m.u.v. opslag ten behoeve van gebruik voor: o Operating systeem; o Toepassingen; o Beheer tools; o Tijdelijke bestanden; o Gebruikersdata in geval van een mobiele werkplek (welke gesynchroniseerd kan worden met de centrale opslag.

5.7.3

Netwerk Num TN01

Beschrijving / Rationale / Implicatie Er is één koppelvlak gedefinieerd voor zowel inkomend als uitgaand verkeer van en naar de IenM ICT Infrastructuur, de DeMilitarized Zone (DMZ), waarbinnen diverse functionele zones zijn ingericht. Door het definiëren van één koppelvlak worden beveiligingsrisico’s verlaagd. Bescherming en controle geschieden op een eenduidige wijze; Retransitie kan op een eenvoudige wijze worden uitgevoerd; Reductie van complexititeit; Ongeautoriseerde toegang tot (gegevens in) een IenM ICT infrastructuur wordt voorkomen; Beveiliging is per functionele zone in te richten; Functionele zones zijn eenvoudig toe te voegen of te verwijderen.

Relatie BP3, BP5

Externe partijen of toepassingen kunnen alleen met vooraf gespecificeerde systemen communiceren via afgestemde protocollen, poorten, IP adressen en diensten; Vereenvoudigt monitoring op inbraakpogingen; Niet beheerde werkplekken die op een wall-outlet van een

Pagina 54 van 57


Num

Beschrijving / Rationale / Implicatie IenM ICT Infrastructuur worden aangesloten, krijgen uitsluitend toegang tot internet.

Relatie

Num TN02

Beschrijving / Rationale / Implicatie Het netwerkverkeer van een systeem naar de productie-, beheeren backup-omgeving is fysiek van elkaar gescheiden. Zorgt voor stabiele omgevingen die geen invloed op elkaar hebben; Verkeerstromen hebben per domein een eigen bandbreedte.

Relatie BP3

Componenten, met uitzondering van werkplekken en randapparatuur, moeten beschikken over minimaal 3 netwerkinterfaces; fysieke netwerkinterfaces van de systemen worden gekoppeld aan de (eventueel) virtueel gescheiden netwerkinterfaces van de overeenkomstige omgevingen.

5.7.4

Beveiliging Num TV01

Beschrijving / Rationale / Implicatie Een gebruiker of systeem is geautoriseerd voor het gebruik van toepassingen en/of toegang tot gegevens die nodig zijn voor het uitvoeren van zijn of haar functie. Duidelijkheid voor een gebruiker welke toepassingen voor hem/haar beschikbaar zijn; Een gebruiker of systeem heeft alleen toegang tot data waarvoor hij/zij/het geautoriseerd is.

Relatie BP3, BP5

Om gebruik te kunnen maken van voorzieningen in een IenM ICT Infrastructuur is een (service)account noodzakelijk; Er is een registratie noodzakelijk voor het beheer van autorisaties.

Num TV02

Beschrijving / Rationale / Implicatie Componenten in de IenM ICT Infrastructuur worden zo snel mogelijk (na beschikbaarkomen) en op gecontroleerde wijze voorzien van security patches, fixes en updates. Beheerde werkplekken en servers waarop gebruik wordt gemaakt van lokale opslagcapaciteit worden voorzien van anti-virus software. De IenM ICT infrastructuur wordt beschermd tegen actuele en bekende bedreigingen van logische aard. Virussen kunnen de data integriteit aantasten en vormen een bedreiging voor de beschikbaarheid en continuïteit van de dienstverlening Veiligheid voldoet aan de IenM kwaliteitseisen. Alvorens patches en fixes aan te brengen worden deze beoordeeld op relevantie voor en werking en impact op de IenM ICT infrastructuur

Relatie BP3

Pagina 55 van 57


Num

5.7.5

Beschrijving / Rationale / Implicatie Mobiele werkplekken dienen regelmatig aan de IenM ICT Infrastructuur gekoppeld te worden, teneinde de patches, fixes en updates te ontvangen.

Relatie

Beschrijving / Rationale / Implicatie Het proces rondom het testen en accepteren van (wijzigingen op) voorzieningen in de IenM ICT Infrastructuur vindt releasematig en volgens een gestructureerde aanpak of methodiek plaats. Gestructureerde aanpak of methodiek zorgt voor: Een goede organisatorische inbedding; Inzet van de juiste hulpmiddelen en infrastructuur; Bruikbare technieken voor de testactiviteiten; Minder risico op verstoring als gevolg van wijzigingen

Relatie BP3

Beheer Num TB01

Het releasematig aanbrengen van wijzigingen kan leiden tot een langere doorlooptijd van het implementatietraject; Vraagt om een onderlinge afstemming tussen de diverse beheerpartijen en belanghebbenden.

Num TB02

Beschrijving / Rationale / Implicatie Voorzieningen (platform, applicatie, services) moeten voldoen aan de Aansluitvoorwaarden om te worden geplaatst in of aangesloten te worden op de IenM ICT infrastructuur. Voorzieningen die voldoen aan de Aansluitvoorwaarden vereisen geen aanpassing aan de ICT architectuur en passen in de IenM ICT infrastructuur; Voorzieningen moeten voldoen aan gestelde kwaliteitsnormen; Voorzieningen moeten in beheer genomen kunnen worden.


De Aansluitvoorwaarden kennen een diepgaander detailniveau dan de architectuur; De Aansluitvoorwaarden worden afgestemd met beheerders van de IenM ICT Infrastructuren; De Aansluitvoorwaarden moeten bekend zijn bij de leverancier van de voorziening.

Pagina 56 van 57


BIJLAGE A – Afkortingen en begrippen Afkorting / begrip Omschrijving Informatievoorziening Het geheel van mensen, middelen, processen en maatregelen gericht op (de ondersteuning van) de informatiebehoefte van een organisatie. Dienst Een dienst is het resultaat of effect (van een afgeronde inspanning) dat wordt geleverd en waarmee in een behoefte van een afnemer wordt voorzien. Hiermee wordt niet een organisatorische eenheid binnen IenM bedoeld. Informatiefunctie Een Informatiefunctie is een in een proces onderkende functionaliteit voor de verwerking van informatie. Informatiesysteem Een Informatiesysteem is een logische clustering van een aantal Informatiefuncties. API Een Application Programming Interface is een verzameling definities op basis waarvan een informatiesysteem kan communiceren met een (deel van een) ander informatiesysteem. Applicatie Applicatie is een door een leverancier geleverde implementatie van een Informatiesysteem. ITIL ITIL (Information Technology Infrastructure Library) is ontwikkeld als een referentiekader voor het inrichten van de beheerprocessen binnen een ICT organisatie. MFP Multi Functional Periphal. Dit is een printer welke uitgebreid is met de functionaliteiten van faxen, kopiëren en scannen. OS Operating Systeem OTAP Hiermee worden de Ontwikkel, Test, Acceptatie en Productie omgevingen aangegeven PDO Product en Diensten Overzicht. In functionele termen beschreven dienst, voorzien van genormeerde performance indicatoren, die wordt aangeboden. SBC Server Based Computing een techniek waarbij de toepassing wordt uitgevoerd op centraal geplaatste servers terwijl de in- en uitvoer van toetsenbord, muis en beeldscherm van het werkstation worden gebruikt. SLA Service Level Agreement. Overeenkomst tussen aanbieder en afnemer van dienstverlening waarin afspraken rondom deze dienstverlening zijn vastgelegd. API Application Programming Interface. Een verzameling definities op basis waarvan informatiesystemen met elkaar kunnen communiceren.

Pagina 57 van 57

Ministerie van Infrastructuur en Milieu IenM Enterprise Architectuur

Recommend Documents