Referentiearchitectuur als normenkader

Referentiearchitectuur als normenkader
Een IT-auditor zou een referentiearchitectuur als normenkader moeten gebruiken. Maar voor welk auditobject kan een referentiearchitectuur als normenkader dienen? En welke onderdelen in een referentiearchitectuur kunnen als norm worden gebruikt?
Hidde Andriessen en Joao Wong A Foe
De Nederlandse beroepsorganisatie van IT-auditors (NOREA) heeft IT-auditing in 2002 als volgt gedefinieerd: ‘IT-auditing is het beoordelen van één of meer kwaliteitsaspecten of beheersingsmaatregelen van één of meerdere onderdelen van de toegepaste dan wel toe te passen ICT.’ Tijdens een IT-audit controleert een auditor aan de hand van een vooraf opgesteld normenkader de mate waarin een object voldoet aan een in het normenkader vastgesteld kwaliteitsniveau. Een normenkader is een stelsel van normen aan hand waarvan een object getoetst wordt. Onder een norm wordt verstaan een richtlijn die objectief en eenduidig is gedefinieerd, relevant is voor het te toetsen object en is voorzien van een meetwijze. Kwaliteit wordt door de NOREA onderverdeeld in zeven kwaliteitsaspecten (onder andere effectiviteit, integriteit). Zo kan een norm ter toetsing van de integriteit van geautomatiseerd berichtenverkeer aangeven dat de versleuteling van alle berichtenverkeer gebaseerd moet zijn op geaccepteerde marktstandaarden.
Referentiearchitectuur
In Nederland zijn de afgelopen jaren verschillende referentiearchitecturen ontwikkeld die sturend en kaderstellend zijn voor de inrichting van de informatievoorziening van een organisatie. De Nederlandse overheid is met de NORA (figuur 1) een drijvende kracht geweest voor veel referentiearchitecturen. Waar de NORA de blauwdruk beschrijft voor de elektronische overheid als geheel, is er een hele NORA-familie ontstaan van referentiearchitecturen die invulling geven aan de elektronische overheid op specifieke onderdelen van de overheid, zoals GEMMA voor de gemeente en PETRA voor de provincies. Hieruit blijkt direct dat referentiearchitecturen variëren in hun scope. Naast de verschillende overheid gerelateerde referentiearchitecturen zijn er ook voorbeelden in de telecom-(eTom) en bankensector (BIAN).

Figuur 1. Bekende referentiearchitecturen
 
Er bestaat geen eenduidige definitie van een referentiearchitectuur. De meest basale definitie is ‘een enterprisearchitectuur die wordt gebruikt als referentie’. TOGAF ziet een referentiearchitectuur als een meer generieke architectuur dan de specifieke Enterprisearchitectuur van een bepaalde organisatie. De scope varieert van een generieke architectuur voor een bepaalde sector (‘industry architecture’), sectoronafhankelijk (‘common systems architecture’) of zelfs nog generieker (‘foundation architecture’). Zie PAUWE (2010) voor meer definities en een vergelijking.
Toegevoegde waarde
Wat is de toegevoegde waarde van een referentiearchitectuur als normenkader? IT-audits worden vaak ingezet om oordelen te geven over kwaliteitsaspecten zoals beheersbaarheid, juistheid, volledigheid, tijdigheid, continuïteit en exclusiviteit van ICT-systemen en de gegevensverwerking. Dit is vooral bij ICT-intensieve organisaties nodig, zodat bijvoorbeeld de accountant ten behoeve van de jaarrekeningcontrole op de informatie uit het geautomatiseerd systeem kan steunen, maar ook kan zien of persoonsgegevens binnen de regels van de wetgeving worden behandeld en gebruikt.
IT-auditors hebben ruime ervaring met dit type audits en de volwassenheid van de aan deze audits ten grondslag liggende normenkaders is hoog. Er is echter minder ervaring met normenkaders voor het beoordelen van ICT-systemen op de kwaliteitsaspecten effectiviteit en efficiency. Ons inziens kan een referentiearchitectuur als normenkader juist worden ingezet voor het beoordelen van deze kwaliteitsaspecten. Dit blijkt ook uit de definitie van effectiviteit en efficiency: architectuur is gericht op de vertaling van eisen en doelstellingen naar oplossingen en traceerbaar maken hoe deze oplossingen bijdragen aan de doelstellingen (effectiviteit); daarnaast beschrijft architectuur standaarden en best practices om problemen op een passende manier, met balans tussen waarde en kosten op te lossen (efficiency).
Eisen
Vanuit zijn sturende en kaderstellende rol is een referentiearchitectuur een kandidaat normenkader. Aan welke eisen moet een referentiearchitectuur voldoen om als normenkader te kunnen fungeren? In de literatuur is al het nodige geschreven over de relatie tussen architectuur en auditing. Hoewel er verschillende raakvlakken worden besproken, worden er geen eisen besproken waar een normenkader gebaseerd op een referentiearchitectuur aan moet voldoen. Wij zien twee aspecten die bepalen of een normenkader bruikbaar is: auditobject (het object van onderzoek) en de mate waarin referentiearchitectuur toetsbare normen bevat.
Auditobject
Een architectuurketen van referentiearchitectuur tot gerealiseerde informatievoorziening kent potentieel een lange keten (figuur 2) . Strikt genomen is een referentiearchitectuur een extern normenkader voor een organisatie. De koninklijke weg is dat de organisatie de referentiearchitectuur eerst vertaalt in een organisatiespecifieke enterprisearchitectuur. Afhankelijk van de grootte van de organisatie zijn er doorvertalingen nodig naar bepaalde segmenten/onderdelen van de organisatie (Segment Architecture voor bijvoorbeeld een businessunit) of een bepaalde capability/functie van de organisatie (capability architecture voor bijvoorbeeld financiën of klantcontractcentrum). Uiteindelijk zijn er projecten nodig die de gewenste veranderingen implementeren. Voor een project wordt dan een Architectural Contract (conform TOGAF) of een Project Start Architectuur (conform DYA) opgesteld.
Figuur 2. Scope referentiearchitectuur
 
