De Architectuur van Architectuur

De Architectuur van Architectuur door ing. F.R.L. Loth MBA, Sr. Consultant & Lead Architect

In de Wereld van de Digitale Architectuur (vrij naar Daan Rijsenbrij) vinden onstuimige ontwikkelingen plaats. Er is een nieuwe versie van DYA uitgebracht, zelfs met een infrastructuur uitbreiding nu, Archimate wordt wellicht tot een wereldwijde standaard verheven, SOA: hype of realiteit is nog steeds een discussie, tooling in allerlei soorten en maten is beschikbaar, certificering van architecten: zin of onzin? Google ICT Architectuur en je krijgt 60 pagina’s. In het Nederlands wel te verstaan. De ontwikkelingen gaan snel, het is soms moeilijk bij te benen. Of op waarde te schatten. Al die onstuimige ontwikkelingen, en de diversiteit die hieruit resulteert, maken duidelijk dat het vakgebied van Architectuur in de Digitale Wereld nog steeds bezig is naar volwassenheid te groeien. Gelukkig begint zich een trend af te tekenen dat naast de “instrumentatie” ook naar andere factoren gekeken wordt. En dat is broodnodig: er moet balans komen in het vakgebied om houvast te geven aan de “rolvervullers”, de Architecten in de Digitale Wereld. Houvast! Waar bestaat deze houvast eigenlijk uit? En zou je dat kunnen beschouwen als de architectuur van architectuur, ons vakgebied?

Toen in de jaren 90 van de vorige eeuw de eerste ICT Architecten, Informatie Architecten en Enterprise Architecten hun intrede deden in de digitale wereld waren we vooral bezig met de beschrijving. Hoe zorgen we er voor dat wat we willen bereiken op een fatsoenlijke manier vastgelegd is en dat de rationale helder is. In deze periode dachten sommige lieden dat je met architectuur bezig was als je voorschreef dat “de standaard toegelaten databases Microsoft SQLserver en Oracle” zijn. Gelukkig waren er genoeg anderen die een bredere kijk hadden. Cap Gemini introduceerde IAF, Integrated Architecture Framework, Novius kwam met haar bijdrage t.a.v. opzetten van informatiearchitectuur, en door dit soort ontwikkelingen werd helder dat ICT Architectuur beschrijvingen veel meer waren dan de ICT Standaard en een tekeningetje van een netwerk en een stel servers. Modellen en architectuurmethoden deden hun intrede, al of niet ondersteund door tooling. En in een werkveld dat nog niet uitgekristalliseerd was ontstonden allerlei “cross-overs”. Sommige tooling of software pakketten positioneerden zichzelf als Architectuur aanpak. Waar dat dus hoogstens dus een hulpmiddel en op zijn best een bepaalde implementatieaanpak van een architectuurstijl (client-server / 3-tier / Component Based / SOA, …) betrof. Hoe dan ook, de MODEL aanpak werd grootschalig omarmd, sterker nog, er is een stroming naar genoemd: Model Driven Architecture. Een foute ontwikkeling? Nee beslist niet. In de complexe wereld waarin wij leven, leveren modellen een hoge toegevoegde waarde om diezelfde complexe wereld in beeld te brengen. Modellen belichten een beperkt aantal samenhangende aspecten en zorgen ervoor dat er een notie ontstaat hoe de complexe wereld werkt. Prima dus en absoluut van belang om ICT oplossingen te realiseren. Maar maak vervolgens niet de fout te denken dat het gerealiseerde systeem een architectuur is of heeft. Dat is zoiets als het statement “het staat in de computer, dus het is waar”. Architectuurmodellen zijn modellen en geen werkelijkheid. En dat is dan ook de reden dat gerealiseerde systemen PER DEFINITIE afwijken van de verwachtingen die geschapen zijn middels diezelfde architectuurmodellen. De werkelijke wereld zit gewoon veel complexer in elkaar!

De MODELmatige benadering van de werkelijkheid is architectuur houvast nummer 1. Echter realiseer jezelf de beperkingen. Dit houvast betekent wel dat een architect moet kunnen modelleren.

www.andarr.nl Andarr • Emmalaan 21 • 3581 HN • Utrecht • Tel. 030 – 6086188

