Concerns van stakeholders in de beheerorganisatie

Risico analyse op basis van interactie en checklists

versie 0.2

Bert Dingemans

2

1 Inleiding

Risico analyse is een relatief onbekend fenomeen binnen de ICT, op een aantal plaatsen kom je het tegen binnen de beheerprocessen zoals ITIL. Echter binnen de methoden voor enterprise architectuur zoals Togaf en Archimate is werken met risico’s een onderbelicht onderwerp.

Dit artikel zoekt naar de mogelijkheden om risico inventarisatie te implementeren binnen de

kaders van Togaf en Archimate. Het beperkt zich hierbij om reden van projectscope tot de risico’s van de beheerorganisatie. Vanzelfsprekend is deze scopebeperking arbitrair. Ook voor andere stakeholders is het werken vanuit risico’s een interessant perspectief.

2 Stakeholders en beheer

2.1 Stakeholders in de beheerorganisatie

Bij het opstellen van een enterprisearchitectuur spelen de concerns van de stakeholders een belangrijke rol. Deze bepalen de richting van de oplossing in de target architectuur. Ook is bij het uitwerken van de baseline architectuur de input van stakeholders een belangrijke bron van informatie bij inventarisatie van concerns.

De beheerorganisatie is in deze een stakeholder populatie die een afwijkende rol vervuld binnen de enterprise architectuur. De beheerorganisatie maakt geen deel uit van bijvoorbeeld de werkprocessen die deel uitmaken van de uitwerking van de architectuur. Sterker nog de beheerorganisatie van ICT systemen is ingericht op basis van eigen

werkprocessen. Deze processen worden omschreven als de beheerprocessen en zijn in veel gevallen gebaseerd op service libraries zoals BISL, ASL en ITIL.

Bovenstaand neemt niet weg dat de betrokken beheerders in veel gevallen een heel goed beeld hebben van de knelpunten in de te modelleren organisatie en haar ondersteunende ICT. Tijdens de beheerfase van een ICT landschap komen de knelpunten van de ingezette software- en infrastructuurcomponenten pas goed aan de orde. Bijvoorbeeld omdat er veel klachten binnenkomen over applicatie componenten. Denk echter ook aan problemen van

beschikbaarheid en performance rond verschillende onderdelen. Deze worden als eerste structureel geconstateerd door de beheerorganisatie. Daarnaast zijn de beheeractiviteiten feitelijk (door de afwijkende taken en processen) geen onderdeel van de “enterprise”. Dat maakt ze een soort van buitenstaander die daardoor in staat zijn een onafhankelijke visie te vormen.

2.2 Aspecten van de beheerorganisatie

Zien we bij architectuur de focus veelal liggen op aspecten van vernieuwing en optimalisatie. Bij ontwikkelaars van software zien we een duidelijke overeenkomst met deze focus, met name gericht op optimalisatie. Beheerders hebben echter focus op hele andere aspecten van het ICT landschap. Onderstaande opsomming geeft een beeld:

Continuiteit

Van ICT voorzieningen wordt verwacht dat deze beschikbaar zijn op het moment dat de afnemers van de diensten van deze voorzieningen dat verwachten. Dat stelt eisen aan de

3

configuratie van het ICT landschap maar ook aan de implementatie van de afzonderlijke onderdelen.

Reductie van complexiteit

Een grote complexiteit van het ICT landschap stelt extra eisen de beheerorganisatie, bijvoorbeeld op het vlak van kennisontwikkeling, inrichting beheerprocessen en op het vlak

beheeractiviteiten. Bijvoorbeeld een ICT landschap dat in hoge mate gestandaardiseerd is op het vlak van technologie (zoals één database platform) zal de introductie van een implementatie met een afwijkend platform proberen te voorkomen. Reden is dat dit afwijkende component een onevenredige eis stelt aan de beheerorganisatie.

Risicoreductie

Naast continuïteit in de dagelijkse uitvoering zie je dat lange termijn continuiteit een belangrijk aandachtspunt is voor de beheerorganisatie. Men zal dus veelal zoeken naar

componenten die “toekomstzeker” zijn. Daartoe wordt bijvoorbeeld gekeken naar de leveranciers rond een component. Leveranciers op het vlak van opleidingen, ondersteuning en toekomstige releases. Hiermee wordt voorkomen dat in een later stadium de continuïteit van de ICT dienstverlening in het gevaar komt of dat onevenredige kosten gemaakt moeten worden voor het beheer van componenten.

