Artikel

Inrichting van de Enterprise Architecture organisatie

In dit artikel gaan we in op de organisatie(structuur) van de Enterprise Architecture functie. Hoe de inrichting van de architectuurorganisatie eruit ziet is voor een groot deel afhankelijk van de bestaande organisatiestructuur, het AMM¹-niveau, het besturingsmodel, de organisatiecultuur en het gekozen gebied van gemeenschappelijkheid (scope van architectuur). Het bekende gezegde ‘there is no one best way to organize’, geldt ook hier. Toch kunnen er wel enkele algemene uitspraken worden gedaan en structuren² gepresenteerd voor de organisatie-inrichting.

Werken onder architectuur

Het inrichten van de Enterprise Architecture organisatie is niet het beginpunt van het ‘werken onder architectuur’. In dit artikel wordt er vanuit gegaan dat u de voorgaande fasen reeds bent doorlopen en dat u nu voor de opgave staat om het ‘werken onder architectuur’ daadwerkelijk van de grond te krijgen.

Vragen die op dit moment moeten worden beantwoord zijn:

  • Welke verantwoordelijkheden, functionarissen en rollenworden onderkend?
  • Hoe ziet de organisatiestructuur eruit (organogram)?
  • Hoe verloopt de onderlinge coördinatie?

Dit artikel poogt in hoofdlijnen een generiek antwoord te geven op deze vragen.

Het ‘werken onder architectuur’ komt niet zomaar van de grond. In veel organisaties worden wel architecturen ontwikkeld, maar de verankering ervan in de staande organisatie krijgt uiteindelijk geen beslag, waardoor het gehele architectuurgedachtengoed in het water valt. Het vaststellen van architectuurprocessen, verantwoordelijkheden, functionarissen, rollen en organisatiestructuur vormt een harde randvoorwaarde voor succes.

In de volgende paragrafen gaan we bij wijze van scopeafbakening allereerst in op de architectuurprocessen, alvorens we in de daaropvolgende paragrafen kijken naar de organisatorische inrichting van deze processen.

Wie is er verantwoordelijk voor de Enterprise Architecture?

Het topmanagement is ervoor verantwoordelijk dat er een architectuur wordt ontwikkeld en dat men onder architectuur gaat werken. De verantwoordelijkheid voor het ontwikkelen, beheren en gebruiken van de architectuur kan echter bij verschillende partijen worden belegd (gedelegeerd).

Er valt grofweg een onderscheid in twee hoofdverantwoordelijken te maken: de business en de ICT-organisatie. De business is verantwoordelijk voor de vraagzijde en de ICT-organisatie is veranwoordelijk voor de aanbodzijde. In figuur 1 is deze scheiding van verantwoordelijkheden grafisch geprojecteerd op het Enterprise Architecture Framework door middel van een stippellijn.

Figuur 1: EA-Framework met scheiding vraag- en aanbodzijde ICT

Dit betekent dat de business initieel leidend is in dit proces. De business is verantwoordelijk voor het ontwikkelen van de Business Architecture en stelt van daaruit eisen en wensen aan de informatievoorziening (informatiebehoeften). De ICT-organisatie is op haar beurt verantwoordelijk voor het optimaal vervullen van de informatiebehoeften.

In de praktijk blijkt dat de noodzaak van het werken onder architectuur vaak als eerste door de ICT-organisatie wordt gevoeld. De fout die men op dat moment vaak maakt is dat men niet tracht de business verantwoordelijk te maken om eerst een Business Architecture te ontwikkelen, maar dat men zelf start met eenzijdig een Information Architecture te ontwikkelen. Dit werkt niet; de Information Architecture is dan niet gebaseerd op een richtinggevende Business Architecture en het hele cyclische spel van werken onder architectuur zal niet van de grond komen.

Welke architectuurprocessen onderkennen we?

Uitgangspunt voor organisatie-inrichting vormen de bedrijfsprocessen en in dit geval in concreto de architectuurprocessen.

In figuur 2 worden de architectuurprocessen grafisch weergegeven. Naast de ‘primaire’ architectuurprocessen van het ontwerpen en implementeren van de architectuur, zijn er de ‘secundaire’ processen: ‘Inrichten en besturen van het architectuurproces (architectuurmanagement)’, ‘(ICT)Trendwatching’, ‘Modellenbeheer en gebruikerssupport’ en ‘Vakontwikkeling en opleiding’.

