De voor de uitoefening van de Enterprise architectuurfunctie benodigde processen

Inleiding 

In mijn blog van januari 2025 ben ik ingegaan op de besturing van de enterprise architectuurfunctie (EA-functie) [1]. In februari ging ik dieper in op het aspect ‘de EA-mensen’ en wel de mensen in én in relatie tot de EA-functie [2]. In maart heb ik een overzicht gegeven van de voor de enterprise architectuurfunctie benodigde middelen [3]. In deze blog ga ik nader in op de voor de uitoefening van de enterprise architectuurfunctie benodigde processen. Dit betreft één van de zeven aspecten die naar mijn mening nodig zijn om de enterprise architectuurfunctie (EA-functie) effectief te laten functioneren. Zie Figuur 1 en de toelichting onder ‘Aspecten van de EA-functie’. 

Aspecten van de EA-functie 

De EA-functie bestaat uit de volgende inhoud te geven en uit te voeren aspecten [5, 6, 7, 7] (zie Figuur 1): 

1) Een gedragen EA-visie waarin duidelijk is gemaakt waarom deze functie bestaat c.q. nodig is, en een concretisering van de te leveren bijdragen aan de organisatie en de wijze waarop. 

2) EA-processen bestaande uit de uit te voeren activiteiten om al hetgeen verwoord in de EA-visie te kunnen waarmaken. 

3) De EA-producten resulterende uit de EA-processen waarmee het waarmaken van de beloften uit EA-visie geconcretiseerd worden. 

4) De EA-mensen (enterprise architecten) die de EA-processen uitvoeren en de EA-producten gestalte geven. 

5) De EA-middelen bestaande uit de nodige budgetten en overige nodige hulpmiddelen als EA-tools e.d. 

6) De EA-besturing om alle EA-zaken in goede banen te leiden. Anders gezegd de PCA van de PDCA besturingscyclus [8]. 

7) De EA-methode die ten behoeve van alle onder de punt 1 tot en met 6 genoemde zaken richtinggevende kaders bevat. 

Processen van de EA-functie 

Zonder gedeelde en gedragen visie, een uitwerking naar processen en producten, de beschikking over mensen met de juiste competenties, de allocatie van de nodige financiële middelen, hulpmiddelen én besturing, kan de EA-functie geen gestalte krijgen. Net zoals bij een marketingfunctie, een financiële functie of andere functies zullen de processen van de EA-functie respectievelijk in beeld moeten worden gebracht, worden toegerust en worden uitgevoerd. Ik maak hierbij een onderscheid naar de besturende en de uitvoerende processen van de EA-functie. In mijn blog van januari 2025 ben ik ingegaan op de besturende processen van de EA-functie [1]. In deze blog ga ik in op de uitvoerende processen van deze functie. De D van de hier gebruikte PDCA-cyclus [8]. Zie Figuur 2. Deze processen zijn ontwikkeld binnen de kaders van het stuurinstrument GEA (General Enterprise Architecting).

Toelichting op de uitvoerende EA-processen 

Eerst ga ik in op Stap 1 tot en met Stap 6 uit . De stappen 1 en 2 zijn nodig voor organisaties die tot nu toe nog niets aan enterprise architectuur gedaan hebben. Stappen 4 t/m 6 zijn bedoeld om met de resultaten van stap 1 en 2 integrale oplossingscontouren te ontwikkelen voor bedrijfsvraagstukken en de hieruit ter realisatie voortvloeiende benodigde acties onder te brengen in het change management portfolio. Daarna zal ik een beknopte toelichting geven op de processen ‘Onderhouden en beheren GEA-framework’ en ‘Bewaken van de architectuurkaders’. 

Stap 1 Initiëren 

Het doel van de stap initiëren is om duidelijkheid te verkrijgen over het enterprise architectuurtraject (EA-traject) in termen van te verwachten resultaten, scope, personele bezetting, ieders betrokkenheid en de voor dit traject benodigde strategische documentatie van de organisatie. Tijdens deze stap vindt een oriëntatie op de situatie plaats, wordt de scope van de enterprise bepaald, de nodige functionarissen en hun rollen geïdentificeerd en de benodigde strategische documentatie beoordeeld op geschiktheid en bruikbaarheid. Na de uitvoering van deze activiteiten en een eenduidig inzicht in de te verwachten resultaten van het EA-traject kan worden aangevangen met Stap 2. 

Stap 2 Analyseren van de samenhang 

Het doel van stap 2 is het creëren van een eerste versie van het GEA-framework. Met behulp van dit framework wordt de samenhang van de organisatie expliciet gemaakt en gevalideerd. Na validatie wordt dit framework gebruikt om voor bedrijfsvraagstukken tot integrale oplossingscontouren te komen. Het betreft hier de samenhang tussen de meta-elementen op zingevingsniveau (missie, visie, kernwaarden, doelen en strategie), tussen de elementen op vormgevingsniveau (belangrijke bestuurlijke invalshoeken [in GEA perspectieven genoemd], kernbegrippen binnen perspectieven, richtinggevende uitspraken gekoppeld aan perspectieven, kernmodellen van perspectieven en relevante relaties tussen richtinggevende uitspraken van verschillende perspectieven), en tussen de elementen van zin- en vormgevingsniveau. 

Nadat de hiervoor benoemde elementen van het GEA-framework zijn afgeleid uit de strategische documentatie van de organisatie wordt de samenhang tussen deze elementen met een hiervoor ontwikkelde set matrices geanalyseerd. De bevindingen van deze analyses resulteren meestal in een zogenoemd ‘Samenhang Verbeterplan’ (SVP) met de nodige acties om geconstateerde omissies in de vigerende samenhang te herstellen c.q. andere ideeën ter verbetering van de samenhang uit te voeren. Als laatste activiteit in stap 2 worden het GEA-framework en het SVP gevalideerd. Het is van groot belang dat de juiste stakeholders goedkeuring geven aan de geëxpliciteerde samenhang. Dit is nodig om bij het ontwikkelen van oplossingscontouren voor bedrijfsvraagstukken, geen discussies meer te hebben over de juistheid en volledigheid van het richtinggevende GEA-framework. 

Na de uitvoering van stap 2 wordt het gevalideerde GEA-framework, inclusief de hierin aangepaste richtinggevende kaders van het SVP, gebruikt om integrale oplossingscontouren voor bedrijfsvraagstukken te ontwikkelen. Het ontwikkelen van een integrale oplossingscontour voor een bedrijfsvraagstuk start echter eerst met stap 3 waarin een grondige vraagstukanalyse wordt uitgevoerd. 

Stap 3: Analyseren vraagstuk 

Het doel van stap 3 is om een eenduidige omschrijving van het onderhavige vraagstuk te verkrijgen én een goed begrip van het vraagstuk bij de perspectiefeigenaren te borgen, waardoor die in staat zijn om tot een integrale oplossingscontour van het vraagstuk te komen. Daarnaast wordt vanuit enterprisearchitectuurperspectief beoordeeld of het richtinggevend kader (het GEA-framework) voor dit vraagstuk volstaat of dat aanpassing c.q. aanvulling nodig is. Ter verkrijging van een eenduidige omschrijving van het onderhavige vraagstuk wordt in een workshop met de eigenaren van het vraagstuk een inhoudelijke analyse uitgevoerd. De vraagstukeigenaar is degene die in de organisatie verantwoordelijk is voor het vraagstuk en het doorvoeren van de oplossing. Vaak is een vraagstukeigenaar ook een perspectiefeigenaar, maar dit hoeft niet zo te zijn. De uitgevoerde vraagstukanalyse resulteert in: 

• Een eenduidige omschrijving van het vraagstuk 
• Inzicht in het belang van het vraagstuk voor de organisatie 
• Inzicht in de mate van urgentie van het vraagstuk (hoe snel moet een oplossing beschikbaar zijn) 
• Een beschrijving van:
  • de aanleidingen/oorzaken van het vraagstuk 
  • de implicaties bij het oplossen en niet oplossen van het vraagstuk, voor zover op voorhand bekend 
  • de risico’s bij het oplossen en niet oplossen van het vraagstuk, voor zover op voorhand bekend. 

Aan de hand van de resultaten van deze vraagstukanalyse wordt getoetst of het GEA-framework voldoende compleet is om stap 4 ‘ontwikkelen integrale oplossingscontour’ te kunnen uitvoeren. Mogelijk is het op voorhand al duidelijk dat op bepaalde onderdelen principes of beleidsuitspraken ontbreken dan wel moeten worden aangepast. De enterprisearchitect brengt deze omissies in beeld en past na besluitvorming hierop het GEA-framework aan. Tevens brengt de enterprisearchitect aan de hand van de kernmodellen in beeld waar het vraagstuk naar verwachting ingrijpt en welke impact het heeft. Daarmee duidt hij/zij de richting van de oplossing en de mogelijke alternatieven. Dit is vooral bedoeld om het vraagstuk nog beter te begrijpen en te positioneren binnen de context van de organisatie. De enterprisearchitect en de vraagstukeigenaar bereiden tot slot een presentatie voor, waarmee in de volgende stap het vraagstuk wordt gepresenteerd aan alle perspectiefeigenaren. 

Stap 4: Ontwikkelen integrale oplossingscontour 

Het doel van stap 4 is het verkrijgen van een integrale oplossingscontour voor het onderhavige bedrijfsvraagstuk. Daarbij is het GEA-framework een belangrijk instrument, waarmee wordt gezorgd voor een integrale en holistische benadering voor het oplossen van het vraagstuk. Voor het ontwikkelen van de integrale oplossingscontour wordt co-creatie als samenwerkingsvorm gebruikt. De aanwezigheid van alle perspectiefeigenaren is hierbij essentieel. 

In de vorm van een eendaagse workshop met de vraagstukeigenaar en perspectiefeigenaren worden mogelijke veranderinitiatieven voor het vraagstuk geïnventariseerd. Voordat hieraan wordt begonnen presenteert de vraagstukeigenaar het vraagstuk, zoals dat in de vorige stap is geformuleerd. Daarna vindt de inventarisatie van veranderinitiatieven plaats, in twee stappen: 

• Geredeneerd vanuit het vraagstuk naar de perspectieven: hierin geeft elke perspectiefeigenaar aan met welke initiatieven hij vanuit zijn perspectief kan bijdragen aan de oplossing van het vraagstuk. Dit zijn initiatieven waarmee oorzaken worden weggenomen, risico’s worden weggenomen of gereduceerd dan wel een implicatie wordt ondervangen. De relatie tussen veranderinitiatief en oorzaak, risico of implicatie wordt vastgelegd, zodat de argumentatie over de bijdrage van het veranderinitiatief duidelijk is en niet verloren gaat. De analyse van het vraagstuk vormt hiervoor de leidraad. Indien een veranderinitiatief ook wordt ondersteund door een principe of beleidsuitspraak of bijdraagt aan een doelstelling, dan wordt ook dit vastgelegd. Hiermee is duidelijk dat het initiatief al dan niet in lijn is met het richtinggevend kader. 
• Geredeneerd vanuit de perspectieven naar het vraagstuk: hierin inventariseren de perspectiefeigenaren (aanvullende) veranderinitiatieven door de richtinggevende uitspraken (principes, beleidsuitspraken, doelstellingen) door te nemen in het licht van het vraagstuk. Vanuit de richtinggevende uitspraken worden kansen en innovatieve ideeën gevonden, die nog niet zijn onderkend in de eerste stap (analyse geredeneerd vanuit het vraagstuk). Dit maakt de inventarisatie van de veranderinitiatieven completer en veelzijdiger. De relatie tussen veranderinitiatief en richtinggevende uitspraak wordt vastgelegd. Van een vanuit de richtinggevende uitspraken geïnitieerd veranderinitiatief wordt, waar van toepassing, aangegeven of het een oorzaak wegneemt, een risico verkleint of een implicatie invult, zodat ook hier de argumentatie over de bijdrage van het veranderinitiatief duidelijk is en niet verloren gaat. 

