8 november 2018

Mag ik u voorstellen? De (informatie) architect

image for Mag ik u voorstellen? De (informatie) architect image

 

Naarmate de hoeveelheid en diversiteit van informatie in (overheids)organisaties groeit, zijn wij DIV-ers en archivarissen steeds minder in staat om deze zelfstandig in goede, geordende en toegankelijke staat te brengen en te houden. Wie resultaten wil boeken, zal allianties moeten smeden met andere vakdisciplines, die ieder hun eigen wereldbeeld, ambities en belangen hebben. Samen sta je immers sterker. In dit artikel maken we kennis met zulke potentiële bondgenoten, de (informatie) architecten.

 

Naarmate de hoeveelheid en diversiteit van informatie in (overheids)organisaties groeit, zijn wij DIV-ers en archivarissen steeds minder in staat om deze zelfstandig in goede, geordende en toegankelijke staat te brengen en te houden. Wie resultaten wil boeken, zal allianties moeten smeden met andere vakdisciplines, die ieder hun eigen wereldbeeld, ambities en belangen hebben. Samen sta je immers sterker. In dit artikel maken we kennis met zulke potentiële bondgenoten, de (informatie) architecten.

In een toenemend aantal organisaties hebben zij een sterke invloed op hoe het informatie- en applicatielandschap zich ontwikkelt. Afhankelijk van hoe de architectuurfunctie in de organisatie is ingericht, richt hun werk zich zowel op de hoofdlijnen als op de kleinste details. Met andere woorden, zij zijn dé ontwerpers van de informatievoorziening van een organisatie en zijn dus dé partner voor archivering by design.

In alle smaken en soorten

Om te beginnen dekt de term ‘informatiearchitect’ niet de volledige lading. Zo staat in de titel van dit artikel ‘informatie’ niet voor niks tussen haakjes! Een informatiearchitect beschrijft (de samenhang van) applicaties en informatieobjecten die in een organisatie rondzwerven. Er zijn echter ook architecten die de organisatie zelf, haar processen en producten en diensten beschrijven. Zo zijn er naast deze architecten ook nog tal van andere soorten architecten. We spreken ook wel van een gelaagdheid in de architectuur.

Enterprise architecture

Figuur 1: De gelaagdheid van architectuur

 De onderste laag wordt gevormd door de technische architectuur die de hardware, operating systems, firewalls, et cetera beschrijft. Daar bovenop ligt de informatiearchitectuur. Zij is dus slechts een onderdeel van de hele architectuur! Binnen de informatiearchitectuur wordt vaak een onderscheid gemaakt tussen de applicatiearchitectuur en de data-architectuur. Bovenop de informatiearchitectuur ligt de business-architectuur, die de organisatiestructuur en processen beschrijft. Al deze lagen komen samen in de enterprise-architectuur, waarin de samenhang tussen deze deel-architecturen wordt bewaakt.

In de praktijk kom je naast deze lagen ook nog andere specialisaties tegen. Domein-architecten houden zich bezig met de business- en informatiearchitectuur binnen een bepaald taakgebied, bijvoorbeeld het sociale domein of de ruimtelijke ordening. Aspect-architecten houden zich bezig met een bepaald aspect van de informatievoorziening dat de hele organisatie doorkruist, maar niet de hele organisatie omvat. Denk bijvoorbeeld aan – jawel – informatie- en archiefbeheer, informatiebeveiliging of -dienstverlening. Tot slot zijn er ook nog project- of solution-architecten die binnen projecten tot op een zeker detail ontwerpen welke wijzigingen wenselijk zijn. Het kan daarbij gaan om wijzigingen op iedere architectuurlaag.

Wat doet een architect?

