Een risico- en kostengedreven aanpak voor architectuur

architectuur

t

­

Een risico- en ­kostengedreven ­aanpak voor architectuur

Risico- en

Architectuur is te beschouwen als een discipline die gedreven

kostenmanagement

wordt door risico’s en kosten. Risico- en kostenmanagement

als primair

is dan het primaire businessdoel van het architectuurproces.

businessdoel

Dit gedachtegoed vormt de basis van een aanpak voor solution architecture die bij Logica is ontwikkeld, getiteld Risk and Cost Driven Architecture (RCDA). De auteurs beschrijven de achtergrond van deze visie en de impact ervan op het werk van de architect.

Eltjo Poort en Hans van Vliet

informatie / november 2011

Er zijn globaal twee zienswijzen op architectuur: 1. Architectuur is een hoog-niveau abstractie en bestaat uit componenten en connectoren (Shaw, 1990). 2. Architectuur is een verzameling ontwerpbeslissingen met bijbehorende onderbouwing (Tyree & Akerman, 2005).

12

Zienswijze 1 legt de nadruk op de oplossing, de uitkomst van het ontwerpproces. Zienswijze 2 is breder en ziet het ontwerpen van een architectuur als een beslisproces, waarbij de architect dus een beslisser is. Deze tweede zienswijze wordt inmiddels breed gedragen (Farenhorst & De Boer, 2009). Er is momenteel veel aandacht voor het structureren van ontwerpbeslissingen en toolondersteuning, maar veel minder voor de vraag waarover de architect dan beslissingen moet nemen.

Wij beschouwen architectuur als een discipline die gedreven wordt door risico’s en kosten. Met andere woorden, de belangrijke zaken waarover architecten beslissingen moeten nemen zijn de inhoudelijke zaken die de hoogste impact hebben qua risico en kosten. Natuurlijk zijn risico’s en kosten altijd al belangrijk geweest, maar wij gaan een stapje verder: we zien risico- en kostenmanagement als primair businessdoel van het architectuurproces. Dit helpt de architect op verschillende manieren: • Het stelt hem in staat zijn bezigheden te ordenen, qua focus en timing van beslissen • Het ondersteunt zijn communicatie met belanghebbenden in businesstermen. Dit gedachtegoed vormt de basis van een aanpak voor solution architecture die bij Logica is ont-

Samenvatting Architectuur kan worden beschouwd als een discipline die gedreven wordt door risico’s en kosten. Deze zienswijze helpt architecten bij het identificeren van vraagstukken die zij moeten oplossen door het nemen van architectuurbeslissingen. Bovendien helpt de zienswijze om het werk van de architect te positioneren bij de belanghebbenden uit de business, waardoor hij zijn werk effectiever kan doen.

Waar gaan architectuurbeslissingen over? Als we softwarearchitectuur zien als een verzameling ontwerpbeslissingen, gaan de beslissingen van een architect kennelijk over softwareontwerp. Dit lijkt echter te algemeen. Niet alle ontwerpbeslissingen hebben impact op de architectuur. Ontwikkelaars bijvoorbeeld nemen allerlei detailontwerpbeslissingen tijdens het programmeren. Je hoort ook vaak dat architecten op een hoger niveau van abstractie werken dan ontwerpers of ontwikkelaars. Veel architecten echter doen meer dan dat en nemen zeer gedetailleerde beslissingen over zaken die zij architecturaal significant achten (Fowler, 2003). De definitie van softwarearchitectuur uit de ISO-standaard zegt: ‘Software architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution’ (ISO, 2007). In deze definitie zijn twee termen essentieel: ‘fundamental’ en ‘guiding principles’. Architecten moeten zich richten op beslissingen over fundamentele zaken en op richtinggevende principes. Of, in de woorden van Ralph Johnson: ‘Architecture is about the important stuff. Whatever that is.’ Voor ons is ‘the important stuff ’ dat wat de meeste impact op risico’s en kosten heeft. Deze zienswijze is door de jaren heen gegroeid, na veel gesprekken met architecten en andere belanghebbenden

en dankzij ervaringen die we hebben opgedaan in complexe situaties. En het heeft geholpen.