Vrij snel realiseerde een deel van de beroepsgroep zich dat de uitsluitend modelmatige benadering onvoldoende waarborg voor succes bood. Wat heb je aan een perfect (ahum?) model als dat te laat is voor degenen die het moeten realiseren? Of als de wereld intussen veranderd is? De architect doet zijn werk immers in meeste gevallen in projecten en een ding is zeker: in projecten wordt de dynamiek in en tussen bedrijven sterk gevoeld. Een statische benadering van Architectuur was dus onvoldoende, er diende ingehaakt te worden op de projectdynamiek. Sogeti heeft met de ontwikkeling van DYA belangrijk werk geleverd op dit gebied. De strategische dialoog, de project start architectuur, de architecture board, zijn wat kernbegrippen die hun intrede deden in het vakgebied. Het werd helder dat een architectuurproces net zo ingebed moest worden in bedrijven als elk ander bedrijfsproces. Een duidelijke procesmatige benadering van architectuur is noodzakelijk en het ligt voor de hand om het architectuurproces te koppelen aan b.v. een Prince2 methodiek.

Dit is uw houvast nummer 2: beschouw Architectuur als een PROCES. Zorg voor een helder proces en bijbehorende organisatie, met duidelijke rollen en verantwoordelijkheden en een goede koppeling met de projectmethodiek. En als je alleen staat als architect: zorg dan dat het in elk geval voor jou helder is hoe het moet werken en acteer er dan ook naar!

Goed. We hebben modellen (de inhoud) en we hebben een proces. Ha, we zijn klaar! Nee, niet zo snel! Er is nog meer! De wereld is complex en de (informatie)systemen die haar (moeten gaan) ondersteunen idem. Op een recente presentatie liet ik de hiernaast afgebeelde slide zien.

Vraag • Hoe zou jij onderstaande vormen ordenen?

De voor de handliggende antwoorden kwamen uiteraard vlot: op vorm, op grootte, op kleur. Pushen van het gehoor leverde geen andere antwoorden op. Toen onderstaande slide getoond werd ging er een zucht door de zaal … Grootte & Vorm, Grootte & Kleur, Kleur & Vorm, je kan zelfs op alle drie factoren ordenen.

Grootte & Vorm

Wij leven toch niet in een 1-dimensionale wereld? Dus ICT moet dan toch ook vele dimensies kennen? In dit voorbeeld is naar ordeningsprincipes gevraagd. En er zijn er drie gevonden. Je kunt ze prioriteit geven. Er ontstaan dan een getrapte ordening. Ik noem dat de Leidende (Primaire) en de Volgende (Secundaire, Tertiaire, …) Principes. Je mag principes ook zien als requirements, eisen, wensen, randvoorwaarden, stellingen of dergelijke.


Als iemand vervolgens roept: “Maar bij mijn bedrijf hebben ze al die principes uitgeschreven. Dat waren er meer dan 3000. Dat is toch niet werkbaar?”. Ha! Waren die ingedeeld in leidende en volgende principes? En dus goed geclusterd, zodat helder is wat aan wat hangt, welke relaties er zijn? Als die moeite niet wordt genomen dan ontstaat inderdaad een onwerkbaar document. Niemand is in staat om 3000 principes in het vizier te houden tijdens een project, zelfs een architect niet. Tenzij er ordening heeft plaatsgevonden. De architect kan dan snel bepalen of een afwijking van een principe erg is. Heeft een afwijking in een tertiair principe een grote afwijking tot gevolg van een De huisstijl van Andarr, dus ook dit document maakt gebruik van primair principe? Ingrijpen is dan het devies. Maakt het niet uit? Geef dan lettertype Calibri. Als Andarr volgende de ruimte! Architecten moeten hard zijn op de leidende principes en ze mogen zacht zijn op de volgende principes. Dat geeft ook ruimte aan de creativiteit van ontwerpers en bouwers. En dat is belangrijk voor het vakmanschap en motivatie van deze professionals.

week overgaat op Times Roman, is dat prima, zolang de resulterende teksten maar leesbaar zijn en er professioneel uitzien. Wat is volgens u hier het leidende principe?

Dit is uw houvast nummer 3: denk in PRINCIPES en ORDEN deze in leidende en volgende principes. Probeer het aantal leidende principes vervolgens beperkt te houden (5 a 15 principes). En wees vervolgens hard op leidende principes en zacht op volgende principes. Uw collega’s zullen u hierom waarderen!

