Artikel

Reviewen en auditen van architectuur

Het goed documenteren en beoordelen van een architectuur blijkt vaak een lastige kwestie. Dit geldt zowel voor een enterprise architectuur als voor een PSA of solution architectuur. Aan welke eisen dient bijvoorbeeld een architectuurdocument te voldoen zodat de opdrachtgever de informatievoorziening krijgt waar om gevraagd is? Welke architectuurdocumenten dienen er überhaupt aanwezig te zijn? En is de opgestelde architectuur wel de juiste architectuur? Hoe stel je dit vast in een review of audit? Dit artikel beschrijft mijn ervaringen op dit gebied en hoe architectuurraamwerken en –methoden, in het bijzonder de “Kruchten 4+1 View”-methode en ATAM, hierbij als hulpmiddel ingezet kunnen worden.

Als leadarchitect binnen een groot project besteed ik een deel van mijn tijd aan het reviewen en beoordelen van architectuurdocumenten en -audits van collega’s en externe partijen. Dat is best een leerzame exercitie omdat ik zo in aanraking kom met een grote diversiteit van opvattingen over de opzet en inhoud van architectuurdocumenten en de uitwerking en resultaten ervan.

Dit artikel beschrijft welke architectuurdocumenten doorgaans aanwezig zouden moeten zijn binnen een organisatie.Vervolgens wordt ingegaan op de eisen waaraan een architectuurdocument zou moeten voldoen om de kwaliteit van de architectuur te verhogen en daarmee beter de review of audit te doorstaan. Vervolgens komt het testen en reviewen van software-architectuurdocumenten nader aan de orde, waarbij de “Kruchten 4+1 View”-methode [1] en het uitvoeren van architectuuranalyses als uitgangspunt wordt genomen. Ten slotte wordt een voorstel gedaan om de kwaliteit van de inhoud van een software-architectuurdocument te verbeteren en tevens de bruikbaarheid van het document te vergroten.

Architectuurdocumenten en hun samenhang

Aan de hand van het aanwezig of afwezig zijn van bepaalde architectuurdocumenten krijg je als auditor een eerste indruk van de volwassenheid van een organisatie op architectuurgebied. In mijn werk gebruik ik de figuur “Architectuurdocumenten per niveau” (figuur 1) als leidraad om een globaal overzicht te krijgen van de architectuurdocumenten die ik verwacht terug te vinden in een organisatie. De figuur toont de samenhang tussen de architectuurdocumenten op strategisch, tactisch en operationeel niveau. Afgezien van enkele variaties, blijkt de afbeelding toepasbaar in veel organisaties die onder architectuur werken. De afbeelding blijkt daardoor goed bruikbaar voor een audit op de architectuurcompliance en deels op architectuurgovernance (zie het kader Soorten audits).

Figuur 1: Architectuurdocumenten per niveau

Figuur 1 laat zien dat architectuur begint op strategisch niveau, met een enterprise architectuur. Deze heeft als doel een eerste indeling te maken in diensten, producten, bedrijfsprocessen, applicaties en onderliggende technische infrastructuur. De enterprise architectuur komt voort uit het beleid, bedrijfsdoelstellingen en/of een informatieplan. Een enterprise architectuur stelt een organisatie in staat beter in te spelen op veranderingen waarbij ICT een rol speelt en is net als het informatieplan een strategisch sturingsinstrument. Een enterprise architectuur in combinatie met een roadmap voor ICT-voorzieningen resulteert op tactisch niveau in een ICT-projectportfolio. Het kan voorkomen dat de enterprise architectuur is opgesplitst in specifieke domeinarchitecturen, maar dat doet niet af aan het feit dat het producten zijn op strategisch niveau.

Bij aanvang van een ICT-project wordt in een project start architectuur beschreven welke principes uit de enterprise architectuur worden geconcretiseerd in het project en hoe deze geconcretiseerd worden in een softwaresysteem. Vervolgens wordt tijdens de realisatie van het project, een visie document plus een software-architectuurdocument (SAD) gemaakt. Deze heeft als functie de ontwerpbeslissingen en de daarbij horende kwaliteitseisen en risico’s van het softwaresysteem te beschrijven en fungeert naast het functioneel en technisch ontwerp als noodzakelijke hulp bij de bouw, het beheer en onderhoud van het softwaresysteem.

Soorten audits

