De Communicatie van Architectuur

Een matrix als hulpmiddel om de belangrijkste architectuurbeslissingen af te stemmen op de voornaamste belangen van alle betrokkenen.

In dit artikel presenteert Henk Koning een eenvoudige (matrix)techniek om de belangrijkste architectuurbeslissingen af te stemmen op de belangen van betrokkenen. De techniek is een onderdeel van een methode in ontwikkeling voor het ontwerpen van IEEE Std 1471 architectuur viewpoints.

Sinds het midden van de negentiger jaren is ‘architectuur’ een populair begrip aan het worden binnen de IT. Met de groeiende omvang van IT-activiteiten was de tijd kennelijk rijp voor een begrip dat wel lijkt op ‘systeemontwerp’, maar breder is en een groter verantwoordelijkheidsgebied omvat. Een veel geciteerde definitie van ‘architectuur’ is die van IEEE Std 1471 ⁽¹⁾, die, vertaald naar het Nederlands, luidt:

“de fundamentele organisatie van een systeem weergegeven in de componenten, hun relaties tot elkaar en tot de omgeving, en de principes die gehanteerd worden bij hun ontwerp en (voortgaande) ontwikkeling”.

Oftewel, als je praat over een heel systeem, uit welke onderdelen bestaat dat dan, wat voor relaties hebben die onderdelen tot elkaar en tot de omgeving en hoe worden die onderdelen ontworpen en gebouwd? De functionele indeling van een informatiesysteem en de afbeelding daarvan op technische componenten, is een heel belangrijk beslissing. Het bouwen van technische componenten van informatiesystemen is de sport (het vak) van veel van de leden van het Software Developer Network, dus dat klinkt wel vertrouwd.

Maar wat moet je nou verstaan onder ‘principes die gehanteerd worden bij hun ontwerp en (voortgaande) ontwikkeling’? Je kunt daarbij het beste denken aan alles wat is afgesproken bij de start van een project en waar je je als ontwikkelaar aan moet houden. Bijvoorbeeld de afspraak dat je één bepaalde class moet gebruiken voor alle database access. Of een afspraak over het wel of niet of onder bepaalde condities mogen gebruiken van open source code fragmenten. Of een afspraak over welke techniek gebruikt wordt om de lagen van een n-tier applicatie met elkaar te laten praten, etc.

Eigenlijk valt er dus voor een wat groter project heel veel te regelen en is een architectuur als richtinggevend model op zijn plaats. Het is daarbij tegenwoordig gebruikelijk om voor verschillende gebieden binnen de IT een eigen architectuur te onderscheiden, bijvoorbeeld software-architectuur, netwerkarchitectuur, enterprise-architectuur, gegevensarchitectuur. Voor die begrippen bestaan weer allerlei betekenissen - zie voor omschrijvingen daarvan Florijn e.a. 2003 ⁽²⁾ - maar in dit kader wil ik volstaan met de opmerking dat software-achitectuur het meest op het lijf van het SDN lijkt te zijn geschreven. Dat gaat dus over de binnenkant van de applicatie.

Communicatie

Waarom is het belangrijk om stil te staan bij de communicatie van architectuur? Het is toch wel duidelijk wat er bedoeld wordt als je een bepaalde class verplicht moet gebruiken! Nou, dat is voor een ervaren ontwikkelaar misschien wel duidelijk, maar er zijn nog veel meer personen betrokken bij dat soort projectafspraken. Zo kan het gebruik van een bepaalde class inhouden dat er rechten moeten worden betaald aan een derde partij en dat vindt de baas misschien helemaal niet fijn, die wil geen financiële relaties met ‘onbekende’ bedrijfjes. Het gebruik van een bepaalde class kan ook inhouden dat het gedrag van het systeem verandert en dat gebruikers het kunnen merken, bijvoorbeeld door een langere wachttijd bij bepaalde handelingen of door ontbrekende informatie bij verwerkingsfouten. Er kan een beheersprobleem zijn, doordat de class gebruikt maakt van een bepaalde versie van een Windows-DLL die problemen veroorzaakt bij andere software.

