Architectuurproducten
Onder architectuurproducten verstaan we de documenten die geproduceerd worden in het kader van architectuurwerk. Hieronder vallen "inhoudelijke" producten zoals een domeinarchitectuur (bestaande uit principes, modellen etc.) maar vooral ook "procesgerelateerde" producten zoals architectuurbesluiten en adviezen. Onderstaande figuur toont de architectuurproducten (en enkele gerelateerde producten uit de strategische veranderketen) en hun onderlinge afhankelijkheden.
De architectuurproducten die als onderdeel van het architectuurwerk geproduceerd worden, gebruiken andere architectuurproducten als input of leiden zelf weer tot nieuwe architectuurproducten. Het product aan de kant van de pijlpunt is afhankelijk van het product aan de andere kant van de relatie als input. Voor de volledigheid zijn ook enkele niet-architectuurproducten uit de veranderketen getoond.
Hieronder worden de producten nader toegelicht.
| Architectuurproduct | Beschrijving | Sjabloon |
|---|---|---|
| Architectuuradvies | Concreet advies over een architectuurgerelateerd knelpunt. Dergelijke knelpunten kunnen ontstaan gedurende definitie en uitvoering van een project (wanneer de projectarchitectuur is vertaald naar detailontwerpen). Enterprise- en domeinarchitecten kunnen desgewenst proactief en op verzoek adviezen geven. Een architectuuradvies is niet noodzakelijkerwijs een document; een whiteboardtekening of bilaterale discussie kan soms genoeg zijn op een knelpunt op te lossen. | Sjabloon voor Architectuuradvies |
| Architectuurafwijkingrapport | Beschrijving van de afwijking van de enterprise- of domeinarchitectuur in een informatieplan, projectarchitectuur of "change". Het architectuurafwijkingrapport bevat een beschrijving van de afwijking zelf, de impact op de architectuur indien goedgekeurd, de impact indien afgewezen, en een advies (aanbeveling) van de architect aan de Architectuurboard. | Sjabloon voor Architectuurafwijkingrapport |
| Architectuurbesluit | Beschrijving van een (formeel) besluit dat genomen is door de Architectuurboard, inclusief de implicaties. We onderscheiden:
| Sjabloon voor Architectuurbesluit |
| Architectuurdoelen en KPI’s | Beschrijving van doelen en key performance indicators voor architectuur. Architectuurprocessen moeten worden beheerd en daarom zijn doelen en KPI’s nodig om te kunnen sturen met behulp van de "plan-do-check-act"-cyclus. | |
| Architectuurimpactanalyse | Beschrijving van de architecturale impact van een voorgestelde (organisatie-)verandering. We onderscheiden:
| Sjabloon voor Architectuurimpactanalyse |
| Architectuurrepository | De architectuurrepository is niet zozeer een architectuurproduct maar vooral een middel om architectuurprincipes en -modellen te creëren en te beheren op een gestructureerde manier. Het ondersteunt ook het maken van impactanalyses voor de ontwikkeling en evaluatie van de architectuur zelf, voor het opstellen van projectarchitecturen en voor het beoordelen van de impact van voorgestelde veranderingen. | |
| Architectuurreviewrapport | Gedurende de uitvoering van een project, ziet de domeinarchitect er op toe dat de geïmplementeerde projectarchitectuur in lijn is met de enterprise- en domeinarchitecturen. Voor dat doel zal hij of zij periodieke en/of gatewayreviews uitvoeren. Het resulterende reviewrapport beschrijft de bevindingen inclusief afwijkingen en richtlijnen voor het oplossen van de afwijkingen. Elk project moet in ieder geval een review aan het eind van het project hebben. | Sjabloon voor Architectuurreviewrapport |
| Architectuurwijzigingsverzoek | Beschrijving van een wijzigingsverzoek in de enterprise of domeinarchitectuur, inclusief status, impact, eigenaar, beoordeling, etc. Architectuurwijzigingsverzoeken kunnen door iedereen ingediend worden. Zij worden geregistreerd en afgehandeld conform het reguliere wijzigingsproces. Elk architectuurwijzigingsverzoek start met status "initieel" en eindigt met status "afgerond". | Sjabloon voor Architectuurwijzigingsverzoek |
| Domeinarchitectuur | Een domeinarchitectuur bestaat uit principes en modellen die ontwerpkeuze beschrijven gerelateerd aan een bepaald deelgebied binnen de organisatie. Domeinen kunnen volgen uit een opdeling naar product(groep), businessunit, architectuurlaag enz. Domeinarchitecturen conformeren zich aan de enterprisearchitectuur en werken ontwerpkeuzes daaruit verder uit tot een detailniveau dat voor hetdesbetreffende domein volstaat. | |
| Enterprisearchitectuur | De enterprisearchitectuur bestaat uit principes en modellen die op organisatiebreed niveau de (architecturele) ontwerpkeuzes beschrijven die richtinggevend zijn voor de inrichting van onder meer bedrijfsprocessen, informatiestromen en applicaties. In beginsel heeft elke organisatie één enterprisearchitectuur. Die moet nauw afgestemd zijn op de organisatiestrategie, zodat aan de daarin gestelde doelen een bijdrage wordt geleverd. De enterprisearchitectuur is idealiter vastgelegd in een gestructureerde repository maar moet ook ondersteunend materiaal bevatten waarmee de ontwerpkeuzes uitgelegd worden aan de hand van illustraties, teksten enz., gericht op alle relevante doelgroepen. | |
| Projectarchitectuur | Beschrijving van het architecturale ontwerp en de impact van een voorgesteld project. Dit is een belangrijke deliverable van de projectdefinitiefase. Als de projectarchitectuur in lijn is met de enterprisearchitectuur, kan deze worden goedgekeurd door de enterprisearchitect. Zo niet dan is goedkeuring nodig van de Architectuurboard middels een formele architectuurbeslissing. Veelal wordt de term projectstartarchitectuur (PSA), een overblijfsel van de verouderde architectuurmethode DYA, gebruikt. | Sjabloon voor Projectarchitectuur |
Verantwoordelijkheden
Onderstaande figuur toont hoe de verantwoordelijkheden met betrekking tot architectuurproducten in de organisatie kunnen worden belegd:
De architectuurproducten (bovenaan naast elkaar weergegeven) komen tot stand door samenwerking tussen de betrokken architectuurrollen. De figuur toont de verantwoordelijkheden volgens de bekende RACI-methodiek.
In rood is weergegeven welke rol verantwoordelijk is voor een architectuurproduct. In beginsel is altijd één rol verantwoordelijk voor de totstandkoming van een architectuurproduct. Dat bij architectuurimpactanalyse en architectuuradvies twee rollen rood zijn gekleurd, komt omdat de verantwoordelijkheid voor adviezen en impactanalyses op enterpriseniveau is belegd bij de enterprisearchitect; op domeinniveau is die belegd bij een domeinarchitect.
In oranje is weergegeven welke rollen uitvoerend zijn bij de totstandkoming van een architectuurproduct, voor zover dat niet tevens de verantwoordelijke is. Meerdere rollen kunnen uitvoerend zijn.
In geel is weergegeven welke rollen geconsulteerd worden bij de totstandkoming van een architectuurproduct. Dit betekent dat de desbetreffende rollen betrokken worden bij het opstellen/uitvoeren op basis van hun expertise of verantwoordelijkheid. Zij geven advies waar mogelijk.
In wit is weergegeven welke rollen geïnformeerd worden over de totstandkoming van een architectuurproduct. Dit betekent dat de desbetreffende rollen niet betrokken worden bij het opstellen/uitvoeren maar wel geïnformeerd dat het product gereed is. Normaliter zullen zij het product ook kunnen raadplegen.
Terug naar Inleiding architectuurbesturing RA of door naar Architectuurprocessen.