Er worden doorgaans drie verschillende soorten audits onderkend [2][3]:

 

  • Audit naar de kwaliteit van het proces en beheer van de architectuur: de architectuurgovernance. Een audit over de governance betreft het functioneren van de verschillende architectuurprocessen binnen de organisatie. De omvang en het resultaat van deze audit soort blijkt sterk afhankelijk van de volwassenheid van de architectuurfunctie binnen een organisatie.
  • Audit naar de kwaliteit van werken onder architectuur: de architectuur compliance. Een compliance audit heeft als doel vast te stellen in hoeverre een organisatie werkt onder architectuur.
  • Audit naar de kwaliteit van de architectuur. Met een audit van de architectuurkwaliteit wordt doorgaans onderzocht in hoeverre de vastgestelde architectuur daadwerkelijk is geïmplementeerd in de infrastructuur, het applicatielandschap, de informatiestromen en in de relatie tot producten, diensten, processen en de organisatie.

Deze soorten zijn, elk op hun specifieke vlak, van toegevoegde waarde bij het bepalen van de beheersbaarheid en controleerbaarheid van architectuur als beheersmaatregel.

Documenteren is het halve werk

Het op een goede wijze documenteren van een architectuur staat of valt mijns inziens onder andere met:

  1. Het vermogen problemen en oplossingen te kunnen abstraheren tot concepten en principes en deze helder te kunnen formuleren;
  2. Kennis en gebruik van architectuurmethoden, –raamwerken en -patterns;
  3. Een duidelijke samenhang tussen de diverse architectuurdocumenten, gedragen door het architectenteam.

Het vermogen problemen en oplossingen te kunnen abstraheren tot concepten en principes is belangrijk voor de begripsvorming, voor het toetsen en reviewen van de architectuurontwerpen en ten aanzien van audits naar de kwaliteit van de architectuur. Communiceren over oplossingen in termen van concepten blijkt doorgaans gemakkelijker te verlopen dan wanneer het gaat om specifieke producten of componenten. Mijn ervaring is dat men het sneller met elkaar eens is als het gaat over conceptkeuzen. Waarschijnlijk haalt het een stuk emotie uit de discussies. Het gaat bij deze discussies immers niet zo snel over bijvoorbeeld de keuze voor Java of .Net; technologieën waar mensen wellicht positieve of negatieve ervaringen mee hebben. Helder formuleren en communiceren houdt ook in de juiste keuze in de drager van de informatie. Dragers zijn niet alleen tekstdocumenten, maar ook visualisaties in de vorm van posters en praatplaten of ander beeldmateriaal zoals video’s.

Kennis en gebruik van architectuurmethoden en –raamwerken vergemakkelijken het documenteren van de architectuur. Het helpt in het conceptualiseren van oplossingen en geeft houvast aan de opzet en inhoud van architectuurdocumenten. Indien de methoden en raamwerken afkomstig zijn van open standaarden, zoals TOGAF, DYA, RUP, “Kruchten 4+1 View”-methode of Dragon1, weet de lezer (collega-architect, auditor) wat hij kan verwachten van het document en op welke aspecten het beoordeeld dient te worden. Let wel, gebruik van een methode alleen geeft nog geen garantie of de ontworpen architectuur ook de juiste is voor een bepaalde situatie. Gebruik van methoden verhogen echter wel de kwaliteit van de architectuur.

Een duidelijke samenhang tussen de architectuurdocumenten is van belang voor het vaststellen van de scope per architectuurdocument voor zowel het architectenteam als voor de opdrachtgevers en projectteams. Dit voorkomt vragen zoals “Hoort het beschrijven van artefact X thuis in een software-/ solution-architectuurdocument of in een project start architectuurdocument?” Of “Wat moet er beschreven worden in de PSA en wat in de domeinarchitectuur of in een referentie architectuur?”. “Schrijven we op dit project een software-architectuur, een applicatie-architectuur, een systeemarchitectuur of zijn het allemaal synoniemen voor hetzelfde architectuurdocument?”. De mate van samenhang is naar mijn mening een indicatie voor de kwaliteit van het architectuurproces en –beheer. Zonder samenhang doet een architectuurteam maar wat (Jan Boerenfluitjes aanpak). Dit resulteert vaak in onduidelijke architectuurdocumenten, zoals dikke PSA-boekwerken waarin de solution architectuur wordt beschreven of een aanpak die per project(leider) verschilt, in losse eilandjes van systeemontwikkeling, in ICT-projecten die langs elkaar lopen en binnen hun IT-systeem verschillende oplossingen bedenken voor eenzelfde integraal probleem. Deze problematiek speelt met name rond thema’s als autorisatie, authenticatie en berichtenuitwisseling.

Referentiekaders en normen voor architectuurdocumenten

