business alignment
t case Overkoepelende taal en technieken
ArchiMate-methode verbindt architectuurdomeinen In juli 2002 startte een aantal Nederlandse instituten en bedrijven het project ArchiMate. Het doel is een taal voor de beschrijving van enterprisearchitecturen op hoofdlijnen. Marc Lankhorst, Leon van der Torre, Hugo ter Doest en Andries Stam
informatie / april 2004
Er zijn deeloplossingen voor de verschillende architectuurterreinen beschikbaar, zoals de Unified Modeling Language (UML) voor softwaremodellering (Booch, Rumbaugh & Jacobson; 1999). Deze richten zich echter op een detailbeschrijving van een beperkt deel van een enterprisearchitectuur en niet op de hoofdlijnen en de samenhang van de verschillende gebieden. Een betekenisvolle beschrijvingswijze voor het in kaart brengen van al die verschillende gebieden en hun onderlinge relaties ontbreekt. Het ArchiMate-project ontwikkelt een dergelijke architectuurtaal. Figuur 1 laat een vereenvoudigd voorbeeld zien van een architectuurmodel uitgedrukt in die taal; het beschrijft de koppeling tussen het claimverwerkingsproces en de ondersteunende applicaties van het (fictieve) verzekeringsbedrijf ArchiSurance.
34
Het is niet de bedoeling met deze architectuurtaal modelleertalen zoals UML te vervangen. Dergelijke talen zijn vaak sterk op hun deelterrein, maar missen de relatie met andere domeinen. Dat is precies waar ArchiMate zich op richt: vanuit modellen op een overkoepelend niveau kunnen relaties gelegd worden met meer gedetailleerde modellen in bestaande talen. Zo zou bijvoorbeeld een applicatieconcept
kunnen worden gekoppeld aan een gedetailleerd UML-model dat de softwarearchitectuur van die applicatie beschrijft; een proces dat die applicatie gebruikt zou bijvoorbeeld in meer detail in de Business Process Modeling Notation (BPMI, 2003) kunnen worden gemodelleerd. De koppeling tussen die twee detailmodellen kan je echter in UML en BPMN niet goed beschrijven. Via het ArchiMate-model kan het verband tussen de verschillende domeinen wel worden gelegd (figuur 2).
Services In het architectuurdenken is het servicebegrip sterk in opkomst. Het beschouwen van de netwerkinfrastructuur als een service aan het applicatieniveau is allang gemeengoed. Op dat applicatieniveau zelf zijn webservices op dit moment de grote belofte (of hype). Webservices vormen een manier om applicatiefuncties via standaardprotocollen over het internet toegankelijk te maken. Dit maakt het koppelen van applicaties en de integratie van systemen van verschillende leveranciers veel eenvoudiger. Ook de manier waarop bedrijven met hun omgeving samenwerken wordt in toenemende mate in services en service level agreements uitgedrukt. En binnen bedrijven worden businessservices steeds belangrijker;
Er is behoefte aan een meer geïntegreerde benadering van architectuur, die aandacht besteedt aan de samenhang tussen verschillende toepassingsgebieden en aan de communicatie over architecturen met alle belanghebbenden. Om in deze behoefte te voorzien startte in juli 2002 het ArchiMateproject, een samenwerkingsverband van het Telematica Instituut, Ordina, ABN AMRO, de Stichting Pensioenfonds ABP, de Belastingdienst, het Centrum voor Wiskunde en Informatica, de Universiteit Leiden en de Katholieke Universiteit Nijmegen.
en integreren van de verschillende architectuurniveaus. Dit was ook al te zien in het voorbeeld van figuur 2.
Views Verschillende belanghebbenden hebben elk hun eigen informatiebehoefte bij een architectuur. De achtergrond van de doelgroep is bepalend voor zowel de inhoud als de gewenste vorm waarin die informatie wordt gepresenteerd. Wat de geschiktste ‘views’ zijn voor de verschillende belanghebbenden en hoe deze gerealiseerd
Applicaties, via services gekoppeld aan het bedrijfsproces ‘schadeclaims verwerken’
1
informatie / april 2004
veel grote informatieverwerkende bedrijven zijn bijvoorbeeld bezig met het inrichten van shared services, waarmee ze de back-office kunnen stroomlijnen en integreren zonder dat het frontoffice van gezicht hoeft te veranderen. Een algemeen servicebegrip, dat op verschillende niveaus een specifieke invulling krijgt, is een belangrijk onderwerp van onderzoek. We zien services als de manier bij uitstek om de integratie zowel binnen als tussen die niveaus te beschrijven. Zoals in figuur 3 wordt geïllustreerd, speelt het servicebegrip een centrale rol in het relateren
35
business alignment
t
Een ArchiMate-model als brug tussen andere modellen
informatie / april 2004
Services als ‘linking pins’ tussen architectuurlagen
36
3
2
kunnen worden, zijn belangrijke onderzoeksvragen. Een belangrijk uitgangspunt is het ‘viewpoint’begrip uit de IEEE 1471-standaard. Een viewpoint geeft een gezichtspunt op een architectuur en een view is de weergave van de architectuur vanuit dit gezichtspunt. Figuur 4 illustreert de relatie tussen architecten en hun modellen, views en analyses hiervan, en de presentatie van de resultaten aan belanghebbenden. Figuur 5 laat een voorbeeld van zo’n view zien: een ‘landschapskaart’ (zie Van der Sanden e.a.; 1999) waarin de applicaties van onze voorbeeldverzekeraar ArchiSurance worden weergegeven ten opzichte van de producten en bedrijfsfuncties van dit bedrijf. Door die visualisaties te koppelen met een onderliggend model wordt het mogelijk op een consistente manier de diverse belanghebbenden van de juiste informatie te voorzien. Omgekeerd zouden sommige visualisaties zelfs interactief kunnen worden gebruikt om de modellen aan te passen of om veranderingen uit de proberen. Wanneer je in de landschapskaart bijvoorbeeld de grenzen van een applicatie kunt veranderen en deze
Impactanalyse Goede analysetechnieken die gebruik maken van de samenhang en relaties in een architectuur kunnen het effect van veranderingen van hoog tot laag doorrekenen. Zo kan bijvoorbeeld worden bepaald welke bedrijfsprocessen en applica-
Presentatie architecturen als brug tussen architecten en belanghebbenden
4
Voorbeeld van een landschapskaart met it-applicaties
5
informatie / april 2004
verandering op het onderliggende model door kunt laten rekenen, wordt het eenvoudiger om de impact van zo’n wijziging te bepalen. Voor architecten, managers en anderen die een geïntegreerde visie op hun bedrijf willen vormen, zijn dit soort analyses een belangrijk hulpmiddel.
37
business alignment
t case ties moeten worden aangepast als een bedrijf een nieuw product aan zijn portfolio wil toevoegen. Doordat in een goed enterprisearchitectuurmodel de verschillende lagen in hun onderlinge samenhang beschreven zijn (bijvoorbeeld met behulp van services, zoals in figuur 3) kunnen de effecten voor het gehele bedrijf in kaart gebracht worden. Bij een impact-of-changeanalyse worden de gevolgen van een verandering op de huidige architectuur beschreven, bijvoorbeeld door de geraakte entiteiten volgens van te voren beschreven regels op te laten lichten. Bij beslissingsondersteunende systemen kan de gebruiker een aantal veranderingen uitproberen en de uitkomsten vergelijken. De resultaten hiervan kunnen worden weergegeven doordat bijvoorbeeld de betrokken elementen van kleur veranderen of op een andere manier. Figuur 6 is een voorbeeld van een impactanalyse over verschillende lagen van een enterprisearchitectuur: alles wat wordt geraakt door het falen van een server is donker weergegeven. Een impact-of-changeanalyse is niet simpel een kwestie van ‘door een plaatje lopen’. Om echt aan veranderingen van een architectuur te kunnen rekenen, moet een analysetechniek de betekenis (semantiek) van de gebruikte modelconcepten kennen. Het achterliggende en algemeen aanvaarde idee van impact-of-changeanalyse is dat een architectuurbeschrijving meer is dan een aantal associaties tussen concepten die gevisualiseerd kunnen worden.
informatie / april 2004
Ontwerpondersteuning
38
Impact-of-changeanalyses dienen niet alleen om meer inzicht te geven in de effecten van veranderingen. Ook helpen ze de architect zelf bij het opstellen van architectuurmodellen. Om de architect te ondersteunen in het ontwerpproces is het zinvol die modellen tijdens het ontwerpen te controleren op consistentie en welgevormdheid. Verder hanteren bedrijven vaak architectuurprincipes of ontwerpregels waaraan bedrijfsvoering, processen en systemen zich moeten houden. UML voorziet in deze behoefte
met de Object Constraint Language (OCL) (Warmer & Kleppe; 1999), die wordt gebruikt om extra eisen op te leggen aan UML-diagrammen. In ArchiMate wordt een vergelijkbare aanpak ontwikkeld: de modellen worden vertaald naar een beschrijvingslogica (analoog aan OCL) waaraan vervolgens de extra eisen worden toegevoegd uitgedrukt in dezelfde logica. Vervolgens leidt een redeneermechanisme af of het model voldoet aan de eisen. Stel dat een architect een systeem heeft gemodelleerd met drie actoren A, B en C, en een constraint die zegt dat A en B deel moeten uitmaken van dezelfde andere actor, C in dit geval. Stel vervolgens dat actor C wordt opgedeeld in twee actoren D en E, op zo’n manier dat A en B niet meer deel uit van dezelfde actor. Dan wordt de constraint overtreden. Door de ‘business rules’ van een bedrijf onafhankelijk van de concrete architectuurbeschrijvingen als logische regels weer te geven en deze automatisch te laten controleren, wordt de architect veel werk uit handen genomen.
Direct of indirect Binnen impact-of-changeanalyse zijn twee aanpakken de directe en de indirecte methode te onderscheiden. Bij de directe methode wordt de impact van een verandering op een architectuur direct beschreven, door bijvoorbeeld de relaties in de architectuur ‘af te wandelen’ om de betrokken objecten te vinden. Bij de indirecte methode wordt er een onderscheid gemaakt tussen drie stappen. 1. Je neemt de huidige architectuur als uitgangspunt en berekent de impact van een verandering als nieuwe architectuur, onafhankelijk van wat je gaat meten (verandering). 2. Je meet de nieuwe en de oude architectuur (meetinstrumenten). 3. Je vergelijkt de oorspronkelijke architectuur met de nieuwe architectuur (visualisatie en vergelijking van meetresultaten). De eerste techniek is vooral bruikbaar om alert te kunnen reageren op veranderingen binnen of buiten het bedrijf. Een snelle impactanalyse leert dan welke onderdelen van het bedrijf worden ‘geraakt’ en waar dus maatregelen moeten worden getroffen. De tweede techniek is meer geschikt voor het vergelijken van alternatieve mogelijkheden (architectuurmodellen) en het uitzetten en beheersen van veranderingstrajecten. Afhankelijk van de gekozen set meetinstrumenten wordt een ander aspect van de verandering geanalyseerd.
Er is nog niet veel bekend over welke techniek het beste voor welke problemen gebruikt kan worden en wat de voor- en nadelen van beide technieken zijn. Een voordeel van de directe methode is dat analysemethoden sneller ontwik-
6
keld kunnen worden. Een nadeel is echter dat de aanpak nogal ad hoc is en dat er elke keer opnieuw bekeken moet worden hoe een analysetaak gemodelleerd kan worden. Een ander nadeel is dat het moeilijk is om de analysevraag te
informatie / april 2004
Voorbeeld van een impactanalyse
39
business alignment
t case valideren: is deze wel logisch correct? Neem bijvoorbeeld een analyse die bedoeld is om te bepalen wat de impact is van een verandering in een actor A en daarom vraagt welke andere actoren deel uitmaken van A. Effecten van die verandering kunnen zich echter ook uitstrekken tot de actoren waarin A zelf weer bevat is, dus deze analysevraag is onvolledig, onafhankelijk van het model waarop hij wordt toegepast. De tweede aanpak heeft een aantal theoretische voordelen. Zo is er de mogelijkheid tot een verdeel-en-heersstrategie, zoals bij elke compositionele aanpak. Ook kunnen de verandering en de meetinstrumenten apart getest worden, wat de kans op fouten in analysevragen vermindert. Verder zijn er vaak al meetinstrumenten die hergebruikt kunnen worden. Ten slotte zou je meetinstrumenten uit andere modellen kunnen hergebruiken; dit kan een eerste stap zijn om niet alleen de modellen maar ook de analysemethoden van aanpakken als Testbed, Protos en UML te integreren.
informatie / april 2004
Tot slot
40
Samenvattend kunnen we stellen dat een goede architectuurpraktijk een belangrijke bijdrage kan leveren aan de bestuurbaarheid van een organisatie. Het gebruik van een goed gefundeerde taal en technieken voor het bedrijfsbreed beschrijven en analyseren van architecturen helpt de belanghebbenden om de gevolgen van beslissingen en veranderingen over de gehele breedte van hun organisatie te overzien, te plannen en te communiceren. Het ontwikkelen van deze technieken is de onderzoeksuitdaging van het ArchiMateproject. De resultaten worden niet alleen door de deelnemende partijen in de praktijk en in het onderwijs ingezet, maar worden ook zoveel mogelijk publiek beschikbaar gemaakt. ArchiMate werkt hierin onder meer samen met het Nederlands Architectuur Forum en met diverse leveranciers van modelleertools. Meer informatie is te vinden op de website van het project: archimate.telin.nl.
Literatuur Booch, G., J. Rumbaugh & I. Jacobson (1999). The Unified Modeling Language User Guide. Addison-Wesley. BPMI (2003). Business Process Modeling Notation, Working Draft (1.0) August 25, 2003. Business Process Management Initiative (BPMI). IEEE (2000). IEEE Std 1471-2000: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Computer Society. Jonkers, H., et al. (2003). Towards a Language for Coherent Enterprise Architecture Descriptions. In Proc. 7th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2003). Brisbane, Australia: IEEE Computer Society. Sanden, W.A.M. van der, P. Bergman, J.C. Campschroer & H.R. de Reus (1999). Realisatie van flexibele informatievoorziening. Informatie januari 1999, pp. 58-65. Warmer, J.B., & A.G. Kleppe (1999). The Object Constraint Language, Precise Modeling with UML. Addison-Wesley. Dr.ir. Marc M. Lankhorst is onderzoeker bij het Telematica Instituut en projectmanager van ArchiMate. E-mail:
[email protected]. Dr. Leon W.N. van der Torre is onderzoeker bij het Centrum voor Wiskunde en Informatica. E-mail:
[email protected]. Dr.ir. Hugo ter Doest is onderzoeker bij het Telematica Instituut. E-mail:
[email protected]. Drs. Andries Stam is consultant bij Ordina. E-mail:
[email protected].
