Eigenschap:Documentation
Type eigenschap
:
Text
Geldige waarden
:
Meerdere waarden toegestaan
:
Nee
Weergave op formulieren
:
Tekstvak
Initiële waarde
:
Verplicht veld
:
Toelichting op formulier
:
Subeigenschap van
:
Geïmporteerd uit
:
Formatteerfunctie externe URI
:
Klik op de button om een nieuwe eigenschap te maken:
A
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. +
Artefacten resulterend uit architectuuractiviteiten. We maken onderscheid tussen enterprise- en domeinarchitectuur. Domeinen kunnen organisatiespecifiek zijn. Principes en modellen worden geregistreerd en beheerd in een architectuurrepository. Aanvullend kunnen views gecreëerd worden voor specifieke doelen zoals projectarchitecturen. +
De architectuurbeheercompetentie bestaat uit taken voor het beheren en verwerken van architectuurwijzigingsverzoeken. +
Beschrijving van een (formeel) besluit dat genomen is door de Architectuurboard, inclusief de implicaties. We onderscheiden:
* Goedkeuring van architecturale artefacten (principes en modellen). Goedgekeurde architecturale artefacten vormen "de architectuur" en zijn daarmee de normatieve richting voor alle projecten en veranderingen.
* Besluiten over architectuurafwijkingen. Architectuurafwijkingen kunnen worden afgewezen, onder voorwaarden goedgekeurd, of permanent goedgekeurd (waarmee ze onderdeel worden van de architectuur). +
De architectuurbesluitvormingscompetentie bestaat uit taken voor goedkeuring van architectuurartefacten en besluiten over afwijkingen. +
De architectuurbesturingscompetentie bestaat uit taken voor het stellen van doelen en KPI’s, het aansturen van werkzaamheden en beheren van architectuurmiddelen. +
De Architectuurboard is verantwoordelijk voor de enterprisearchitectuur, stelt doelen en KPI’s voor de architectuur vast, en neemt architectuurbesluiten op organisatieniveau. Elke organisatie hoort één architectuurboard te hebben. Daarin moeten alle belanghebbenden van architectuur vertegenwoordigd zijn: business, IT en de veranderorganisatie (projectuitvoering, informatiemanagement, ...). +
Elke organisatie moet de architetuurcompetenties in dit model belegd hebben om effectief invulling te kunnen geven aan architectuur. Het gaat om in totaal vijftien competenties, gegroepeerd in een vijftal groepen van hoodfcompetenties. +
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. +
Beschrijving van de architecturale impact van een voorgestelde (organisatie-)verandering. We onderscheiden:
* Impactanalyse als onderdeel van de projectdefinitiefase. Doel is prioritering, planning en toewijzing van resources aan een project.
* Impactanalyse ("architectuurgoedkeuring") noodzakelijk voor het vaststellen of een verandering leidt tot een kleine verandering of dat het volledige veranderproces voor projecten moet worden doorlopen. +
De architectuurontwikkelcompetentie bestaat uit taken voor het opstellen van enterprise- en domeinarchitecturen en projectarchitecturen. +
De Architectuurmanager is verantwoordelijk voor het formuleren van architectuurdoelen en KPI's, het sturen van de architectuurwerkzaamheden op de gestelde doelen en voor het (laten) beheren van de architectuurmiddelen en architectuurwijzigingsverzoeken. In beginsel is er één architectuurmanager voor de hele organisatie. +
De architectuurontwikkelcompetentie bestaat uit taken voor het opstellen van enterprise- en domeinarchitecturen en projectarchitecturen. +
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. +
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. +
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. +
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". +
Opslag die niet meer gewijzigd kan worden en lange tijd bewaard moet worden +
Een fysiek goed dat is beschreven als product, dat is gefabriceerd van materiaal en dat in voorraad kan worden genomen. +
Het beheren van meta-informatie over IT objecten, zowel hardware als software. +
Het verzenden of ontvangen van beeld en/of geluid. +
Een reverse proxy die verzoeken authenticeert. +
Het aanvragen van een (aanvullende) autorisatie en het goed/afkeuren van aanvragen voor autorisaties. +
Een file transfer systeem dat gericht is op veilige, internet gebaseerde uitwisseling. +
B
Ondersteunt bericht-gebaseerde integratie met externe partijen. +
Het beheer van de backupvoorzieningen. +
Een kopie maken van gegevens zodat in geval van verstoringen deze weer teruggeplaatst kunnen worden. +
Software die het maken en beheren van backups ondersteunt. +
Een generieke view waarbinnen de meest voorkomende bedrijfsfuncties getoond worden +
Een generieke view waarbinnen +
Een generieke view waarbinnen de meest voorkomende bedrijfsfuncties getoond worden inclusief de gegevensobjecten waar zij toegang toe hebben +
Een generieke view waarbinnen de meest voorkomende bedrijfsfuncties getoond worden inclusief de bijbehorende logische informatie systemen +
Het beheren van bedrijfsregels en het uitvoeren ervan. +
Ondersteunt het maken, beheren en uitvoeren van bedrijfsregels. +
Voorgenomen actie om de impact van een risico preventief dan wel ten tijde van optreden van risico te minimaliseren. +
Beheren van architectuurmiddelen omvat alle activiteiten noodzakelijk voor het uitvoeren van architectuurtaken, zoals beheren van een architectuurrepository en modelleertool, publiceren van architectuurbesluiten, voorbereiden van architectuurboardvergaderingen en creëren en beheren van de architectuurcompetentie en plannen van trainingen. +
Architectuurwijzigingsverzoeken kunnen in alle architectuurgerelateerde processen in de organisatie ontstaan. Ze worden geregistreerd in een register en beoordeeld op hun "ontvankelijkheid"; onbegrijpelijke, onwenselijke en onhaalbare verzoeken worden afgewezen. De indiener wordt daarvan op de hoogte gesteld en het proces eindigt. Haalbare wijzigingsverzoeken worden vervolgens, op gezag en onder verantwoordelijkheid van de enterprisearchitect, beoordeeld op hun impact op de architectuur.
Wanneer sprake is van een wijziging zonder impact, dan spreken we van een redactionele wijziging. Dit soort wijzigingen kan zonder meer verwerkt worden conform het proces "Bijwerken architectuurartefacten". Wanneer sprake is van een wijziging met impact, dan spreken we van een inhoudelijke wijziging. Dit soort wijzigingen behoeft goedkeuring; deze worden verwerkt conform het proces "Wijzigen architectuurartefacten". +
Verzoeken voor het wijzigen van de architectuur komen voort uit (afgeronde) projecten en reguliere "changes", en kunnen worden ingediend door iedereen in de organisatie. Elk verzoek moet worden geregistreerd, beoordeeld, en geclassificeerd als update, wijziging of afwijzing. Updates zijn gedefinieerd als wijzigingen met zero impact. +
Een gedragslijn voor de verwezenlijking van bepaalde doelstellingen. +
Kleine wijzigingen worden geïmplementeerd zonder een uitgebreid projectproces te volgen. Voor het implementeren van een dergelijke wijziging zal een architect de impact analyseren om te borgen dat de wijziging inderdaad geen significante impact heeft. +
Een evaluatie van een medewerker conform het functieprofiel behorend bij formatieplaats. +
Het routeren en vertalen van protocollen en berichten +
Het ondersteunen van het nemen van beslissingen bij het oplossen van complexe problemen. +
Architectuurafwijkingen kunnen ontstaan tijdens op definiëren van een projectarchitectuur of tijdens het toezichthouden op de uitvoering van een project. In beide gevallen is sprake van het verzoek om van de staande enterprise- en/of domeinarchitectuur te mogen afwijken. De eerste stap in de besluitvorming is het bepalen van de impact. Dit is tweeërlei: enerzijds is er de impact van het toestaan van de afwijking op de bestaande situatie; anderzijds is er de impact van het niet toestaan van de afwijking op het desbetreffende project.
Als de impact helder is, kan een besluit worden genomen. Er zijn drie mogelijkheden:
* De afwijking wordt permanent toegestaan. Feitelijk wordt hiermee de architectuur uitgebreid met de afwijking. Het project kan doorgaan, en het architectuurbesluit vormt input voor een actie waarbij de enterprise- of domeinarchitectuur wordt aangepast conform het proces "wijzigen architectuurartefacten".
* De afwijking wordt onder voorwaarden toegestaan. Meestal voor een bepaalde tijd, waarna alsnog een permanente oplossing moet worden geïmplementeerd die wel in lijn is met de architectuur. Ook hier kan het project doorgaan, maar de vervolgactie moet wel vastgelegd en bewaakt worden. Hier wordt meteen duidelijk waarom het goed documenteren van voorwaardelijke goedkeuring belangrijk is.
* De afwijking wordt niet toegestaan. Het project moet terug naar de tekentafel en de projectarchitectuur aanpassen. +
Formele besluiten zijn nodig bij het niet voldoen aan de kaders van veranderprogramma's, projectarchitectuur en/of gedetailleerde ontwerpen. Mogelijke uitkomsten zijn afwijzing, voorwaardelijke goedkeuring (bijvoorbeeld voor een bepaalde periode), of permanente goedkeuring. In geval van het laatste zal de architectuur worden aangepast aan de (niet langer als zodanig bestaande) afwijking. +