Bij veel ontwerpbeslissingen is het zo dat er vanuit ontwikkelaarstandpunt een bijna vanzelfsprekende logica voor is, maar dat er anderen zijn voor wie die beslissing helemaal niet zo vanzelfsprekend is en die er soms onverwachte nadelen van hebben. ‘Onverwacht’ dan voor de ontwikkelaar. Het is dus zaak om bij belangrijke beslissingen goed te kijken naar wie er allemaal een belang bij heeft en hoe die beslissing voor hem/haar uitpakt.

Omdat dat ook vaak niet-technische mensen zijn, is communicatie van belang. Hoe leg je de techniek uit in termen die begrijpelijk zijn voor die mensen? Welke informatie geef je hen? Het is niet alleen het wel of niet technisch zijn wat meespeelt. Sowieso hebben mensen soms hele andere interessen in een systeem. Iemand van de exploitatie-afdeling zal vooral willen weten hoe de installatieprocedure werkt en welke hardware en software vereist is, en een verkoper wil vooral dat de user-interface er gelikt uitziet. Dus je wilt mensen ook die informatie geven over een architectuur waar ze in geïnteresseerd zijn.

IEEE Std 1471

In 2000 is er door de IEEE een standaard vastgesteld voor het beschrijven van de architectuur van software-intensieve systemen. Hieronder een plaatje van het conceptueel model van deze standaard.

Belangrijkste aspect van dit model voor dit artikel is dat volgens deze standaard een architectuurbeschrijving bestaat uit views die gemaakt zijn volgens een viewpoint. Een viewpoint schrijft voor hoe een view gemaakt moet worden, het is een ontwerp van een view: welke informatie moet er in de view, hoe wordt die informatie eventueel nog vergaard, en volgens welke modellen moet die informatie worden weergegeven? Bovendien - en dat is erg belangrijk - geeft het viewpoint aan voor welke stakeholders (betrokkenen) de view van belang is en welke concerns (belangen of zorgen) van die stakeholders afgedekt worden door de view.

Het IEEE 1471 model is een metamodel van een architectuurbeschrijving. We komen daarmee op metaniveau terecht en dat maakt de rest van dit artikel wel wat abstract. Degenen die moeite blijven doen om het verhaal te volgen, worden aan het eind beloond met een praktisch voorbeeld.

In de praktijk van vandaag is de architectuurbeschrijving meestal één groot document dat aan alle betrokkenen wordt toegestuurd. Die moeten meer dan eens slikken vanwege de omvang van het document en gaan ijverig op zoek naar de informatie die voor hen van belang is. Het kan ook zijn dat ze besluiten om het document voorlopig maar opzij te leggen en te wachten op de live presentatie door de architect.

Onderzoek

Het valt nog niet mee om in een bepaald project vast te stellen wie geïnteresseerd is in welke architectuurinformatie en vervolgens hoe de totale informatie het best ingedeeld en gepresenteerd kan worden. Aan de Vrije Universiteit wordt onderzoek gedaan naar de communicatie van IT-architectuur ⁽³⁾ en is een methode bedacht voor het ontwerpen van architectuurviews. De methode bestaat uit vier stappen:

1.      analyseren stakeholders en hun concerns

2.      samenvatten architectuurontwerp

3.      relateren architectuursamenvatting aan concerns van stakeholders

4.      definiëren viewpoints

Voor elke stap zijn richtlijnen en (bescheiden) hulpmiddelen bedacht (Word template, Visio tekentechniek). De methode is in enkele projecten toegepast en er is commentaar gevraagd van IT-architecten uit de praktijk. Een conclusie is dat het ook met de huidige versie van deze methode nog niet meevalt om goede viewpoints te definiëren (eigenlijk zou het mooi zijn als de viewpoints er gewoon kant en klaar waren), maar dat de stappen als zeer zinvol worden ervaren. Het helpt om de belangen van de stakeholders in het oog te houden en niet teveel te focussen op de techniek. Het helpt om de essentie van je architectuurontwerp expliciet te maken. Het helpt binnen een projectteam aan elkaar te vertellen wat je denkt en wilt.

