Heeft u vragen en/of opmerkingen over deze pagina, mailto:postbusear@rijksoverheid.nl


De EAR wordt opgevolgd door de RORA (RijksOverheid Referentie Architectuur), hier vindt u meer informatie over de RORA.

Beheermodel Enterprise Architectuur Rijksdienst

Versie door EARbot (overleg | bijdragen) op 27 sep 2016 om 04:06
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)

Beheer van de EAR: de rollen en verantwoordelijkheden

In dit hoofdstuk wordt aangegeven op welke wijze de EAR beheerd wordt. Kern van dit hoofdstuk:

  • Brondocumenten in de EAR kennen hun eigen vaststellings- en beheerproces. De EAR-redactie is NIET verantwoordelijk voor het beheer van de brondocumenten zelf. De EAR-redactie is wel verantwoordelijk voor het netjes verzamelen van deze brondocumenten en het in samenhang beschrijven ervan.
  • Door opname van brondocumenten in de EAR wordt de EAR(-redactie) niet verantwoordelijk voor de uitvoering van de ambities uit de brondocumenten.

De eigenaar van de EAR

De Directeur Informatiseringsbeleid Rijksdienst is als RijksCIO eigenaar van de EAR. De eigenaar:

  • Stelt, op basis van een jaarlijks op te stellen redactieplan, de capaciteit en middelen beschikbaar voor de doorontwikkeling en het beheer van de EAR.
  • Zorgt ervoor dat de doorontwikkeling van de EAR onderwerp van gesprek is tijdens de kwartaaloverleggen die de RijksCIO houdt met de portefeuillehouder Architectuur en Standaarden.

De eigenaars van de brondocumenten

Met opname van brondocumenten (bijv. doelarchitecturen) in de EAR gaat het eigenaarschap van het betreffende document NIET over naar de RijksCIO (de EAR-eigenaar). De verantwoordelijkheid voor beheer, doorontwikkeling en implementatie van een doelarchitectuur of standaard blijft bij de oorspronkelijke eigenaar van het document liggen.

In de regel geldt dat brondocumenten die worden opgenomen in de EAR in hun eigen vaststellingsproces het document ter advies hebben voorgelegd aan de Architectuurboard Rijksdienst.

CIO-Beraad

CIO-Beraad stelt jaarlijks op basis van de het jaarplan van de redactie vast:

  • dat het beheerproces van de EAR op orde is;
  • dat de inhoud van de EAR kaderstellend is voor projecten/programma’s/ontwikkelingen met een I-component.
  • welke brondocumenten moeten worden toegevoegd dan wel heroverwogen (gewijzigd).

De portefeuillehouder A&S van CIO-Beraad

De portefeuillehouder Architectuur en Standaarden in CIO-Beraad:

  • Ziet toe op de kwaliteit van de EAR.
  • Ziet toe op het functioneren van de EAR-redactie.


De redactie

De redactie bestaat uit ca. 8-10 leden en is opgebouwd uit leden van het team A&S bij DIR en uit architecten van de beleidsdepartementen en uitvoeringsorganisaties. De redactie:

  • Voegt nieuwe of herziene brondocumenten toe aan de EAR.
  • Draagt zorg, op basis van input van de brondocument-eigenaar, voor de vulling/wijziging van het kennismodel dat onderdeel uitmaakt van de EAR-Wiki.
  • Zorgt voor aanpassingen/aanvullingen op basis van het nieuwe/herziene document.

De redactieleden nemen allen een “deel” van de Wiki als redacteur voor hun rekening. Er is in ieder geval een redacteur voor de 7 I-domeinen.

De redactieleden komen één keer per maand bijeen om te bespreken:

  • de werkzaamheden van de afgelopen periode;
  • de voorziene werkzaamheden van de komende periode;
  • de activiteiten rondom communicatie (zie hoofdstuk gebruik);
  • de algehele kwaliteit van de EAR.

De redactie van de EAR geeft adviezen aan de werkgroep EAR over de gewenste/noodzakelijke totstandbrenging van nieuwe brondocumenten.