In deze keten zijn theoretisch verschillende auditobjecten mogelijk. Een referentiearchitectuur is in principe een normenkader voor de Enterprisearchitectuur. De Enterprisearchitectuur is op zijn beurt het normenkader voor de segmentarchitectuur, et cetera. In de praktijk hebben lang niet alle organisaties zo’n keten geheel uitgewerkt. Dit betekent dat er een gat kan bestaan tussen het normenkader en het auditobject, bijvoorbeeld als een project getoetst moet worden ten opzichte van een referentiearchitectuur. Een auditor zal in zo’n geval een specifiek normenkader moeten opstellen afgeleid van de referentiearchitectuur. Een ander belangrijke toetsfactor is of het auditobject laat zien hoe het invulling geeft aan de referentiearchitectuur. Hiervoor moet een duidelijk spoor te vinden zijn aan welke onderdelen van de referentiearchitectuur invulling gegeven wordt. Nog belangrijker zijn de eventuele afwijkingen ten opzichte van de referentiearchitectuur. Hierbij geldt de regel ‘comply or explain’. Dit is een regel waar de auditor ook zonder normenkader een oordeel over kan geven.
Potentiële normen
Omdat we een auditobject hebben dat we tegen een referentiearchitectuur willen toetsen, moet de referentiearchitectuur normen bevatten waar het object aan getoetst kan worden. Kijkend naar de IEEE-definitie van architectuur, bestaat uit een architectuur uit modellen en principes: ‘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.’
We zullen kijken in hoeverre modellen en principes als normen te gebruiken zijn. Vooraf is belangrijk om vast te stellen dat referentiearchitecturen niet altijd als norm worden gepositioneerd, maar bijvoorbeeld als best practices. Een best practice is in tegenstelling tot een norm vrijblijvend. Vanuit het perspectief van de auditor kan dan alleen gezegd worden dat het zonder goede argumentatie onverstandig is om best practices te negeren.
Architectuurprincipes
Volgens TOGAF zijn principes algemene regels en richtlijnen, die invulling geven aan de manier waarop een organisatie zijn missie vervult. Het gaat hierbij volgens TOGAF om duurzame regels en richtlijnen die zelden gewijzigd worden. Greefhorst en Proper hebben uitgebreid onderzoek gedaan naar architectuurprincipes. Een goed principe voldoet volgens Greefhorst aan de SMART-criteria (specifiek, meetbaar, aanvaardbaar, realistisch en tijdsgebonden). Dit sluit aan bij de eisen vanuit NOREA dat een norm objectief, eenduidig en relevant moet zijn. Om aan deze eisen te voldoen beschrijft TOGAF dat een principe beschreven moet worden in een vast formaat: een statement (het principe zelf), een rationale (de onderbouwing) en een implicatie (randvoorwaarden en gevolgen van toepassing van het principe). Het is de implicatie die de uiteindelijke toetsbare norm vormt (zie de voorbeelden aan het eind van dit artikel). De vuistregel is dan ook dat als je voor een principe geen implicatie kunt beschrijven het principe niet relevant is en je het kunt weglaten. De implicatie wordt vaak pas in een later stadium van het architectuurontwerp beschreven. Het zegt over het algemeen iets over de volwassenheid van een architectuur. In de praktijk zien we dan ook dat de statement en de rationale beschreven zijn, maar de implicatie vaak ontbreekt of nog niet volledig is. Naarmate de volwassenheid toeneemt en er een meetbare implicatie is, worden de principes beter toetsbaar, zie de voorbeelden over NORA 3.0 en CORA 3.0.
Architectuurmodellen
IEEE definieert een model als de abstractie van de essentie van een systeem in componenten en relaties. TOGAF voegt toe dat een model een beschrijving van een systeem gemaakt voor een bepaald doel is. Modellen kunnen worden onderscheiden in twee categorieën: modellen die de huidige organisatie en ICT beschrijven en modellen die inzicht geven in een gewenste toekomstsituatie. Een referentiearchitectuur bestaat uit het tweede type model. Deze modellen beschrijven een toekomstige situatie en zijn het resultaat van impliciete en expliciete keuzes gemaakt om tot dit scenario te komen.
Een (referentie-) model kan voldoen als normenkader als de keuzes die in het model zijn gemaakt expliciet zijn. Voor het expliciet maken van deze keuzes kan de structuur van principes gebruik worden: de keuze (statement), de reden achter de keuze (rationale) en de gevolgen van de keuze (implicatie). Het model is toetsbaar mits de implicatie net als bij principes voldoende SMART is uitgewerkt. Indien de keuze niet expliciet is gemaakt in de referentiearchitecuur, moet de IT auditor de vertaalslag naar een normenkader maken.
Er is een grote variatie in de modellen van de bekende referentiearchitecturen, van modellen van een hoog abstractieniveau (bijvoorbeeld NORA-basisarchitectuur, het CORA-procesmodel) tot zeer gedetailleerde modellen (bijvoorbeeld het NORA-dossier informatiebeveiliging, het GEMMA-procesontwerp). Modellen die de gewenste toekomstige situatie gedetailleerd schetsen zijn geschikt voor gebruik als norm mits de keuzes expliciet worden weergegeven en de implicatie SMART is gemaakt. Een keerzijde van gedetailleerde modellen in een referentiearchitectuur is de onderhoudbaarheid. Vanwege de benodigde inzet voor het specificeren en onderhouden van deze modellen is het een uitdaging voor de architect om deze modellen tijdig van updates voorzien. Zo lopen de GEMMA detailprocesmodellen een versie achter op de GEMMA-architectuur. In 2011 werd aangekondigd dat de detailmodellen van een update versie 2 worden voorzien. Deze zijn op het moment van schrijven nog niet beschikbaar.
Conclusie
Een referentiearchitectuur kan als normenkader worden gebruikt mits aan een aantal voorwaarden wordt voldaan. Ten eerste moet het auditobject relevant zijn ten opzichte van de referentiearchitectuur. Het meest relevante auditobject voor een referentiearchitectuur is een enterprisearchitectuur. Voor elk ander auditobject moet de auditor vaststellen of de referentiearchitectuur concreet genoeg is voor het auditobject of dat er eerst nog een vertaalslag nodig is. Voor de informatievoorziening zelf is een referentiearchitectuur over het algemeen niet zonder vertaalslag als normenkader toepasbaar. De tweede voorwaarde is dat de referentiearchitectuur normen moet bevatten. Zowel architectuurprincipes als architectuurmodellen kunnen dienen als norm. Een architectuurprincipe moet hiervoor uitgewerkt zijn met een meetbare implicatie. De door TOGAF voorgeschreven structuur van een principe geeft hiervoor een goed handvat. Architectuurmodellen kunnen beschrijvende en richtinggevende elementen bevatten. Om te dienen als norm moet een model richtinggevend zijn. De in het model gemaakte keuzes moeten expliciet worden beschreven. Kijkend naar de bekende referentiearchitecturen kunnen we stellen dat principes in de recente meer volwassen referentiearchitecturen over het algemeen goed als norm te gebruiken zijn. Op het gebied van modellen zien we dat deze referentiearchitecturen wel richtinggevende modellen bevatten, maar dat de bijbehorende keuzes vaak nog onvoldoende expliciet beschreven worden. Voor deze modellen moet de auditor zelf nog een grote vertaalslag maken om tot geschikte normen te komen.
 