Een organisatie doet er goed aan om voor zichzelf het doel van werken onder architectuur te bepalen en normen vast te stellen (of te adopteren) waaraan de architectuurdocumenten moeten voldoen. Dit dient niet alleen overgelaten te worden aan de architectuurteams. Welk doel streeft een organisatie na met het werken onder architectuur? Bij welke domeinen, afdelingen of onderdelen van de organisatie wordt onder architectuur gewerkt en bij welke niet?

Het vaststellen van doelen en normen voorkomt tevens dat een organisatie zich volledig afhankelijk maakt van het architectuurteam. Ook hier geldt immers “de business in the lead”. De doelen en normen op organisatieniveau kunnen anders zijn dan de doelen en normen binnen het architectuurteam, in het bijzonder als het architectuurteam wordt bemenst door externen. Ook vergemakkelijkt het vaststellen van normen het review- of auditproces. Bij een audit wordt immers de aanwezige architectuur getoetst tegen normen wat resulteert in een auditrapport. Afhankelijk van de auditopdracht zijn dit normen en doelen van de organisatie zelf of van externe partijen (of de facto normen). Wanneer de doelen en normen helder en bekend zijn bij beide partijen zijn de verwachtingen tussen beide partijen beter op elkaar afgestemd. Een prettig gevolg hiervan is dat de verrassingen bij een audit minder groot zullen zijn.

Testen, reviewen en auditen van softwarearchitectuur

Voor het beschrijven van de softwarearchitectuur bij de organisatie waar ik momenteel werkzaam ben wordt de “Kruchten 4+1 View”-methode gebruikt. Deze methode beschrijft de architectuur van de structuur en constructie van de software zoals deze gebouwd is (IST architectuur). Wat echter niet beschreven wordt, zijn de ontwerpbeslissingen en de daarbij horende gekwantificeerde kwaliteitseisen, ofwel de niet-functionele eisen en risico’s van het softwaresysteem die geleid hebben tot het uiteindelijke resultaat. Dat is erg jammer omdat in de beheerfase en bij aanpassingen aan de software vaak wordt afgevraagd “Waarom hebben ze destijds gekozen voor oplossing X of tool Y? Daar hebben we nu last van.” Alleen de mensen die destijds betrokken waren bij de bouw weten het antwoord omdat het in hun hoofden zit - maar het staat niet op papier!

Men kan dan ook niet meer vaststellen of een beslissing destijds doordacht was. De softwarearchitectuur opgesteld aan de hand van de “Kruchten 4+1 View”-methode fungeert hierdoor eigenlijk alleen als hulp tijdens de bouw en implementatie en niet zozeer als naslagwerk tijdens het beheer en onderhoud van het softwaresysteem. Dat is mijns inziens een tekortkoming omdat een softwaresysteem haar meeste levenstijd doorbrengt in de beheerfase. Wat ontbreekt is een architectuuranalyse. Met een architectuuranalyse toets je de kwaliteit van de architectuur op functionele, kwalitatieve en constructieve tekortkomingen.

“Kruchten 4+1 View”-methode

Het Kruchten 4+1 View-model geeft een standaardmethode om de softwarearchitectuur te beschrijven. Figuur 2 toont schematisch de methode. Hierbij wordt de architectuur aan de hand van use cases plus vier perspectieven beschreven:

 

  1. Het logisch perspectief beschrijft de objectstructuur en interacties daartussen;
  2. Het procesperspectief beschrijft de geautomatiseerde processen;
  3. Het ontwikkelperspectief beschrijft de applicatiestructuren, bestanden en packagestructuur van de software;
  4. Het fysieke perspectief beschrijft de installatie en uitrolstrategie.

De vier views worden beschreven aan de hand van de use cases die ten grondslag liggen aan de software. De notatietaal die doorgaans gebruikt wordt in de beschrijving is UML.

Figuur 2: “Kruchten 4+1 View”-methode

Architectuuranalyse

Al gedurende het architectuurproces dient de kwaliteit van de architectuur vastgesteld te worden om bij de opdrachtgever, ontwerpers en bouwers het vertrouwen te kweken dat de voorgestelde architectuur bijvoorbeeld past bij de gevraagde informatievoorziening. Vaststellen van het kwaliteitsniveau kan volgens Gorton [4] op twee manieren. De eerste manier is om zelf als architect je werk te toetsen aan de hand van architectuurscenario’s. Dit is verder beschreven in het kader ‘Architectuurscenario’s’. De tweede manier om je architectuur te toetsen is door de architectuurconcepten te toetsen aan de hand van een eenvoudige archetype van de gewenste oplossing of software: de proof of concept.

Architectuurscenario’s

Met architectuurscenario’s toets je de architectuur of het ontwerpvoorstel aan de bedrijfsdoelen en kwaliteitsdoelen. Het resultaat van de toets is een set aan risico’s, zwakke schakels en features die als wisselgeld (extra features) kunnen fungeren. Als leidraad voor het evalueren van (software)architecturen kan je gebruikmaken van de architectuurmethode Architecture Trade-off Analysis Method (ATAM) [5].

