Architectuur in acht praktische richtlijnen

Een groeiend aantal mensen in de ict draagt de titel 'architect'. Deze architecten kunnen beschikken over bibliotheken vol vakliteratuur, zowel over de inhoud als het proces van hun werk. Ze kunnen bovendien kiezen uit talloze frameworks, van Zachman tot DYA tot Togaf. Als je deze frameworks goed bestudeert zie je daarin vier aspecten van architectuur nagenoeg overal terugkomen

De vier praktische aspecten van architectuur lijken de belangrijkste succesfactoren van het vakgebied. Ze blijken zelfs veel belangrijker dan willekeurig welk inhoudelijk of procesmatig aspect van welk architectuur-framework dan ook. Ze luiden alsvolgt:
– Business requirements vormen het uitgangspunt;
-Het framework is een middel en nooit een doel op zich;
– Hetzelfde framework moet door alle betrokkenen op eenzelfde wijze worden gebruikt;
–  Een framework hoeft niet per se direct en volledig te worden ingevuld: je kunt met een paar onderdelen beginnen en die eventueel uitbreiden met andere elementen.

Vier aspecten, vier klassieke valkuilen

We weten dat de toepassing van architectuur-frameworks in -grotere- organisaties vaak slechts beperkt succesvol is. De redenen daarvoor lijken vaak direct gerelateerd aan de genoemde aspecten. We belichten ze nader:

Business requirements
In de praktijk gebeurt het vaak dat de toepassing van een architectuur-framework zich beperkt tot een ict-afdeling, of zelfs maar een deel daarvan. Business-requirements en business-processen, en niet ict-requirements, vormen echter het uitgangspunt van het framework. Een architectuurproces dat dus op deze beperkte wijze en niet volgens business-requirements wordt toegepast mist een wezenlijk uitgangspunt van het werken onder architectuur.

Hetzelfde probleem ontstaat wanneer verschillende bedrijfsonderdelen verschillende frameworks hanteren. Architectuur-frameworks zijn in het algemeen ontwikkeld om binnen de gehele organisatie te worden toegepast, dus binnen alle onderdelen van die organisatie. Een framework kan daarom alleen volledig succesvol zijn indien het binnen de organisatie als geheel wordt toegepast. In werkelijkheid hanteren verschillende bedrijfsonderdelen zelden hetzelfde framework. Bedrijfsonderdelen werken vaak met hun eigen leveranciers en die hebben allemaal hun eigen voorkeuren. In sommige gevallen hanteren bedrijfsonderdelen zelfs helemaal geen framework.

Je kunt je eenvoudig voorstellen dat deze realiteit de mate waarin de toepassing van een framework succesvol kan zijn in hoge mate beperkt.

Architectuur als doel op zich
Een andere valkuil is dat architecten zich soms onvoldoende verplaatsen in de realiteit van een organisatie. Vaak worden vanuit architectuurvoorschriften opgesteld die niet uitvoerbaar zijn, omdat ze geen rekening houden met beschikbare tijd, beschikbare resources of met onvoorziene details.

Het gevaar bestaat daarmee dat architectuur een bureaucratisch proces wordt dat bijvoorbeeld letterlijk de processtappen van een framework volgt. Het framework wordt gehanteerd als ‘stempelkaart': voordat je een verandering mag doorvoeren moet je eerst een stempeltje halen. Op die wijze wordt een framework een ‘disabler' voor veranderingen in plaats van een ‘enabler'.

Het werkelijke doel van de organisatie, en indirect dus ook dat van het gebruik van architectuur, is daarom nooit het volgen van een vastomlijnd proces of het opleveren van vastomlijnde artefacten. De werkelijke doelen zijn doelen als kostenverlaging, inspelen op veranderingen, martkaandeel vergroten. Kortom: de werkelijke doelen zijn business-doelen.

Eenduidige invulling
In de meeste grotere organisaties heerst de hardnekkige misvatting dat applicaties en ict-infrastructuur los van elkaar bestuurd kunnen worden. Applicatie-ontwikkeling en pakketselectie vinden bijvoorbeeld veelal plaats dichtbij of binnen ‘de business', terwijl hosting en telecommunicatie steevast zijn ondergebracht in een aparte ict-afdeling.

Door deze tweedeling bestaat er vrijwel automatisch een heterogene invulling van architectuur, namelijk applicatie-architectuur enerzijds en infrastructuur-architectuur anderzijds.

Hierdoor ontstaat een gebrek aan afstemming tussen bedrijfsapplicaties enerzijds en de infrastructuur waarop deze applicaties moeten draaien anderzijds. Het gevolg is dat stabiliteit, beschikbaarheid, schaalbaarheid, wijzigbaarheid en beveiliging van de applicaties niet altijd kunnen voldoen aan de verwachtingen en eisen van ‘de business'.

