Bij Bvolve geloven wij dat het ondersteunen van verandering één van de belangrijkste doelen van architectuur is. In deze blog wordt er stilgestaan bij de rol van Enterprise Architectuur in de context van een project. Daarnaast wordt er geanalyseerd wat architectuur in een project context inhoudt en worden er een aantal best practices gedeeld.
Waarom Enterprise Architectuur belangrijk is voor verandering
Enterprise Architectuur geeft inzicht en overzicht in complexe organisatiestructuren en de informatievoorziening. Aan de hand van vorm- en zingeving, principes en richtlijnen helpt architectuur de visie te vertalen naar concrete proces- en IT-landschappen. In complexe veranderorganisaties zien wij Enterprise Architectuur in toenemende mate een belangrijke toegevoegde waarde leveren. Enterprise Architectuur ondersteunt de organisatie bij het maken van de juiste keuzes in prioriteiten, het bewaken van de samenhang en de inzet van middelen. Concreter is Enterprise Architectuur een verzameling van views, principes en richtlijnen, die ervoor zorgen dat de aspecten, die eerder zijn genoemd, in samenhang ontworpen en geïmplementeerd worden. Het creëren van inzicht en overzicht gebeurt met behulp van architectuur views, zoals modellen van de huidige en de (beoogde) toekomstige of gewenste situatie (de IST en SOLL-architectuur). De architectuur principes en richtlijnen bieden, samen met de organisatie doelen, generieke kaders en oplossingsrichtingen voor het ontwerp en de implementatie van veranderinitiatieven.
Enterprise architectuur in een projectcontext?
In de architectuur kan er een onderscheid gemaakt worden in diverse niveaus. In deze blog worden er drie niveaus van architectuur gehanteerd:
- Enterprise Architectuur (EA): de architectuur op het niveau van de gehele organisatie;
- Domein Architectuur (DA): de architecturen die worden gedefinieerd op basis van specifieke typen producten, diensten, processen of functies;
- Project Architectuur: het deel van de architectuur (uit de EA of DA) die specifiek van toepassing is voor een bepaald project. Dit bestaat uit:
- Een verzameling van modellen, principes en richtlijnen;
- Een analyse van de ‘gap’ tussen de huidige en toekomstige of gewenste situatie (IST – SOLL);
- Ondersteunend gedetailleerde weergave van de architectuurvisie specifiek gericht op het project;
- Werken aan een oplossingsrichting gerelateerd aan de vraag vanuit de business.
Een van de bekendste onderdelen van projectarchitectuur is een Project Start Architectuur (PSA). De PSA bevat de vraag van de business en hoe deze zich vertaalt naar een mogelijke oplossingsrichting. De ontwikkeling van een PSA komt iteratief tot stand en wordt in samenwerking met de business ontwikkeld. De PSA bestaat voor een deel uit projectinformatie, waarin onder andere de context, doelstellingen, beoogde resultaten en architectuurdrijfveren van het project worden geformuleerd. Daarnaast wordt er vanuit de architectuur een visie geformuleerd voor een desbetreffend project.
Inhoudelijke wordt de PSA verder vormgegeven met een beschrijving van de huidige en toekomstige of gewenste situatie specifiek voor een project. Dit wordt ondersteund door kaders, standaarden en principes vanuit de architectuur. De mogelijke oplossingsrichting komt voort uit het analyseren van de ‘gap’ tussen de huidige en gewenste of toekomstige situatie. Op basis van de voorgaande aspecten kan er verdere invulling gegeven worden aan de transitie en de ontwerpbeslissingen in de PSA. De PSA bevat ondersteunend hieraan relevante modellen en voorschriften die het verdere verloop van het project richting geven. Een PSA kan daarom gezien worden als een uitwerking van een deel van de Enterprise/ Domein architectuur voor een specifiek onderwerp. Deze uitwerking komt iteratief tot stand en wordt gedurende de ontwikkeling getoetst aan de Enterprise Architectuur.
Enterprise architectuur onder tijdsdruk van projecten?
In de situatie dat een project constateert dat de EA nog onvoldoende kaders biedt is het project zelf verantwoordelijk voor het opstellen of het complementeren van de betreffende architectuur voordat de PSA kan worden opgesteld. Deze aanpak dwingt het project eerst de benodigde architectuurkaders uit te werken en zich er zo van te verzekeren dat het past binnen de context en (langere termijn) ontwikkelingen. De architectuurmodellen ondersteunen de ontwikkeling en vormgeving van de PSA, maar zijn geen doel op zich. Op deze wijze wordt tevens de EA gebruikt om hogere bestuurslagen te voeden met, de in de context van het project, opgedane inzichten en ideeën. Zodat dit gebruikt kan worden voor visievorming.
3 Best practices van Bvolve
Hieronder zullen er drie best practices gedeeld worden, die effectief zijn gebleken voor het werken met EA in een project context. Deze best practices zijn wellicht breder toepasbaar.
1. Architecten in een vroeg stadium betrekken bij veranderinitiatieven
De kern van Enterprise Architectuur is ‘structuur met een visie’. Van oudsher is Enterprise Architectuur een manier om richting te geven aan veranderingen door middel van modellen, structuren, harde richtlijnen en de zogenoemde ‘blauwdrukken.’ Hierdoor wordt architectuur vaak als vertragend gezien in verandertrajecten en wordt er vaak gezegd dat architectuur niet snel genoeg inspeelt op de actuele behoefte van de organisatie. De huidige perceptie is echter ook dat deze aanpak niet meer past in de tijd waarin we leven en dat de nadruk gelegd moet worden op een meer dynamische architectuur die mee kan veranderen met de behoefte en incrementeel kan worden ontwikkeld. In een project context is het hierbij belangrijk om architecten zo vroeg mogelijk te betrekken in een project. Haak als architect zo snel mogelijk aan bij initiatieven en nieuwe projectleiders en bied daar je diensten aan. Dan kun je op een positieve manier de gewenste richting vormgeven en hoeft architectuur op deze manier niet als belemmerend te worden ervaren.
2. Verduidelijken van rollen
Bij het werken met EA in een projectcontext is het belangrijk om de diverse rollen en verantwoordelijkheden te beleggen. Hierbij is er een onderscheid te maken tussen de rollen die door de architectuur worden vormgegeven en de rollen die door het project worden benoemd. Vanuit de architectuur zijn er voor projecten vier generieke rollen te onderscheiden, namelijk: Enterprise Architect (ook vaak de controlling architect), Project Architect, Architectuurboard en het Architectuur team (bestaande uit domein architecten). Deze rollen dragen elk een bepaalde verantwoordelijkheid en mandaat in het architectuurproces gedurende een project. In de volgende blog gaan we in meer detail in op de verschillende rollen en verantwoordelijkheden.
3. Olievlek-methode
De olievlek methode is een manier om het werken met Enterprise Architectuur verder te ontwikkelen binnen de organisatie. De praktijk wijst uit dat organisaties de architectuur eerst tot in detail uitwerken om daarna concreet aan de slag te gaan met Project Architectuur. De olievlek methode houdt in dat een organisatie, ondanks de lage volwassenheid van de architectuur, van het begin af aan een project onder architectuur uitvoert. Deze werkwijze en het succes van het project dienen als uitgangspunt voor volgende projecten. Met deze werkwijze bouw je enerzijds ‘on-the-go’ aan de volwassenheid van je architectuur en sluit het aan bij het principe van ‘just-enough architecture’, door wanneer nodig de desbetreffende architectuur in kaart te brengen. Anderzijds speel je in op de zogenoemde ‘quick-wins’ door de organisatie snel kennis te laten maken met het uitvoeren van een project onder architectuur. Gerelateerd hieraan staat het delen van de succesverhalen van het werken onder architectuur in projecten binnen de organisatie. Hierdoor wordt de acceptatie om architecten eerder te laten aanhaken vergroot. Daarnaast draagt dit bij aan het creëren van draagvlak voor architectuur in de organisatie.
In mijn volgende blog zal ik je meenemen in het werken met PRINCE II onder architectuur.
Meer weten over het werken onder Enterprise Architectuur in een project context binnen jouw organisatie? Lees dan mijn volgende blog en/of neem direct contact op met Thomas Veenhoven.
Een schoolvoorbeeld: Enterprise Architectuur blog bundel
In een van onze opdrachten ondersteunen wij een grote academische instelling bij het inrichten van hun architectuurfunctie en in het bijzonder de centrale architectuur repository in BiZZdesign Enterprise Studio. Samenwerken in een model brengt verschillende uitdagingen met zich mee. In deze blogreeks vertelt Bvolve consultant Mark Kahmann over dit traject. De oplossingen zijn waarschijnlijk ook relevant voor jouw organisatie.