Door deze benaderingswijze wordt voorkomen dat, bij het zoeken naar veranderinitiatieven, alleen vanuit het vraagstuk wordt geredeneerd. Door (ook) te redeneren vanuit het GEA-framework, wordt ervoor gezorgd dat de veranderinitiatieven passen in de richting die de enterprise op wil. Door alle perspectiefeigenaren te betrekken, wordt gezorgd voor een integrale benadering en daarmee een relatief hoog draagvlak. 

Het laatste onderdeel van de workshop is het prioriteren van de veranderinitiatieven. Per groep van perspectiefeigenaren (meestal wordt in de workshop gewerkt in groepen van drie of vier perspectiefeigenaren) worden de vijf belangrijkste veranderinitiatieven benoemd. Hierbij is het hoogst oplossend vermogen van de veranderinitiatieven in het licht van het betreffende vraagstuk bepalend. Voor zover dit in de voorgaande analyses nog niet (volledig) is gedaan, wordt elk veranderinitiatief gekoppeld aan één of meerdere doelstellingen (ten behoeve van het opstellen van het realisatieplan van de oplossingscontour in stap 5. In het geval dit niet in de eendaagse workshop past, voert de enterprise architect met een kernteam deze actie na afloop van de workshop uit. 

Het is van groot belang de workshop grondig voor te bereiden en te zorgen voor een begeleider en een notulist. Tijdens de workshop dient het GEA-framework voor alle deelnemers eenvoudig toegankelijk te zijn. De aanwezigheid van alle vraagstuk- en perspectiefeigenaren is cruciaal, het verdient aanbeveling de directie de uitnodiging voor de workshop te laten verzorgen. 

Aan de hand van de workshopresultaten worden de geïnventariseerde veranderinitiatieven geclusterd tot een integrale oplossingscontour. Dit kan worden gedaan door het kernteam of, indien opportuun, in een sessie met de perspectiefeigenaren. Een integrale oplossingscontour is meer dan een optelsom van veranderinitiatieven. Het gaat hier om betekenisvolle samenhang en het creëren van elkaar ondersteunende en versterkende veranderingen. Er kunnen tegenstrijdigheden met andere veranderinitiatieven zijn, er kan overlap zijn en veranderinitiatieven kunnen tegenstrijdig zijn met richtinggevende uitspraken van andere perspectieven. Dit wordt voor alle veranderinitiatieven onderzocht, te beginnen met de initiatieven met de hoogste prioriteit. Eventuele ‘geschillen’ worden in ieder geval voorgelegd aan de betreffende perspectiefeigenaren, die hierover een besluit nemen. Op basis hiervan wordt een integrale oplossingscontour beschreven en ter besluitvorming voorgelegd aan de eindverantwoordelijke bestuurders. Eisen die aan een integrale oplossingscontour worden gesteld zijn: 

• Alle perspectiefeigenaren hebben meegedaan in de ontwikkeling 
• Tegenstrijdigheden tussen veranderinitiatieven zijn inzichtelijk 
• Veranderinitiatieven zijn geclusterd en geprioriteerd 
• Tegenstrijdigheden van veranderinitiatieven met het GEA-framework zijn inzichtelijk 
• Geschikt voor besluitvorming 

Bij het samenstellen van de integrale oplossingscontour kan het voorkomen dat er aanpassingen worden gedaan aan het GEA-framework. In deze substap wordt het GEA-framework bijgewerkt, zodat het weer actueel is en voor een volgend vraagstuk kan worden gebruikt. Zowel op zingevings- als vormgevingsniveau kunnen aanpassingen voorkomen. Denk aan het aanpassen van de visie of strategie (zingeving), het toevoegen of aanpassen van perspectieven, kernbegrippen en richtinggevende uitspraken (vormgeving). De aanpassingen worden afgestemd met het topmanagement (zingeving) en de perspectiefeigenaren (vormgeving). 

Stap 5: Maken realisatieplan oplossingscontour 

Het doel van stap 5 is dat de integrale oplossingscontour wordt uitgewerkt in een realisatieplan, zodanig dat het mogelijk is de benodigde veranderingen op te nemen in het (verander)portfolio van de enterprise. Dit is nodig, omdat: 

• een veranderinitiatief niet (per definitie) een project hoeft te zijn (mogelijk zijn het meerdere projecten of wordt het gerealiseerd vanuit een epic backlog) 
• de integrale oplossingscontour niet (per definitie) een programma hoeft te zijn 
• veranderinitiatieven gefaseerd gerealiseerd kunnen worden, waarbij in elke fase functionaliteit wordt toegevoegd (het hoeft niet altijd in één keer af) 
• veranderinitiatieven afhankelijkheden kennen (de realisatie van een veranderinitiatief kan randvoorwaardelijk zijn voor een ander veranderinitiatief) 
• de voor de oplossing van het vraagstuk benodigde veranderingen mogelijk al in het portfolio zijn voorzien of met een kleine aanpassing geschikt te maken zijn 
• de voor de oplossingscontour benodigde capaciteit moet worden afgewogen ten opzichte van andere veranderingen die in het portfolio zijn opgenomen. 

Om de oplossingscontour te kunnen inpassen in het portfolio worden de dimensies tijd (wat moet wanneer en met welke kwaliteit c.q. volwassenheid klaar zijn) en capaciteit (wat is de benodigde inspanning) toegevoegd. Als eerste worden de veranderinitiatieven in de tijd uitgezet. De doelstellingen van de enterprise zijn hierin leidend. Het gaat erom dat het totaal van veranderinitiatieven in samenhang de bedrijfsdoelstellingen realiseert en dat daarop kan worden (bij)gestuurd. Gezien de strategische aard van enterprisevraagstukken gaan we daarbij uit van een tijdhorizon van 0 tot 5 jaar. 

Per veranderinitiatief wordt bekeken op welk moment de resultaten, gezien de doelstellingen, beschikbaar moet zijn. Daarbij worden verschillende ‘volwassenheidsniveaus’ voor een veranderinitiatief onderkend. We gaan hier uit van het ‘just in time’ en ‘just enough’ realiseren van veranderingen. Voor het bereiken van een doelstelling op korte termijn hoeft het veranderinitiatief mogelijk minder compleet uitgewerkt te zijn dan voor een doelstelling op langere termijn. De volwassenheidniveaus drukken we uit als ‘brons’ (minst volwassen), ‘zilver’ en ‘goud’ (meest volwassen). Het goed nadenken over de volwassenheidsniveaus voorkomt dat meteen voor de maximaal benodigde oplossing wordt gegaan, terwijl dat (nog) niet altijd nodig is. Niet in alle gevallen zal er overigens sprake zijn van drie volwassenheidsniveaus. Als een doelstelling vereist dat direct de maximale invulling van een veranderinitiatief nodig is, dan onderkennen we alleen ‘goud’. 

Op deze manier wordt een matrix gecreëerd met de doelstellingen (onderdeel van de vormgeving) in de tijd uitgezet op de x-as, de veranderinitiatieven op de y-as en de verschillende te bereiken volwassenheidsniveaus van de veranderinitiatieven in de cellen. Tijdens het creëren van de matrix kan blijken dat veranderinitiatieven moeten worden gesplitst in onderdelen, omdat bepaalde onderdelen van het initiatief gezien de doelstellingen eerder beschikbaar moeten zijn dan andere onderdelen.

Vervolgens wordt gekeken naar de onderlinge afhankelijkheden tussen de veranderinitiatieven (in een specifieke volwassenheid). Als blijkt dat een veranderinitiatief pas kan worden opgepakt na afronding van een ander veranderinitiatief, dan heeft dit invloed op de planning. Op deze manier wordt toegewerkt naar een plan dat uitvoerbaar is (gezien de afhankelijkheden) en zo maximaal mogelijk bijdraagt aan de doelstellingen van de enterprise. 

Uit de matrix volgt welke ontwikkelingen in gang gezet moeten worden om het vraagstuk op te lossen. Elke kleurovergang (bijvoorbeeld van niets naar brons of van brons naar zilver) representeert een ontwikkeling. Een ontwikkeling kan, gezien het integrale karakter van GEA, van alles zijn: introductie van een nieuw product, upgrade van een systeem, verbeteren van de fysieke beveiliging, een procesaanpassing, een anders ingerichte organisatie, verbeterde service naar klanten, een opleiding, et cetera. Elk veranderinitiatief uit de integrale oplossingsrichting wordt gerealiseerd door één of meerdere ontwikkelingen. 

Om de veranderinitiatieven en de daarbij behorende ontwikkelingen in het portfolio te kunnen onderbrengen, is naast inzicht in de planning ook inzicht nodig in de benodigde capaciteit. De capaciteit om het portfolio uit te voeren is doorgaans gelimiteerd. Voor het inschatten van de benodigde capaciteit wordt gebruik gemaakt van de techniek planningpoker, zoals bekend uit de agile softwareontwikkeling. Van eén van de ontwikkelingen wordt de benodigde capaciteit zo nauwkeurig mogelijk ingeschat. Deze ontwikkeling geldt als referentie. Van alle andere ontwikkelingen wordt de capaciteit ingeschat in relatie tot de referentie, op basis van een beschrijving van de resultaten en/of activiteiten ervan. Op deze manier kan de benodigde capaciteit van de integrale oplossingscontour worden ingeschat. Deze substap wordt door het kernteam in nauwe samenwerking met de bij het vraagstuk betrokken vraagstukeigenaar en perspectiefeigenaren uitgevoerd. 

Nu de integrale oplossingscontour is geconcretiseerd in tijd en capaciteit, wordt door het kernteam het realisatieplan van de oplossingscontour opgesteld. Hierin wordt opgenomen: 

• De vraagstukbeschrijving 
• De business case – de kwalitatieve en kwantitatieve (financiële) onderbouwing van de verandering 
• Het architectuurkader – kaderstellend en richtinggevend kader, bestaande uit de oplossingscontour, de relevante delen van het GEA-framework en de normen en standaarden die bij de realisatie moeten worden gehanteerd 
• De planning en capaciteit – planning van de ontwikkelingen en de daarbij benodigde capaciteit en resources 

Het realisatieplan is nodig om in de volgende stap de ontwikkelingen onder te brengen in het portfolio én dit plan vormt het kader om bij de realisatie te toetsen of de beoogde doelstellingen worden behaald en of dit binnen de architectuurkaders wordt gedaan. 

Stap 6 Ontwikkelingen onderbrengen in portfolio 

Het doel van stap 6 is om alle ontwikkelingen onder te brengen in het veranderportfolio van de enterprise. In stap 5 is de integrale oplossingscontour verder geconcretiseerd in termen van planning en capaciteit, onafhankelijk van de manier waarop de realisatie gaat plaatsvinden (programma, project, epics, etc.). In stap 6 vindt de verbinding met portfoliomanagement plaats. We rekenen het zorgen dat de ontwikkelingen een plaats krijgen in het portfolio tot de verantwoordelijkheid van de EA-functie en daarmee behoort het tot het GEA- stappenplan. Het daadwerkelijk realiseren van de verandering rekenen we niet tot de verantwoordelijkheid van de EA-functie. Uiteraard blijft de enterprisearchitect betrokken bij de uitvoering en heeft daar een toetsende en adviserende rol. 

Om alle ontwikkelingen de juiste plaats in het portfolio te kunnen geven, is het allereerst noodzakelijk dat de voor het portfolio verantwoordelijke manager goed inzicht heeft in de benodigde te realiseren veranderinitiatieven. Deze zijn beschreven in het realisatieplan. Het kernteam, waar nodig ondersteund door het topmanagement, presenteert het realisatieplan van de oplossingscontour aan de portfoliomanager. Eventuele onduidelijkheden worden besproken en weggenomen. 

Vervolgens wordt de samenhang tussen het realisatieplan en het bestaande portfolio geanalyseerd. In deze substap wordt door het kernteam en portfoliomanager geanalyseerd hoe de ontwikkelingen uit het realisatieplan zich verhouden tot het bestaande portfolio. Daaruit kan blijken dat: 

• de ontwikkelingen uit het realisatieplan van de oplossingscontour al zijn onderkend in het portfolio. In dat geval wordt bekeken of de planning past of dat aanpassing nodig is (mogelijk moet de realisatie naar voren gehaald worden dan wel naar achteren gebracht) 
• de ontwikkelingen uit het realisatieplan eenvoudig gekoppeld kunnen worden aan of uitbreidingen zijn van initiatieven uit het bestaande portfolio 
• de ontwikkelingen uit het realisatieplan van de oplossingscontour nog niet onderkend zijn en dus een aanvulling vormen op het portfolio. 

Vervolgens wordt in overleg met de portfoliomanager geanalyseerd op welke manier de ontwikkelingen het beste gerealiseerd kunnen worden. Dit is afhankelijk van de uitvoeringsvorm(en) die in de enterprise worden toegepast. Indien bijvoorbeeld zowel ‘traditioneel’ als ‘agile’ voortbrengingsprocessen zijn ingericht, dan zal een keuze worden gemaakt welke vorm voor welk deel van de ontwikkelingen het meest geschikt is. 

Omdat in een enterprise alles onderhevig is aan verandering, stopt het niet bij het (eenmalig) onderbrengen van de ontwikkelingen in het portfolio en moet de EA-functie verbonden blijven met het portfoliomanagement. Omdat veranderingen zowel aan de kant van het portfolio als aan de kant van enterprisearchitectuur kunnen ontstaan, is er een wederzijdse verantwoordelijkheid om de andere partij te betrekken, gezamenlijk de consequenties te analyseren en tot wijzigingsvoorstellen (op het realisatieplan van de oplossingscontour en/of het portfolio) te komen. 

Keuzes die in het portfolio worden gemaakt (bijvoorbeeld: door een noodzakelijke en urgente verbetering aan de technische infrastructuur schuiven andere ontwikkelingen naar achteren) hebben invloed op het realisatieplan van de oplossingscontour. De consequenties daarvan moeten gezamenlijk worden bekeken (bijvoorbeeld door de matrix van het realisatieplan, zie Figuur 3, opnieuw te analyseren) en bij vergaande consequenties worden voorgelegd aan het topmanagement. Ook wanneer doelstellingen van de enterprise veranderen, ten opzichte van de doelstellingen die zijn gehanteerd bij het opstellen van het realisatieplan van de oplossingscontour, zal opnieuw moeten worden gekeken naar consequenties voor planning en capaciteit (zie stap 5). Deze consequenties worden voorgelegd aan portfoliomanagement om te komen tot een passende oplossing in de uitvoering. Kortom: er is een continue verbinding tussen enterprisearchitect c.q. kernteam en portfoliomanagement om veranderingen die invloed hebben op de realisatie van de oplossing van het vraagstuk, te beoordelen op impact en het realisatieplan van de oplossingscontour en het portfolio daarop aan te passen. 

Onderhouden en beheren GEA-framework 

Actualiteit van het GEA-framework is zeer belangrijk om de meest recente inzichten en besluiten van de enterprise van toepassing te laten zijn bij het ontwikkelen van oplossingscontouren voor vraagstukken. Ook kunnen recente inzichten en besluiten dermate belangrijk zijn dat die direct leiden tot een nieuw SVP c.q. ingrijpen op een al bestaand SVP. Zoals al gebleken is bij de hiervoor toegelichte processen Stap 3 t/m 6 leidt het ontwikkelen van oplossingscontouren continu tot wijzigingen in het GEA-framework. Een andere bron van mutaties op het GEA-framework vormen de 

in de enterprise vigerende besturingscycli met de hierbij behorende kwartaal-, halfjaarlijkse- en jaarlijkse rapportages. Ook het fenomeen ‘nieuwe heren/dames nieuwe wetten’. In het geval van managementwisselingen, fusies/overnames, joint ventures c.q. andersoortige allianties ontstaan ongetwijfeld wijzigingen op zowel zin- als vormgevingsniveau. Ook spontane reacties op onverwachte gebeurtenissen in de omgeving van de enterprise, waaronder het eco-systeem waar de enterprise toe behoort, alsook politieke-, sociale-, economische- en technologische machtsfactoren, zullen hun invloed hebben op de bestaande richtinggevende kaders in het GEA-framework. 

Bewaken van de architectuurkaders 

In de hierboven beschreven Stap 6 ‘Ontwikkelingen onderbrengen in portfolio’ is al uitgebreid stilgestaan bij het bewaken van de architectuurkaders door de EA-functie tijdens de realisatie van een oplossingscontour via een toetsende en adviserende rol. Het ‘bewaken van de architectuurkaders’ heeft daarnaast een bredere werking. De EA-functie is namelijk niet de eigenaar van de ‘enterprisearchitectuur’. De eigenaren zijn het topmanagement (zingeving) en de perspectiefeigenaren (vormgeving). De EA-functie voert in delegatie van deze eigenaren alle in deze blog beschreven uitvoerende processen uit, waaronder het bewaken van de architectuurkaders. Dit laatste ontslaat de hiervoor genoemde eigenaren echter niet van hun eindverantwoordelijkheid in deze. Anders gezegd, ook zij hebben de plicht erop toe te zien dat de richtinggevende kaders op zowel zin- als vormgevingsniveau actueel en samenhangend zijn én toegepast worden. 

Tot slot 

De mate van toepassing van de in deze blog toegelichte EA-processen zal vanzelfsprekend altijd situationeel zijn. Met bovenstaande EA-procesbeschrijvingen pretendeer ik niet uitputtend c.q. volledig te zijn. In mijn volgende blog zal ik ingaan op de producten die door de uitvoering van de hier beschreven processen voortgebracht worden. Voor op- en aanmerkingen houd ik mij van harte aanbevolen. 

Referenties: 

1. Besturing van de enterprise architectuur functie. Hoe doe je dat? Besturen van de enterprise architectuurfunctie. Hoe doe je dat? – Solventa 

2. De mensen in en in relatie tot de enterprise architectuurfunctie. De mensen in en in relatie tot de Enterprise architectuurfunctie – Solventa 

3. De voor de enterprise architectuurfunctie benodigde middelen. De voor de Enterprise architectuurfunctie benodigde middelen – Solventa 

4. Stovers, R., Ruijter, J.D., Wagter, R.: GEA Enterprise Architecture in de praktijk: Betere prestaties door sturen op samenhang. Uitgeverij Dialoog, Zaltbommel, Nederland (2019) 

5. Stovers, R., Ruijter, J.D., Wagter, R.: GEA Enterprise Architecture in Practice: Better Performance by Managing Coherence. Dialoog, Zaltbommel, the Netherlands (2021) 

6. Wagter, R.: Enterprise Coherence Governance. Ph.D. thesis, Radboud University, Nijmegen, the Netherlands (2013) 

7. Proper, H.A., Wagter, R., Bekel, J.: Enterprise coherence with GEA- A 15 year co-evolution of practice and theory. In: Serral, E., Stirna, J., Ralyté, J., Grabis, J. (eds.) The Practice of Enterprise Modeling- 14th IFIP WG 8.1 Working Conference, PoEM 2021, Riga, Latvia, November 24–26, 2021, Proceedings, Lecture Notes in Business Information Processing, vol. 432, pp. 3–18. Springer (2021). https://doi.org/10.1007/978-3-030-91279-6_1 

8. Deming, W.E.: http://nl.wikipedia.org/wiki/Kwaliteitscirkel_van_Deming, last visited January 10, 2025