Figuur 2: De architectuurprocessen (ontleend aan Nolan Norton & Co)

Bij de organisatie-inrichting dienen al deze processen organisatorisch te worden ingebed. In de volgende paragrafen worden deze processen en de bijbehorende organisatiestructuur, functionarissen, rollen en coördinatie besproken.

De architectuurorganisatie

In figuur 3 wordt een voorbeeld gegeven van de ophanging en structuur van een architectuurorganisatie (organogram).

Figuur 3: Voorbeeld - ‘Architectuurorganisatie en de diverse architectenprofielen’

Architectuurmanager: niet onder CIO, maar onder COO

Er dient één verantwoordelijke voor de totale Enterprise Architecture te zijn. Deze functionaris kunnen we de Architectuurmanager noemen. Hij is verantwoordelijk voor de inrichting en besturing van het architectuurproces en is daarmee leidinggevende van de architectuurorganisatie.

Er valt veel over te discussiëren aan wie deze functionaris zou moeten rapporteren, maar de auteur heeft daar een uitgesproken visie op: De Architectuurmanager dient idealiter onder de Chief Operations Officer (COO) te vallen. Dit omdat, zoals we eerder hebben gesteld, de business de drijvende kracht achter Enterprise Architecture dient te zijn.

In de praktijk zien we dat de Architectuurmanager momenteel meestal onder de Chief Information Officer (CIO) valt, maar de auteur is van mening dat de functie van CIO van tijdelijke aard is; dit is namelijk een gekunstelde constructie uit de tijd dat ICT nog relatief los stond van de bedrijfsvoering. In de toekomst zal de functie van de CIO worden overgenomen door de COO, aangezien een separate verantwoordelijkheid voor ICT met de huidige proces- en ICT-integratie niet meer van deze tijd is. De COO zal naar verwachting integrale verantwoordelijkheid voor bedrijfsprocessen én ICT krijgen.

Enterprise Architect

Naast de Architectuurmanager is er tevens een Enterprise Architect als ‘masterarchitect’ die het overzicht heeft over de gehele organisatie en architectuur. Hij is inhoudelijk coördinator boven de ‘Domeinarchitecten’. De rollen van Architectuurmanager en Enterprise Architect kunnen mogelijk ook in één functionaris verenigd zijn.

Domeinarchitecten

De totale scope van architectuur wordt doorgaans verdeeld in een aantal domeinen. Domeinen zijn logisch samenhangende gebieden die doorgaans overeenkomen met (delen van) architectuurlagen of bedrijfsfuncties. De meest grove indeling die wel wordt gemaakt is die in ‘front office’, ‘mid office’en ‘ back office’. Een fijnere granulariteit is de indeling op basis van bedrijfsfuncties. Een voorbeeld hiervan is het domein ‘Inkoop’. Deze onderverdeling in domeinen wordt gemaakt omdat een bepaald domein specifieke domeinkennis vereist. Aan een domein worden één of meerdere domeinarchitecten gekoppeld. Het kan natuurlijk ook zo zijn dat één architect verantwoordelijk is voor meerdere domeinen.

Het centrale overleg: de Architecture Board Meeting

Periodiek dient er een centraal overleg op het hoogste niveau te zijn waarin alle architectuurzaken die op dit niveau spelen worden besproken en waarin belangrijke architectuurbesluiten worden genomen. Dit zou men de ‘Architecture Board Meeting’ kunnen noemen. De COO kan vaste zitting hebben en is in dat geval voorzitter, maar ook kan ervoor gekozen worden om de COO alleen periodiek of bij bepaalde onderwerpen te laten aanschuiven. In dat geval is het beter als de Architectuurmanager voorzitter is. De voorzitter wordt inhoudelijk terzijde gestaan door de Enterprise Architect. Afhankelijk van de specifieke situatie behoren de domeinarchitecten al dan niet tot de vaste leden van de Architecture Board.

Overige architectuurrollen

Omdat het in dit bestek te ver voert om de gehele architectuurorganisatie in detail te beschrijven, wordt hier volstaan met enkele andere noodzakelijke of veelvoorkomende architectuurrollen.

Trendwatcher

Trendwatching is een doorlopend proces. Veelal wordt dit uitgevoerd door de Strateeg of een speciaal daartoe aangestelde Trendwatcher. Nieuwe trends worden periodiek in de Architecture Board Meeting besproken op hun toepasbaarheid. Het gaat hier zowel om businesstrends, als om ICT-Trends. Business Trendwatchers en ICT-Trendwatchers zijn doorgaans verschillende personen/functionarissen. De Trendwatcher fungeert in dit overleg als inhoudelijk deskundige en adviseur.

Architectuurbeheerders

Inhoudelijk beheerders (modelbeheerders)
Alle architecturen dienen inhoudelijk te worden beheerd. Voor het bedrijfsbrede gegevensmodel (corporate objectmodel) kan dit bijvoorbeeld de Bedrijfsgegevensmodel-beheerder zijn. Zo heeft ieder ‘architectuurproduct’ een inhoudelijk beheerder.

Technisch beheerders (support)
De diverse architecturen dienen niet uitsluitend qua inhoud beheerd te worden, maar dienen tevens centraal opgeslagen en beschikbaar te worden gesteld. Hiervoor zijn diverse rollen denkbaar, maar vast staat dat er een centrale opslaglokatie (repository) dient te zijn, met een repositorybeheerder.

Projectarchitecten

  • De controlling architect (reviewt en houdt architectuuraudits op projecten)
  • De projectarchitect (ontwikkelt de projectarchitectuur op basis van zijn kennis van de totaalarchitectuur)

Vakarchitecten

  • Productarchitect
  • Procesarchitect
  • Organisatiearchitect
  • Gegevensarchitect
  • Functioneel architect
  • Technisch architect

Architectenpool

Daarnaast is er een ‘pool’ van vakarchitecten die voor specifieke onderdelen kunnen worden ingehuurd op basis van hun expertise. Ze kunnen door de domeinarchitecten worden ingehuurd voor het ontwikkelen/beheren van delen van de domeinarchitectuur of voor het geven van gebruikerssupport, opleiding en –advies. Daarnaast kunnen ze worden ingehuurd voor een adviserende of controlerende rol binnen programma’s en projecten. Een ‘pool’ is een oplossing om minder frequent gevraagde expertise toch in eigen huis te hebben. Doordat de pool organisatiebreed werkt, wordt voorkomen dat afzonderlijke bedrijfsonderdelen die onvoldoende werk voor gehele FTE’s hebben toch zelf onderbezetten mensen in dienst moeten nemen of externen moeten inhuren.

Docenten en trainers

Ten slotte dienen bestaande en nieuwe architecten te worden opgeleid en bijgeschoold. Ook dient de architectuurkennis te worden ontwikkeld en beheerd. Deze kennismanagementfunctie dient door de daartoe ingestelde architecten/opleiders te worden ingevuld.

Op hoofdlijnen vormt dit een mogelijke inrichting van de Enterprise Architecture organisatie. Het zij nogmaals gezegd dat een en ander in grotere organisaties complexer kan zijn en dat de organisatie-inrichting er in kleinere organisaties eenvoudiger uit kan zien dan hier voorgesteld.

Voetnoten

1Met behulp van het Architecture Maturity Model (AMM) kan de volwassenheid van een organisatie op het gebied van Enterprise Architecture worden bepaald. Het Architecture Maturity Model kent vijf niveaus van volwassenheid. In het kader van dit artikel wordt niet nader op het AMM-model ingegaan.
2De hier gepresenteerde concrete functies, rollen en organisatiestructuren betreffen een mogelijke wijze waarop men een en ander gestalte zou kunnen geven. Uiteraard zijn er nog andere wijzen waarop men dit kan doen, afhankelijk van de situatie en voorkeuren.
3Een rol is een pakket taken, bevoegdheden en verantwoordelijkheden. Eén functionaris kan meerdere rollen hebben.

Categorie:   
Auteur(s)
afbeelding van edgarjohannsmann
Edgar Johannsmann
Organisatieadviseur

De auteur, Edgar Johannsmann, heeft 20 jaar ervaring op het gebied van Enterprise Architecture. Zowel in de rol van Organisatieadviseur, als in de rol van (interim) Informatie- en Enterprise Architect, in allerlei sectoren en branches.

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.