Houvast nummer 3 is meteen de opstap naar houvast nummer 4: ATTITUDE. De architect speelt een belangrijke rol binnen ICT intensieve bedrijven (en welke bedrijfstak in Nederland is niet afhankelijk van ICT?). Van de architect verwachten we overzicht en inzicht. Het vermogen om complexiteit te reduceren, om abstractieniveaus aan te brengen. Om uitleg te geven aan verschillende groepen Stakeholders. We verwachten dat hij/zij in staat is om ruimte te creëren voor discussie, dat hij/zij ook de uitdaging aan gaat. Dat hij/zij helder krijgt welke impliciete principes gehanteerd werden in het verleden. En deze op waarde weet te schatten. Al met al moet er ultieme helderheid ontstaan over datgene wat er gerealiseerd moet worden, waar we naar toe willen met het bedrijf en wat dat dan betekent voor de ICT. Dat noemen we deftig “Business-ICT Alignment”. Een architect is beslist geen “omhooggevallen” ontwerper. Ontwerpers zijn specialisten, focussen op details, op de “wat / hoe” vraag. Zij overzien een deel en zijn vaak alleen betrokken in de ontwerpfase. Ze zijn “leverancier”. Architecten daarentegen moeten generalisten zijn, abstraherend vermogen hebben. Zij kijken vooral naar de “wat / waarom” vraag (principes!!!). Ze overzien het geheel en horen gedurende het gehele project betrokken te zijn. De architect is mede-acceptant van het systeem!! En ja, het gehele project! Rijsenbrij heeft in zijn inaugurele rede bij de Universiteit van Nijmegen het woord Architect (Architekton) herleid naar het Sanskriet. In essentie betekent architect “de eerste vormgever en leidsman bij detaillering en uitvoering van het ontwerp”.

Ooit tijdens de lunch zat een projectmanager tussen twee collega architecten. Zegt de projectmanager: “Ik weet nu precies hoe een remschijf zich moet voelen …”

Deze betekenis kan teruggebracht worden naar de kernwoorden Reguleren en Participeren. Regulerende architecten houden zich alleen bezig met “doelarchitecturen”, “hoe het hoort”, “de ICT standaard en ICT beleid”. Ze maken het ontwerp, … en storten zich dan op het volgende project. Dat is niet in de geest van Architekton. Participerende architecten zorgen OOK voor de regulatie EN maken dat de regels werkbaar worden binnen projecten. Ze leren van de projecten door


tot het einde mee te lopen en zorgen dat de regels waar nodig aangepast worden aan de praktijk. Architecten van de regulerende soort zitten nog vast in de MODEL fase en hebben vergeten dat de werkelijkheid complexer is dan de architectuur.

ATTITUDE is houvast nummer 4. Is uw attitude juist? Doet u aan participatie of aan regulatie, en zorgt u ervoor om alle Stakeholder groepen op allerlei niveaus aan te haken middels heldere en duidelijke communicatie?

4 x Houvast: Principes, Modellen, Het Proces en Attitude. De titel van dit artikel is “Architectuur van de Architectuur”. Dan vormen deze 4 houvasten kennelijk de principes van de “meta-architectuur”. Zijn dit alle vier leidende principes of is er nog een ordening? Of zijn dit volgende principes en is er nog een leidend principe?

DRIVING FORCE van ARCHITECTUUR in de DIGITALE WERELD

In de vier genoemde principes is met redelijkheid geen prioriteit in aan te brengen. En inderdaad: er is voor alle 4 principes een en hetzelfde leidende principe te definiëren en dat is het antwoord op de vraag: “wat is de driving force van architectuur in de digitale wereld?”. Deze vraag werd voor het eerst gesteld op een congres, een jaar of tien geleden. Op zoek naar de identiteit van de ICT Architect, was hoogleraar Architectuur aan de faculteit Bouwkunde van de TU Delft, Carel Weeber (bekend van het “Wilde Wonen”), uitgenodigd een verhandeling te verzorgen over architectuur. De boodschap die ik uit zijn betoog haalde was het volgende. “Bouwkundig architecten zijn bezig met de benutting van ruimte. En om dat te doen moeten zij structuren oprichten. Dat betekent dat zij altijd in gevecht zijn met de zwaartekracht: structuren als muren, vloeren, daken, etc. hebben immers de neiging in te storten als zij niet goed zijn geconstrueerd. Bouwkundig architecten zijn zelfs zo goed geworden in het bedwingen van de zwaartekracht dat zij in staat zijn om te laten lijken dat een gebouw zweeft en dat zwaartekracht afwezig is. Maar vergis je niet: je moet niet aan een bouwkundig architect vragen om een ruimtelab o.i.d. te ontwerpen: hij zal zich geen raad weten. De aanwezigheid van zwaartekracht is essentieel voor het werk van de bouwkundig architect!”. Na nog een aantal omzwervingen en voorbeelden beëindigde Weeber zijn betoog met de vraag: “Wat is de driving force in de ICT? Als u dat weet, dan weet u ook wat u moet doen”. Het bleef beklemmend stil in de zaal.