Beide manieren geven voldoende handvatten om de kwaliteit van de architectuur te verhogen en geven daarmee de opdrachtgever meer vertrouwen dat de architectuur en de daaruit voortkomende oplossing positief bijdraagt aan de gevraagde opdracht. Tevens kunnen de scenario’s dienen als extra hulpmiddel bij aanpassingen tijdens de beheerfase van het softwaresysteem, omdat de ontwerpbeslissingen die hebben geleid tot het huidige softwaresysteem in de vorm van architectuuranalyses zijn vastgelegd. Hiermee wordt de kwaliteit van de architectuur verhoogd.

Conclusie

Aan het begin van dit artikel is de vraag gesteld wat je ten aanzien van testen, reviewen en auditen mag verwachten op basis van de huidige architectuurraamwerken en –methoden. Het artikel focust daarbij voornamelijk op de kwaliteit van de architectuur bij het testen, reviewen en auditen van de softwarearchitectuur beschreven aan de hand van “Kruchten 4+1 View”-methode. Deze methode blijkt door haar opzet eigenlijk vooral nuttig tijdens de bouw- en implementatiefase en minder nuttig tijdens de beheer- en onderhoudsfase. Dit komt doordat de “Kruchten 4+1 View”-methode niet een perspectief biedt om ontwerpbeslissingen en de daarbij horende gekwantificeerde kwaliteitseisen (niet-functionele eisen) en risico’s van het softwaresysteem die geleid hebben tot het uiteindelijke resultaat te documenteren.

Een software-architectuurbeschrijving die bruikbaar is over de gehele lifecycle van het systeem zou de volgende aspecten moeten bevatten:

1      Project context
2      Architectuurbehoeften (requirements)
2.1   Overzicht belangrijkste doelen
2.2   Architecturale behoeften van de belanghebbenden
2.3   Beperkingen (constraints)
2.4   Niet-functionele eisen (kwaliteitskarakteristieken)
3      Oplossing
3.1   Relevante architectuur- en softwarepatterns
3.2   Oplossing in logisch perspectief, ontwikkelperspectief, fysiek perspectief, procesperspectief
     Architectuuranalyse
4.1   Scenario-analyse en risico’s
4.2   Proof of Concepts

In het algemeen maken hoofdstuk 1, 2 en 3 deel uit van de “Kruchten 4+1 View”-methode, waarbij de diepgang per hoofdstuk kan verschillen afhankelijk van onder andere de projectgrote of –complexiteit, de complexiteit van het systeem en de auteur. De uitbreiding zit in hoofdstuk 4: Architectuuranalyse. Met een scenario-analyse wordt de kwaliteit van de architectuur op tekortkomingen getoetst van functionele, kwalitatieve en constructieve aard. De architectuuranalyse kan gedaan worden met architectuurscenario’s en de proof of concept. Als leidraad voor het evalueren van architecturen kan bijvoorbeeld gebruik gemaakt worden van de methode Architecture Trade-off Analysis Method (ATAM).

De “Kruchten 4+1 View”-methode resulteert in softwarebeschrijvingen die niet compleet genoeg zijn voor de gehele lifecycle van een softwaresysteem. Indien er een review of audit gedaan wordt op de kwaliteit van de architectuur kan alleen een uitspraak gedaan worden over de huidige stand van de software en de architectuur hiervan en nauwelijks op toekomstbestendigheid van de software in het geval dat de architectuur moet worden aangepast. Dit laatste wordt veroorzaakt door het ontbreken van de ontwerpbeslissingen die geleid hebben tot de huidige stand van de software.

Een review of audit op de architectuurgovernance betreft het functioneren van de architectuurprocessen. De aanwezigheid of afwezigheid van architectuurdocumenten is hierbij belangrijker dan de inhoud van de architectuurdocumenten, ofschoon het doen van architectuuranalyses op een hogere mate van volwassenheid kan duiden. Mits het uitvoeren van scenario’s en proof of concepts tot en met de evaluatie ervan in de processen is ingevoerd.

Categorie:   
Auteur(s)
afbeelding van harmverschuren
Harm Verschuren
Energie Data Services Nederland (EDSN) - informatiearchitect

Ik ben een ervaren informatiearchitect met bedrijfservaring binnen de branches energie (centrale marktfacilitering), overheid & retail. Lange ervaring in ICT breed met als speerpunten informatie-, proces-, data architectuur en applicatie-integratie (EAI, SOA, EDA).

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.