Architectuur: een onsje meer of minder?
Het toepassen van Enterprise Architectuur als stuurmiddel kan het initiëren van een project versnellen, project risico’s verkleinen, de complexiteit van het project beheersbaar maken en de kans van slagen van het project verhogen. Met deze wetenschap zou je kunnen stellen dat organisaties altijd Enterprise Architectuur moeten gebruiken als stuurmiddel voor projecten. Maar wat doe je als je als organisatie niet beschikt over een onbeperkt aanbod aan architecten? En kan een project misschien ook niet af met een ‘onsje minder’ architectuur? Highberg heeft een model ontwikkeld dat helpt bij het bepalen van de hoeveelheid gewenste architectuurinzet bij een project.
In de besluitvorming om al dan niet projecten onder architectuur te brengen kun je grosso modo twee type besluiten onderscheiden, namelijk wel of niet ontwikkelen binnen de kaders van de Enterprise Architectuur en zo ja, hoeveel. Drie belangrijke redenen voor het niet toepassen van Enterprise Architectuur zijn tijdsdruk, een tijdelijke oplossing en een ontoereikende Enterprise Architectuur.
Tijdsdruk wordt gezien als een belangrijk criteria voor het niet toepassen van Enterprise Architectuur. Project initiatieven die bijvoorbeeld voortkomen uit de naleving van wet en regelgeving waar moeilijk op te anticiperen valt, zijn veelal onderhevig aan tijdsdruk. Daarnaast zijn er projecten die voorzien in oplossingen met een tijdelijke aard. Deze worden veelal niet binnen de kaders van de Enterprise Architectuur ontwikkeld. Een voorbeeld hiervan is het implementeren van een oplossing die tijdelijk informatie uitwisselt met keten-partners. Een derde criteria is de ontoereikendheid van de Enterprise Architectuur zelf. Deze biedt dan (nog) geen concrete kaderstelling voor het project. Gelukkig is het besluit om niet binnen de kaders van de Enterprise Architectuur te ontwikkelen een uitzondering op de regel, omdat je idealiter altijd binnen de kaders van de Enterprise Architectuur ontwikkeld. Ontwikkel je binnen deze kaders, dan wijs je middelen zoals de PSA en een controlerend architect toe om op basis van de principes en kaderstellingen te kunnen toetsen en daar waar nodig bij te sturen. In de meeste gevallen is dit een standaard set aan middelen, maar je kunt ook bepalen in welke mate je deze stuurmiddelen toepast.
Highberg ontwikkelde een besluitvormingsmodel voor het bepalen van de juiste mate van het toepassen van Enterprise Architectuur als stuurmiddel voor projecten met een IT component. Het besluitvormingsmodel helpt bij (de inrichting van) een effectieve en efficiënte werkwijze waarin het project ook in onvoorziene situaties, alsnog binnen de kaders van de Enterprise Architectuur ontwikkeld kan worden. Het toewijzen van de juiste middelen gebeurt op basis van de gewenste en/of benodigde mate van controle. In een impliciete risico- en impact analyse besteed je aandacht aan de vraag hoeveel middelen en technieken er nodig zijn om een specifieke oplossing in overeenstemming met de Enterprise Architectuur te implementeren. Deze analyse voer je idealiter uit parallel met het portfolio management proces uit. Zo is er voor aanvang van het project duidelijk hoeveel middelen er nodig zijn om het project binnen de kaders van de Enterprise Architectuur te ontwikkelen. Hierdoor kan de architectuur functie tevens anticiperen op het beschikbaar stellen van de benodigde resources. Deze impliciete risico- en impact analyse is geconcretiseerd in het volgende multi-criteria model:
Minor projecten: Projecten binnen de minor categorie worden gekenmerkt door een relatief lage hoeveelheid middelen en technieken met betrekking tot Enterprise Architectuur. Deze projecten worden gekenmerkt door kleine veranderingen die laag scoren op de criteria. Daarom worden deze projecten onderworpen aan een mindere mate van controle door de Enterprise Architectuur functie. De PSA is in deze categorie vervangen door een startnotitie, waarin een beperkt aantal afspraken worden gemaakt aan de hand van principes en kaderstellingen. In plaats van een controlerend architect, is de project manager verantwoordelijk voor de naleving van het project aan de Enterprise Architectuur. De projectmanager zal niet alleen rekening houden met de tijd en middelen, maar moet ook rekening houden met het ontwikkeling van het project binnen de kaders van de Enterprise Architectuur.
Medior projecten: Deze categorie is gelijk aan de gemiddelde wijze waarop de organisaties Enterprise Architectuur inzetten als stuurmiddel voor projecten. De mate waarin de PSA geschreven wordt is afhankelijk van de project specifieke kenmerken. Hiervoor wordt het normale PSA sjabloon gebruikt. De PSA bestaat uit afspraken die zijn gemaakt op basis van modellen, principes en kaderstellingen. De rol van de controlerend architect wordt toegekend aan een architect uit de organisatie die het project op de naleving van de Enterprise Architectuur controleert. De opgeleverde project resultaten worden getoetst aan de hand van principes en kaderstellingen door middel van een in mindere mate uitgevoerde controle. Daarnaast levert de architect de benodigde diensten aan het project en kan geraadpleegd worden voor een advies. De controlerende architect kan aan meerdere medior projecten tegelijk toegewezen worden.
Major projecten: Binnen deze categorie worden de middelen en technieken met betrekking tot Enterprise Architectuur toegepast in een meer rigoureuze mate. Projecten die hoog scoren op de diverse criteria zijn onderhevig aan een uitgebreide PSA. De uitgebreide PSA vereist een meer gedetailleerde beschrijving van de modellen, principes en kaderstellingen. De controlerend architect die aan dit soort projecten toegewezen is, is in hoge mate betrokken en voert op regelmatige basis controles op de naleving uit. De controlerende architect die aan dit soort projecten is toegewezen is vaak een architect die al meer ervaring heeft met het type oplossing. Waar de controlerend architect kan worden toegewezen aan meerdere medior projecten, wordt de controlerende architect van in deze situatie permanent toegewezen. Daarnaast worden er meer gedetailleerde diensten geleverd aan het project zoals getailleerde modellen en advies.
Bovenstaand model is geen spreadsheet die je even invult en er rolt een bezetting uit. Het geeft wel richting aan een gestructureerd denkproces waarin je bepaalt hoeveel architectuur je wilt gaan inzetten op een project. En dat is mooi, want soms kan het wel een onsje minder, en soms mag het ook wel een onsje meer zijn.
Gerelateerde artikelen