We zien bijvoorbeeld dat steeds meer organisaties ervoor kiezen om infrastructuur onder te brengen in ‘de cloud'. Wanneer bestaande bedrijfsapplicaties echter zonder enige aanpassing worden verhuisd naar een cloud-infrastructuur, heeft dit gevolgen voor non-functionele eigenschappen zoals veiligheid, stabiliteit of beschikbaarheid van die applicaties. De aanpassingen die nodig zijn om een applicatie vanuit de cloud aan te bieden worden in veel gevallen niet uitgevoerd.

Volledige invulling
De vraag in hoeverre een framework bruikbaar is voor een organisatie, of voor een deel daarvan, is in hoge mate afhankelijk van de context. De volgende aspecten spelen een belangrijke rol:
• Hoe gaat de organisatie om met requirements, functioneel ontwerp, pakketselectie, hosting en beheer van informatiesystemen?
• Welke activiteiten in de waardeketen van informatiesystemen worden gecombineerd uitgevoerd, en welke gescheiden of in verschillende afdelingen?
• Welke afdelingen maken gebruik van het framework en welke niet?
• Op welke wijze werken de afdelingen die van het framework gebruikmaken?

Afhankelijk van de antwoorden op deze en vergelijkbare vragen is in nagenoeg alle gevallen slechts een deel van een framework toepasbaar. Een afdeling die zich bijvoorbeeld bezighoudt met het beschrijven en ontwerpen van bedrijfsprocessen, zou zich niet bezig moeten houden met de onderdelen van het framework die bedoeld zijn voor het beschrijven van infrastructuur, en andersom

Toch worden frameworks in de praktijk vaak in hun geheel toegepast. Ze worden niet aangepast aan de context van de organisatie of de afdeling. Het gevolg is dat ze hun doel voorbijschieten en dat ze bovendien een blok aan het been van de architect zijn.

Acht praktische richtlijnen

We zien dus dat ict-architectuur vier cruciale valkuilen bevat waar architecten toch regelmatig instappen. Hoe kunnen we architectuur dan wel succesvol toepassen?

De volgende richtlijnen bieden een handreiking om architectuur succesvol toe te passen. Het zijn praktische richtlijnen die zijn gebaseerd op de ervaringen van i-to-i bij het toepassen van succesvolle architectuurprojecten bij onze klanten. Ze staan los van welk framework dan ook en daardoor in iedere situatie toepasbaar.

1. Context, context, context
Het allerbelangrijkste gereedschap in de koffer van de architect is het bewustzijn van de organisatorische context. Deze context blijkt in alle situaties belangrijker dan welk framework of proces dan ook. Een framework is een model, en moet daarom juist aan de unieke context en omgeving van de organisatie worden aangepast. Alleen dan kun je het succesvol maken. In de praktijk betekent dit dat je grote delen van een framework best terzijde kunt schuiven en alleen die onderdelen kunt toepassen die bijdragen aan de context van de organisatie.

Het belang van de context is terug te vinden in alle overige richtlijnen.

2. Wees bewust van het draagvlak
Vanzelfsprekend staan bij het invoeren van een architectuur-framework de business requirements centraal. Als architect zal je daarom bij de juiste mensen de juiste vragen moeten stellen om deze requirements boven water krijgen. Hierdoor krijg je een beeld van het kader waarin je je werkzaamheden gaat uitvoeren.

In veel gevallen wordt architectuur echter niet op enterprise- of business-niveau bedreven, maar bijvoorbeeld alleen binnen een ict-afdeling. Dat maakt het onmogelijk om een framework te gebruiken dat uitgaat van enterprise- of business architectuur. Er zijn aanpassingen nodig om het framework succesvol te kunnen toepassen.

Het is dus voor een architect van wezenlijk belang om het draagvlak voor het werken onder architectuur te kennen. Is dat draagvlak er slechts gedeeltelijk, of wordt het niet door de hele organisatie gedragen, dan kan een framework enkel dienen als impliciet gereedschap. De architect moet in dat geval de vastomlijnde artefacten en processtappen alleen voor zijn eigen denkproces gebruiken. Als het draagvlak klein is, zullen expliciete verwijzingen naar een framework meestal een averechts effect hebben. Maar wanneer je de resultaten van een impliciet gebruikt framework zichtbaar kunt maken, kan dat eraan bijdragen dat je een groter draagvlak voor architectuur verkrijgt.

3. Vier domeinen, vier snijvlakken
We zien binnen de ict grofweg vier snijvlakken tussen vier domeinen:
1) Het snijvlak tussen het business-domein en het applicatiedomein;
2) Het snijvlak tussen het applicatiedomein en het infrastructuurdomein;
3) Het snijvlak tussen het infrastructuurdomein en het exploitatiedomein;
4) Het snijvlak tussen het exploitatiedomein en het business-domein.

Bij het business-domein worden impliciet of expliciet requirements geformuleerd.

Binnen het applicatiedomein vindt applicatie-ontwikkeling en/of pakketselectie plaats. Het infrastructuurdomein houdt zich bezig met interne en externe hosting.

Het exploitatiedomein verzorgt het beheer van ict-oplossingen en heeft over het algemeen service level agreements met het business-domein.

In veel organisaties bestaat er dus een scheiding tussen het business- en applicatie domein enerzijds en het infrastructuur- en exploitatie domein anderzijds. Een architect moet zich bewust zijn van deze vier snijvlakken, ongeacht in welk domein hij werkzaam is. Zijn taak bestaat er nagenoeg altijd uit om voor afstemming te zorgen op tenminste één van deze snijvlakken.

4. De kracht van de eenvoud
Een architect is een vertaler, een bemiddelaar, die opereert op het snijvlak van techniek en mensen, van business en ict, van bouw en beheer. Op al deze snijvlakken heeft hij bovendien te maken met een groot aantal belanghebbenden, zowel binnen als van buiten de organisatie. Al deze partijen hebben hun eigen taal en hun eigen belangen, van politiek tot commercieel en alles daartussenin.

Het begint vaak bij de vraag wie ‘de business' is. Vaak zijn de echte business stakeholders verborgen achter één of meer lagen van ict-stakeholders zoals applicatie-ontwikkelaars of functioneel ontwerpers. Als architect is het belangrijk om dit te onderkennen, en te weten wie de daadwerkelijke business stakeholders zijn. Alleen zij kennen de daadwerkelijke ‘business requirements'. Pas als het duidelijk is wat de echte business requirements zijn, kun je een helder onderscheid maken tussen deze requirements en andere belangen zoals bijvoorbeeld ict-belangen.

Bovendien hanteert elke groep belanghebbenden doorgaans een eigen ‘dialect': jargon, normen en waarden en non-verbale communicatie. De architect moet de verschillende culturen, dialecten en belangen kennen om zijn werk optimaal te kunnen doen.

Het is onze ervaring dat het nuttig is om het abstractie- en detailniveau van je communicatie aan te passen aan de stakeholder. Hoe meer je op het niveau van exploitatie communiceert, hoe meer details. En hoe dichter je bij de business komt, hoe abstracter je communicatie kan zijn.

In alle gevallen gelden er drie basisregels, namelijk:
1) Laat iedereen in zijn waarde;
2) Stem je communicatie af op je doelgroep;
3) Houd het zo eenvoudig mogelijk.

5. Wees open en integer
Voor een architect is het van groot belang om open te communiceren, transparantie te betrachten en daarmee duidelijkheid te verschaffen voor alle betrokkenen. Dit uiteraard binnen de grenzen van eventuele geheimhoudingsplicht.

Een architect heeft opereert binnen diverse geledingen van een organisatie en heeft daardoor bij uitstek de positie om belanghebbenden te betrekken bij veranderingen en ze daarvoor te motiveren. Dat kan alleen wanneer je daadwerkelijk openheid van zaken geeft en integriteit en authenticiteit uitstraalt.

Deze wijze van werken heeft twee bijkomende voordelen. Je bent namelijk minder vatbaar voor politieke intriges en bovendien bouw je een goede reputatie en een breed draagvlak op. En daarmee vergroot je automatisch je invloed op de organisatie.

6. Samenwerken
Uiteindelijk zijn de veranderingen die je als architect probeert te realiseren mensenwerk. En met welke taak of opdracht je ook belast bent, de kans is gering dat je die alleen kunt vervullen. Het is dan ook zaak om zorgvuldig de mensen uit te zoeken met wie je kunt samenwerken om de beste resultaten te behalen. De kwaliteit van de mensen die je om je heen verzamelt is daarbij veel belangrijker dan het aantal mensen.

Meestal werk je als architect samen met zowel opdrachtgevers als leveranciers. Idealiter zijn contracten en afgesproken procedures daarbij richtinggevend en sturend, maar niet al te beperkend en bureaucratisch. Vaste afspraken en protocollen beperken de flexibiliteit die nodig is om in de realiteit van alle dag succesvol te zijn en de gewenste veranderingen door te voeren. Soms heb je als architect invloed op leverancierselectie en contractsamenstelling. Gebruik deze invloed dan om een leverancier te kiezen en een contract na te streven waarbij samenwerking en werken in teamverband een essentiële rol spelen. Probeer bij leveranciers te werken met vaste contactpersonen.

