Heeft u vragen en/of opmerkingen over deze pagina, mailto:postbusear@rijksoverheid.nl
Doelarchitecturen: verschil tussen versies
Regel 5: | Regel 5: | ||
==Inleiding== | ==Inleiding== | ||
− | Een doelarchitectuur beschrijft een toekomstig gewenste situatie (SOLL). Een doelarchitectuur wordt met name opgesteld om bestuurders binnen de rijksdienst (CIO’s en | + | Een doelarchitectuur beschrijft een toekomstig gewenste situatie (SOLL). Een doelarchitectuur wordt met name opgesteld om bestuurders binnen de rijksdienst (CIO’s en CIO-Beraad) zicht te bieden op de situatie zoals die over een paar jaar ontstaat. Een doelarchitectuur onderscheidt zich van de huidige architectuur (IST), ook wel "as-is"- architectuur genoemd en de oplossingsarchitectuur, ook wel "solution"-architectuur genoemd. De "as-is"-architectuur is een representatie van de architectuur die al is gerealiseerd en dus de huidige situatie weergeeft, in een "solution"-architectuur is de voorgestelde oplossing uitgewerkt. Op concernniveau zijn binnen de Rijksdienst al enkele doelarchitecturen uitgewerkt. In bijgaande afbeelding zijn 6 doelarchitecturen en 3 belangrijke documenten met kaders, richtlijnen en principes “geplot” op de 7 informatiseringsdomeinen zoals die binnen de Rijksdienst zijn onderscheiden. |
==Overzicht (doel)architecturen== | ==Overzicht (doel)architecturen== | ||
Regel 32: | Regel 32: | ||
==De vaststelling van doelarchitecturen== | ==De vaststelling van doelarchitecturen== | ||
− | Het verzoek om een doelarchitectuur op te stellen is meestal gedaan door de CIO belast met de portefeuille Architectuur als lid van de stuurgroep Generieke informatievoorziening. Eindprodukten zijn aan deze stuurgroep voorgelegd en via 1 of meerdere subcommissies van | + | Het verzoek om een doelarchitectuur op te stellen is meestal gedaan door de CIO belast met de portefeuille Architectuur als lid van de stuurgroep Generieke informatievoorziening. Eindprodukten zijn aan deze stuurgroep voorgelegd en via 1 of meerdere subcommissies van het CIO-Beraad doorgeleid naar de het CIO-Beraad ter vaststelling.<!-- Page revision date: 2016-09-23T15:17:55Z --> |
Huidige versie van 24 sep 2016 om 04:08
Inleiding
Een doelarchitectuur beschrijft een toekomstig gewenste situatie (SOLL). Een doelarchitectuur wordt met name opgesteld om bestuurders binnen de rijksdienst (CIO’s en CIO-Beraad) zicht te bieden op de situatie zoals die over een paar jaar ontstaat. Een doelarchitectuur onderscheidt zich van de huidige architectuur (IST), ook wel "as-is"- architectuur genoemd en de oplossingsarchitectuur, ook wel "solution"-architectuur genoemd. De "as-is"-architectuur is een representatie van de architectuur die al is gerealiseerd en dus de huidige situatie weergeeft, in een "solution"-architectuur is de voorgestelde oplossing uitgewerkt. Op concernniveau zijn binnen de Rijksdienst al enkele doelarchitecturen uitgewerkt. In bijgaande afbeelding zijn 6 doelarchitecturen en 3 belangrijke documenten met kaders, richtlijnen en principes “geplot” op de 7 informatiseringsdomeinen zoals die binnen de Rijksdienst zijn onderscheiden.
Overzicht (doel)architecturen
Om meer inzicht te krijgen in de diverse doelarchitecturen zijn ze hiernavolgend opgesomd met de mogelijkheid ze nader te bekijken.
- Overzicht Doelarchitectuur Toegang
- Overzicht Functionele doelarchitectuur DWR
- Overzicht Doelarchitectuur DWR Zoeken
- Overzicht Functionele doelarchitectuur Gesloten Rijkscloud (GRC)
- Overzicht Algemene kaders Consolidatie Datacenters Rijk (CDR)
- Overzicht Doelarchitectuur Digitale Duurzaamheid (DiDu)
- Overzicht Doelarchitectuur Rijks Application Store (RAS)
- Overzicht Baseline Informatiebeveiliging Rijksdienst (BIR 2012)
- Overzicht Architectuurschets van het stelsel voor gegevensuitwisseling
Wat meestal de opzet is van de doelarchitecturen
Binnen de Rijksdienst is er nog geen sprake van één vastomlijnde aanpak om te komen tot een doelarchitectuur. Wel is een doelarchitectuur meestal opgebouwd uit drie delen:
- een beschrijving van de huidige (IST-)situatie en een schets van uitgangspunten en principes
- een beschrijving van de toekomstige (SOLL-)situatie (streefbeeld, ambitie) in jaar XXXX en
- een beschrijving van de te nemen stappen om van de huidige situatie naar de toekomstige situatie te komen (bijv. een roadmap, een plateauplanning).
Het streefbeeld van de SOLL-sitiuatie beschrijft de gewenste situatie in jaar XXXX, waarin alle principes op een doelmatige en doeltreffende wijze zijn gerealiseerd. De IST-situatie beschrijft de huidige stand van zaken waarbij kan worden aangegeven wat er in de huidige situatie wel en niet beschikbaar is en nodig is om hetgeen men wenst te bereiken te realiseren. Één van de doelarchitecturen (Rijks App Store) is opgezet conform het TOGAF Architecture Development Model. Bij 3 andere doelarchitecturen (DWR, DWR-Zoeken en GRC) is een functionele benadering gevolgd waarbij gewerkt is met zgn. 'personas'. Deze laatste aanpak is heel positief ontvangen, omdat heel duidelijk wordt ingezoomd op het wensbeeld van functionarissen (lees gebruikers).
De werkwijze die nogal eens wordt gebruikt om ze tot stand te laten komen
In de meeste gevallen is een start gemaakt met een 2- of 3 daagse werkconferentie met ca. 10 architecten. Een oproep tot deelname is in enkele gevallen gedaan via de LinkedIn-groep "Rijksarchitecten zonder Grenzen". Het resultaat is voorgelegd aan de opdrachtgever en na de opdracht om op basis hiervan een vervolg te geven is altijd een schrijfgroep aan de slag gegaan. De tussentijdse produkten en het eindprodukt zijn voorgelegd aan een klank- of reviewgroep. Het eindprodukt is vervolgens aan de opdrachtgever voorgelegd.
De vaststelling van doelarchitecturen
Het verzoek om een doelarchitectuur op te stellen is meestal gedaan door de CIO belast met de portefeuille Architectuur als lid van de stuurgroep Generieke informatievoorziening. Eindprodukten zijn aan deze stuurgroep voorgelegd en via 1 of meerdere subcommissies van het CIO-Beraad doorgeleid naar de het CIO-Beraad ter vaststelling.
Deze pagina is voor het laatst bewerkt op 24 sep 2016 om 04:08.