Architect moet kunnen ontwerpen & ontwikkelen

Architectuur wordt te veel opgevat als een project en te weinig als een doorlopend programma, als een continu proces. Jaap Schekkerman stelt in de Automatisering Gids van 4 november 2005 terecht dat dit een belangrijke reden is voor het ontbreken van succesvolle implementaties van enterprise-architectuur. Wanneer architectuur als project wordt opgevat, dan wordt impliciet gewerkt volgens de stappen die gebruikt worden bij het ontwerpen. Er wordt dan met een groep experts gewerkt aan een oplossing die in één keer gerealiseerd kan worden (zie kader). Met deze werkwijze is niets mis, als het om materiële zaken gaat, zoals software en infrastructuur. In de context van ICT-projecten kan de architect heel goed de rol spelen van expert, die achter de tekentafel oplossingen voor technische problemen ontwerpt. Voor de helderheid: die rol is moeilijk genoeg en heeft binnen projecten beslist toegevoegde waarde. De moeilijkheid doet zich vooral voor bij een enterprise-architectuur. Wanneer het realiseren van zo’n architectuur wordt opgevat als het realiseren van organisatieveranderingen, dan zal de enterprise-architect de ontwikkelingsbenadering moeten beheersen. Deze vereist dat de architect de rol van procesbegeleider op zich neemt. De architect moet in staat zijn om samen met de belanghebbenden in de organisatie (de business) op zoek te gaan naar oplossingen en naar draagvlak voor die oplossing. ‘Validatie’ van de oplossing vindt plaats door middel van een proces van interactie en wederzijdse beïnvloeding, dat zorgt voor draagvlak en acceptatie bij de belanghebbenden. Een ontwikkeling wordt per definitie in meerdere iteraties gerealiseerd. Dat betekent, dat de enterprise-architect in staat moet zijn cyclisch te denken. Hij moet dus in staat zijn zijn doelen (tijdelijk) bij te stellen: er is namelijk niet één weg naar de beste oplossing, die koste wat kost gerealiseerd moet worden. Een enterprise-architect hoeft niet per se goed te kunnen analyseren of specialistische ICT-kennis te hebben. Hij moet vooral omgevingsbewust zijn (kansen en bedreigingen zien en daarop kunnen acteren, zonder daarbij sturing nodig te hebben) en in staat zijn mensen te beïnvloeden. Flexibiliteit en creativiteit en het vermogen mensen samen te brengen zijn daarbij van groot belang. Dit proces speelt zich voor het grootste gedeelte af buiten de ICT-afdeling. De enterprise-architect moet daarom niet alleen verstand hebben van ICT, maar ook van de producten, de processen en de mensen in de organisatie en de manier waarop deze het beste ondersteund kunnen worden met ICT. Dat betekent dat de architect ook een beeld moet hebben van de best practices en de nieuwe ontwikkelingen in de branch. Het is uiterst belangrijk voor de enterprise-architect te weten of een oplossing voldoende uitgekristalliseerd is en of die oplossing voldoende draagvlak heeft (zie kader). Daarvoor is een goed gevoel voor verhoudingen vereist, maar ook de nodige ontwerpkennis. De vraag is namelijk niet alleen of de oplossing voldoende gedragen wordt door de belanghebbenden, maar ook of de oplossing maakbaar is. Wanneer dat niet zo is, moet eerst meer tijd worden besteed aan het vinden van coalities die de geaccepteerde oplossingen verder uitwerken. De kans dat één persoon zowel de expert is die een ontwerptraject kan uitvoeren, als de procesbegeleider die een ontwikkelingstraject binnen de business kan begeleiden, is erg klein. In de praktijk zal een multidisciplinair team nodig zijn. Dit team moet in staat zijn ontwerpen te maken van voldoende (technisch) niveau én in staat zijn de business te begeleiden bij het zoeken naar en het iteratief realiseren van de organisatieveranderingen die in de enterprise-architectuur worden beschreven. Dit is, zoals Jos Vrancken in de Automatisering Gids van 11 november 2005 stelt, een virtuoze balanceer-act. Ontwikkelen is daarbij net zo belangrijk als ontwerpen: zij zijn afhankelijk van elkaar en kunnen elkaar aanzienlijk versterken. Alleen met een team architecten dat beide kan, zal een architectuur de organisatie de beloofde toegevoegde waarde bieden. Drs. Ria van Rijn is senior-informatiearchitect bij de divisie Architectuur & Business Solutions van Sogeti Nederland BV.Competenties architecten Het is belangrijk dat een architect zowel het ontwerpen als het ontwikkelen beheerst. Het ‘ontwerpen’ van veranderingen wordt typisch toegepast bij materiële objecten, zoals software of onderdelen van de infrastructuur. De ontwerper is een expert die in een klein team de oplossing uitwerkt. In de eerste fase wordt in overleg met de opdrachtgever vastgesteld om welk probleem het precies gaat. Dit probleem wordt in detail geanalyseerd. Aan de hand van deze analyse worden tevens de specificaties (randvoorwaarden, eisen en wensen) voor de oplossing vastgesteld. Daarna volgt een aantal iteraties waarin het ontwerp gemaakt wordt. Het ontwerp bestaat uit het ontwerp van het object zelf en uit het ontwerp van de manier waarop het object gerealiseerd moet worden. Na iedere iteratie wordt beoordeeld of beide ontwerpen voldoen aan de specificaties, die eraan zijn gesteld. Voor het beoordelen van het ontwerp worden validatietechnieken gebruikt, zoals simulaties, doorrekenen of testen, om vast te stellen of de oplossing goed is en aan de specificaties voldoet. Ook dit gebeurt weer door experts. Als het ontwerp is goedgekeurd wordt het uitgevoerd. Dit kan een complexe aangelegenheid zijn. Hoe complex het ook is: de stappen in de uitvoering in een ontwerptraject zijn sequentieel, niet iteratief. Wanneer er mensen moeten veranderen met al hun meningen, ervaringen, angsten en verwachtingen, is ‘ontwikkelen’ nodig. De ontwikkelaar is vooral een procesbegeleider. De ontwikkelaar moet zich allereerst inleven in de organisatie en haar probleem. Hij moet begrijpen wat er aan de hand is, waar belanghebbenden het over hebben en wat dµe mogelijkheden van de organisatie zijn. Samen met de belanghebbenden wordt dan uit de hele kluwen van symptomen en mogelijke oplossingen, een specifieke aanpak gekozen, bijvoorbeeld: we gaan architectuur inzetten om de IT-ontwikkelingskosten te verlagen. Vervolgens wordt vastgesteld binnen welke randvoorwaarden of grenzen de oplossing tot stand moet komen en aan welke eisen de oplossing moet voldoen. Daarna wordt de oplossing verder uitgewerkt. Om gefaseerd van de huidige naar de beoogde eindsituatie te komen wordt een ontwikkelingsplan opgesteld. Dit plan wordt in een aantal iteraties gerealiseerd. Dat gebeurt altijd iteratief, omdat zowel de gewenste eindsituatie als de weg waarlangs die bereikt moet worden, pas goed begrepen en uitgewerkt kunnen worden in een proces van interactie tussen en wederzijdse beïnvloeding van de belanghebbenden. Na iedere fase of stap die gerealiseerd is, worden het resultaat en de werkwijze geëvalueerd. Op grond van de evaluatie wordt zo nodig het plan bijgesteld en wordt weer een volgend onderdeel van het plan gerealiseerd. Dit gaat net zolang door, totdat de belanghebbenden oordelen, dat de huidige situatie overeenkomt met de beoogde situatie. Tijdens alle fasen van een ontwikkelingstraject maar ook daarna, als de toegevoegde waarde van de oplossing beoordeeld wordt, speelt interactie en wederzijdse beïnvloeding een belangrijke rol. Dit is de enige vorm van validatie die in een ontwikkelingstraject kan plaatsvinden. Er zijn altijd omstandigheden, waaronder het moeilijk, zo niet onmogelijk is om met een architectuur tot een goede oplossing van organisatieproblemen te komen. Een enterprise-architect moet kunnen inschatten of een goede oplossing haalbaar en maakbaar is. Als er sprake is van een of meer van de volgende omstandigheden, dan is het niet mogelijk om via ontwerpen of ontwikkelen tot een goede oplossing te komen: • Ambigue vraagstukken. • Slecht te definiëren problemen. • Instabiele situaties. • Onvoorspelbare interactie. Een organisatie zal in deze situatie eerst verandering moeten brengen. Pas daarna heeft het zin om een ontwerp te maken of een gezamenlijke ontwikkeling naar een oplossing door te maken. Als men ondanks de onduidelijkheid en onvoorspelbaarheid toch begint aan het ontwerpen of ontwikkelen van een oplossing, dan is die oplossing gedoemd te mislukken.