Kostenaspecten

In bovenstaande punten is reeds een aantal keren het kostenaspect genoemd. Een slecht beheerd en divers ICT landschap is naast de andere aspecten veelal duur. Bijvoorbeeld

omdat er meer personen ingezet moeten worden om de componenten beschikbaar te houden, maar ook doordat bijvoorbeeld vaker updates en releases nodig zijn. Ook is het op peil houden van het kennisniveau van een divers ICT landschap veelal duurder dan een homogene inrichting.

Uit bovenstaande punten blijkt dat de beheerorganisatie hele andere criteria hebben voor de componenten in een ICT landschap. Neem daarnaast de afwezig dat het beheren van ICT componenten veelal vele malen duurder is dan het ontwikkelen van deze componenten. Gevolg is dat de beheeraspecten een interessante oplossingsrichting zijn om ICT architectuur te optimaliseren op het vlak van risico’s en kosten.

3 Concerns, principes en requirements

3.1 Indeling van de concerns

Concerns, principes en requirements zijn binnen Togaf verschillende views op de requirements die betrokken stakeholders stellen aan het applicatie en ICT landschap. Bij het

uitwerken van een architectuur zijn deze requirements een belangrijk uitgangspunt voor de selectie van de verschillende onderdelen. Want afhankelijk van het belang van een requirement zal het ene ICT component beter toepasbaar zijn dan het andere.

Bijvoorbeeld voor alle betrokken stakeholders geldt dat de kosten van de voorgestelde oplossing zo laag mogelijk zijn. Voor de keuze van het database platform is dan MySQL een interessantere keuze ten opzichte van bijvoorbeeld SQL-server of Oracle vanwege licentiekosten. Echter andere concerns zoals bijvoorbeeld beschikbaarheid en schaalbaarheid zijn in sommige situaties eveneens belangrijke concerns. Gevolg is dat een afweging gemaakt moet worden welk concern het zwaarst wegend is.

Om bovengenoemde afweging te kunnen maken is het noodzakelijk om verschillende

concerns te gaan kwantificeren en op basis van deze kwantitatieve analyse deze

4

vergelijking te onderbouwen. In het volgende hoofdstuk wordt een uitwerking gegeven waarbij op basis van checklists gevraagd wordt aan de relevante stakeholders wat hun oordeel is over de score voor architectuur componenten voor een concern. In onderstaande paragraaf zijn een aantal voorbeelden van concerns beschreven.

3.2 Voorbeelden concerns

Concerns liggen voor allen stakeholders op een ander vlak. Zo zullen gebruikers van de systemen concerns hebben op het vlak van gebruikersvriendelijkheid, gebruiksgemak en het ondersteunen van de werkzaamheden. Voor stakeholders betrokken bij informatiebeveiliging

liggen de concerns met name op het vlak van beveiliging en beveiligingsrisico’s. Voor de beheerorganisatie zijn met name non functionele aspecten als beschikbaarheid, beheerbaarheid en uitbreidbaarheid van groot belang. Hieronder een aantal relevante concerns voor stakeholders uit de beheerorganisatie. Nogmaals wordt benadrukt dat de inperking voor de beheerorganisatie een keuze is voor het ARE project. Concerns kunnen voor alle stakeholders bepaald en gekwantificeerd worden.

Kosten

Kosten, maar ook de opbrengsten van de componenten in een architectuur zijn vanzelfsprekend voor een groot aantal stakeholders belangrijke concerns. Een onbeperkt budget voor ICT komt niet vaak voor. Toch zie je bij de uitwerking van een architectuur dat

het kostenaspect niet of maar ten dele aan de orde komt. Wordt er gekeken naar de kosten, dan zie je veelal dat dit beperkt blijft tot de initiele kosten zoals ontwikkel- en licentiekosten. Beheer- en migreerkosten zijn lastiger te berekenen en worden daarom regelmatig buiten beschouwing, of er wordt een vuistregel toegepast.

Non functionals

