Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2
Bert Dingemans
1
Inleiding
Risico’s zijn een extra dimensie bij het uitwerken van een architectuur. Binnen de beschrijving van bestaande architectuur methoden als Togaf en Archimate neemt risico analyse een kleine plaats in. In Togaf [1] worden risico wel benoemd maar wordt aangegeven dat risico management wordt uitgevoerd binnen project management. Dat is wat mij betreft maar ten dele waar. Zeker als de architectuur binnen een project als uitgangspunt dient zal de architect in ieder geval over de architectuur een beeld gevormd moeten hebben over de risico’s van de oplossing op het vlak van door de stakeholders benoemde risico’s. In het whitepaper “concerns van stakeholders” [2] ben ik ingegaan op de werkwijze om de risico’s te inventariseren op basis van de inventarisatie van concern en het implementeren van checklists. In dit artikel gaan we in op de presentatie van risico’s binnen een architectuur taal (Archimate). Dit wordt gedaan door een uitbreiding van de notatie te beschrijven. Voorafgaand aan deze Archimate uitbreiding wordt een beeld gegeven van modelleerwijzen binnen architectuur.
2
Architectuur modelleren
Waarom is architectuur modelleren relevant, is beschrijven van architectuur in documenten niet voldoende? Ik wil het belang van modelleren graag toelichten met een aardig voorbeeld. Enige jaren geleden was ik voor langere tijd in Nepal, en verbleef ik regelmatig in de hoofdstad Kathmandu. Alhoewel een niet heel grote stad, door de wirwar van straatjes was het lastig om mijn weg te vinden. Dus een stadsplattegrond gekocht wat me in veel gevallen goed op weg hielp. Niet altijd want soms liep ik toch verkeerd en wist dan niet meer waar ik was en straatnaambordjes kent men niet. Mijn tactiek was dan om de weg te vragen aan iemand. In eerste instantie deed ik dat door diegene mijn plattegrond te laten zien en te vragen waar ik mij bevond op de kaart. Dat bleek een verkeerde tactiek, men bestuurde de kaart aandachtig hield hem op zijn kop maar een plaats aanwijzen was veelal niet mogelijk. Blijkbaar is het model van een stadsplattegrond een onbekend fenomeen voor degenen die ik aansprak. De weg vragen naar een bepaalde marker zoals een tempel of plein werkte wel goed. Blijkbaar blijkt deze modelleerstrategie effectiever in die situatie. Voor het uitwerken van een architectuur model is de situatie niet anders. Ook daarbij moet men vooraf afspraken maken om de betekenis van diagrammen en notaties te kunnen interpreteren. Bij het uitwerken van architectuur zijn een aantal notatiepatronen te onderkennen. In onderstaande paragrafen een uitwerking van deze patronen. Voor risico inventarisaties is in het kader van deze artikelen een prototype van een webapplicatie ontwikkeld (http://aretest.interactory.nl) waarin de werkwijze beschreven in de artikelen is uitgewerkt. In onderstaande paragrafen wordt daarom een uitwerking van de patronen in de vorm van een schermvoorbeeld getoond.
2.1 Lijsten 2
Opsommingen en groeperingen van architectuur onderdelen die op enigerlei wijze bij elkaar horen. Bieden veelal een samenvattend beeld en worden daarom gecombineerd met tabellen waarin detail gegevens zijn opgenomen.
Binnen een geautomatiseerde toepassing ziet men regelmatig dat lijsten gecombineerd worden met andere patronen zoals bijvoorbeeld details maar ook met matrices.
2.2 Tabellen Lijsten geven een samenvattend beeld, echter er is ook behoefte aan detail in een aantal gevallen. Een tabel met een detaillering van de gegevens is hiertoe een adequate notatie. In onderstaande afbeelding een voorbeeld waarbij een detail gecombineerd wordt met een lijst.
3
Ook met andere notatiewijzen dan de lijst kan de tabel gecombineerd worden, bijvoorbeeld met matrices en bomen. Daarnaast wordt de tabel gebruikt in twee verschijningsvormen, te weten weergave en mutatiemodus.
2.3 Matrices Matrices zijn een verbijzondering van lijsten. De verbijzondering is dat men drie assen met elkaar verbindt namelijk twee dimensie assen en een feit as. Dit is een krachtige wijze van modelleren van architectuur. Met name omdat deze modelleerwijze geen nadere kennis vereist van de modellering. De opzet mag als bekend worden verondersteld bij alle stakeholders.
4
In de afbeelding een eenvoudige matrix met twee dimensies en een enkelvoudig feit element, namelijk het feit dat er een verbinding bestaat tussen de twee dimensies. Met name in de feit weergave kunnen extra weergeven worden toegevoegd zoals kleuren, waarden, combinaties van elementen. Daarnaast is het mogelijk om ook de dimensie assen te verrijken, met name door het toevoegen van groeperingsdimensies maar ook sorteringen. Voor de risico inventarisatie is er een verrijkte weergave in de vorm van matrices ontwikkeld. Namelijk de uitkomsten van de checklists (ingevuld door stakeholders) wordt ingedeeld in categorieen. In de huidige opzet zijn er voor alle checklists drie risico categorieen die met een kleur worden aangeduid in de matrix, groen, geel en rood. De grenzen tussen de categorieen kan per checklist gedefinieerd worden in de toepassing.
Matrices en de hierboven beschreven lijsten zijn de meestgebruikte architectuur notaties binnen Togaf [1].
2.4 Grafen Grafen is een notatie die je in veel ICT notaties terugziet, ER diagrammen, UML class diagrammen maar ook de Archimate notatie is gebaseerd op grafen. Grafen kunnen kortweg omschreven worden als entiteiten (rechthoeken) die op basis van relaties (lijnen) met elkaar verbonden zijn. Deze basisconcepten kunnen verder verrijkt worden door verschillende weergaven te maken van deze rechthoeken en lijnen waardoor deze van elkaar kunnen worden onderscheiden. Daarnaast kunnen binnen de entiteiten en de relaties extra attributen getoond worden. Bijvoorbeeld de kolomnamen binnen een ER-diagram. In onderstaande afbeelding een weergave van een graaf op basis van de Archimate notatie die verrijkt is met attributen die de risico’s weergeven. Hierbij wordt wederom een
5
kleurencategorisering gebruikt zodat in een diagram snel inzicht te krijgen is van waar risico’s optreden in de architectuur uitwerking.
2.5 Bomen Bomen zijn feitelijk een verbijzondering van grafen. In de boomgraaf zijn een aantal extra beperkingen in de notatie opgenomen. Namelijk dat de relatie tussen een “ouder” en een “kind” zijn ingeperkt. Deze inperking betreft dat een kind slechts één ouder kan hebben en een ouder meerdere kinderen. Naast de weergaven in een graaf zoals hierboven getoond bij grafen in bovenstaande paragraaf zie je regelmatig een notatie waarbij de rechthoek van de ouder meerdere kinderen omsluit. Daarnaast is de boomweergave zoals gebruikt binnen veel administratieve toepassen met de plussen en minnen een veel toegepaste werkwijze. Onderstaande afbeelding toont een scherm uit het prototype van deze laaste vorm van boomweergave in combinatie met een tabelweergave voor de detaillering.
6
3
Archimate concepten in ARE
Bij de uitwerking van ARE zijn de architectuur methoden Togaf 9 en Archimate 1.0 als uitgangspunt genomen. Met name de Archimate taal is belangrijk vanuit het ARE perspectief omdat deze taal verrijkt is met risico inventarisaties in de ARE implementatie.
3.1 Basis modellering De architectuurtaal van Archimate is opgebouwd rond de grafennotatie. Hierbij zijn zowel de rechthoeken (architectuur elementen) als de lijnen (assosiaties) verrijkt. Dit verrijken houdt in dat de elementen en associaties beiden geclassificeerd kunnen worden op basis van een gedefinitieerd domein. Deze domeinen worden voor de entiteiten getoond op basis van een symbool in de rechthoek dat het type entiteit aangeeft. Een soortgelijke opzet geldt voor de associaties waarbij de uiteinden van de lijn het associatie type weergeeft. Naast de verrijkte notatie in de elementen zijn er meerdere sorteringen en groeperingen mogelijk van de entiteiten. Meest onderscheidend hierin zijn de architectuur kolommen en – lagen in archimate. Deze sorteringen brengt met zich mee dat bepaalde associaties beperkingen kennen in het gebruik, echter in de specificatie komt dit niet duidelijk aan de orde maar zijn deze meer impliciet in de lagen en kolommen indeling ondergebracht [3].
3.2 Extensies
7
Naast de basismodellering van Archimate zijn er een aantal extensie mogelijkheden beschreven in de Archimate specificatie. Hierbij worden twee soorten extensies onderscheiden [3]: •
•
Specialisatie van concepten, hierbij worden de basisconcepten uitgebreid met eigen specifiekere concepten, eventueel uitgebreid met een extra notatie. Bijvoorbeeld een uitbreiding van het type service in de notatie zodat hiermee deze specialisaties onderscheiden worden Attributen toevoegen aan concepten en relaties, hierbij worden door de gebruiker gedefinieerde attributen toegevoegd aan de elementen en de relaties. Bij het uitwerken van ARE is deze extensie gekozen voor de elementen
3.2 Risico extensies modelleren Bij het uitwerken van de risico extensies is er gekozen voor enerzijds de Archimate grafen notatie en een extensie hierop en het gebruik van een matrix zoals veel in Togaf 9 toegepast wordt. In paragraaf 3.2. en 3.3 vindt u van beide uitwerkingen een beschrijving en voorbeeld. In het prototype van ARE kunt u zich een beeld vormen van de werkwijze en de notatie gebruikt binnen deze risico extensie.
4
Tot slot
In dit whitepaper is ingegaan op het modelleren van risico extensies op basis van Archimate notatie en matrices. Naast het artikel over stakeholder concerns [1] geeft dit een beeld van de uitwerking van risico extensies binnen een IT architectuur. Bij deze uitwerking is gekozen voor een aantal beperkingen, allereerst is de focus gelegd op de stakeholders binnen de beheerorganisatie. Ten tweede is een beperkte set van risico’s geanalyseerd zoals volwassenheid en non functionele requirements. Hiermee is de basis gelegd voor een extensie van de Archimate taal. Hiermee is de mogelijkheid ontstaan om risico extensie uit te breiden in de richting van beide dimensies. Zo is het mogelijk om ook andere stakeholders dan die in de beheerorganisatie te vragen naar risico’s die zij zien in een architectuuroplossing. Daarnaast kunnen er andere risico’s geinventariseerd gaan worden, bijvoorbeeld op het vlak van de gebruikersorganisatie of een detaillering van de interoperabiliteitseisen gesteld aan een component. Door de gekozen inperking voor de beheerorganisatie is impliciet de risico extensie met name gericht op de componenten en software onderdelen. Echter ook voor elementen als processen, actoren, services en (data)objecten is het mogelijk om in samenspraak met de stakeholders de risico’s te benoemen en inventariseren. Naast deze extensie is gewerkt aan een prototype dat een aantal randvoorwaarden implementeert bij het inzetten van een checklist gebaseerde architectuur extensie. In dit geval zijn dit: • • •
8
Checklist module Architectuur repository Grafische weergave van de notaties
Dit prototype is te vinden op http://aretest.interactory.nl
5
Literatuur
[1]The Open Group, Togaf 9, Van Haren Publishing, 2009. [2] Dingemans, Bert, Concerns van stakeholder in de beheerorganisatie, www.are.interactory.nl, Culemborg 2011 [3] The Open Group , Archimate 1.0 specification, Van Haren Publishing, 2009.
9
