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.

Architectuur en Projecten

Wat, Hoe, Doen

We voeren projecten en programma's uit omdat we verandering en vernieuwing willen creëren. Werken aan projecten en programma's is DOEN. Voordat we starten met het DOEN is er bewuste beslissing genomen dat dit stuk vernieuwing of verandering noodzakelijk is. Het bepalen WAT we doen op het gebied van informatiehuishouding noemen we Informatieplanning. HOE we projecten en programma's uitvoeren wordt bepaald door de randvoorwaarden, uitgangspunten en kaders die het project meekrijgt: Architectuur.

de figuur toont de relatie tussen "architectuur", "informatieplanning" en "het uitvoeren van projecten en programma's. De figuur wordt in de onderstaande tekst toegelicht.
Architectuur, Informatieplanning in relatie tot uitvoeren van projecten/programma's


Informatieplanning: Wat gaan we doen?

De organisatie heeft een missie, visie, een bedrijfsstrategie en bedrijfsdoelen. Vanuit een informatiestrategie wordt via informatieplanning geregeld dat dat de informatiehuishouding van de organisatie kan bijdragen aan het bereiken van de bedrijfsdoelen. In een informatieplan vindt een vertaling plaats van de bedrijfsstrategie naar de informatiehuishouding:

  • Wat is de huidige situatie van de informatiehuishouding (A)?
  • Wat is de gewenste situatie? (B)
  • En welke veranderingen (projecten) moeten we doorvoeren om van A naar B te komen.

Op die wijze komt een informatie-strategie, een informatie(jaar)plan en uiteindelijk een projectenportfolio tot stand. Met andere woorden: Informatieplanning leidt tot het antwoord op de vraag "Wat gaan we doen?"

Architectuur: Hoe gaan we het doen?

En dan wordt er gebouwd, veranderd. Projecten worden uitgevoerd. Soms projecten die passen in een programma. En juist bij het uitvoeren van projecten en programma's komt het er op aan dat we de juiste uitgangspunten gebruiken:

  • Hoe gaan we een nieuwe voorziening/dienst vormgeven?
  • Welke uitgangspunten hanteren we?
  • Aan welke afspraken moeten we ons houden?

De uitgangspunten en afspraken rondom de informatiehuishouding worden vastgelegd in bijvoorbeeld:

  • Referentie-architecturen zoals NORA, waarin organisatie-overstijgende afspraken/kaders worden vastgelegd.
  • Enterprise-architectuur zoals deze EAR, waarin organisatie-brede afspraken/kaders worden vastgelegd.
  • Doelarchitecturen, waarin de soll-situatie van specifieke onderwerpen worden vastgelegd.


Realisatie van veranderingen: Projecten en Programma's

Vanuit de projectenportfolio wordt vervolgens een project opgestart. In de initiatiefase wordt aan de hand van de Projectbrief een Project-Start-Architectuur (PSA) opgesteld waarin de in de organisatie geldende principes, normen en kaders zijn vertaald c.q. concreet zijn gemaakt naar de betreffende projectomgeving. Dit betekent dat de kaders, afspraken, uitgangspunten, principes, standaarden en generieke bouwstenen, die van toepassing zijn op het project worden vertaald naar de projectomgeving.
De PSA vormt input voor het Project Inititiatie Document (PID) en de businesscase en is kaderstellend voor de projectdeliverables (zoals de solutionarchitectuur, gerealiseerde componenten, etc.). De PSA wordt daarbij ook gebruikt door de architectuurorganisatie om steeds te toetsen of de projectdeliverables nog steeds voldoen aan de PSA of dat er sprake is van afwijkingen.
In het schema hieronder is dit nog eens als "proces" uitgebeeld, startend bij de bedrijfsstrategie, uiteindelijk leidend tot een daadwerkelijke verandering.
Meer informatie over de PSA is elders in de EAR via het menu te vinden.

de figuur geeft het "proces" weer waarin veranderingen tot stand worden gebracht, startend bij de bedrijfsstrategie, ia een informatiestrategie en infomratieplan, uiteindelijk leidend tot een daadwerkelijke verandering middels een project. In de figuur worden tevens de architectuurdocumenten geplaatst. De figuur wordt in de begeleidende tekst verder toegelicht.
Van bedrijfsstrategie tot en met gerealiseerde verandering



Projectbelang vs. Architectuurafspraken

de figuur beschrijft de wijze waarop issues rondom projecten en architectuur iedere keer naar een hoger niveau worden geëscaleerd. De figuur wordt in de tekst verder omschreven.
project versus architectuurbelang: hoe te escalleren

Omdat de projectbelangen (gericht op korte termijn realiseren van oplossing binnen tijd, geld en kwaliteit) en architectuurbelangen (gericht op lange termijn, toewerkend naar “stip op de horizon”) divers van aard zijn, is de kans op een geschil tussen de architectuurorganisatie en de projectorganisatie bij uitvoering van projecten aanzienlijk. Het schema hiernaast laat een generiek escalatiemodel zien voor die gevallen wanneer een projectdeliverable niet voldoet aan de kaders zoals deze zijn geformuleerd in de PSA.

Let op! In het schema wordt uitgegaan van een ideaal situatie waarbij een volledig ingerichte architectuur-organisatie bestaat binnen de organisatie. Dat zal vaak niet het geval zijn. Aan de hand van de specifieke organisatie moet dit escallatie-model vertaald worden naar de eigen situatie.

Kern van het model is dat indien er een issue ontstaat tussen project- en architectuurbelang, iedere keer afstemming plaatsvindt. Wanneer deze afstemming niet leidt tot overeenstemming wordt het issue naar het naast hoger niveau gebracht om daar tot overeenstemming te komen. Als uiteindelijk op het een na hoogste niveau de CIO en de Proceseigenaar er niet uitkomen. Rest (in geval van een kerndepartement) alleen nog maar besluitvorming in de bestuursraad.

In de architectuurboard is een vertegenwoordiging van de business, ICT en project / programma op directeurenniveau die architecturen vaststelt en geschillen beslecht.

Deze pagina is voor het laatst bewerkt op 12 aug 2016 om 03:05.