Indien de redactie signaleert dat brondocumenten onvolkomenheden c.q. strijdigheden met eerder vastgestelde brondocumenten bevatten, wordt hiervan in eerste instantie melding gemaakt aan de eigenaar van het document. Indien dit niet leidt tot gewenste veranderingen, wordt dit met de werkgroep EAR besproken, zodat dit kan leiden tot voorstellen richting CIO-Beraad.

De redactie organiseert “het ophalen van feedback” over de EAR. Dit wordt deels via de website zelf georganiseerd (lezers kunnen reageren, suggesties doen, tekstvoorstellen doen), deels organiseert de redactie deze feedback door jaarlijks een enquête uit te zetten over de EAR (bij architecten en bij leden van de specifieke doelgroepen waar “views” voor zijn gemaakt. De feedback en de wijze waarop met deze feedback is/wordt omgegaan, worden expliciet gemaakt in het EAR-jaarverantwoording.

De redactie kent een hoofdredacteur die wordt aangewezen door de RijksCIO. De hoofdredacteur is één van de redactieleden die de dagelijkse coördinatie van de redactiewerkzaamheden op zich neemt. De hoofdredacteur maakt een vertaling van het jaarplan naar een werkplan en stuurt de redactieleden daarop aan.

De werkgroep EAR

Drie maal per jaar komt de werkgroep EAR bijeen. Deze werkgroep bestaat uit:

  • (een vertegenwoordiging van) de redactie EAR;
  • de portefeuillehouder A&S van het CIO-Beraad;
  • de voorzitters van de ABR, Standaardisatiecommissie en de werkgroep professionalisering;
  • evt. aangevuld met nader aan te wijzen specialisten.

De werkgroep zorgt voor een jaarlijks EAR-jaarplan dat voor de start van een kalenderjaar wordt voorgelegd aan het CIO-Beraad via de subcommissie A&S. Op basis van dit EAR-jaarplan:

  • Voert de redactie haar werkzaamheden aan de EAR uit.
  • Worden de gewenste/noodzakelijke brondocumenten tot stand gebracht c.q. worden bestaande brondocumenten heroverwogen/gewijzigd.

In het EAR-jaarplan dat door het CIO-Beraad wordt vastgesteld wordt per activiteit aangegeven wie daarvoor opdrachtgever is en waar de noodzakelijke capciteit vandaan komt.

De werkgroep kent een voorzitter die de vergaderingen van de werkgroep voorzit en zorg voor tijdige totstandkoming van het EAR-jaarplan en de EAR-jaarverantwoording.

De voorzitter van de werkgroep wordt aangewezen door de portefeuille-houder A&S in het CIO-Beraad.

Doelgroepen EAR-website/ view-eigenaren

De EAR kent meerdere doelgroepen. Bijvoorbeeld:

  1. (i-)bestuurders en (i-)beslissers;
  2. projectverantwoordelijken (opdrachtgevers, programmamanagers, projectmanagers);
  3. adviseurs en architecten.

Op het niveau van de EAR wordt geen onderscheid gemaakt tussen:

  • de vraagkant van Informatievoorziening;
  • de regieorganisaties;
  • de aanbodkant van Informatievoorziening.

De EAR beschrijft voor zowel vraag-, regie- als aanbodkant van de Informatievoorziening de afspraken en kaders.

De “kale” EAR-Wiki is bedoeld voor adviseurs, architecten en informatiemanagers binnen de Rijksdienst.

Echter, voor specifieke doelgroepen worden specifieke “views” gemaakt. Zo’n view presenteert voor de betrokken doelgroep de voor hen van belang zijnde onderwerpen uit de EAR, bijvoorbeeld:

  • wat moet ik doen als bestuurder? wat moet ik weten?
  • ik ben programma-manager, waarom is architectuur van belang voor mijn programma? En wat moet ik regelen binnen mijn programma?

De I-atlas is een voorbeeld van zo’n “view”, een bestuurlijke view. Er wordt nu ook een view gemaakt voor project- en programmamanagers.

Op dit moment wordt bijvoorbeeld gedacht aan een view op de EAR voor auditors, toezichthouders.

Indien behoefte is aan een view op de EAR wordt op zoek gegaan naar een View-eigenaar. Wie wil dat de view er komt en wie wil energie, middelen en capaciteit te beschikking stellen om de view op te stellen en te beheren?

Bij het beheren van een view moet o.a. geregeld worden dat wijzigingen in de EAR (bijvoorbeeld als gevolg van nieuwe/herziene brondocumenten) ook worden doorgevoerd in de betreffende view. De beheerder van een view neemt zitting in de redactie EAR.

Het beheer van de EAR: het proces

Op basis van de rollen en verantwoordelijkheden, zoals omschreven in hoofdstuk 2, ontstaat het in dit hoofdstuk omschreven beheerproces. Bij de beschrijving hiervan is onderscheid gemaakt tussen:

  • de opname van architectuurdocumenten die binnen de Rijksdienst worden opgesteld (paragraaf 3.1);
  • de opname in EAR van vastgestelde I-standaarden en I-bouwstenen (paragraaf 3.2);
  • de overerving van principes en kaders vanuit NORA (paragraaf 3.3).

De totstandkoming van documenten die in de EAR opgenomen worden kan meerdere “triggers” hebben.

Bij de beschrijving van het proces gaan we hier nu uit van de situatie dat de wens om het document op te stellen is voortgekomen uit het jaarplan EAR.

Voorbereiding

Jaarplan EAR De werkgroep EAR levert in het najaar een concept jaarplan EAR op. In dit jaarplan worden de activiteiten rondom de doorontwikkeling van de EAR opgenomen. De activiteiten worden voorzien van de noodzakelijke middelen (geld en capaciteit). Tevens wordt per activiteit aangegeven wie vanuit het CIO-Beraad de aansturing doet (portefeuillehouder) en functioneert als opdrachtgever.

Het jaarplan EAR wordt (evt. ingevoegd in het jaarplan CIO-Beraad, fiche A&S) vastgesteld door het CIO-Beraad.

Projectbrief Voor iedere activiteit in het jaarplan EAR wordt een korte projectbrief opgesteld door de portefeuillehouder binnen het CIO-Beraad.

Concept architectuurdocument

deze figuur is een grafische weergaven van het proces dat in de tekst is omschreven met betrekking tot de opname van documenten in de EAR
Opname van documenten in de EAR

Op basis van de uitgangspunten uit de projectbrief en onder aansturing van de portefeuillehouder CIO-Beraad wordt een architectuurdocument in concept opgesteld.

Advies Architectuurboard Rijksdienst De portefeuillehouder vraagt, voordat besluitvorming plaatsvindt, advies aan de Archtiectuurboard Rijksdienst over het betreffende document. De architectuurboard kan, naast algemene vragen als “past dit document” binnen de EAR en “is dit document volwassen genoeg”, op verzoek van de portefeuillehouder ook op specifieke vragen antwoord geven.

Definitief concept Op basis van het advies van de Architectuurboard laat de portefeuillehouder een definitief concept opstellen.

Besluitvorming

De portefeuillehouder brengt het definitieve stuk ter bespreking in de betreffende subcommissie, waarna het stuk wordt doorgeleid naar het CIO-Beraad. Daar vindt dan bespreking en vaststelling van het definitieve concept plaats.

Het aanbiedingsformulier voor stukken voor het CIO-Beraad wordt zodanig aangepast dat aangegeven kan/moet worden of het betreffende stuk opgenomen moet worden in de EAR.

Het advies dat de Architectuur Board Rijksdienst heeft gegeven wordt toegevoegd aan het definitieve concept.

Definitieve versie Op basis van de bespreking en vaststelling in het CIO-Beraad, stelt de opsteller van het stuk een definitieve versie op en laat deze formeel vaststellen door de RijksCIO. Bij het opstellen van deze definitieve versie worden de opmerkingen en/of keuzes van het CIO-Beraad verwerkt en wordt eventuele expliciete besluitvorming op onderdelen zichtbaar gemaakt.

Vertrouwelijkeheid en Privacy Bij het opstellen van het definitieve stuk, wordt een check uitgevoerd of het document vertrouwelijke en/of gevoelige informatie bevat. In dat geval wordt besloten ofwel het document niet te plaatsen in de EAR dan wel de vertrouwelijke/gevoelige onderdelen te verwijderen.

Ditzelfde geldt voor gegevens die privacy van personen schenden.

ICBR-besluitvorming Indien besloten wordt dat het betreffende stuk vastgesteld moet wordein in de ICBR wordt de definitieve versie (formeel als nieuw definitief concept) voorgelegd ter besluitvorming in de ICBR.

Na besluitvorming in de ICBR, worden eventuele aanpassingen in het stuk gedaan en wordt de definitieve versie vastgesteld door de dgOBR.

Opname in EAR

Indien besluitvorming in het CIO-Beraad en/of ICBR heeft plaatsgevonden en is aangegeven dat het stuk onderdeel wordt van de EAR, wordt de definitieve versie van het stuk door de EAR-redactie opgenomen als brondocument in de EAR.


Input voor Kennismodel De EAR bestaat uit drie delen:

  • een ongestructureerd deel (vooral samenhang beschrijvende teksten);
  • de brondocumenten (bijv. via de bibliotheek);
  • een gestructureerd kennismodel.

Het kennismodel zorgt er o.a. voor dat op een snelle manier zicht kan worden verkregen in principes, afspraken, standaarden en bouwstenen die gelden op bepaalde domeinen. Om dit kennismodel op de juiste wijze te vullen, wordt door de opsteller van een definitief architectuurdocument input geleverd voor de vulling van het kennismodel. Deze input bestaat o.a. uit:

  • het aangeven welke richtinggevende principes worden vastgelegd in het betreffende stuk;
  • het aangeven aan welke doelstelling een principe bijdraagt.

De betrokken redacteur vult in overleg met de opsteller van het stuk deze gegevens in het kennismodel.

Beschrijving samenhang Naast het plaatsen van het definitieve architectuurdocument als bron in de EAR en het (aan)vullen van het kennismodel, maakt de betrokken EAR-redacteur een tekst waarin het nieuwe brondocument kort wordt samengevat en de samenhang met andere brondocumenten wordt beschreven.

Opname in EAR van standaarden en bouwstenen

Overerving Overheidsstandaarden College en Forum Standaardisatie

Uitgangspunt bij het beheer van de EAR is dat zoveel als mogelijk gebruik wordt gemaakt van authentieke bronnen en documenten.

Voor de standaarden die door College en Forum Standaardisatie worden vastgesteld geldt dat deze niet opnieuw in de EAR worden “overgetypt”, maar dat deze via een technische voorziening vanuit de website van het Forum worden doorgelinked.

Rijksstandaarden

Aanvullend op de standaarden van het Forum, worden specifieke standaarden voor de Rijksdienst vastgesteld. Deze worden voorbereid door de werkgroep Standaardisatie Rijksdienst en vastgesteld door het CIO-Beraad.

Na vaststelling van deze Rijksdienst-standaarden door het CIO-Beraad worden ze aangeboden aan de EAR-redactie en volgens het proces zoals beschreven in paragraaf 3.1.3 opgenomen in de EAR.

Overerving vanuit NORA

Uitgangspunt bij het beheer van de EAR is dat zoveel als mogelijk gebruik wordt gemaakt van authentieke bronnen en documenten.

Vandaar dat ook voor de principes van NORA (en overheidsbrede generieke bouwstenen/voorzieningen geldt dat die niet (handmatig) worden opgenomen in de EAR maar dat gebruik wordt gemaakt van een technische voorziening waarbij de NORA principes (ook bij wijzigingen) en voorzieningen (ook nieuwe) worden doorgelinked in de EAR.

Deze pagina is voor het laatst bewerkt op 27 sep 2016 om 04:06.