KADER
Voorbeeld 1: Principes in NORA 3.0
NORA 3.0 bestaat uit tien basisprincipes (strategisch) en veertig daarvan afgeleide principes (tactisch). Volgens NORA 3.0 zijn de basisprincipes vooral richtinggevend, zij bieden ruimte voor interpretatie en zijn als zodanig niet toetsbaar. De veertig afgeleide principes geven een concretere invulling aan de basisprincipes: ‘Zij zijn te beschouwen als een checklist van kwaliteitskenmerken. Voor elke dienst vertaalt de dienstverlener deze kwaliteitskenmerken (in de vorm van ontwerpprincipes) naar kwaliteitsnormen (in de vorm van ontwerpbeslissingen).’ Afgeleide principes in de NORA kennen een zeer gestructureerde uitwerking op basis van een statement, rationale en implicatie, waarbij de rationale een toelichting, een voorbeeld en relatie met andere principes weergeeft.
Om te kijken in hoeverre deze afgeleide principes toetsbaar zijn nemen we afgeleid principe 1 als voorbeeld: ‘Diensten zijn herbruikbaar’. Dit principe heeft de volgende uitgewerkte implicatie. De dienst:
• Is zó beschreven dat de resultaten en voorwaarden
ook in een andere context begrepen kunnen worden; Maakt maximaal gebruik gemaakt van (open) standaarden om zo min mogelijk drempels op te werpen voor gebruik;
• Kent een minimum aan gebruiksvoorwaarden;
• Is aangemeld bij een landelijk serviceregister.
Kijkend naar de toetsbaarheid van deze implicatie kan gesteld worden dat het eerste punt lastig objectief vast te stellen is. Het is niet evident wanneer je spreekt over een andere context en wat begrip dan precies inhoud. Het tweede punt is beter toetsbaar omdat je vast kunt stellen of er gebruik gemaakt wordt van een standaard. Maximaal gebruik kan geïnterpreteerd worden als: er was voor deze dienst geen additionele standaard mogelijk. De volledigheid hiervan is lastig vast te stellen. Het derde punt is ook toetsbaar, want zolang geen van de gebruiksvoorwaarden weg te laten is kan men spreken over een minimum. Het vierde en laatste punt is gemakkelijk vast te stellen, want als de dienst is aangemeld bij het landelijk serviceregister, dan moet hij daar ook terug te vinden zijn. Ervan uitgaande dat deze vier punten de volledigheid van implicatie van dit principe weergeven, kan gesteld worden dat met een kanttekening bij het eerste punt dit principe toetsbaar is.
 