Het heeft mij persoonlijk een maand of drie gekost om het antwoord te vinden: VERANDERING. En vervolgens nog een half jaar om te valideren of dit het goede antwoord was door vele discussies te voeren. Verandering is de kracht waar we als architecten in de Digitale Wereld continu mee te maken hebben, en waar we ook mee in gevecht zijn. Veranderingen in de omgeving, de business, de mensen, de eisen, de wensen. Alles verandert continu, zoals ook het ICT vakgebied zelf continu aan verandering onderhevig is. Ons houvast, de PRINCIPES, PROCESSEN, MODELLEN en onze ATTITUDE zijn ondergeschikt aan het hoofdprincipe dat VERANDERING de driving force is in de digitale wereld.


De betekenis hiervan is dat de architect in de Digitale Wereld zich in alles wat hij/zij doet of produceert zich rekenschap moet geven van het feit dat verandering de constante is waar hij/zij mee te maken heeft. Leidende principes zijn dus het liefst het minst aan verandering onderhevig. Het architectuurproces moet liefst zo vroeg mogelijk inhaken op verandering in businessprocessen. Ziedaar het belang van de strategische dialoog, de project start architectuur. En de modellen? Die vormen een momentopname: het beschrijft hoe we de werkelijkheid hadden willen zien op een bepaald moment in het verleden, met de kennis die we toen hadden. Wat is dus de waarde van de doelarchitectuur voor 2015? Als je niet bereid bent om de rationale periodiek te evalueren is het antwoord “nihil”. Als je het doel al bereikt, dan ben je op een plek gekomen waarvan je in het verleden dacht dat je daar in de toekomst moest zijn. Echt, als u daar eenmaal bent, dan vraagt u zich vertwijfeld af wat u op die plek doet (en u kijkt verwijtend naar uw architecten). De attitude van de architect is van cruciaal belang om verandervermogen in de ICT en de ICT organisatie te brengen: een architect in de Digitale Wereld moet veranderinggezind zijn en bereid zijn om anderen mee te krijgen op het pad der verandering. Enige kennis van psychologisch/sociologische invloeden en wat verandermanagement vaardigheden moeten daarom behoren tot de bagage van elke zichzelf respecterende architect. Maar hij/zij moet vooral bereid zijn de eigen dogma’s onder ogen te durven zien en deze ter discussie durven te stellen en af te zweren. Dat vergt moed, en is dan ook de ultieme lakmoesproef voor de architect.

Ten slotte Nu je weet dat je als architect met 5 principes te maken hebt die van belang zijn voor een succesvolle architectuur -de architectuur van de architectuur- wordt je werk dan makkelijker? Nee, dat niet. Je moet opeens met veel meer aspecten rekening houden. En in plaats van dat je probeert zo min mogelijk verandering te veroorzaken -dat is immers vaak de oorzaak van verstoringen- moet je dat nu gaan faciliteren. Dat vergt wel wat “umdenken” als je daar nog niet aan toe was. Maar bedenk: het draait niet om de architectuur, maar om de “real world”. Met deze complete blik op architectuur wordt het wel leuker, want je hebt als participerend architect een groter speelveld tot je beschikking en veel meer invloed dan je je realiseert. Ga daar dan wel prudent mee om!

De tijd van regulerende architecten is voorbij, participerende architecten: welkom!!!

Frans Loth (45) is sinds 1986 actief in de IT en heeft vele rollen vervuld bij een groot aantal bedrijven. Als architect is hij, met tussenpozen, nu ruim 10 jaar actief. In zijn zoektocht naar het antwoord op de vraag hoe architecten werkelijke toegevoegde waarde kunnen bieden is dit essay zijn voorlopige antwoord. Ook dit kan namelijk veranderen!


De Architectuur van Architectuur

Recommend Documents