Functionele requirements zijn door stakeholders meestal wel te benoemen. Een deel van de non functionele aspecten worden vaak genoemd zoals beschikbaarheid en performance. Een goed uitgangspunt bij het uitwerken van non functionele requirements is de standaard norm ISO 9126 en de uitbreiding Quint 2 genaamd. Deze non functionele eisen kunnen goed gebruikt worden voor een inventarisatie van de concerns in combinatie met een gedetailleerde verdeling van wegingsfactoren.

Software volwassenheid

Een minder voor de hand liggende concern is de volwassenheid van de organisatie rond componenten. Hiermee kun je in kaart brengen hoe toekomstvast een bepaald component is. Selecteer je bijvoorbeeld een toepassing die ontwikkeld en beheerd wordt door slechts één persoon waarbij de broncode niet vrijgegeven is heeft grotere volwassenheidsrisico’s

dan een component dat in een veelgebruikte ontwikkelomgeving is ontwikkeld en waarvan de broncode wel beschikbaar is.

Beheerlibraries

Een categorie alleen relevant voor beheerorganisatie zijn de beheerprocessen in libraries zoals ITIL, ASL en BISL. Deze libraries beschrijven de beheerprocessen vanuit een verschillend

beheerperspectief. Risico’s hierbij liggen op het vlak van ontbreken van de inrichting van deze beheerprocessen of dat deze processen wel ingericht zijn maar dat de inrichting onvoldoende in staat is om aan de vraag vanuit de organisatie te voldoen. Hierbij speelt

5

vanzelf ook de beheerbehoefte van de verschillende ICT componenten een rol. Denk bijvoorbeeld aan de keuze voor een divers of homogeen applicatielandschap.

6

4 Risico inventarisatie en interacties

Risico inventarisatie is een relatief onbekend fenomeen binnen enterprise architectuur. Binnen de beheerlibraries wordt al iets meer gedaan aan risico analyse, bijvoorbeeld door

het toepassen van acceptatiecriteria. De wijze waarop risico inventarisatie kan worden ingezet binnen architectuur wordt beschreven in deze paragraaf. Hierbij worden een aantal voorbeelden van inventarisaties genoemd, echter de uitwerking is niet uitputtend. Hierbij is het aanpassen van de interacties aan de specifieke situatie voor een inventarisatie van groot belang.

4.1 Verschillen in risico inventarisatie

Bij het doen van risico inventarisaties zijn verschillen in de opzet van groot belang voor de uitwerking. Een veelgebruikte indeling is de volgende:

• Test, bij non functionele meetbare requirements wordt bijvoorbeld gemeten of aan de eis wordt voldaan, zoals performance en beschikbaarheid

• Review, bij non functionals zoals uitbreidbaarheid, herbruikbaarheid en onderhoudbaarheid een veel toegepaste werkwijze

• Checklist, vragenlijsten en checklists om te controleren of aan de gestelde eis is voldaan.

Vanuit architectuur kunnen de volgende verschillende viewpoints genoemd worden:

• Inventarisatie van de risico in de baseline architectuur. Hierbij wordt gekeken naar

welke risico’s er zijn voor de huidige inrichting. Men zal in deze situatie veelal kijken voor welke componenten in de architectuur het risico het hoogst of laagst is in de bestaande situatie.

• Inventarisatie van de risico’s in de target architectuur. Men kan in dat geval enerzijds kijken naar welke componenten in de toekomstige situatie het meeste risicovol zijn. Een andere mogelijkheid is een analyse van een target architectuur waarbij de

risico’s van de baseline architectuur het meest gereduceerd worden. • De roadmap inventarisatie, hierbij brengt men in kaart wat de grootste verschillen zijn

om de risico’s van de baseline binnen target architectuur te reduceren in de target architectuur. Een grote inspanning per component heeft dan een grote impact en vormt dan een groter risico.

• Bij het uitwerken van risico inventarisaties zijn verschillende vormen te vinden. Een veel

voorkomende werkwijze is bijvoorbeeld het opgeven van verschillende elementen en deze vervolgens te sommeren. Denk bijvoorbeeld aan het in kaart brengen van de kosten voor een bepaald component of een cluster van componenten.

• Een andere uitwerking is het combineren van een waardering en een score. Men scoort een component en deze score wordt vermenigvuldigd met een waardering, op basis van deze berekening kan een sommering gemaakt worden van deze