Voorbeeld 2: Principes in CORA 3.0
CORA 3.0 bestaat uit zeven principes. Elk principe is uitgewerkt in een beschrijving, een redenering, een toelichting en een toetsing. CORA beschrijft dat het een stuurinstrument is en dat bestuurders de CORA kunnen gebruiken om opgestelde plannen voor veranderingen te toetsen aan de principes en modellen van de CORA. Daarnaast beschrijft de CORA dat de CORA gebruikt kan worden om projectresultaten te toetsen.
Om te kijken in hoeverre deze principes toetsbaar zijn nemen we principe 1: ‘De doelstellingen van de woningcorporatie en de inrichting van de bedrijfsvoering bepalen de inrichting van de informatievoor-ziening en de inzet van IT.’ Dit principe heeft de volgende uitgewerkte toetsing: ‘Dit blijkt uit afspraken over de wijze van besturing van veranderingen binnen woningcorporaties of is traceerbaar in de woningcorporatiearchitectuur. Wordt bijvoorbeeld gewerkt met planvorming op basis van op CORA gebaseerde uitgangspunten?’
Kijkend naar de toetsbaarheid van deze ‘toetsing’ komen een paar vragen naar voren. Hoe stel je vast dat iets ‘blijkt uit afspraken over de wijze van besturing’? Er wordt een voorbeeld gegeven om dit te illustreren. Dit voorbeeld zelf is toetsbaar, maar daarmee is het principe nog niet eenduidig vast te stellen. Het is wel toetsbaar te maken door de norm verder uit te werken. Dit is een slag die de auditor dan zou kunnen maken in voorbereiding van de audit.
Het tweede deel van de toetsing spreekt van traceerbaarheid in de woningcorporatiearchitectuur. Dit is wel direct toetsbaar. Hierbij kan verwacht worden dat de woningcorporatiearchitectuur expliciet maakt hoe bepaalde inrichtingskeuzes bijdragen aan de doelstellingen van de woningcorporatie en de inrichting van de bedrijfsvoering. Of die bijdrage ook reëel is, is op het niveau van een woningcorporatiearchitectuur waarschijnlijk veel moeilijker vast te stellen. Hier zullen detailplannen en detailontwerpen verdere invulling aan moeten geven. En deze plannen en ontwerpen zullen dan ook getoetst moeten worden.
 