Architecturaal belangrijk in termen van risico’s en kosten We zullen laten zien hoe het belang van architectuurvraagstukken gekwantificeerd kan worden. Hiermee kan een architect de vraagstukken ordenen en zich richten op de meest significante. In de praktijk zullen veel architecten bij het bepalen van wat architecturaal belangrijk is afgaan op hun ervaring en onderbuikgevoel, ondersteund door checklists en templates. De formule die we geven is ter verdere ondersteuning. Onze aanpak is gebaseerd op het volgende principe: het architecturale belang (AB) van een vraagstuk kan worden weergegeven door het budget dat we moeten reserveren om het vraagstuk op te lossen (of juist niet), inclusief onvoorziene kosten, oftewel: AB(I) = Kosten(I) + Risico(I)

Hierin staat Kosten(I) voor de geschatte kosten voor het oplossen (of onopgelost laten) van het vraagstuk, en Risico(I) voor de geschatte kosten als ‘dingen verkeerd gaan’: de onvoorziene kosten. Over het inschatten van Kosten is al veel geschreven; hieronder gaan we in op het onderdeel Risico van de formule. De formule drukt architecturaal belang uit in geld. Dat is niet alleen handig voor het sorteren van architectuurvraagstukken, het geeft ook een idee van het maximale economische voordeel van elk vraagstuk. Als de kosten meer zijn dan de maximale opbrengsten, heeft het duidelijk geen zin verder te gaan; die vraagstukken zijn dan niet architecturaal significant. Het gebruik van risico om te bepalen wat een architect wel en niet moet doen, is ook de basis van Fairbanks’ risicogedreven model (Fairbanks, 2010). Wij voegen daar nog het onderdeel kosten aan toe.

informatie / november 2011

wikkeld, getiteld Risk and Cost Driven Architecture (RCDA). Inmiddels zijn meer dan honderd Logica-architecten in deze aanpak getraind en krijgen we zeer positieve reacties aangaande het gebruik in de praktijk. We beschrijven hier de achtergrond van deze visie en de impact op het werk van de architect. Een uitgebreidere versie van dit artikel is eerder dit jaar gepresenteerd aan de internationale softwarearchitectuurgemeenschap (Poort & Van Vliet, 2011).

13

architectuur

t

Risico Een risico is iets wat mis kan gaan. In kwantitatieve termen wordt het risico vaak als volgt uitgedrukt: Risico(F) = p(F) × I(F)

Daarbij is F een faalscenario, p(F) de kans dat F optreedt en I(F) de verwachte kosten van F. We gaan er voor het gemak van uit dat I(F) alle kosten representeert, bijvoorbeeld ook de indirecte kosten als gevolg van later opleveren als het fout gaat. Het gaat hier steeds over geschatte kans en verwachte kosten, omdat de architect de echte waarden natuurlijk niet van tevoren kent. De volgende stap is het koppelen van architectuurvraagstukken aan faalscenario’s. Als we eenmaal alle faalscenario’s behorend bij een vraagstuk hebben bepaald, kunnen we simpelweg de financiële risico’s van die scenario’s bij elkaar optellen. Dat is hetzelfde als het uitrekenen van het benodigde budget onvoorzien (‘contingency’) op basis van het risicoregister. De sleutel tot het identificeren van de faalscenario’s bij een architectuurvraagstuk ligt bij de architectuurbeslissingen. Het meest generieke falen is ‘het niet nemen van de juiste beslissingen’, oftewel ‘het nemen van beslissingen als gevolg waarvan de oplossing niet aan de eisen voldoet’. Meer specifieke faalscenario’s kunnen hieruit afgeleid worden met behulp van standaard-risicoevaluatieberekeningen. Een voor-

informatie / november 2011

architectuurbeslissingen

14

besluiten best passende oplossing

beeldvraagstuk uit de softwarearchitectuur is: hoe houden we Java-objecten in een applicatieserver gesynchroniseerd met de overeenkomstige records in een relationele database? Dit staat bekend als het O/R-mappingprobleem en er zijn verschillende hulpmiddelen en technieken om dit aan te pakken: het gebruik van Hybernate, entity beans, hard gecodeerde SQL enzovoort. Stel voor het gemak dat we één beslissing nodig hebben voor het O/R-mappingprobleem: het kiezen van een van de beschikbare hulpmiddelen of technieken. De faalscenario’s zijn die scenario’s die maken dat aan kwaliteitseisen zoals onderhoudbaarheid, dataintegriteit en prestaties niet wordt voldaan. Afhankelijk van de context kan de beslissing om hard gecodeerde SQL-instructies te gebruiken een foute zijn. De sterke koppeling van de Java-code met het relationele datamodel die hier het gevolg van is, kan veel kosten met zich meebrengen als we iets willen veranderen. Als deze verandering noodzakelijk wordt, moet de code ‘gerefactored’ worden, en de impact van de foute beslissing vertaalt zich uiteindelijk naar de totale kosten van deze refactoring, inclusief de extra kosten als gevolg van latere oplevering. Dit zijn in feite de kosten van het ongedaan maken van de beslissing. Dit voorbeeld illustreert een algemeen punt: de maximale schade als gevolg van een foute beslissing zijn de kosten van het ongedaan maken van die beslissing. We kunnen ook zeggen dat ontwerpbeslissingen meer architecturaal worden naarmate het duurder wordt ze ongedaan te maken. Een architect moet zich realiseren dat verschillende belanghebbenden ook een verschillende kijk op risico’s hebben. Een projectmanager zal vooral geïnteresseerd zijn in risico’s die impact hebben op projectsucces, terwijl een beveiligingsexpert vooral geïnteresseerd zal zijn in beveiligingsrisico’s. Deze laatste zullen vooral optreden nadat het systeem

identificeren & prioriteren architectuurvraagstukken

architectuurvraagstukken (backlog)

onderzoeken mogelijke oplossingen

Figuur 1. Dagelijkse werkstroom van architecten

Impact op architectuurwerk Hoe beïnvloedt onze kijk op architectuur het werk van architecten? De dagelijkse werkstroom van architecten wordt in Hofmeister et al. (2005) omschreven als een schijnbaar lukraak proces, waarbij architecten impliciet dan wel expliciet een ‘backlog’ bijhouden van nog te vervullen eisen, open vraagstukken, ideeën en dergelijke. De elementen in deze backlog worden continu opnieuw geprioriteerd. Een van de krachten die deze prioritisering stuurt is het bijbehorende risico (naast druk vanuit het team of belanghebbenden, moeilijkheidsgraad en dergelijke). Veel architecten geven aan dat vooral hier de toegevoegde waarde van de risico- en kostengedreven aanpak ligt. Deze stelt architecten in staat de elementen in de backlog beter te ordenen. Gewapend met de financiële onderbouwing van zijn prioriteiten kan de architect bovendien beter aan belanghebbenden uitleggen waaraan hij zijn tijd besteedt en waarom.

Implementatie van risico- en kostengedreven architectuuraanpak Zoals eerder beschreven is bij Logica een uitgebreide solution-architectureaanpak ontwikkeld, gebaseerd op de risico- en kostengedreven visie op architectuur. De volgende algemene richtlijnen kunnen echter binnen iedere architectuuraanpak worden toegepast: • Maak een assessment van risico’s en kosten onderdeel van de architectuuranalyse. Deze richtlijn is een voorwaarde voor alle volgende richtlijnen. • Houd een qua risico’s en kosten geordende lijst van architectuurvraagstukken bij. De bovenste drie tot zeven elementen uit deze lijst zijn het meest significant. Deze lijsten zijn niet alleen belangrijk voor de architect, maar leveren op termijn ook een projectoverstijgende geschiedenis op. • Monitor de belangrijkste architectuurvraagstukken regelmatig. Het belang van een vraagstuk kan toenemen zelfs nadat er een beslissing over is genomen, gestuurd door voortschrijdend inzicht in risico en kosten van de beslissing.

• Communiceer over architectuurvraagstukken met belanghebbenden uit de business in termen van risico’s en kosten. Architecten moeten hun prioriteiten expliciet koppelen aan de businesscontext van hun belanghebbenden. • Betrek jezelf bij het risicoregister. Architectuurvraagstukken impliceren risico’s en horen dus vaak thuis in het risicoregister. • Geef voortgangsrapportages in termen van risico’s en kosten. De mate waarin architectuurvraagstukken onder controle zijn is een goede mate van voortgang voor de architectuurfase. • Stop het architectuurproces als de impact van beslissingen te laag wordt. Doe niet meer architectuur dan noodzakelijk is.

Veelgestelde vragen Sommige vragen die gesteld worden door architecten tijdens de training in deze aanpak komen steeds weer terug: 1. Hoe zit het met bestaande systemen? Bij bestaande systemen weten we immers hoe de beslissingen uitgevallen zijn. Heeft het dan nog wel zin te praten over risico’s van foute beslissingen? Het antwoord is ja. Architecturale activiteiten gerelateerd aan bestaande systemen, zoals herstructurering en evaluatie, hebben ook betrekking op risico’s en kosten. Wat architecturaal relevant is wordt ook hier bepaald door risico’s en kosten: gaan we het systeem overzetten naar een ander platform? Gaan we een component die lastig te onderhouden is herstructureren? 2. Hoe zit het met waarde? Je zou kunnen beargumenteren dat waarde voor belanghebbenden zeker zo belangrijk is als risico’s of kosten. In de praktijk blijkt dat architecten zich minder met waarde bezighouden. Overwegingen over de waarde van een systeem hebben veelal al hun weerslag gehad in de doelen en businesseisen die de architect gegeven zijn. In twee soorten situaties zie je wel dat architecten betrokken zijn bij discussies over waarde. Ten eerste: het creëren van waarde voor ‘interne’ belanghebbenden. Voorbeelden zijn beslissingen over het creëren van herbruikbare componenten, of over een efficiëntere implementatie. In deze gevallen bestaat de waarde uit kostenbesparing en is de architect dus weer risico- en kostengedreven. En ten tweede: kosten-batenanalyses over architectuurbeslissingen (Asundi, Kazman & Klein, 2001). 3. Moeten architecten altijd de risico’s minimaliseren? Nee. Risico’s en kosten spelen een rol in de afwegingen die een architect maakt. Andere

informatie / november 2011

is opgeleverd en de projectmanager vertrokken is. Dit kan in de bovenstaande formule zichtbaar worden gemaakt door deze per belanghebbende toe te passen. Vervolgens kunnen deze kosten bij elkaar worden opgeteld. In feite is het architecturale belang van een vraagstuk belanghebbendeafhankelijk. Het is dan ook belangrijk voor architecten om zich dit te realiseren en goed om te gaan met uiteenlopende belangen.

15

architectuur

t

»Gewapend met de financiële onderbouwing van zijn prioriteiten kan de architect beter aan belang­ hebbenden uitleggen waaraan hij zijn tijd besteedt en waarom«

overwegingen kunnen eveneens een rol spelen. Wat belangrijk is, is dat de risico’s expliciet worden gemaakt en worden meegewogen in de afwegingen. 4. Geldt deze werkwijze ook voor (infrastructuur-, systeem- enzovoort) architecten? Van de tot nu toe getrainde architecten noemde de helft zich niet softwarearchitect. Zij waren geïnteresseerd in de aanpak, omdat ook zij beslissingen nemen en ook zij te maken hebben met dezelfde belangrijke concepten: belanghebbenden, vraagstukken, beslissen enzovoort. Zij achtten de door ons gepresenteerde principes evenzeer van toepassing op hun omstandigheden. Hoewel de hier geschetste visie dus gebaseerd is op ideeën uit de softwarearchitectuur, wordt deze gebruikt in de bredere context van solution architecture. Reviewer Patricia Lago

Literatuur Asundi, J., R. Kazman & M. Klein (2001). Using Economic Considerations to Choose Among Architecture Design Alternatives. SEI, Technical Report CMU/SEI-2001-TR-035. Fairbanks, G. (2010). Just Enough Architecture: The RiskDriven Model. Crosstalk, Nov/Dec. Farenhorst, R. & R. de Boer (2009). Architectural Knowledge Management: Supporting Architects and Auditors. Ph.D. dissertation, VU University, Amsterdam. Fowler, M. (2003). Who needs an Architect? IEEE Software, vol. 20, no. 5, pp. 11-13. Hofmeister, C. et al. (2005). Generalizing a model of software architecture design from five industrial approaches. 5th Working IEEE/IFIP Conference on Software Architecture (WICSA 2005). Pittsburgh, Pennsylvania, pp. 77-86. ISO (2007). Recommended Practice for Architecture Description of Software-Intensive Systems. 2007. Poort, E.R. & H. van Vliet (2011). Architecting as a Risk- and Cost Management Discipline. 9th Working IEEE/IFIP Conference on Software Architecture (WICSA 2011). Boulder, Colorado, pp. 2-11. Shaw, M. (1990). Toward higher-level abstractions for software systems. Data & Knowledge Engineering, vol. 5, no. 2, pp. 119-128. Tyree, J. & A. Akerman (2005). Architecture decisions: Demystifying architecture. IEEE Software, vol. 22, no. 2, pp. 19-27. Eltjo Poort is lead expert architectuur bij Logica. E-mail: eltjo.poort@ logica.com.

informatie / november 2011

Hans van Vliet is hoogleraar software engineering aan de Vrije Universiteit. E-mail: [email protected].

16