berekening. Hierbij wordt een onderscheid gemaakt tussen een negatieve en een positieve sommering. Dit is gerelateerd aan de inventarisaties zoals genoemd in bovenstaande opsomming een relevante werkwijze. Bij een positief gestelde analyse zal gezocht worden naar een zo hoog mogelijk uitkomst van de score, bij een negatieve opzet is het realiseren van een zo laag mogelijke score een positief resultaat.

• Een meer complexe vorm is inventarisatie die gebaseerd is op eigen formules. Hierbij kunnen negatieve en positieve aspecten met elkaar gecombineerd worden en is in de ene situatie de waardering negatief en in de andere positief. Ook de uitwerking van de overall berekening kan in deze anders zijn dan een sommering. Denk bijvoorbeeld aan een sommering van de positieve onderdelen verminderd met de

7

negatieve onderdelen of het berekenen van verschillen tussen vragen en een groot verschil tussen de beantwoording positief of negatief te beoordelen.

4.2 Interactievormen

Risico inventarisaties onderscheiden zich in twee interactievormen:

• Directe interactie, de stakeholder wordt rechtsreeks bevraagd door de architect. Veelal door middel van checklists, enquetes en vragenlijsten

• Indirecte interactie, de stakeholders worden bevraagd door de architect in de vorm van interviews of workshops, vervolgens bepaald de architect de risico score op basis van de uitkomsten van de toegepaste interactievorm, bijvoorbeeld bij reviews.

Directe interactievormen

Checklists en vragenlijsten, de meest voor de hand liggende vorm van interactie. Men stelt een aantal vragen op en de beantwoording van deze vragen bepaald in welke mate het

risico geanalyseerd wordt. Bijvoorbeeld zoals hierboven genoemd met een positieve of negatieve inventarisatiewijze. Hierbij kunnen verschillende presentatievormen gebruikt worden voor het bepalen van de score voor een vraag. Zoals keuzelijsten, sliders of grafische weergaven zoals stoplichten of smileys e.d.. In onderstaande afbeelding een voorbeeld van deze interactie.

Afbeelding

Berekeningen en calculaties, zeker bij een kwantitatieve analyse van bijvoorbeeld kosten,

opbrengsten, rendement of andere financiële aspecten van een inrichting. Invulling van deze onderdelen biedt dan vervolgens de mogelijkheid om uit te rekenen wat de financiele

8

risico’s zijn van een architectuur configuratie. Onderstaande afbeelding geeft een voorbeeld van deze vorm.

Afbeelding

Score en sorteringen, Bij een analyse kan men een groep van verschillende entiteiten laten sorteren voor één of meerdere risico’s. Op een as zet men aan de ene kant aan dat het risico hoog is en aan de andere kant of het risico laag is. Vervolgens laat men de stakeholder de verschillende componenten op deze as afbeelden waarmee men aangeeft welk een hoog en welk een laag risico betreft. In onderstaande afbeelding een voorbeeld.

9

Afbeelding

Matrices, bovenstaande interactievormen hebben als nadeel dat men twee dimensies onderscheid, de componenten en de risico’s, maar dat men bij één van de dimensies slechts één onderdeel kan uitwerken. Of men heeft meerdere componenten gerelateerd aan één risico of omgekeerd. In een aantal gevallen kan het verhelderend werken voor de stakeholder om het verband te zien tussen meerdere componenten en meerdere risico’s. Dit

kan men doen door het toepassen van een matrix waarbij op de ene as de componenten worden afgebeeld en op de andere risico’s. Zie bijvoorbeeld onderstaande afbeelding.

10

Afbeelding

Indirecte interactievormen

Interviews, bij een interview worden de stakeholders geïnterviewd door de architect. Dit kan in groepen of in één op één vraaggesprekken. Het voordeel van de werkwijze is dat men

specifiek in kan gaan op de antwoorden die gegeven worden tijdens het interview op de vragen. Op basis van deze antwoorden kan ook een detaillering gemaakt worden op niet vooraf bepaalde risico’s. Het is een krachtige interactievorm die echter wel als nadeel heeft arbeidsintensief en duur te zijn.