Voorbeeld 3: Modellen in GEMMA
GEMMA is een uitwerking van de NORA tot een sectorspecifieke architectuur voor Nederlandse gemeenten. Het is bedoeld als basis voor de inrichting van gemeenten en richtinggevend voor het realiseren van een elektronische overheid op gemeenteniveau. De GEMMA-specificatie bestaat uit de procesarchitectuur, de informatiearchitectuur en vier nadere catalogi/specificatie onderdelen.
De procesarchitectuur bestaat uit richtinggevende principes en modellen die beschrijven hoe de processen van gemeenten eruit horen te zien. Het procesmodel start met de onderverdeling van een gemeente in drie categorieën: sturende, primaire en ondersteunde processen. Per categorie worden de (bedrijfs-) processen benoemd en beschreven. Enkele processen zijn gedetailleerd uitgewerkt in werkprocessen en processtappen. Figuur 3 laat vier processtappen van het werkproces ‘Intake’ zien.

Figuur 3. Vier processtappen van het GEMMA-werkproces ‘Intake’

Voor de gemeenten zijn de bedrijfsprocessen zonder een grote vertaalslag te realiseren. GEMMA beschrijft immers de inrichting van deze processen tot detailniveau. Op de doelstellingen van GEMMA in het algemeen na wordt het beoogde effect van een op deze wijze geïmplementeerd bedrijfsproces niet gedetailleerd weergegeven in GEMMA. De keuzes zijn niet expliciet aangegeven en de implicatie is daardoor niet
SMART opgesteld. Dit maakt het voor een IT-auditor lastig om processen in de architectuur van GEMMA als normenkader te gebruiken voor processen van een gemeente. Ter voorbereiding van een normenkader biedt de procesarchitectuur toegevoegde waarde aan de IT-auditor door inzicht te geven in de inrichting van de gemeente.
 
Voorbeeld 4: Modellen in NORA 3.0
NORA 3.0 is gespecificeerd in twee katernen en vier dossiers. De modellen van de NORA 3.0 katernen zijn van een hoog abstractieniveau. Het model van de basisarchitectuur van een organisatie geeft schematisch weer hoe een overheidsorganisatie kan worden ingericht. Er wordt onderscheid gemaakt in contactfuncties, bedrijfsprocessen en gegevens. De organisatie zal in zijn architectuur dus rekening moeten houden met dit onderscheid en het kan alleen een verbijzondering geven of een onderbouwde afwijking. Dit model kan gebruikt worden door overheidsorganisaties, maar biedt ruimte voor interpretatie. De keuzes voor de indeling zijn niet expliciet gemaakt, en de implicatie van het model is niet
SMART beschreven. Hierdoor is het model als zodanig niet toetsbaar. De auditor zal (samen met de organisatie) moeten bepalen of de inrichting op basis van dit model een doel moet zijn voor de organisatie en hoe de implicatie van dit model meetbaar gemaakt kan worden.
 
Figuur 4. Basisarchitectuur overheidsorganisatie
 
Hidde Andriessen MSc EMITA en ir. Joao Wong A Foe zijn adviseur bij KPMG IT Advisory N.V. op het gebied van enterprisearchitectuur. Zij schreven dit artikel op persoonlijke titel.
E-mail: andriessen.hidde@kpmg.nl en wongafoe.joao@kpmg.nl
 
Literatuur
Bouwen aan een eigen begrippenkader Referentiearchitectuur, M. Pauwe, XR-Magazine, 15 april 2010
NOREA geschrift nr. 1: IT-auditing aangeduid, 1998.
NOREA studierapport 3: Raamwerk voor ontwikkeling normenstelsels en standaarden, 2002.
TOGAF versie 9.1, The Open Group, december 2011. Architecture Principles, The Cornerstones Of Enterprise Architecture,
D. Greefhorst, E. Proper, mei 2011.
IEEE Std 1471:2000, Recommended Practice for Architectural Description of Software intensive Systems.
DYA® Stap voor stap naar professionele enterprise-architectuur, M. van den Berg, M. van Steenbergen, 2004.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag