De enterprisearchitect als coach

De enterprisearchitect als coach
Grotere organisaties kennen vaak een (te strikte) scheiding tussen enterprise- en projectarchitecten. Dat leidt tot inefficiëntie en past niet bij deze tijd. Hoe is verbetering mogelijk met lessen uit ‘agile’ denken?
Raimond Brookman en Wouter Roelofs
De praktijk in veel (vooral grotere) organisaties is om veel structuur aan te brengen en daarin verantwoordelijkheden zoveel mogelijk te scheiden. Dit resulteert dan bijvoorbeeld in de volgende structuur. Ten eerste is er een strategische architectuurgroep die zich richt op de lange termijn. Daarbij ligt de nadruk op de veranderingen die op de organisaties af komen en op de problemen in de organisatie en IT-inrichting die moeten worden aangepakt om met al die veranderingen om te kunnen gaan. Dit leidt vooral tot principiële uitspraken en het schetsen van een toekomstbeeld. Daarnaast zijn er domeingerichte architectuurgroepen die de langetermijnrichting vertalen naar beleid binnen het betreffende domein. Denk hierbij aan domeinen als procesarchitectuur, informatiearchitectuur, softwarearchitectuur, infrastructuurarchitectuur en data-architectuur. Ten slotte is er een groep architecten die concreet binnen projecten aan de slag zijn om inhoudelijk te bepalen hoe de oplossing eruit gaat zien om de projectdoelen te bereiken. Deze passen daarbij de architectuurkaders toe. Vaak vindt er ook al concreet architectuurwerk plaats in de initiatiefase van een project. Dit krijgt dan vorm in de Project Start Architectuur (PSA). Opvallend is dat deze stap procesmatig op veel verschillende manieren plaatsvindt en dat organisaties daarin zeer verschillende keuzen maken, met uiteraard bijbehorende voor- en nadelen. Wat hierbij opvalt, is dat er vaak sprake is van een ‘top-down approach’. Enterprisearchitecten zetten op enterpriseniveau kaders neer en zijn dan ‘klaar’ met hun werk. Vervolgens mogen de projectarchitecten met deze kaders aan de slag om projectarchitectuur te maken en zijn zij ‘klaar’ met hun werk. En ga zo maar door. Er is niet of nauwelijks sprake van een opwaartse stroom van feedback.
Veel voorkomende problemen
Deze manier van architectuur bedrijven kan leiden tot een aantal problemen. Deze blijven vaak niet beperkt tot een bepaald abstractieniveau, maar zijn door de hele keten voelbaar. Hierdoor lopen projecten en dus de business schade op door onnodige kosten, een inefficiënte werkwijze of zelfs door ronduit falen. We noemen enkele voorbeelden van problemen die regelmatig voorkomen in de praktijk. Het eerste probleem is dat het wiel opnieuw wordt uitgevonden. Omdat architectuur op enterpriseniveau vaak puur kaderend is, moeten projectarchitecten nog veel concrete keuzen maken. Eenmaal gemaakt zijn deze keuzen vaak ook toepasbaar op andere projecten of vervolgprojecten. Helaas gebeurt het maar al te vaak dat deze nuttige vondsten het projectniveau niet ontstijgen, omdat er onvoldoende communicatie is met de enterprisearchitecten. Hierdoor maken
andere projectarchitecten opnieuw soortgelijke keuzen. Dit is niet alleen inefficiënt, maar leidt regelmatig ook tot wildgroei in oplossingsrichtingen. Het tweede probleem is de invloed van projectdruk. Projecten zijn tijdig van aard en hebben vaak te maken met strakke deadlines. Enterprisearchitectuur vindt echter vaak op projectoverstijgend niveau plaats en heeft een meer continu karakter. Deze verschillen in druk kunnen botsen, waardoor projectarchitecten door de tijdsdruk zelf keuzen gaan maken of forceren. Terwijl besluitvorming hierbij juist in een breder kader moet plaatsvinden. Het derde probleem is gebrekkige overdracht. Vaak zijn enterprisearchitecten slechts bij de opstart van een project betrokken en vertrekken zij nog voordat de projectarchitect aan de slag is.
Als enige vorm van overdracht hebben ze dan de PSA. Hieruit blijkt lang niet altijd welke keuzen de enterprisearchitect heeft gemaakt of welke ideeën hij had bij deze keuzen. De projectarchitect moet vervolgens tijd en energie steken in het ‘ontcijferen’ van de beschikbare documentatie en doet zo werk dubbel of interpreteert zaken anders.
Anti-patronen
De oorzaken van de genoemde problemen zijn te vinden in de volgende vijf anti-patronen:
• Ivoren toren denken: De strategische groep staat los van de projecten, denkt te ver vooruit en denkt te veel in ideaalbeelden die ver van de werkelijkheid staan. De te volgen tussenstappen zijn onduidelijk.
• Copy-pastearchitectuur en architectuurproces: - De organisatie benoemd een standaard zoals TOGAF tot de nieuwe manier van werken zonder daarbij een implementatietraject in te gaan, terwijl dit soort standaarden juist aangeven dat een organisatiespecifieke inrichting heel belangrijk is. - Eén-op-ééntoepassing van een referentiearchitectuur (denk bijvoorbeeld aan overheid: NORA en afgeleiden) zonder naar de organisatiespecifieke situatie te kijken.
• Niet-gedragen kaders: - Hanteren van principes ‘omdat framework X dat zegt’ zonder dat de voordelen en de implicaties duidelijk zijn of bediscussieerd binnen de organisatie. - Kaders die wel moeten maar niet kunnen: enterprisearchitecten spreken kaders onvoldoende door met mensen die ze moeten toepassen. Desondanks bekrachtigt het management ze. Dit legt onhaalbare doelen bij projecten neer. Projecten plaatsen deze doelen vervolgens ergens tijdens het traject buiten scope. Een ander effect kan zijn dat projectarchitecturen in de regel veel toegestane afwijkingen hebben op de kaders waardoor de kaders geen toegevoegde waarde meer bieden.
• Slagboomarchitectuur: architecten leggen de nadruk op wat allemaal niet mag en acteren vooral als een scheidsrechter richting projecten, die de boel zo goed mogelijk in de gaten houdt en ‘kaarten uitdeelt bij overtredingen’. Maar er is vaak juist behoefte aan meedenken over hoe een project zo goed mogelijk zijn doelstellingen kan halen en tegelijk zoveel mogelijk in de gewenste strategische richting beweegt. Kortom: veel onderwerpen zijn niet zwart-wit, maar kennen gradaties.
• Wollige documentatie: hiervan is sprake op diverse gebieden, zoals kaders, referentiearchitectuur en projectarchitectuurdocumenten. Documentatie bevat vaak grote hoeveelheden aanleiding, historie, gevolgd proces en uitleg van allerhande gehanteerde termen en patronen in plaats van helder te communiceren wat de gemaakte keuzen zijn en wat de achterliggende motivatie is. Dit begint vaak al in documenttemplates met grote hoeveelheden tekst. Ook vindt er vaak veel herhaling plaats door uit diverse brondocumentatie integrale hoofdstukken over te nemen zonder specifiek aan te geven waarom dit in de context van het project interessant is en wat dat betekent.
Lessen uit agile denken
Het ‘agile manifesto’ voor software development (Beck et al, 2001) zegt het volgende:
• ‘Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.’
Deze zaken kunnen we ook toepassen op het architectuurproces:
• Individuals and interactions. In plaats van alles te communiceren via documenten en modelleertools is het van belang om ‘face to face’ en in workshops gezamenlijk zaken aan te pakken en uit te werken. Een andere valkuil is om heel strikt in alle gevallen het proces te willen volgen, terwijl nu eenmaal niet alle situaties daarbinnen passen.
• Working software. Iets algemener kun je dit vertalen naar ‘werkende oplossingen’, aangezien projecten vaak niet alleen een IT-component maar ook procesmatige veranderingen kennen, wat in zijn geheel moet samenwerken. Kortom: meet succes af aan het toepassen van de oplossing binnen de organisatie en aan de daarmee geleverde business value, niet aan de hoeveelheid geproduceerd papier.
• Customer collaboration. In plaats van harde kaders neer te zetten en daaraan vast te houden, moeten project- en enterprise-architecten samenwerken om de best haalbare oplossing te realiseren. Dit betekent ook dat er een continue betrokkenheid is in plaats van te denken in afzonderlijke taken en doorgeefluikjes.
• Responding to change. Juist omdat er in het begin van een project nog veel onduidelijkheden zijn, is het niet realistisch om te verwachten dat kaders al heel precies duidelijk zijn. Een architectuurdocument (zoals een PSA) dient al wel voldoende helder te zijn om vanuit een eenduidige visie een project te kunnen starten, maar er zullen zeker nog veranderingen plaatsvinden. Ook hier moet het doel niet zijn om keihard vast te houden aan het initiële plan, maar om binnen de beperkingen van het project te komen tot een adequate oplossing. Negeer veranderingen in de context van het project niet, maar neem ze mee in te maken keuzen en laat de architectuur evolueren, zoals ook een businesscase zich gedurende het project ontwikkelt.
Lessen uit agile practices
Aanvullend zijn er nog een aantal agile principles en practices die je iets generieker dan puur vanuit softwaredevelopment op de volgende manier kan uitleggen.
• ‘YAGNI’: You Ain’t Gonna Need It (Jeffries et al, 2001). Te ver vooruitdenken is gevaarlijk. Steeds snellere veranderingen in de omgeving maken dat plannen al achterhaald kunnen zijn voordat ze af zijn. Laat staan dat je ze kunt uitvoeren. Het gedetailleerd uittekenen van een SOLL-architectuur voor de lange termijn is dan ook ongewenst. Ook is het niet zinvol om kaders neer te zetten en uit te schrijven die nog niet vanuit een projectcontext nodig zijn.
• ‘DRY’: Don’t Repeat Yourself (Hunt & Thomas, 1999). Alhoewel het gewenst is om een duidelijk en volledig verhaal te hebben, is het niet zinvol om documenten bij elkaar te copy-pasten. Herhalen van zaken die al ergens vastliggen is onnodig. Bovendien kan dit erg foutgevoelig zijn als de ‘waarheid’ inmiddels achterhaald is en het niet inzichtelijk is op hoeveel plekken bepaalde informatie voorkomt. In deze tijd, waarin de noodzaak tot het gebruik van papier (gelukkig) steeds verder afneemt, is het ook steeds eenvoudiger om verwijzingen te leggen naar achterliggende documentatie met meer gedetailleerde beschrijvingen of referentiemateriaal, voor wie daar in geïnteresseerd is. Even doorklikken op de tablet is dan vele malen handiger dan iedereen grote hoeveelheden ‘hergebruikte’ tekst voor te schotelen. Tegelijkertijd is het ook handig om essentiële onderwerpen juist wél vast te leggen. Sommigen denken bij agile aan ‘we documenteren niet meer’. Dit principe zegt juist: leg zaken vast die je anders keer op keer uitlegt of die je uittekent op een blaadje of een whiteboard.
• ‘Travel light’: Reduceer beschrijvingen tot de essentie (Ambler, 2004). Geef eerder de voorkeur aan platen dan aan tekst. Vastlegging hoeft niet formeel te zijn in een modelleer taal of tool als dat niets toevoegt op langere termijn. Aan de andere kant kunnen modellen in één oogopslag veel duidelijk maken waar anders vele pagina’s tekst voor nodig zijn. Ook voor latere analyse kan het belangrijk zijn om te modelleren, maar pas op voor syntactische discussies of heilige oorlogen over hoe je de modelleertaal precies toepast.
• ‘Whole team’: In plaats van verschillende groepen die georganiseerd zijn naar discipline, is het belangrijk om een multidisciplinair team te hebben met leden die samen de verantwoordelijkheid voelen om een werkende oplossing te realiseren (Jeffries et al, 2001). Dit betekent betrokkenheid van een businesseigenaar, maar ook een enterprisearchitect. Bovendien kan het perspectief van andere disciplines toegevoegde waarde hebben voor de architectuur zelf.
• ‘Information radiators’: Cruciale informatie kun je het best beschikbaar stellen via grote posters aan de muur (Cockburn, 2001). Het is een stuk eenvoudiger om naar een poster te lopen en op basis daarvan dingen uit te leggen, dan dat je eerst een tool moet openen, naar de juiste plek moet navigeren en vervolgens met een beperkt scherm ruimte inzichtelijk moet maken. Ook geeft het de mogelijkheid er even snel wat bij te schrijven of te tekenen als meer uitleg van dat onderdeel of aanpassing nodig is. Deze ‘information radiators’ zijn bijvoorbeeld prima toepasbaar om de referentiearchitectuur en de architectuur
principes te delen of om duidelijk te maken hoe de projectspecifieke architectuur eruit ziet.
Enterprisearchitectuur ‘nieuwe stijl’
De eerder genoemde agile lessen zijn samen te vatten tot een paar essentiële thema’s:
• Samenwerking, communicatie en gezamenlijke verantwoordelijkheid (individuals & interactions, customer collaboration, whole team, information radiators) • Focus op business value (working software)
• Just Enough Architecture (YAGNI, DRY, travel light)
• Omarmen van verandering en dynamiek (responding to change).
 
Wanneer we dit toepassen, komen we tot een nieuwe wijze om enterprisearchitectuur te bedrijven. Figuur 1 geeft dit proces weer. Figuur 2 toont hoe binnen dit proces de betrokkenheid van de enterprise- en de projectarchitect nu vaak is en wat de gewenste situatie is. We lichten dit proces toe en benoemen daarbij de belangrijke momenten (genummerd in beide figuren).
Figuur 1. Het continuous architectuurproces
 
Figuur 2. Mate van betrokkenheid architecten in het proces
 
Strategisch afspraken maken (1)
• Breng in kaart welke wijzigingen de organisatie op zich af ziet komen. Identificeer daarbij op hoofdlijnen waar dat impact gaat hebben zonder al een gewenste eindinrichting te bepalen. Dit betekent tegelijkertijd ook referentieplaten op hoog niveau om die impact op in te tekenen.
• Breng in kaart welke hardnekkige problemen de organisatie kent. Dit zijn problemen waar de organisatie al tijden mee worstelt en keer op keer niet op kan lossen.
• Breng in relatie tot de bovenstaande punten de principes in kaart die de organisatie belangrijk vindt en waarlangs zij zich wil bewegen. De kracht is om het aantal principes te beperken en de concrete vertaling pas te maken op het moment dat het nodig is. Zorg wel voor een duidelijke beschrijving van de motivatie en de implicaties, zodat wel duidelijk is wat de potentiele gevolgen kunnen zijn en waarvoor men kiest. Nadruk leggen op de komende veranderingen en hardnekkige problemen voorkomt dat je allerlei ‘open deur’-principes beschrijft over zaken die normaliter eigenlijk wel goed gaan.
• Haak hierbij maximaal aan bij ondernemingsplannen en strategische doelstellingen.
• Voer deze acties uit met zowel het hoger management als met key players die vaak een rol hebben bij organisatorische en IT-veranderingen (waaronder projectarchitecten). Hierbij is een continue dialoog erg belangrijk.
• Besteed hier niet te veel tijd aan, compleetheid is geen doel op zich. Zaken die echt belangrijk zijn komen wel boven en laaghangend fruit komt op een later moment vanzelf langs.
• Vul strategische afspraken in op tactisch niveau. Daar blijkt dan of de strategie helder genoeg is om concreet toe te passen en dit levert feedback op over de vraag of bijstelling nodig is.
Tactisch concretiseren
• Het is goed om voor het komende jaar te prioriteren welke veranderingen het belangrijkst zijn. Deze prioritering dient plaats te vinden op basis van ‘business benefits’. Daarnaast is er ook een categorie projecten die sowieso moet gebeuren, bijvoorbeeld omdat deze gerelateerd zijn aan wetgeving. Beschouw deze lijst echter niet als volledig definitief. Gaandeweg het jaar kunnen prioriteiten veranderen en het is goed om daarin mee te kunnen gaan. (2)
• Cluster gerelateerde veranderingen tot projecten, waarbij kleinere projecten de voorkeur hebben boven grote projecten die alles in één keer proberen op te lossen. Enterprisearchitecten spelen hierin een belangrijke rol om inzicht te krijgen in die samenhang. (3)
• Maak op basis van de geselecteerde projecten en hun globale impact een inschatting van de mate waarin deze binnen de bestaande architecturen en kaders passen. Dan is duidelijk welke kaders aanvulling of uitbreiden vereisen. Ook hier is dus een feedback-loop aanwezig om de enterprisearchitectuur te laten evolueren. (3)
• Enterprisearchitecten kunnen hier alvast mogelijke oplossingsrichtingen verkennen in relatie tot de afgesproken principes. (3)
• Voer voor complexere projecten eventueel een vooronderzoek uit en stel een schetsmatige PSA op, zodat het project vanuit een concrete oplossingsrichting kan vertrekken. Hierbij is samenwerking tussen de enterprisearchitect en de projectarchitect essentieel. De projectarchitect kan mogelijkheden schetsen, waarbij de enterprisearchitect ‘het geweten’ van de organisatie is voor de lange termijn en de projectarchitect coacht binnen de gewenste richting. Het resulterende architectuurdocument is uitvoerbaar door de projectarchitect en verkoopbaar door de enterprisearchitect aan de rest van het enterprisearchitectuurteam. Concreet toepassen van de kaders maakt helder waar nog aanvulling of aanscherping moet plaatsvinden. Door hierover mondeling afspraken te maken, kan het project van start gaan terwijl parallel uitwerking van de kaders plaatsvindt. (3)
Operationeel invullen
• Binnen een project voert de projectarchitect de hoofdmoot van het architectuurwerk uit. Bij onduidelijkheden betrekt hij de enterprisearchitect voor sparring en advies. (4)
• Enterprisearchitecten nemen ook zelf initiatief om op de hoogte te blijven van de voortgang en issues binnen het project. Daarvoor zoeken zij persoonlijk contact. (5)
• Enterprisearchitecten leggen de kaders afdoende vast, zodat de projectarchitect daaraan kan refereren. (5)
• Aanscherpingen en afwijkingen van kaders neemt de enterprisearchitect mee terug om de kaders te kunnen aanvullen voor volgende projecten. (6)
• De enterprisearchitect breidt de referentiearchitectuur uit op basis van het projectresultaat, zodat deze door de tijd heen groeit, steeds vollediger wordt, maar ook blijvend meebeweegt met de veranderende koers die de organisatie volgt.(6)
• Enterprisearchitecten hebben ook buiten projecten een rol om changes in het changemanagementproces te bewaken door deze op architectuurimpact te wegen. Deze werkwijze borgt dat changes met een hoge impact in projectvorm plaatsvinden, met bijbehorende architectuuractiviteiten. (7)
Andere rollen
Samenvattend betekent dit in plaats van een top-down strategie het veel meer volgen van een middle-out strategie. Enterprisebreed de architectuur en kaders op hoofdlijnen schetsen en dit vervolgens vanuit concrete projecten inkleuren. Dit vereist een veel nauwere samenwerking tussen enterprise en projectarchitecten. De projectarchitect geeft invulling aan de architectuurkeuzen en verfijnt deze steeds verder. De enterprisearchitect heeft hierbij veel meer een coachende rol om te borgen dat deze architectuurkeuzen in lijn zijn en blijven met de strategische richting. Dit betekent ook dat een enterprisearchitect vertrouwen moet geven aan de projectarchitect om de juiste keuzen te maken. En een projectarchitect moet accepteren dat een aantal zaken initieel nog onduidelijk is en sommige keuzen nog niet gemaakt zijn. Maar dat maakt het proces wel veel efficiënter en, naar onze mening, ook leuker. Projectarchitecten zijn eerder betrokken en enterprisearchitecten kunnen de realisatiefase met een gerust hart aan de projectarchitect overlaten.
Aanbevelingen
Uiteraard is het niet mogelijk om in één dag over te gaan op deze werkwijze. Hiervoor moet geleidelijk een aantal veranderingen plaatsvinden, in zowel de werkwijze van de verschillende disciplines van architectuur als in de organisatie en haar processen zelf. Wij geven hiervoor de volgende aanbevelingen:
• Geef de enterprisearchitecten de ruimte en tijd om (deels) betrokken te blijven bij projecten. Een coachende rol (in plaats van scheidsrechter) is daarbij heel belangrijk.
• Geef de projectarchitecten de ruimte en het vertrouwen om invulling te geven aan nog onbeantwoorde stukken enterprisearchitectuur.
• Ga na welke documentatie daadwerkelijk nodig is om (project-) doelen te behalen en pas dit waar nodig aan voor specifieke situaties. Accepteer ook dat documentatie niet direct compleet is en alle antwoorden bevat. Het hoeft de voortgang niet in de weg te staan.
• Richt structurele feedbackloops in tussen de verschillende niveaus van architectuur (strategische, tactisch en operationeel) om zo enerzijds continu te kunnen leren uit de praktijk en anderzijds continu de kaders actueel te kunnen houden.
• Bekijk met regelmaat of de huidige principes, kaders en projectportfolio nog aansluiten bij de actuele wensen van de organisatie.
 
Ing. Raimond Brookman is Principal Architect bij Info Support. E-mail: Raimond.Brookman@infosupport.com
Wouter Roelofs MSc is IT-consultant bij Info Support. E-mail: Wouter.Roelofs@infosupport.com
Literatuur
Beck, Kent et al (2001). Manifesto for Agile Software Development, agilemanifesto.org
Jeffries, Ronald E. et al (2001). Extreme Programming Installed.
Hunt, Andrew & Thomas, David (1999). The Pragmatic Programmer.
Ambler, Scott W. (2004). The Object Primer: Agile Model-Driven Development with UML 2.0.
Cockburn, Alistair (2001). Agile Software Development.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag