Business Scenario Voorbeeld Archimate Risico Extensie versie 0.1
Bert Dingemans
Administratieve pagina Wijzigingshistorie Versie
Datum
Auteur
Reden wijziging
Review historie Naam
Afdeling
Functie
Datum
Afdeling
Functie
Datum
Afdeling
Functie
Inhoud afgestemd met Naam
Distributie Naam
2
Inleiding Dit document beschrijft een business scenario dat dienst zal doen als voorbeeld toepassing binnen het ARE project. Het omvat de projectomgeving van een architectuur repository waarbij een aantal stakeholders gevraagd wordt op een kwantitatieve wijze een beeld te schetsen van hun concerns. Dit business scenario zal gebruikt worden als voorbeeld binnen het ARE project. De entiteiten en hun onderlinge relaties zullen de vulling zijn van de voorbeeld architectuur repository. Op basis hiervan worden de vervolgdocumenten uitgewerkt worden. Voor dit business scenario maken we gebruik van Archimate modelleertechnieken. Voor templates (zoals dit document) wordt gebruik gemaakt van Togaf 9.
Probleemstelling Geef een voorbeeld bedrijfsproces voor inclusief de architectuur waarmee de concerns van een aantal stakeholders binnen de beheeromgeving op adequate wijze gemodelleerd en geregistreerd kunnen worden. Het is een vereenvoudiging van een werkelijke situatie maar bevat voldoende complexiteit om de business case voor ARE aantoonbaar te maken.
Omgeving Omgeving van het architectuur proces bestaat uit het een aantal bedrijfsprocessen binnen het Togaf ADM. In onderstaande afbeelding wordt dit getoond.
3
Afbeelding 1: Togaf ADM Hierbij wordt op basis van requirements (van de beheerders een architectuurmodel opgesteld. Vervolgens kunnen verschillende architectuurmodellen op basis van deze requirements en de kwanititatieve analyse hiervan met elkaar vergeleken worden. De requirements analyse vindt plaats op het volgende componenten model:
4
Afbeelding 2: Componentenmodel
Doelstellingen en eisen Binnen de bovenstaande componenten wordt een analyse uitgevoerd voor de volgende concerns cq requirements:
5
• • • •
Geselecteerde componenten in configuratie bieden een implementatie die kostenoptimaal is. Organisaties rond de geselecteerde componenten, zoals leveranciers en dienstverleners, hebben een hoge mate van volwassenheid Non functionele eisen op basis van verschil tussen de huidige inrichting en de gewenste inrichting voor de geselecteerde componenten Beheerprocessen (ITIL/ASL/BISL) op basis van verschil tussen de huidige inrichting en de gewenste inrichting voor de geselecteerde componenten
Op basis van de vier bovenstaande clusters worden verschillende soorten vragenlijsten en checklists opgesteld. Deze checklists kunnen door betrokken stakeholder zelf ingevuld worden, op basis van interactieve workshops maar ook door gesprekken met de betrokken architect waarna deze de verdere verwerking doet.
Actoren Actoren binnen het probleemgebied die gebruik gaan maken van de functionaliteit van de oplossing: •
•
Directe gebruikers o Enterprise architecten o Software architecten o Service managers Indirecte gebruikers (vanuit integratie perspectief) o DBA o Functioneel applicatiebeheerder o ICT architect o Infrastructuur specialist o Systeembeheerder o Teamleider ICT o Technisch applicatiebeheerder
Componenten Zie afbeelding 2.
Rollen en verantwoordelijkheden
Beheerprocessen
Non functional
Volwassenheid
Kostenoptimaal
In onderstaande tabel is een weergave gegeven van de concerns en de actoren. Eindverantwoordelijke van de wijze van interactie is in deze de architect die de analyse uitvoert.
6
DBA
X
X
X
Functioneel applicatiebeheerder
X
ICT architect
X
Infrastructuur specialist
X
X
X X
Systeembeheerder
X
Teamleider ICT
X
Technisch applicatiebeheerder
X
X
X
X X
X
Op basis van bovenstaande matrix zullen de checklists gekoppeld worden aan de bovengenoemde stakeholders in de voorbeeldtoepassing.
7
