NORA dochters: verschil tussen versies
(Ik heb mijn e-mailadres beschermd. Het lijkt me zinvol dat ook voor anderen te doen. Laten we elkaar niet aan meer spam helpen!) |
(referentie naar nieuwe informatie in sjabloon Archief) |
||
| (19 tussenliggende versies door 4 gebruikers niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
De NORA | {{Archief|Zie [[NORA Familie]] en de [[Architecturen NORA Familie]] voor meer actuele informatie over (dochter-)architecturen.}} | ||
__TOC__ [[Categorie:Noradochterskruimel]] | |||
==Visie op dochters== | |||
NORA is het interoperabiliteitsraamwerk voor de Nederlandse overheid en vertaalt daartoe wetgeving, beleid en standaarden naar architectuurprincipes, beschrijvingen en modellen. Het doel is het verbeteren van de samenwerking tussen (overheids)organisaties en de verbetering van dienstverlening. | |||
Volgens Kabinetsbesluit van juni 2008 geldt NORA als referentie-architectuur voor de ontwikkeling en realisatie van ICT-projecten van rijksdiensten. Een jaar later heeft het Kabinet NORA vastgesteld als norm voor de gehele overheid. Dit betekent dat alle architecturen van de individuele overheidsorganisaties en projecten zich blijvend moeten conformeren aan NORA. Daarbij is de wens dat ook private organisaties met een publiekrechtelijke taak voldoen aan NORA. | |||
Echter, al deze organisaties zijn niet per se directe gebruikers van NORA. In de afgelopen jaren zijn immers veel referentie-architecturen ontwikkeld. Denk aan de NORA-dochters van de bestuursdomeinen, te weten EAR (Rijk), GEMMA (Gemeenten), PETRA (Provincies) en WILMA (Waterschappen). Of domein- en ketenarchitecturen, zoals ROSA voor het Onderwijs, KARWEI voor Werk en Inkomen en SRK voor de Strafrechtketen. | |||
Veel overheidsorganisaties maken gebruik van deze referentie-architecturen. Ze kunnen echter alleen aansluiten op de afspraken in hun domeinen en ketens én tevens blijvend conformeren aan NORA, wanneer ook deze domein- en ketenarchitecturen zich blijvend conformeren aan NORA. | |||
Daarmee is NORA het referentiekader voor alle andere (referentie)architecturen. Content van NORA, zoals principes, standaarden, normen en definities moeten dus integraal worden overgenomen (of er wordt naar verwezen). Er is geen ruimte voor herformuleringen of “cherry picking.” Content afkomstig uit NORA kan eventueel worden aangevuld of verdiept, maar niet worden gewijzigd. | |||
[[Bestand:Relatie NORA en dochters.png|Relatie NORA en dochters|alt="Schematische weergave relatie NORA met dochters. Wetten, beleid en standaarden komen in NORA. NORA wordt verdiept, aangevuld, overerfd in dochters. Organisaties passen dat toe in eigen Enterprise Architectuur. Architectuurvraagstukken leggen de omgekeerde route af."]] | |||
Een organisatie kan vraagstukken ten aanzien van haar eigen Enterprise Architectuur (EA) aankaarten bij de beheerders van de domein- en ketenarchitecturen waarbinnen zij werkzaam is. Uitgangspunt is dat dáár, in de samenwerking, een oplossing wordt gevonden. Indien dat niet mogelijk is, kan door de beheerders van die domein- en ketenarchitecturen het vraagstuk worden aangekaart bij de beheerder van NORA. Dat kan resulteren in een wijziging in NORA. Een wijziging in NORA zal moeten leiden tot aanpassingen in álle dochters. | |||
De beheerders van die NORA-dochters zijn verantwoordelijk voor het juist en tijdig doorvoeren van die aanpassingen. Hierover worden afspraken gemaakt. | |||
In de praktijk blijkt dat niet eenvoudig te zijn, met name door de verschillende stadia van ervaring met het werken met en onder architectuur en door verschillen in prioriteitstelling en beschikbare capaciteit. Door bestaande hulpmiddelen, zoals de semantische wiki’s, meer met elkaar te koppelen en kennis met elkaar te delen, wordt beoogd de beheerlast te verminderen. Daarnaast ontstaat de wens om meer gezamenlijke afspraken te maken over de uitwerking en het beheer van thema’s. | |||
<ref>Bron:[[Heeft bron::Beheer NORA Strategisch Kader]]</ref> | |||
===Organisatie-gerichte referentie-architectuur op strategisch en tactisch niveau...=== | |||
Enkele NORA-dochters zijn gericht op de specifieke bestuurslagen van de Nederlandse overheid en de achterliggende overheidsorganisaties, te weten: | |||
Een aantal referentiearchitecturen voor verschillende bestuurslagen is publiek toegankelijk via een wiki: | |||
* [[GEMMA (Gemeentelijke ModelArchitectuur)]] | |||
* [[EAR (EnterpriseArchitectuur Rijksdienst)]] | |||
* [[PETRA (Provinciale EnTerprise ReferentieArchitectuur)]] | |||
* [[WILMA (Waterschaps Informatie & Logisch Model Architectuur)]] | |||
De invalshoek van deze referentie-architecturen is de positie van de organisatie en dat ondersteunt de ontwikkeling en beheer van hun Enterprise Architecturen. | |||
Een voorbeeld hiervan is het Gemeentelijk Fundament, dat een blauwdruk is van de Enterprise Architectuur van een gemeentelijke organisatie. Daarin is tevens zichtbaar gemaakt welke (NUP) voorzieningen relevant zijn. | |||
===...verbinden met domein- en ketendienst-gerichte architectuur op operationeel niveau=== | |||
Volgens de visie op dienstverlening zouden overheidsdiensten niet gebonden moeten zijn aan individuele overheidsorganisaties, maar aan de overheid als geheel. Om een indruk te geven hoe die samenwerking vorm kan worden gegeven, waarbij enerzijds gebruik wordt gemaakt van de gemeenschappelijke (NUP)voorzieningen en anderzijds ruimte blijft voor de zelfstandigheid van de betreffende overheidsorganisaties, zijn filmpjes gemaakt. | |||
Voor de architectuur van de overheid betekent dit, dat domein- en ketendienst-architecturen naast de invalshoek "de dienst aan de burger en het bedrijf" ook de invalshoek "het samenwerken van de organisaties" moet kennen en dat overheidsorganisaties hun Enterprise Architectuur verbinden aan die domein- en ketendienstarchitecturen. | |||
== | ==De NORA binnen Europees verband== | ||
Zoals NORA-dochters aansluiten op de NORA, sluit de NORA aan op de architectuur die Nederland afspreekt op Europees niveau en is gedefinieerd in de European Interoperability Reference Architecture (EIRA). Zie ook [[Architectuur internationaal]]. | |||
== | {{afbeelding met beschrijving|EIRA architectuurlagen.png}} | ||
==Alle dochter-architecturen== | |||
{{#ask: [[Category:Standaarden]] [[Category:Architecturen]] | |||
| ?Werkingsgebied | |||
| ?Beschrijving | |||
| limit=80 | |||
}} | |||
[[Categorie:noradochterskruimel| ]] | |||
[[Categorie:Elementen]] | |||
<references /> | <references /> | ||
Huidige versie van 4 okt 2023 om 15:30
Zie NORA Familie en de Architecturen NORA Familie voor meer actuele informatie over (dochter-)architecturen.
Visie op dochters[bewerken]
NORA is het interoperabiliteitsraamwerk voor de Nederlandse overheid en vertaalt daartoe wetgeving, beleid en standaarden naar architectuurprincipes, beschrijvingen en modellen. Het doel is het verbeteren van de samenwerking tussen (overheids)organisaties en de verbetering van dienstverlening.
Volgens Kabinetsbesluit van juni 2008 geldt NORA als referentie-architectuur voor de ontwikkeling en realisatie van ICT-projecten van rijksdiensten. Een jaar later heeft het Kabinet NORA vastgesteld als norm voor de gehele overheid. Dit betekent dat alle architecturen van de individuele overheidsorganisaties en projecten zich blijvend moeten conformeren aan NORA. Daarbij is de wens dat ook private organisaties met een publiekrechtelijke taak voldoen aan NORA.
Echter, al deze organisaties zijn niet per se directe gebruikers van NORA. In de afgelopen jaren zijn immers veel referentie-architecturen ontwikkeld. Denk aan de NORA-dochters van de bestuursdomeinen, te weten EAR (Rijk), GEMMA (Gemeenten), PETRA (Provincies) en WILMA (Waterschappen). Of domein- en ketenarchitecturen, zoals ROSA voor het Onderwijs, KARWEI voor Werk en Inkomen en SRK voor de Strafrechtketen.
Veel overheidsorganisaties maken gebruik van deze referentie-architecturen. Ze kunnen echter alleen aansluiten op de afspraken in hun domeinen en ketens én tevens blijvend conformeren aan NORA, wanneer ook deze domein- en ketenarchitecturen zich blijvend conformeren aan NORA.
Daarmee is NORA het referentiekader voor alle andere (referentie)architecturen. Content van NORA, zoals principes, standaarden, normen en definities moeten dus integraal worden overgenomen (of er wordt naar verwezen). Er is geen ruimte voor herformuleringen of “cherry picking.” Content afkomstig uit NORA kan eventueel worden aangevuld of verdiept, maar niet worden gewijzigd.
Een organisatie kan vraagstukken ten aanzien van haar eigen Enterprise Architectuur (EA) aankaarten bij de beheerders van de domein- en ketenarchitecturen waarbinnen zij werkzaam is. Uitgangspunt is dat dáár, in de samenwerking, een oplossing wordt gevonden. Indien dat niet mogelijk is, kan door de beheerders van die domein- en ketenarchitecturen het vraagstuk worden aangekaart bij de beheerder van NORA. Dat kan resulteren in een wijziging in NORA. Een wijziging in NORA zal moeten leiden tot aanpassingen in álle dochters.
De beheerders van die NORA-dochters zijn verantwoordelijk voor het juist en tijdig doorvoeren van die aanpassingen. Hierover worden afspraken gemaakt.
In de praktijk blijkt dat niet eenvoudig te zijn, met name door de verschillende stadia van ervaring met het werken met en onder architectuur en door verschillen in prioriteitstelling en beschikbare capaciteit. Door bestaande hulpmiddelen, zoals de semantische wiki’s, meer met elkaar te koppelen en kennis met elkaar te delen, wordt beoogd de beheerlast te verminderen. Daarnaast ontstaat de wens om meer gezamenlijke afspraken te maken over de uitwerking en het beheer van thema’s.
[1]
Organisatie-gerichte referentie-architectuur op strategisch en tactisch niveau...[bewerken]
Enkele NORA-dochters zijn gericht op de specifieke bestuurslagen van de Nederlandse overheid en de achterliggende overheidsorganisaties, te weten: Een aantal referentiearchitecturen voor verschillende bestuurslagen is publiek toegankelijk via een wiki:
- GEMMA (Gemeentelijke ModelArchitectuur)
- EAR (EnterpriseArchitectuur Rijksdienst)
- PETRA (Provinciale EnTerprise ReferentieArchitectuur)
- WILMA (Waterschaps Informatie & Logisch Model Architectuur)
De invalshoek van deze referentie-architecturen is de positie van de organisatie en dat ondersteunt de ontwikkeling en beheer van hun Enterprise Architecturen. Een voorbeeld hiervan is het Gemeentelijk Fundament, dat een blauwdruk is van de Enterprise Architectuur van een gemeentelijke organisatie. Daarin is tevens zichtbaar gemaakt welke (NUP) voorzieningen relevant zijn.
...verbinden met domein- en ketendienst-gerichte architectuur op operationeel niveau[bewerken]
Volgens de visie op dienstverlening zouden overheidsdiensten niet gebonden moeten zijn aan individuele overheidsorganisaties, maar aan de overheid als geheel. Om een indruk te geven hoe die samenwerking vorm kan worden gegeven, waarbij enerzijds gebruik wordt gemaakt van de gemeenschappelijke (NUP)voorzieningen en anderzijds ruimte blijft voor de zelfstandigheid van de betreffende overheidsorganisaties, zijn filmpjes gemaakt. Voor de architectuur van de overheid betekent dit, dat domein- en ketendienst-architecturen naast de invalshoek "de dienst aan de burger en het bedrijf" ook de invalshoek "het samenwerken van de organisaties" moet kennen en dat overheidsorganisaties hun Enterprise Architectuur verbinden aan die domein- en ketendienstarchitecturen.
De NORA binnen Europees verband[bewerken]
Zoals NORA-dochters aansluiten op de NORA, sluit de NORA aan op de architectuur die Nederland afspreekt op Europees niveau en is gedefinieerd in de European Interoperability Reference Architecture (EIRA). Zie ook Architectuur internationaal.
Ook andere parameters kunnen meegegeven worden (maximaal 6 andere), zo lang die niet een is-teken bevatten.
