De beheerrisico s van architectuur

Transcriptie

1 De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans

2 Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich mee, architectuur heeft namelijk betrekking op verandering en innovatie. Daarom is het verrassend dat risico s inventariseren binnen architectuur geen vanzelfsprekendheid is. Tenslotte is de impact van architectuur op met name beheerrisico s groot. Architectuur bepaald de fundamenten van de ICT inrichting en is daardoor een bepalende factor voor zowel de implementatie- als beheerrisico s. In dit artikel wordt ingegaan op (beheer)risico s vanuit het gezichtveld van architectuur. Hiertoe wordt een risico extensie geintroduceerd voor de architectuurtaal Archimate. Risico s inventariseren Inventariseren van risico s is binnen het werkveld architectuur relatief onbekend. In Togaf 9 wordt er aan risico s minimale aandacht besteedt in de vorm van guidelines en techniques [1]. Deze guidelines geven aan dat de architectuur gebruik kan maken van de risicomethoden aanwezig binnen de organisatie. Echter inbedding van risico inventarisatie in de Togaf fasen en deliverables ontbreekt. Binnen andere ICT werkvelden is risico inventarisatie verder uitgewerkt. Bijvoorbeeld binnen: ITIL Beheer, in ITIL 3 is een risico framework uitgewerkt dat ingezet kan worden binnen de service management processen [2]. Hierbij wordt gebruik gemaakt van een risico classificatie. Vermeldenswaardig in deze is dat men ontwerprisico s onderkend, architectuur zal veelal betrekking hebben op deze risico s. Informatiebeveiliging, vanzelfsprekend is de uitwerking van risico s en de bijbehorende maatregelen in dit werkveld vergaand uitgewerkt. ISO en 27002, Govcert en CRAMM zijn bekende voorbeelden. Zo beschrijft CRAMM een fasering en methodische werkwijze om zowel technische als beheersmatige risico s te analyseren en te beheersen [3]. Analyse van deze en andere methoden bieden een kader voor risico inventarisaties binnen ICT architectuur. Risico s en architectuur ITIL [2] onderscheidt vier soorten risico s waarvan vanuit architectuurperspectief met name ontwerprisico s relevant zijn. Architectuur legt de kaders voor ontwerp en heeft daarom een grote impact op risico s met name op het non functionele vlak. Impact van beheerrisico s door architectuur wil ik toelichten met een tweetal voorbeelden: 2 Diensten zijn herbruikbaar (Nora 3.0 [4]), hiermee wordt bereikt dat een organisatie doelmatiger is en meer gericht is op kerntaken, dit omdat herbruikbare taken van andere diensten ingezet kunnen worden of omdat de eigen taken hergebruikt worden door afnemers. Echter de impact van dit principe voor het beheer van het ICT landschap is groot, zeker als hergebruik over de

3 organisatiegrenzen heen gaat. Beschikbaarheid en performance van de dienst moet voldoen aan de eisen van de afnemer met de hoogste eisen. Daarnaast kan door een opeenstapeling van eisen van verschillende afnemers piekbelasting optreden. Risico liggen op het vlak van de inrichting van de infrastructuur èn de beheerorganisatie. Bij gelijke geschiktheid heeft Open Source Software de voorkeur ( doel is om enerzijds te besparen op licentiekosten en anderzijds vendor lock-in te voorkomen. Impact van dit principe op ICT kan echter groot zijn. Vanuit beheerperspectief wordt veelal gezocht naar standaardisatie van infrastructuur en applicatiecomponenten. Dit om de beheertaken eenvoudig te houden en kennisborging te bewaken. Introductie van OSS heeft tot gevolg dat de inrichting complexer wordt in situaties waar geen bigbang introductie wordt toegepast. Risico s liggen met name op het vlak van kennisontwikkeling, veranderingen in beheerprocessen en migratieaspecten. Bovenstaande punten geven een beeld van de impact die architectuur principes kunnen hebben op de (beheer)organisatie. Architectuur kan rekening houden met de beheeraspecten vanaf de allereerste fasen van de architectuuruitwerking. Reden om te zoeken naar een werkwijze voor het doen van risico inventarisaties binnen een ICT architectuur traject. Hierbij wordt een risico inventarisatie alsvolgt onderverdeeld: Architectuur risico inventarisatie Risico s visualiseren binnen een architectuurtaal In onderstaande paragrafen werken we beide aspecten uit. Risico inventarisatie Bij ICT architectuur ligt de focus op aspecten van vernieuwing en optimalisatie. Bij ontwikkelaars van software zien we een duidelijke overeenkomst met deze focus, met name gericht op optimalisatie. De beheerorganisatie heeft de focus op de volgende aspecten van het ICT landschap: 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 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 aan de beheerorganisatie, bijvoorbeeld op het vlak van kennisontwikkeling, inrichting van 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 op het vlak van kennisontwikkeling en beheeractiviteiten. 3

4 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. 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 [1]. Hieronder een aantal relevante concerns voor stakeholders uit de beheerorganisatie. Nogmaals wordt benadrukt dat de inperking voor de beheerorganisatie een keuze is. Concerns kunnen voor alle stakeholders bepaald en gekwantificeerd worden met behulp van risico inventarisaties Inventarisatie van de concerns en de onderliggende risico s kan op meerdere manieren uitgevoerd worden. Een veelgebruikte indeling is de volgende [6]: 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. In onderstaande afbeelding van een geautomatiseerde checklist voor het inventariseren van risico s. 4

5 Eindresultaat van een risico inventarisatie is dat er een beeld is van de risico s behorende bij de componenten binnen de ICT architectuur vanuit het perspectief van één of meerdere stakeholders. Hierbij is het mogelijk om de componenten per risicogebied met elkaar te vergelijken door ze te classificeren binnen vooraf gedefinieerde categorieen. Vervolgens kunnen verschillende architectuur uitwerkingen op basis van deze classificatie (kwanitiatief) vergeleken worden. ` 5

6 Architectuur risico visualisatie Een uitwerking van een risicoinventarisatie van geclassificeerde architectuur componenten en het vergelijken van uitwerkingen zal al snel complex worden. Het visualiseren van risico s binnen architectuur kan bijvoorbeeld op de volgende manieren: Matrices Matrices zijn een weergave van drie dimensies en zijn daardoor geschikt om componenten, risico s en de score binnen de classificatie weer te geven Voor de risico inventarisatie is er een verrijkte weergave ontwikkeld met een kleurcodering voor de categorieen. Grafen Voorbeelden van grafen zijn ER diagrammen, UML class diagrammen. De architectuur modelleertaal Archimate [5] is gebaseerd op grafen. Grafen kunnen kortweg omschreven worden als entiteiten (rechthoeken) die op basis van relaties (lijnen) met elkaar verbonden zijn. Aan deze twee dimensies kan een extra dimensie toegevoegd worden voor visualisatie van risico s. In onderstaande afbeelding een graaf op basis van de Archimate notatie die verrijkt is met attributen die de risico s weergeven. Hierbij wordt wederom een kleurencategorisering gebruikt zodat snel inzicht te krijgen is van waar risico s optreden in de architectuur uitwerking. 6

7 Beide architectuur visualisaties maken het mogelijk om op een eenvoudige wijze inzichtelijk te maken welke componenten binnen de architectuur de meeste of minste risico s vormen. Dit kan verder uitgebreid worden door bepaalde concerns en/of stakeholders een andere waardering te geven. Hiermee kan dan vervolgens een sommering gemaakt worden van de waardering en de score waarbij de totaalscore aangeeft welke configuratie kwantitatief het laagste risico omvat. Tot slot In dit artikel is ingegaan op de mogelijkheden van risico inventarisatie en -visualisatie binnen ICT architectuur. Hierbij is een beeld gegeven van een werkwijze. Deze werkwijze wordt uitgewerkt in de vorm van een risico extensie voor de modelleertaal Archimate. Deze uitwerking bestaat uit de volgende onderdelen: Beschrijving van methodische stappen Voorbeelden van risico inventarisatie checklists Architectuur visualisaties Prototype van een geautomatiseerde risico extensie tool Meer informatie over de Archimate Risico Extensie is te vinden op Bronnen [1] The Open Group, Togaf 9.0, [2] Foundations of IT Service management op basis van ITIL v3 7

8 [3] Cramm.com [4] Goutier, H. & Lieshout, J. Van, Nora 3.0, principes voor samenwerking en dienstverlening,e-overheid, [5] The Open Group, Archimate 1.0 specification, [6] Best, B. De, Acceptatiecriteria,