Workshops, een bijzondere vorm van interviews is het werken met workshops. Hierbij wordt gewerkt met groepen van stakeholders die binnen een workshop met elkaar interacteren om de risico’s te bepalen. Vaak wordt er gezocht naar een combinatie van indirecte en directe werkvormen. Indirect is bijvoorbeeld het opsplitsen in kleine werkgroepen en vervolgens in

een groepssessie de uitkomsten te bespreken. Vaak wordt het relateren van korte omschrijvingen van risico’s op basis van Brown paper sessies gebruikt. Hierbij zie je vaak dat de interactie onderling de uitkomsten binnen de groep bepalen. Dit kan een positief maar ook een negatief effect hebben. Deze vorm is minder arbeidsintensief dan het doen van interviews maar vraagt vaardigheden van de architect in het begeleiden van deze workshops

Score sessies, Een nog specifiekere vorm van interactie zijn scoresessies. In workshop vorm

worden risico’s in kaart gebracht. Vervolgens wordt per risico of component bepaald welke de hoogste of laagste score heeft. Hierbij kan men bijvoorbeeld kiezen voor het verdelen van een beperkt aantal scorepunten over de desbetreffende onderdelen. Een andere vorm is het in volgorde zetten van onderdelen in workshop opzet.

Een bijzondere vorm, veel in agile omgevingen gebruikt, is een vorm van poker. Deze vorm van risico poker is om de deelnemers per component een kaart te laten neerleggen. Een

11

kaart met een laag getal betekent een laag risico, een hoog getal een hoog risico. Vervolgens lichten de deelnemers met de meest extreme score (positief en negatief) de afgegeven score toe.

Combinaties van directe en indirecte interacties, bovengenoemde directe en indirecte vormen van interactie kunnen vanzelfsprekend op allerlei wijzen met elkaar gecombineerd

worden. Bijvoorbeeld in eerste instantie een beeld vormen van de risico’s op basis van vragenlijsten en checklist. Vervolgens kan op basis van deze uitkomsten een interactieve sessie met de stakeholders worden georganiseerd of vraagt men aan een deel van de betrokkenen om de uitkomsten te scoren.

In bovenstaande beschrijving zijn een aantal interactievormen genoemd, echter dit is slechts een klein voorbeeld van de vele interactievormen die ingezet kunnen worden voor het inventariseren van de risico’s

4.3 Are checklists en vragenlijsten

Het kunnen doen van risico inventarisaties binnen een architectuur is een belangrijk onderdeel in de implementatie binnen de Archimate Risico Extensie. Enerzijds is het de module die zorgdraagt voor het kwantificeren van risico´s en het relateren van deze kwantificatie aan de diverse architectuur elementen. Anderzijds is het een uitwerking van

verschillende checklists en vragenlijsten die van waarde zijn bij het bepalen van architectuur risico´s.

Bij de uitwerking van ARE is een prototype ontwikkeld in de vorm van een eenvoudige webapplicatie. Deze webapplicatie kent een aantal modulen waarvan de checklist of enquete module een is. In deze module is het mogelijk om eenvoudige checklists te registreren en toe te wijzen aan relevante stakeholders. Vervolgens worden deze stakeholders uitgenodigd via email deze checklist in te vullen. Deze laatste activiteit wordt ook ondersteund in het het prototype.

Implementatie

Implementatie van de chelcklistmodule bestaat uit een data georiënteerde webapplicatie. Dit houdt in dat er een eenvoudige gebruikersinteractie is die het mogelijk maakt om de gegevens omtrent de entiteiten binnen de checklistmodule te beheren. Gezien de opzet van het bedrijfsproces is niet gekozen voor een implementatie in de vorm van een

werkprocesondersteuning. Gevolg is dat de schermen zijn gebaseerd op lijst detail interactiepatronen, waarbij via de detail interactie de gegevens van de entiteiten gemuteerd worden. In onderstaande afbeelding ziet u een voorbeeld van de webinterface

12

Afbeelding

Ten behoeve van het invullen en verwerken van de checklists is de opbouw van de

toepassing iets verder uitgewerkt. De in de databank opgeslagen checklist gegevens worden omgezet naar verschillende soorten checklist. De beheerder van de toepassing heeft de mogelijkheid de samenstelling van de vragen en evaluaties aan te passen en uit te breiden waarmee het zonder de inzet van technische expertise mogelijk is om deze beheertaken uit te voeren.