De kern van het architectuurwerk kan beschreven worden in termen van decompositie en compositie. Architecten bestuderen en beschrijven hoe grotere gehelen bestaan uit kleinere onderdelen, die op hun beurt ook weer verder opgeknipt kunnen worden. Zo bestaat de overheid uit meerdere overheidsorganisaties, die weer bestaan uit organisatieonderdelen, et cetera. Een ICT-landschap bestaat uit o.a. applicaties, die meerdere functionaliteiten ondersteunen, die weer bestaan uit een reeks aan functies, et cetera. Door het toevoegen, vervangen of veranderen van de juiste onderdelen gaat – mits de samenhang goed is bewaakt – het grotere geheel beter functioneren. Althans, dat is het streven van een architect.

Waarvoor is architectuur nodig?

Om goed te begrijpen wat architecten doen en waarom, helpt enig inzicht in de ontstaansgeschiedenis van het vak. Architectuur – het soort waarover dit artikel gaat – komt voort uit het ICT-vakgebied. In de begindagen was ICT slechts een hobby of interesse van – veelal – mannen die ook graag met oude radio’s en andere elektronica knutselden. Deze pioniers experimenteerden niet alleen thuis, maar ook op het werk. Na enige tijd kreeg het management van hun organisaties in de gaten dat de mogelijkheden van technologie wel eindeloos leken! De beperkingen waar zij tegenaan liepen, lagen niet in de technologie zelf, maar in de beschikbare kennis, tijd en (financiële) middelen. Het management moest slimme keuzes gaan maken! Hiervoor had zij onder andere het volgende nodig:

  • overzicht en inzicht in de huidige situatie (IST-situatie);
  • duidelijkheid in wat men wil gaan bereiken (doelen);
  • overzicht en inzicht in wat daarvoor nodig is (SOLLsituatie);
  • overzicht en inzicht in wat dus moet veranderen (impact- c.q. gap-analyse);
  • afbakening1 en planning van de veranderingen (roadmap).

 

Architecten hanteren beproefde methoden om deze informatie op een uniforme en overdraagbare wijze te beschrijven en te analyseren, waarover hieronder meer.

Werken volgens standaarden

Iedere architect heeft uiteraard zijn of haar persoonlijke stijl, maar ook in dit vakgebied gelden er diverse normen en standaarden die breed geaccepteerd en toegepast worden.
Binnen de overheid zijn een aantal van die standaarden en normen ontwikkeld en/of gebundeld in zogeheten referentiearchitecturen. Een referentiearchitectuur omvat op alle architectuurlagen standaarden, normen en best practices die de beoogde doelgroep mag en kan toepassen in de eigen organisatie. Zo hoeft niet iedere organisatie zelf het wiel uit te vinden en spreken we dezelfde taal.
Op het niveau van de gehele overheid bestaat hiervoor de NORA2. Voor diverse overheidslagen is deze verder uitgewerkt en nader gespecificeerd. Zo is er de GEMMA voor gemeenten, PETRA voor provincies, WILMA voor waterschappen, et cetera3.

De referentiearchitecturen sluiten uiteraard ook aan op internationale standaarden. In dit artikel onderscheid ik twee soorten standaarden:

  • Standaarden over het beschrijven van de architectuur.
    Denk daarbij aan de welbekende architectuurplaten met blokken, iconen, lijnen en pijlen.
  • Standaarden over het beheer van de architectuur.
    Denk daarbij aan processen rondom de besluitvorming en het doorvoeren van wijzigingen.

 Het beschrijven van de architectuur gebeurt aan de hand van een modeltaal. Een veelgebruikt voorbeeld hiervan is Archimate4. Dit is ook de standaard modeltaal5 die gebruikt wordt in de referentiearchitecturen. Archimate beschrijft per architectuurlaag6 welke elementen er voor kunnen komen en hoe zij aan elkaar gerelateerd kunnen zijn. Voorbeelden van elementen zijn7: business actor, business process, application component, data object en device.

Figuur 2: Een voorbeeld in Archimate

Figuur 2: Een voorbeeld in Archimate

 Mogelijke relaties zijn: serving, realization, assignment en aggregation. Voor iedere elementsoort definieert Archimate een icoon. Voor iedere relatie-soort definieert zij een pijl of lijn. De architect tekent in deze beeldtaal architectuurplaten op het juiste detailniveau, die de samenhang tonen tussen de afzonderlijke elementen op de business, informatie en/of technische architectuurlaag.

Het reikt voor het doel van dit artikel te ver om de verschillende elementen en relaties in detail te bespreken. Wie meer wil weten over de elementen en relaties raad ik aan om samen met een architect uit je eigen organisatie naar een van zijn of haar praatplaten te kijken. Door Archimate te leren aan de hand van praktijkvoorbeelden gaat deze standaard sneller voor je leven. En zo heb je gelijk een goed excuus om elkaar beter te leren kennen!

Een welbekend en veel toegepast voorbeeld van een standaard over het architectuurbeheer8 is TOGAF9. Centraal hierin staat de Architecture Development Method (ADM), een cyclisch proces waarin achtereenvolgens ambities worden gevormd, doel-architecturen worden opgesteld, een roadmap wordt opgesteld en uitgevoerd, waarna de feitelijk gerealiseerde architectuur weer wordt vastgesteld en er een nieuwe ambitie kan worden gevormd. Bij iedere stap in het ADM-proces is gedefinieerd wie waarvoor verantwoordelijk is en wordt er bewaakt of iedereen zich aan de afspraken houdt. Het proces wordt eenmaal (of, wanneer nodig, opnieuw) afgetrapt in een inleidende fase (preliminary fase) waarin de taken en verantwoordelijkheden worden afgesproken en de architectuurprincipes worden vastgesteld; de basiseisen waaraan de architectuur moet voldoen.

Figuur 3: De ‘Architecture Development Method (ADM)’ van TOGAF. (Bron: Wikipedia)

Figuur 3: De ‘Architecture Development Method (ADM)’ van TOGAF. (Bron: Wikipedia)

 Het zal de lezer niet verbazen dat deze werkzaamheden in de praktijk zelden netjes achter elkaar verlopen. Architecturen worden al opgesteld terwijl er nog geen duidelijke visie is, projecten lopen al voordat de architectuur gereed is, roadmaps worden voortdurend aangepast en halverwege de implementatie veranderen de plannen. De architect moet – net als iedere andere (informatie)professional – voortdurend laveren tussen hoe het hoort en hoe het is.

Hoe kan de architect je helpen?

Architecten ontwerpen oplossingen. Wanneer er in de inleidende fase afspraken zijn gemaakt in het kader van informatie- en archiefbeheer, dan kan hij/zij hier rekening mee houden bij het ontwerpen van oplossingen voor anderen.
Wanneer de architectuur conform TOGAF wordt aangestuurd, dan wordt regelmatig getoetst of deeloplossingen en het grote geheel ook daadwerkelijk aan de gemaakte afspraken voldoen. Zo wordt er mede invulling gegeven aan het kwaliteitsmanagement.
Ook kun je zelf nog oplossingen nodig hebben. Is de duurzame toegankelijkheid van informatie nog niet voldoende geborgd? Is de informatievoorziening nog niet voldoende AVG-proof? Of wil je juist werken aan een transparantere overheid en meer informatie openbaar toegankelijk maken? Ieder hedendaags vraagstuk vraagt om een totaaloplossing met maatregelen op zowel technisch als organisatorisch vlak. Een architect kan helpen om inzicht en overzicht te krijgen in hoe het geheel nu in elkaar steekt en wat er moet veranderen om het gewenste resultaat te bereiken.
Hij of zij kan tot op het gewenste detailniveau praatplaten opstellen, die het gesprek over de gewenste verandering kunnen ondersteunen en begeleiden. Een architect zal voor het management andere praatplaten opstellen dan voor de ICT-er, die weer een andere plaat nodig heeft dan de procesanalist.
Zo krijgt iedere vakspecialist de informatie die hij of zij nodig heeft, waarbij de architect op de achtergrond de samenhang bewaakt.

Hoe kan jij de architect helpen?

Wie geholpen wil worden, zal ook zelf bereid moeten zijn om een steentje bij te dragen. Door actief deel te nemen aan het architectuur-proces verwerf je niet alleen inspraak, maar verrijk je ook de architectuur en draag je dus bij aan het succes ervan.
Zo zou je kunnen helpen door in de inleidende fase mee te denken over de architectuurprincipes. Een principe zou bijvoorbeeld kunnen zijn dat in alle applicaties het informatie- en archiefbeheer geregeld moet zijn. De implicaties hiervan zullen uiteraard nader uitgewerkt moeten worden zoals in TOGAF staat beschreven. Hiermee help je de architecten ervoor te waken dat de oplossingen die zij ontwerpen aan wet- en regelgeving voldoen: archivering by design!
Je zou daarnaast in de eerste fase van het ADM-proces kunnen meedenken over de visie en ambitie. Er kan bijvoorbeeld afgesproken worden om stappen te zetten in open data. Door vervolgens ook bij te dragen in het bewaken van de architectuurprincipes en ambities gedurende het hele architectuurproces, neem je ook verantwoordelijkheid voor de uitvoering en realisatie van de architectuur.
Je kunt dus meedenken en meepraten, maar vergeet vooral niet om ook mee te DOEN. Op de roadmap staan diverse wijzigingen die gerealiseerd en geïmplementeerd moeten worden. Dat gaat niet vanzelf. Door deel te nemen aan projecten of zelf projecten te trekken laat je zien dat je niet alleen kunt lullen, maar ook kunt poetsen. Wie betrokken wil worden bij het architectuurproces zal vaak moeten beginnen met het opstropen van de mouwen.

En, vergeet niet, er spelen ook andere belangen. Die zijn net zo belangrijk en verdienen net zo veel aandacht als het archiefbelang. Ga niet alleen voor je eigen belang staan, maar denk mee, praat mee en – bovenal – werk mee in het realiseren van de ambities van anderen. Neem medeverantwoordelijkheid voor hun ambities en prestaties en – wie weet – helpen ze jou ook bij jouw ambities en prestaties.

 

Marco Klerks Ten tijde van het schrijven van dit artikel was Marco Klerks werkzaam bij de gemeente ’s-Hertogenbosch als informatiearchitect. Inmiddels werkt hij bij de gemeente Rotterdam als recordmanager.


Noten

1 Een organisatie doet er goed aan om niet alle wijzigingen in één keer door te voeren, maar ze op te knippen in uitvoerbare ‘werkpakketten’. Rome is ook niet in één dag gebouwd.
2 https://www.noraonline.nl.
3 https://www.noraonline.nl/wiki/NORA_dochters.
4 http://www.opengroup.org/subjectareas/enterprise/archimate.
5 In de praktijk kun je ook andere modeltalen tegenkomen, zoals UML of BPMN. Deze worden niet in dit artikel behandeld.
6 Recent is de Archimate-standaard uitgebreid met elementen en relaties waarmee ook doelen, drijfveren, requirements, et cetera gemodelleerd kunnen worden. Hierdoor sluiten TOGAF en Archimate nog beter op elkaar aan.
7 Archimate is helaas (nog) niet vertaald naar het Nederlands. Omdat sommige termen zich niet goed laten vertalen zonder dat er mogelijk betekenis verloren gaat, kiest de auteur ervoor om de oorspronkelijke, Engelstalige termen uit de standaard te hanteren.
8 TOGAF omvat ook een model voor het beschrijven van de (enterprise-) architectuur, maar deze wordt weinig toegepast. Andere modellen, zoals Archimate, genieten vaak de voorkeur.
9 http://www.opengroup.org/subjectareas/enterprise/togaf.