Waak voor te hoog abstractieniveau

Referentiearchitecturen zijn belangrijk voor bedrijven, zij bieden houvast. Toch blijven veel mogelijkheden onbenut. Het veelal hoge abstractieniveau is spelbreker. Als het lukt om referentiearchitecturen minder abstract en herkenbaar te maken, kunnen zij meer bijdragen aan de beoogde doelen. Met minder inhoud kunnen zij van meer waarde zijn.

Referentiearchitecturen

Vanaf het verschijnen van de Nederlandse Overheids Referentie Architectuur (NORA) in 2006 groeit het aantal referentiearchitecturen gestaag. Lokale overheden zoals provincies en gemeenten, maar eigenlijk alle zichzelf respecterende (semi)publieke sectoren hebben inmiddels een eigen referentiearchitectuur, soms zelfs meerdere. Ook nu nog wordt hard gewerkt aan nieuwe (versies van) referentiearchitecturen. Kortom, bijna tien jaar referentiearchitecturen. Wat zien we daarvan terug in de praktijk? Wat werkt en wat niet?

Referentiearchitecturen bieden houvast

Om met het goede nieuws te beginnen: referentiearchitecturen voegen in de praktijk daadwerkelijk iets toe. Zeker in relatief nieuwe sectoren en/of sectoren waar het gestructureerd omgaan met informatievoorziening nog niet altijd prioriteit heeft gehad, bieden referentiearchitecturen houvast. Bijvoorbeeld in discussies over gedeelde doelstellingen zoals samenwerking of digitalisering, maar ook bij vergelijkingen: waar staan we ten opzichte van collega-organisaties of ten opzichte van waar de sector heen wil? Referentiearchitecturen zoals GEMMA, VERA en CORA – voor respectievelijk gemeentes, veiligheidsregio’s en woningbouwcorporaties – dienen als het woordenboek waarmee verschillende organisaties elkaar beter begrijpen. Ze leggen het gemeenschappelijke jargon vast en schetsen, hoog over, wat zoal de voorkomende principes, processen, producten, diensten of applicatiefuncties zijn – typisch onderdelen waaruit een referentiearchitectuur meestal bestaat.

Diezelfde lijsten van processen of functies blijken ook heel nuttig als checklist. Voor het in kaart brengen van de voor informatieplanning relevante trends en ontwikkelingen, voor het krijgen van overzicht over het applicatielandschap: het is handig om gestructureerd de lijsten langs te lopen en zo geen gebieden te vergeten. Referentiearchitecturen beschrijven overigens vaak ook de samenhang tussen de verschillende processen of functies; handige indelingen die kunnen helpen bij het opstellen van een eigen architectuur.

Op meer strategisch niveau dragen referentiearchitecturen bij aan het onder de aandacht brengen van belangrijke ontwikkelingen. Mede door GEMMA staat zaakgericht werken bijvoorbeeld bij vrijwel alle gemeentes op de agenda. En omdat het gegevensperspectief vast onderdeel is van bijna alle referentiearchitecturen, groeit op veel plaatsen het besef van de mogelijkheden van – en overigens vaak ook de wettelijke verplichtingen tot – het gebruik van basisregistraties of eigen kernregistraties.

Te abstract

De ambitie van veel referentiearchitecturen gaat echter vaak veel verder: makkelijker samenwerken, informatie uitwisselen en software aanschaffen zijn een paar veelvoorkomende doelen. Los van de vraag of dat überhaupt realistische doelstellingen zijn voor een referentiearchitectuur en of daar niet pragmatischer hulpmiddelen voor denkbaar zijn, helpen veel architecturen daar nu nog bepaald niet bij. Een belangrijke oorzaak daarvoor is dat referentiearchitecturen vaak nauwelijks herkenbaar blijken voor de ‘business’. Regelmatig zijn het primaire proces en de daaromheen georganiseerde afdelingen lastig te herkennen.

Een GGD kenschetsen met generieke bedrijfsfuncties als ‘behandeling patiënt’ (PURA, referentiearchitectuur voor de publieke gezondheidszorg) gaat voorbij aan wat een GGD is: een verzameling van specialismen, zoals jeugdzorg, SOA-voorlichting en behandeling en tuberculosebestrijding. En dat spoedeisende contacten van burgers met de meldkamer onder dezelfde functie ‘contacten’ vallen als langlopende overleggen over convenanten tussen overheden, zal ook niet voor iedere bestuurder van een veiligheidsregio even vanzelfsprekend zijn. Wat herkenbaarheid verder tegenwerkt is dat de visualisaties niet de daadwerkelijke verhoudingen weergeven. In de PURA is het crisismanagementproces ‘beheersing risico’s en grote uitbraak’ – waar ook bij een grote GGD hoogstens enkele medewerkers zich mee bezighouden – nauwelijks kleiner weergegeven dan de ‘gezondheidsbevordering/bescherming en behandeling’, waarbinnen honderden medewerkers werkzaam kunnen zijn.

Hoge abstractieniveau

Een andere oorzaak is dat het veelal hoge abstractieniveau van referentiearchitecturen niet altijd voldoende recht doet aan de specifieke uitdagingen in de dagelijkse praktijk. Specialistische onderdelen van bijvoorbeeld veiligheidsregio’s of GGD’s hebben te maken met andere doelgroepen, hebben een andere omvang en dynamiek, kennen andere ketenpartners en gebruiken eigen informatievoorzieningen. Veel organisaties lopen dan ook al snel vast als ze proberen hun applicatielandschap te ‘plotten’ op functiemodellen uit een referentiearchitectuur: één applicatie dekt meerdere functies of één functie wordt door meer applicaties afgedekt. Zeker met gebruik van off-the-shelf-pakketten is dit vaak het geval. Dat is niet vanzelfsprekend een teken van een slecht gestructureerd applicatielandschap, maar eerder een teken van een onterechte abstractie in de referentiearchitectuur. De generieke applicatiefuncties uit referentiearchitecturen suggereren dat generieke software mogelijk en wenselijk is, terwijl het maar zeer de vraag is of dat altijd terecht en realistisch is. Zeker is in ieder geval dat een te hoge of verkeerde abstractie niet helpt bij het bereiken van doelstellingen als informatie uitwisselen of software aanschaffen.

Pragmatische doorontwikkeling

Referentiearchitecturen worden bruikbaarder als het lukt de eigenheid van een domein vast te leggen en niet te verzanden in te generieke concepten. GEMMA onderkent bijvoorbeeld specifieke functies zoals ‘belastingen’ of ‘burgerzaken’ – zaken die bij iedere gemeente direct te herkennen zijn in bijvoorbeeld organisatiestructuur en applicatielandschap. Dat helpt bij het in kaart brengen van het eigen applicatielandschap; zozeer zelfs dat het proces geautomatiseerd ondersteund kan worden met de GEMMA-softwarecatalogus. Concreet zijn waar dat moet, dus. Concreet zijn waar het kán, is een ander pragmatisch verbeterpunt. Alle GGD’s moeten actieve tuberculosegevallen registreren in OSIRIS van het RIVM, álle veiligheidsregio’s gebruiken LCMS bij rampen en crises.

Tips

Waarom dat soort dingen niet vastleggen in de betreffende referentiearchitectuur? Als het lukt om referentiearchitecturen naast minder abstract ook herkenbaarder te maken, kunnen ze meer bijdragen aan de beoogde doelen. Daarvoor zou wat meer pragmatiek geen kwaad kunnen:

• Sla metamodellen en architectuurtheorie over. Niet zelden beginnen referentiearchitecturen met dikke verhandelingen over de gebruikte metamodellen, de relatie met overkoepelende architecturen, met een visie op architectuur: wat moet de gemiddelde lezer daarmee?
• Werk díe onderdelen uit die specifiek zijn voor een domein. Tientallen pagina’s gaan nu op aan het uitdiepen van functies of informatieobjecten voor algemene onderwerpen als klantcontact, besturing en bedrijfsvoering.
• Blijf weg van algemene architectuurwaarheden en principes waar je het niet mee oneens kunt zijn, zoals ‘gebruik standaarden en richtlijnen’ (zie ook ‘Principeverslaving verzwakt architectuur’)
• Gebruik perspectieven of ‘views’. Architectuur gaat minstens zoveel over communicatie als over inhoud, dus maak overzichtelijke, opzichzelfstaande platen voor specifieke doelgroepen. Zo’n opzet sluit beter aan bij de belevingswereld van een lezer dan één allesomvattend document.
• Wees realistisch over de maakbaarheid van organisaties en hun informatievoorziening. De invalshoek van een referentiearchitectuur is vaak niet de enige werkelijkheid waar onderdelen van organisaties mee te maken hebben: ketenverbanden en daarin gemaakte (referentiearchitectuur) afspraken zijn vaak net zo belangrijk of belangrijker dan de organisatie waar een afdeling soms min of meer toevallig onderdeel van uitmaakt.
• Besteed meer aandacht aan het ketenperspectief. Met wie wordt samengewerkt en informatie uitgewisseld? Welke afdelingen en/of functies spelen in welke ketens een rol? 
• Kijk uit met doel en middel. Referentiearchitecturen voeren doelen als samenwerking en informatie-uitwisseling op als bestaansrecht. Maar wil de business wel echt samenwerken en uitwisselen? En op welk vlak dan precies, met welke doelstellingen? En wat is dáár dan precies aan architectuur – of aan iets anders – voor nodig?

Minder is meer

Concreter, herkenbaarder: door referentiearchitecturen meer in te kaderen en toe te spitsen op specifieke doelgroepen, kunnen ze met minder inhoud van meer waarde zijn. Een wiki-vorm als die van de huidige NORA is wat dat betreft een goede stap en biedt mogelijkheden om daar in te stappen waar dat voor de lezer relevant is. Nu nog wat minder architectuur en wat meer business en pragmatisme, dan dragen referentiearchitecturen misschien meer bij aan ambitieuze doelen als samenwerken, informatie uitwisselen en software aanschaffen. 

Morgen aan de slag

Veel referentiearchitecturen hebben geen verplichtend karakter. Veel inhoud is bovendien voornamelijk richtinggevend van aard, niet kaderstellend. Dat neemt niet weg dat organisaties hun voordeel kunnen doen met een referentiearchitectuur. Drie zaken waar morgen mee aan de slag gegaan kan worden.

1. Landschap in kaart – hoewel niet alle referentiearchitecturen zich er dus goed voor lenen, kan het plotten van de in de organisatie gebruikte applicaties op bedrijfs- of applicatieve functies vaak snel een beeld geven van waar dubbele functionaliteiten worden geboden, of op welk gebied juist nog geen goede ondersteuning is.

2. Doe de principecheck – achter principes als ‘gegevens hebben één bron’ gaat een wereld schuil van reële risico’s als gevolg van inconsistente gegevens. Heeft iedereen in de veiligheidsregio de beschikking over dezelfde, recente informatie over wegopbrekingen? Inventariseren wat dergelijke principes écht voor de organisatie betekenen kan dus geen kwaad. Worden ze al toegepast, en zo nee, wat vraagt dat van de organisatie?

3. Visie, thema’s en ontwikkelingen – bevat de referentiearchitectuur zaken die onterecht niet op de radar van de organisatie staan? Zijn zaakgericht werken, het inrichten van kernregistraties of het aansluiten op basisregistraties ook hier van belang? Deze activiteiten kunnen helpen bij informatieplanning. Voor het daadwerkelijk oppakken is het verstandig aan te sluiten bij nieuwe projecten die zich binnen de informatievoorziening aandienen. Bestaande applicaties zijn bijvoorbeeld niet zomaar aan te passen op de gegevensstandaarden uit een referentiearchitectuur, bij een vervanging kan die keuze nog wel worden gemaakt.