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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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)
wet- en 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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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 ontwerp- en 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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
[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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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-, beheer- en 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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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-, rol- en 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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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) wet- en 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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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.
Relatie
BP1,
BP2,
BP3
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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 reken- en 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.
Relatie
BP1,
BP2,
BP3,
BP4,
BP5
Voor reken- en 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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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.
Relatie
BP1,
BP2,
BP3
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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.
Relatie
BP1,
BP2,
BP3,
BP4,
BP5
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
Concept | IMEA – IenM Enterprise Architectuur | Versie 0.2
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

Getrechterde besluitvorming: ni wegen alleen

Het verhaal van de EA

Financieel administratief medewerker

Lees de nieuwsbrief 2014-02

PDF - 491 kB

Presentatie 3 dec 2014 Dick Appelman

Toelichting bij amendement SP-01 en SP-02

Programma

Besluit van de Minister van Infrastructuur en Milieu

Aanwezigen stellen zich voor en schetsen de