Gebruik de mensen met wie je samenwerkt als klankbord. Bied jezelf bovendien ook aan als klankbord: vul elkaar op die manier aan, maar zonder dat op te dringen.

Wanneer je de mensen om je heen daadwerkelijk kent, kan je gemakkelijker met ze communiceren en samenwerken. Probeer bij voorkeur op dezelfde plek te werken en vermijd waar mogelijk conference calls of andere niet-persoonlijke communicatie. Want bij echte afspraken, waar je elkaar kunt zien, schep je eerder een band, voel je elkaar beter aan en communiceer je uiteindelijk efficiënter.

Respecteer je collega's en laat niet na je waardering te laten blijken wanneer dat verdiend is. Een compliment is gemakkelijk te geven, en levert enorm veel goodwill op.

7. Wees flexibel
Een veelgehoorde klacht over architecten is dat zij zich autoritair opstellen. Dat ze zich boven anderen verheven voelen en vanuit hun ‘ivoren toren' starre richtlijnen uitvaardigen waaraan de rest van de organisatie zich dient te houden.

In werkelijkheid ben je je als architect juist bewust van de praktische haalbaarheid van architectuur-richtlijnen. Je weet er dus ook flexibel mee om te gaan. Al was het alleen maar om het stigma van de ‘ivoren-toren-architect' te ontlopen. Want een dergelijke reputatie is dodelijk voor de effectiviteit van de architect in een organisatie.

Architectuur, en de bijkomende richtlijnen, zijn nooit een doel op zich. Architectuur dient altijd hogere doelstellingen, meestal bedrijfsdoelstellingen. Het moet daarom altijd mogelijk zijn van de richtlijnen af te wijken, als daarmee de bedrijfsdoelstellingen beter gediend zijn. Wees je bewust van deze verantwoordelijkheid. Een architect die vasthoud aan architectuur om reden van de architectuur zelf is een bureaucraat in wording!

Wees dus faciliterend, niet manipulerend. Wees praktisch, niet star.

8. Begin klein, wees realistisch
Als architect heb je vaak te maken met complexiteit, bureaucratie en traagheid. Dit maakt je taak, het reduceren van complexiteit en het werken onder architectuur, vaak enorm groot. Je ondervindt altijd weerstand als je probeert bepaalde zaken te veranderen. Sommige van die veranderingen zijn feitelijk cultuuromslagen voor de organisatie. En cultuuromslagen vergen tijd… en kleine stapjes. 'Een olifant eet je in kleine hapjes op', luidt het spreekwoord niet voor niets. Probeer daarom niet teveel veranderingen tegelijk te realiseren. Creëer draagvlak door behaalde successen te vieren, hoe klein ook. Zorg voor positieve ruchtbaarheid. Dit soort ‘exposure' creëert draagvlak en zorgt voor navolging. Bovendien zullen de volgende veranderingen steeds gemakkelijker te realiseren zijn. Je maakt je taak daarmee zowel voor jezelf als voor je opdrachtgever eenvoudiger, en dat is precies wat we willen.

Conclusie

Als je de literatuur rond ict-architectuur-frameworks bestudeert, zie je vier aspecten telkens terugkeren: business requirements vormen het uitgangspunt, het framework is een middel en nooit een doel, hetzelfde framework moet door alle betrokkenen op eenzelfde wijze worden gebruikt, en een framework hoeft niet per se direct en volledig te worden ingevuld.

Ondanks dat de verschillende aspecten duidelijk en veelvuldig zijn beschreven, zien we dat de toepassing van architectuur-frameworks in grote organisaties slechts beperkt succesvol is. Het lijkt erop of de manier waarop de architect te werk gaat van essentieel belang is voor een succesvolle toepassing van architectuur in de organisatie. In dit artikel belichten we acht richtlijnen die van doorslaggevende betekenis kunnen zijn in het succes van architectuur: de context waarin je je werk doet is van wezenlijk belang, wees je bewust van het draagvlak in de organisatie, onderken de domeinen en de snijvlakken in de organisatie, communiceer zo eenvoudig mogelijk en stem je communicatie af op de doelgroep, wees open en integer, werk samen, wees flexibel, en ten slotte: wees realistisch en begin klein.

De architect die deze richtlijnen in acht neemt vergroot zijn invloed en zijn geloofwaardigheid, met als resultaat dat hij met dezelfde inspanningen meer waarde aan de organisatie kan toevoegen. Het proberen waard!