De methode is dus gebaseerd op het IEEE Std 1471 model, op literatuur over architectuur-views en op een ronde van gesprekken en experimenten met IT-architecten in de praktijk. De methode wordt nog verder ontwikkeld.

Voor dit moment, als eerste kennismaking met het SDN, wil ik mij graag beperken tot een techniek uit stap 3, relateren architectuur samenvatting aan concerns van stakeholders. Het is een simpele matrix, die in de praktijk erg handig blijkt te zijn, en, zo simpel als hij eruit ziet, je soms toch flink tot nadenken zet bij het invullen. De andere onderdelen van de methode zijn misschien stof voor een volgend artikel. Degenen die nu al geïnteresseerd zijn in de hele methode kan ik verwijzen naar de website, of stuur mij een mail voor de laatste beschrijving. Ook is het mogelijk om door middel van een workshop getraind te worden ⁽⁴⁾.

Matrix

De matrix die hier besproken wordt, heet in de methode een ‘content-2-concerns table’ (zie tabel 2 voor een template). De template wordt als volgt ingevuld:

• In de eerste kolom worden, met telkens een lege regel ertussen, de voornaamste architectuurbeslissingen (architectural statements) genoteerd.

• In de koppen van de overige kolommen worden de belangrijkste concerns vermeld die van belang zijn voor dit ontwerp, plus de stakeholders waarvoor zij gelden. Het is belangrijk om voor de concerns die zorgen en interessen te nemen, die dicht bij de stakeholder liggen, dingen dus die voor hem/haar belangrijk zijn in zijn/haar dagelijks functioneren. Per kolom is er één concern.

• Voor het invullen van de kruispunten in de tabel (architectuurbeslissing x concern), wordt eerst gekeken of de architectuurbeslissing van belang is voor dat concern. Zo niet, dan wordt er niets ingevuld. Zo ja, dan worden er twee stukjes tekst ingevuld:
  • In het vakje ter hoogte van de architectuurbeslissing wordt een stukje tekst geplaatst wat aangeeft wat de architectuurbeslissing betekent voor het concern.

  • In het lege vakje daarboven wordt een stukje tekst geplaatst dat aangeeft wat het algemene concern betekent voor deze architectuurbeslissing.

Tabel 1: Template voor “content-2-concerns table” voor het relateren van architectuurbeslissingen aan de concerns van de stakeholders

Op dit moment is het de gewoonte om de tekst i.v.m. concerns een achtergrondkleur geel te geven. Suggesties voor een betere presentatie zijn welkom. De teksten kunnen in telegramstijl zijn; dit is een hulpmiddel voor de architect zelf. Door beknopt te zijn kan er op één pagina een overzicht van veel informatie gecreëerd worden.

Vooral het formuleren van het tweede tekstblokje (wat het concern betekent voor déze architectuurbeslissing) blijkt in de praktijk lastig. Het valt niet mee om onder woorden te brengen wat het effect is van een beslissing voor een bepaalde stakeholder, maar daarom is het juist goed om te doen.

In de methode wordt deze matrix gebruikt om een idee te krijgen welke architecturale informatie voor wie van belang is. Tijdens het ontwerpen kan de methode ook gebruikt worden om varianten van één beslissing te evalueren voor hun effect op de belangen van de stakeholders.

Het invullen van deze matrix blijkt binnen een team ook een goede manier te zijn om aan elkaar te vertellen hoe je erover denkt en wat voor ieder de essenties zijn. De discussie kan aanleiding zijn om concerns en/of architecturale beslissingen toe te voegen, samen te voegen, generieker of preciezer te maken, etc. Het kan even duren voordat er een evenwichtig beeld ontstaat. Het invullen blijkt ook een goede manier te zijn om gefocust te blijven op de belangen van de doelgroep en niet teveel de techniek in te duiken. Het kan heel motiverend zijn om ineens veel duidelijker te zien hoe je je doelgroep(en) bedient.

Voorbeelden

Ik wil afsluiten met twee voorbeelden.

Het eerste voorbeeld komt uit een enterprise-architectuur studie (relatie van bedrijfsfuncties naar informatiesystemen). Het gaat om een project dat tot doel had het samenvoegen van financiële rapportagefuncties uit een dertigtal systemen bij een Nederlandse internationale bank (alles gebeurt daar Engelstalig) en het creëren van een gezamenlijk datawarehouse. Zie tabel 2 voor een stukje van de matrix. De totale matrix omvat 5 architectuurbeslissingen die gekruist worden met 9 concerns. Een klein beetje uitleg is misschien wel op zijn plaats.

Bovenin kolom 2 en volgende worden de voornaamste concerns genoemd van de stakeholders: de versnippering van de verwerking, de snelheid (traagheid) waarmee nieuwe producten geïntroduceerd kunnen worden, etc. Voor de leesbaarheid zijn enkele kolommen weggelaten. Boven de concerns worden de voornaamste stakeholders genoemd, die dit concern hebben: Chief Executive Officer (CEO), Chief Informations Officer (CIO) en Business Managers.

In de eerste kolom zijn de voornaamste beslissingen genoemd die het architectenteam voorstelt aan het management. Het is een beknopte samenvatting van 60 slides in PowerPoint.

Op die kruispunten in de tabel waar een architectuurbeslissing van belang lijkt voor een concern, worden deze beide naar elkaar ‘toe gepraat’. Het eerste concern wordt b.v. specifieker gemaakt dan  ‘hoe kan het simpeler?’ en de eerste beslissing hiervoor wordt uitgewerkt als ‘één systeem maakt het veel simpeler, maar het proces om zover te komen kan best complex zijn’.

Zoals u ziet zijn het zeer beknopte teksten (hoog abstractieniveau), in eerste instantie alleen bedoeld voor gebruik binnen het architectenteam zelf. Zij beantwoorden hiermee de vraag “wat willen wij en hoe vertaalt zich dat naar de belangrijkste stakeholders? Wat is onze  boodschap aan hen?”.

Tabel 2: Voorbeeld van een gedeelte van een ingevulde content-2-concerns table

Het tweede voorbeeld komt uit een college software-architectuur. De opdracht aan groepen studenten was om de software-architectuur te ontwerpen van een volledig digitale rechtbank. Zie tabel 3 voor een gedeelte van de matrix van een van de groepen. De totale matrix omvat 6 architectuurbeslissingen die gekruist worden met 11 concerns. Ik neem aan dat met de ervaring van het eerste voorbeeld dit stukje van de matrix zonder verdere uitleg te volgen is. Nogmaals het zijn korte zinnen, waar nog een wereld aan ideeën onder kan zitten. Het is de top van een informatieboom.

Tabel 3: Voorbeeld van een gedeelte van een ingevulde content-2-concerns table, genomen uit een studenten opdracht (ontwerpen software architectuur van een volledig digitale rechtbank)

Conclusie

Het opstellen van architectuur is een belangrijke manier om IT-projecten de juiste strategische sturing te geven. De IEEE Std 1471 geeft een globaal model voor het indelen van architectuurbeschrijvingen, waarin stakeholders (belanghebbenden) en hun concerns (zorgen of belangen) een belangrijke rol spelen. Door belangrijke architectuurbeslissingen in een zogenaamde ‘content-2-concerns table’ (matrix) te relateren aan de belangrijkste concerns van stakeholders kan het effect van deze beslissingen geëvalueerd worden en de communicatie van deze beslissingen voorbereid worden.

Referenties:

1.      IEEE, IEEE recommended practice for architecture description, IEEE Standard 1471, 2000

2.      Gert Florijn e.a., Softwarearchitectuur, Overzicht en Compendium, Ten Hagen en Stam, 2003, ISBN 9044007521

3.      Onderzoek “Communicatie van IT-Architectuur”, homepage http://www.cs.vu.nl/~henk

4.      Workshop “Ontwerpen van Stakeholdergerichte Viewpoints”, http://www.arc-it.nl/ontwerpen-viewpoints.html