Op dit moment zijn een beperkt aantal checklist implementaties mogelijk, te weten:

• Sommeren van antwoorden • Vermenigvuldigen van waardering en score • Formuleberekening

Hiermee worden de directe interactievormen checklists en berekeningen geimplementeerd. Deze checklists worden dynamisch samengesteld en in de module gepresenteerd aan de gebruiker. Deze kan de vragen beantwoorden en verzenden naar de toepassing. Daar wordt vervolgens de score berekend.

Objectmodel

13

Het objectmodel van de checklist bestaat uit de volgende entiteiten

• Checklist, beschrijving van het soort checklist, inclusief omschrijving voor de eindgebruiker. Daarnaast wordt hier de relatie naar de concerns van de stakeholder gelegd

• Vraag, eigenschappen van de vraagstelling, antwoordkeuzes, soort

besturingselement en validatie • Evaluatie, instantie van een checklist voor één specifieke stakeholder. Aan deze

evaluaties worden de antwoorden op de vragen gerelateerd • Antwoord, instantiatie en dus beantwoording van vragen door een stakeholder • Evaluatie_element, koppeling tussen evalutie en architectuur element. Hiermee

kunnen de behaalde scores gekoppeld worden aan de architectuur elementen.

In onderstaande afbeelding een uitwerking van de objecten en hun onderlinge relaties.

Architectuur proces

Het proces dat ondersteunt wordt binnen het Are project omvat enerzijds de analyse van de concerns van stakeholders binnen ICT beheer. Stakeholders betrokken bij ICT beheer hebben concerns op het vlak van ICT kosten en opbrengsten, risico’s op het vlak van non functionele requirements zoals performance en beschikbaarheid en dergelijke. Anderzijds wordt aandacht besteedt aan de modelleerwerkzaamheden van enterprise architecten. Dit wordt

samengevoegd tot een uitbreiding van de Archimate taal waarbij in de diagrammen een extra dimensie wordt toegevoegd. Deze dimensie omvat een weergave van de risicodimensie voor de structurele elementen. Indien mogelijk wordt op basis van infrastructuur- en applicatieservices een extra ontsluiting toegevoegd aan de archimate taal.

14

Processen zijn uitgewerkt op basis van Togaf ADM. In onderstaande afbeeldingen wordt getoond binnen welke fasen van het ADM de risico inventarisatie wordt toegepast. Daarnaast worden ook de activiteiten benoemd relevant voor deze extensie in onderstaande afbeelding.

Afbeelding Togaf ADM

Risico inventarisaties worden voornamelijk uitgevoerd in de fasen van het uitwerken van de architecturen. Dit geldt zowel voor de baseline als de target architectuur. Hierbij is de risico

inventarisatie een extra dimensie van de architectuur die uitgewerkt wordt en gerelateerd aan de architectuur elementen in de uitwerking.

Dit proces wordt vanzelfsprekend gevoed door de requirements en concerns die door de beheerders zijn geformuleerd. Deze requirements worden gevoed door veranderingen in de omgeving, de beheerprocessen en de overige ontwikkelingen binnen de organisatie.

15

5 Tot slot

In dit artikel is het inventariseren van risico’s aan de orde gekomen. Hierbij is ingegaan op een aantal risico’s die onderkend worden bij het beheren van een ICT landschap. Aspecten

als toekomstvastheid, beheerprocessen en non functionele requirements zijn hierbij benoemd. Vanzelfsprekend is dit een beperkte set van risico’s binnen de beheerorganisatie. De webtoepassing ingericht voor dit project biedt de mogelijkheid om zelf de risico inventarisatie uit te breiden.

Daarnaast moet benadrukt worden dat deze werkwijze niet enkel toepasbaar is voor de stakeholders binnen de beheerorganisatie. Ook voor andere stakeholders kan het interessant zijn om risico’s te inventariseren met behulp van checklists en vragenlijsten. Dit op vergelijkbare wijze als hierboven beschreven.

Laatste aandachtspunt is dat in dit artikel alleen de risico inventarisatie en het verzamelen van gegevens aan de orde is gekomen. Net zo belangrijk als het verzamelen van de

gegevens is het presenteren van de uitkomsten binnen een architectuur notatiewijze. Hierover is op de Are website een artikel te vinden.