Wie de laatste jaren op het Landelijk Architectuurcongres rondliep, was getuige van een uit elkaar groeien van twee culturen in architectenland. Het is een splitsing tussen adviseurs en trekkers, tussen stadsplanners en gebouwenontwerpers. Het lijkt erop dat de beide groepen zelfs culturele verschillen gaan vertonen en zich tegen elkaar afzetten. Het zou de beroepsgroep architecten in de digitale wereld sieren elkaar juist te versterken.
Er zijn vele architectenrollen, -titels en -profielen. De laatste jaren lijken al die soorten architecten te zijn samengestroomd in twee hoofdstromen. Aan de ene kant zijn er de architecten die de scepter voeren over de ontwikkeling van een bepaalde oplossing . Deze bonte verzameling van onder andere product-, software-, systeem- en infra-architecten duiden we aan met de verzamelterm Solution Architecten. Aan de andere kant zijn er de Enterprise Architecten, die een bredere scope hebben, en wier interesse meer ligt aan de kant van de business dan die van de 'harde' it. Beide gaan uit van hetzelfde concept van architectuur, zoals vastgelegd in de IEEE-1471 standaard (tegenwoordig ISO-42010).
De twee gemeenschappen verschillen aanzienlijk op een aantal gebieden. De invloedssfeer van de Enterprise Architecten (EA) is de hele onderneming, die van de Solution Architecten (SA) beperkt zich tot een project of product. De hoofdverantwoordelijkheid van de EA is business-it alignment; die van de SA het bedenken van een oplossing die requirements van stakeholders vervult. De omgeving waarin de EA opereert is de business, die van de SA meer de it. De hoofdtaak van de EA is kaderstellen; de SA moet een inhoudelijke autoriteit zijn. Qua houding stelt de EA zich op als management-adviseur, terwijl de SA zich als beslisser, 'chief engineer' opstelt.
Het grootste verschil lijkt te liggen in het begrip van 'waarde'. Voor een Enterprise Architect geldt de basisaanname dat 'business altijd boven techniek gaat', terwijl Solution Architecten vaak meer oog hebben voor de inherente waarde van de kwaliteit van een oplossing. Dit verschil leidt tot emotionele discussies en misverstanden. Ik heb Enterprise Architecten herhaaldelijk horen zeggen dat het woord 'Software Architect' eigenlijk een contradictio in terminis is, omdat iemand die verantwoordelijk is voor software nooit een architect kan zijn. Aan de andere kant vinden veel Solution Architecten dat Enterprise Architectuur een wazig vak is, dat weinig anders voortbrengt dan lange lijsten 'principes' die moeilijk smart gemaakt kunnen worden.
Objectief gezien vertonen Enterprise Architecten en Solution Architecten verrassend veel overeenkomsten. Beide rollen komen voor in de internationaal geaccepteerde certificering voor architecten van de Open Group , de ITAC. De Solution Architect wordt daar 'Chief/Lead Architect' genoemd. Wat opvalt is dat de lijsten met eisen waaraan de architect moet voldoen om het level 3 ITAC certificaat te behalen voor 80 procent identiek zijn – een duidelijke aanwijzing dat het grotendeels over hetzelfde vak gaat.
Het zou goed zijn als de architecten uit beide stromen meer oog hadden voor deze overlapping, in plaats van elkaars recht op de titel architect aan te vechten. Het verder uit elkaar groeien van twee architectenculturen kan niet bevorderlijk zijn voor het onderlinge begrip en het succesvol toepassen van it in organisaties. Dit geldt des te sterker in dit tijdperk van soa en cloud, waarin het onderscheid tussen enterprise-breed en solution-specifiek niet altijd even duidelijk is.
Onderscheiden van zaken als bedrijfs-, informatie en technische architectuur is vaak handig, maar mag niet leiden tot het misverstand dat de werkelijkheid zich gedraagt zoals ons bedachte model. Dat is uiteindelijk niet meer dan een hulpmiddel om de complexe werkelijkheid vereenvoudigd af te beelden. Helemaal eens met de auteur dat architecten het goede voorbeeld moeten geven en zich vooral op overlap en samenhang moeten richten in plaats van ‘het eigene’ te benadrukken.
Eltjo, wat ik mis in je artikel is de tussenlaag. Kijkend naar TOGAF (óók Open Group) dan is er ook sprake van Business Architectuur en Informatie Systeem Architectuur. Uiteraard met de daarbij horende architecten. Deze twee zijn naar mijn idee de ‘linking pin’ tussen de hoogover Enterprise Architectuur en de (technische)Solution Architectuur. Zij zijn in staat om beide talen te spreken en de requirements ‘smart’ te maken!