Artikel

De relatie tussen architecten en IT projecten

De grote historische bouwwerken lijken te bevestigen dat architectuur ‘goed’ is. Dat wil zeggen, wat is blijven staan. Maar zijn er ook bouwwerken die ‘onder architectuur’ zijn ingestort? En duurde het niet eindeloos voordat zo’n kathedraal af was? De waarde van architectuur en de rol van architecten bij het realiseren van moderne bouwwerken zoals grote IT projecten verdient zeker een reflectie. Er stort té veel in, kost té veel, duurt té lang en is misschien niet wat we hadden gewild. Hoe passen architecten in grote IT projecten?

De samenhang van de delen is bepalend voor het succes van het geheel. Daarmee heb ik eigenlijk meteen mijn persoonlijke bevestiging uitgesproken vóór het belang van architectuur in grotere projecten. En dus zeker in grote IT projecten. Maar daarmee is de discussie over de rol van architecten in zulke projecten niet afgerond, maar begint deze juist pas. En hier wil ik zeker niet zo snel een positieve conclusie aan verbinden. Hoe krijg je de voordelen van een goede architectuur gerealiseerd in een groot project? Wat moet er dan door wie worden gedaan? En bij deze vraagstelling wil ik ook graag de tegenovergestelde vraag beschouwen. Wat moet er vooral niet gedaan worden?

Grote projecten kunnen op meer manieren mislukken, dan dat ze goed gaan. We moeten dus wel degelijk ervaringen uit het verleden meenemen om succesvol te zijn. Deze ervaringen liggen gedeeltelijk vast in moderne methodologieën. Systematische aanpakken als Prince2 en MSP, beide van dezelfde bron OGC, zijn een prima houvast en leidraad voor het pad naar de gewenste uitkomst. Want laten we wel wezen, het project is nooit het doel. Hooguit een middel om iets te bereiken. Hiermee wordt de vraagstelling wat specifieker. Wat kunnen architecten bijdragen aan het doel van een project?

Het doel van een project

In de praktijk zie ik vaak dat het makkelijker is om projecten te starten dan af te ronden. En het blijkt helemaal moeilijk om projecten te stoppen. Voor de start-, stop- en afrondproblematiek zijn legio redenen aan te voeren, maar vaak is het terug te voeren op gebrek aan richting en persoonlijk belang bij voortzetting. Laten we even teruggaan naar de relatie van een organisatie en haar projecten.

De enterprise formuleert haar visie op de wereld, haar missie daarin en vertaalt dit naar de strategie. De strategie reflecteert daarmee het voorgenomen pad naar het gestelde doel. En de enterprise probeert met ontwikkelingen en innovatie deze te verwezenlijken in haar organisatie. En daarmee is eigenlijk ook gezegd dat elke activiteit en dus ook de projecten een relatie moeten hebben met die strategie. Maar ja, de praktijk blijkt weerbarstig. Bij een strategiewijziging blijkt het in grotere organisaties toch een hele klus om al die activiteiten en projecten dan weer bij te sturen.

De theorie definieert een project als een eenmalige activiteit om een bepaald product te realiseren binnen de driehoek tijd, kwaliteit en kosten. Dit past eigenlijk niet goed bij de strategie, wat een voortdurend pad is met een langere horizon, wat verandert door de context van de enterprise. Hier komt de programma-aanpak om de hoek kijken, waarin projecten hun plek krijgen naast andere activiteiten om de gewenste blijvende veranderingen te realiseren. Programma’s hebben geen product als resultaat, maar een voordeel voor de enterprise in lijn met de gekozen strategie.

Programma- en projectmanagement zijn daarom ook erg verschillend van aard. Een goede projectmanager regelt dat het afgesproken resultaat behaald wordt binnen de gestelde scope, tijd en budget. Waar nodig worden dan hier en daar de nodige parameters gebogen. Het resultaat is heilig en als de klus is geklaard, wegwezen en op naar de volgende klus. Een goede programmamanager daarentegen is veeleer bezig met belangen, acceptatie en borging in de organisatie. Hierin kan heel goed een project worden geofferd als dat goed is voor de gewenste uitkomst, opdat het voordeel van de organisatie wordt bereikt. Een programma heeft dan ook veel meer activiteiten dan alleen maar projecten. Communicatie is daar een sprekend praktijkvoorbeeld van. Om het nog iets meer aan te zetten; de projectmanager denkt in producten en resources, terwijl de programmamanager denkt in uitkomsten en belangen.

Figuur 1: Programmamodel

De rol van architectuur in een programma

De programmaoptiek in de context van de organisatie en projecten kunnen we zien als een samenhangend geheel, dat ons is aangereikt door de wijze geesten achter de programma- en projectmanagement methodologieën. We zouden zelfs kunnen definiëren dat dit de ‘architectuur’ is van strategierealisatie. Maar laten we niet te ver afdwalen in het theoretische, want dat is toch al een valkuil voor de architecten onder ons.

Terug naar de vraagstelling hoe architectuur kan bijdragen aan de missie door het bereiken van het volgende strategische doel. Een enterprise heeft goede programma’s met de juiste richting nodig voor de realisatie van haar strategie. Een programma heeft de goede activiteiten nodig met de juiste richting om de gestelde uitkomsten en voordelen te realiseren. Een project heeft de goede werkpakketten nodig om de juiste producten te realiseren. Hier lijkt een trend waarneembaar over de lagen van het model. Als architect en als IT-er geeft dat een goed gevoel.

Als architectuur kan bijdragen aan ‘richting’, ‘goed’, en ‘realisatie’, dan zijn we proper bezig. Anders gezegd, architectuur moet ondersteunen bij kaders stellen, kaders controleren en creatie. En dat is eigenlijk best voor te stellen als je door zo’n kathedraal loopt als ware je de betreffende architect: ‘We gaan een groot kruisvormig gebouw maken met een koepel! Zijn deze stenen onder deze hoek gemaakt? Ik teken wel even hoe je die verbinding moet maken.’

Architectuur kan dus dienstbaar zijn door kaders te stellen, deze te controleren en te ondersteunen bij de creatie. Maar dan moet het wel passen in het totaal. Dus de architectuur moet op de juiste laag op de juiste wijze worden gebracht. Teveel detail of te weinig duidelijkheid zijn voedingsbodems voor de antipathie tegen architecten. ‘Architecten maken alleen maar wolken’ of ‘Architecten bemoeien zich teveel met de details’ zijn bekende kreten uit de praktijk.

Figuur 2: Architectuur in het programmamodel

De uitdagingen van een architect

Architecten zijn die mensen die bezig zijn met de architectuur, dus met ‘richting’, ‘goed’ en ‘realisatie’. Solution architecten kunnen bijvoorbeeld in een project meehelpen om het ontwerp voor een infrastructuur uit te werken. Maar als ze in het project blijven herhalen dat iets niet kan of niet mag dan zal de projectmanager waarschijnlijk ingrijpen en de betreffende architect wegsturen.

Enterprise architecten bijvoorbeeld stellen principes op voor alle delen van de gehele enterprise. Duidelijk kader stellend. De praktijk laat voorbeelden zien van veel te veel detail, eindeloze discussies over de wijze van formuleren en een heel traag proces van acceptatie. Het is gemakkelijk om hier de gebruikelijke fout van ‘doel en middel’-verwisseling te begaan. De principes zijn niet het doel, ze zijn slechts een middel om richting te geven aan de programma’s en dan is het niet nodig om te gedetailleerd te zijn. Het gaat om de richting en op dit niveau bijvoorbeeld niet om het specificeren van de versie van de software voor de eindgebruiker.

Acceptatie van principes is een andere uitdaging voor de architect. Mocht er al een forum zijn waarin de principes kunnen worden geformuleerd, dan is dat slechts het begin van de tocht ter accordering van die principes. En wil je werkelijk programma’s kunnen controleren, dan moet je dus met de mensen boven de programma’s aan de slag. Nu zijn deze mensen juist aangesteld op basis van hun drive en persoonlijkheid, dus niet de makkelijkste karakters voor een discussie over controle. Als de argumentatie niet direct gerelateerd is aan de strategie en is geformuleerd in business taal, dan is de architect verloren en liggen uitstel, afstel en nivellering van de rol in het verschiet.

Een valkuil op projectniveau is de langsvliegende architect. Het project is al een tijdje onderweg en heeft al een aantal keuzes gemaakt voor de realisatie. Naar goed gebruik is er regulier een projectoverleg waar de senior architect altijd voor uitgenodigd is, maar in verband met agenda, drukte en belangen op een hoger niveau niet eerder is verschenen. Als de architect dan uiteindelijk een keer in de vergadering verschijnt, is het niet onwaarschijnlijk dat er met principes gegooid worden die geen van de project teamleden kent, er geconcludeerd wordt dat het project dus niet goed bezig is en dat de architect ook altijd alles zelf moet doen om iets goed te krijgen. Zie hier de valkuil van drie rollen tegelijk uitvoeren gecombineerd met de valkuil van het doorsnijden van de verschillende niveaus in het programmamodel.

‘Te mooi’ is een ander bekend fenomeen uit de praktijk. De architect binnen een project moet een ontwerp opleveren, maar het is te laat. De projectmanager wordt onrustig en dringt aan op voortgang. Hier kan het hart van de architect om mooie dingen te maken, die voor altijd blijven staan, de overhand krijgen en het project komt nooit af.

Dit zijn enkele illustratieve voorbeelden van de uitdagingen van de rol van de architect. Hoe balanceer je ‘richting’, ‘goed’ en ‘realisatie’? En hoe balanceer je tussen de lagen van het programmamodel? Als je als architect je bewust bent van deze verschillen, dan gaat het al een stuk beter.

Organisatie en de plaats van de architect

Maar hoe kunnen we nu de architecten helpen in hun toch wel belangrijke rol? Daarvoor kunnen we de positie van de architect in de organisatie beschouwen. De drie aspecten van architectuur geven drie verschillende verhoudingen tot de activiteiten in de enterprise. Het is moeilijk om van binnenuit richting te geven en daarom kan dit beter van bovenaf gedaan worden. Dus vanuit de ene laag de richting aangeven voor de onderliggende laag. Daarmee zou de architect wel onderdeel kunnen zijn van een programma, maar staat dan wel boven de projecten.

Controleren wordt ook bij voorkeur niet van binnenuit gedaan, maar vanuit een neutrale rol buiten de sturende lijn. En controle is iets anders dan correctie. De correctie moet niet vanuit de architect komen, maar vanuit de lijn. Architecten en lijnmanagers hebben een verschillend karakter en deze moeten niet verkeerd ingezet worden.

Het realisatie aspect ligt binnen een activiteit. Dus bijvoorbeeld als teamlid in een project. Maar daarmee is de architect ook ondergeschikt aan de projectmanager. Op deze wijze kan het voorkomen dat er iets gemaakt wordt wat niet goed strookt met de principes en dan moet de architect zich schikken.

Dit leidt ertoe dat de architectuurfunctie in een organisatie bij voorkeur naast de programma- en projectenstructuur geplaatst wordt en gelaagd wordt opgezet. Dit geeft onafhankelijkheid per activiteit en consistentie over de verschillende activiteiten. Richting geven kan dan vanuit de architectuurfunctie plaatsvinden met deelname van de betreffende belanghebbenden en gelaagd om details en domeinen naar beneden toe verder uit te werken.

Controle kan vanuit de architectuurfunctie worden aangeboden aan de rollen die in het programmamodel daarvoor opgesteld staan. Dus bijvoorbeeld een Senior User in een Project Board kan voor de Q&A rol een architect uit de architectuurfunctie vragen. Echter, de eventuele correctie is niet de taak van de architect, maar van de verantwoordelijke in het project. Een ander voorbeeld is de deelname van een architect in een audit team.

Voor het realisatie-aspect is het anders. De architect wordt onderdeel van het team en staat daarmee ook onder aansturing van de teammanager. Als het er dan op aankomt, gaat de teamscope voor de architecturale schoonheid. Dit zou ook vanuit de programma- en projectenstructuur kunnen worden gedaan, maar voor synergie en verbinding naar het grotere geheel heeft de organisatorische ophanging in een aparte architectuurafdeling de voorkeur.

Een separate architectuurfunctie leidt de architect beter op in het rollenspel over de drie aspecten. Daarmee is de architect goed gepositioneerd voor de verschillende aspecten in, voor en over de programma activiteiten (inclusief de projecten). Een ander voordeel is dat de architecten nu ook een groeipad kan worden geboden over de lagen heen. En niet te vergeten zijn met een separate architectuurfunctie ook de programma- en projectmanagers beschermd tegen de architect die buiten zijn rol valt.

Conclusie

Architectuur is zeer waardevol voor de strategie van een enterprise, maar architectuur is geen doel op zich. Het doen van architectuur ten dienste van de doelen van programma’s en ook van projecten heeft een belangrijke bijdrage aan het totale succes.

Binnen architectuur zijn drie aspecten te onderscheiden, ‘richting’, ‘goed’ en ‘realisatie’, die bepalend zijn voor de aard en wijze van het doen van architectuur. Het vervloeien van deze aspecten in de uitvoering door de architect en het onbewust doorsnijden van de niveaus van het programmamodel zijn de valkuilen voor de architect.

De architectuurfunctie in een organisatie is bij voorkeur separaat van de inrichting van het programmamodel, opdat architecten beter (op)geleid worden in hun verschillende rollen en de project- en programmamanagers op hun beurt beter beschermd zijn tegen de architect.

Categorie:   
Auteur(s)
afbeelding van harrypotma
Harry Potma
Atos - Global Lead Transformation Methodologies

Harry Potma is werkzaam bij Atos als Global Lead Transformation Methodologies.

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.