0 comments
Enterprise Architecture 
IT-architecten zijn er in verschillende soorten en maten. Het belangrijkste onderscheid is ongetwijfeld die tussen de enterprise architect en de solution architect. De kloof tussen deze twee groepen is de laatste jaren groter geworden, doordat de bedrijfsprocessen en IT-systemen van tegenwoordig vragen om een pragmatischere aanpak en kortere horizon. Een solution architect die te maken heeft met sprints van twee weken riskeert dat hij of zij vergeet om naar het grote plaatje te kijken.
Precies daarin schuilt ook een gevaar, want dat grote plaatje mag nooit uit het oog worden verloren. Om de kloof te overbruggen, is er een handreiking nodig van beide partijen.
Twee werelden
Grof gezegd (en, toegegeven, enigszins gechargeerd) bestaan er binnen grote bedrijven twee soorten IT-architecten:
- Enterprise architecten bekijken architectuur vanuit een strategische bril. Ze hebben niet noodzakelijkerwijs een technische achtergrond, richten zich vooral op de lange termijn en hebben als doel om de architectuur in lijn te brengen met het doel van de organisatie. Ze denken vooral in roadmaps en schetsen een toekomstbeeld.
- Solution architecten zijn vooral bezig met projecten in het hier en nu. Hun horizon beperkt zich vooral tot de volgende milestone; wat moeten we dan opleveren? Ze zijn meer pragmatisch ingesteld en kijken naar de architectuur van de solution en niet zozeer naar de enterprise als geheel.
Het belang van IT-architectuur stamt eigenlijk al uit het client-server-tijdperk. Door de decentralisatie van IT ontstonden er op verschillende plaatsen in de organisatie losse systemen en databases. De samenhang tussen deze verschillende omgevingen werd te complex om te overzien.
Het vak van enterprise architect ontstond vanuit de discipline van informatie-architectuur. De vraag die centraal stond is: hoe beheren we de informatie binnen onze organisatie en hoe zorgen we ervoor dat de kwaliteit van de informatie op peil blijft? De enterprise architect had ook een governance-rol: het bewaken van de complexiteit van de IT-architectuur. Als er wildgroei dreigt te ontstaan aan solution en databases, dan is er iemand nodig die deze ontwikkeling in goede banen kan leiden.
Het vak van solution architectuur ontstond doordat ook de individuele IT-systemen steeds groter en complexer werden. Om er zeker van te zijn dat systemen flexibel genoeg waren en onderhouden konden worden, bleek het steeds meer nodig te zijn dat iemand overzicht hield over alle functionele onderdelen van het systeem, inclusief een consistente en modulaire manier van opbouw van de software.
In dat licht is het misschien niet vreemd dat enterprise architecten van oudsher sterk zijn gericht op de beleidsmatige kant van architectuur; als we ervoor zorgen dat er goede regels zijn waar iedereen zich aan moet houden, dan kunnen we nieuwe systemen daaraan toetsen. Het onbedoelde gevolg was echter dat enterprise architecten nogal eens werden gezien als “slagboomarchitecten”; als een nieuw idee niet paste binnen het beleid, dan werd er al gauw ‘nee’ verkocht.
Verschuiving
De laatste jaren heeft er een verschuiving plaatsgevonden. Allereerst is de horizon van zowel de enterprise als de solution architect een stuk korter geworden. Waar enterprise architecten vroeger het liefst vijf jaar vooruitkeken, is het tegenwoordig een stuk ingekort tot hooguit een jaar of twee. Veel verder in de toekomst kijken heeft weinig zin, omdat er zoveel verandert in zo’n rap tempo.
Solution architecten leefden vroeger toe naar het eerstvolgende releasemoment, die hooguit nog een half jaar weg was. Door de agile manier van werken en continuous delivery is die horizon aanzienlijk verkort, naar de volgende release die binnen nu en twee weken plaatsvindt.
Deze nieuwe werkelijkheid heeft ervoor gezorgd dat de enterprise architect het lastiger heeft gekregen om zijn oorspronkelijke taak te realiseren. Waar hij vroeger nog tijd genoeg had om een roadmap op te tekenen, een projectplanning op te stellen en de board daarvan te overtuigen, wordt dit proces tegenwoordig al gauw ingehaald door de werkelijkheid. Tegen de tijd dat plannen zo ver zijn uitgewerkt dat ze in de praktijk kunnen worden toegepast, bestaat het systeem wellicht al niet eens meer.
Bestaansrecht
Een conclusie die hieruit zou kunnen worden getrokken is dat de enterprise architect geen bestaansrecht meer heeft. Waarom zou je nog een strategisch architect benoemen die kijkt naar de lange termijn, als de focus steeds meer op de korte termijn ligt?
Het paradoxale is dat er juist eigenlijk meer dan ooit behoefte is aan een dergelijke rol. Neem als voorbeeld een gemiddelde grote bank, waar al gauw honderden verschillende systemen in de lucht worden gehouden door honderd verschillende teams. Het is voor deze teams niet te doen om alles op elkaar af te stemmen. Toch is het van wezenlijk belang dat de grote lijnen onderling worden afgesproken en dat systemen op de juiste manier op elkaar worden afgestemd.
Solution architect wordt meer enterprise, enterprise wordt stakeholder
Om in deze nieuwe situatie optimaal te kunnen functioneren, moeten beide soorten architecten hun rol anders vervullen. Enterprise architecten moeten binnen teams meer als stakeholders opereren. Waar ze vroeger sturing vooraf gaven en bepaalden hoe systemen moesten worden ingericht, moeten ze nu meer denken vanuit de doelstellingen van de organisatie; wat willen we bereiken en hoe kunnen de individuele teams hier relatief autonoom invulling aan laten geven? Enterprise architecten sturen minder, maar zijn er vooral om solution architecten te informeren en te coachen om de juiste keuzes te maken.
Ook als solution architect kun je niet meer acteren op een eiland. Je moet nadenken over de samenhang met de rest van de enterprise.
Zeker met microservices architecturen die nu steeds meer in opkomst zijn is het ondenkbaar dat je als solution architect alleen kijkt naar je eigen stukje; je moet het totale plaatje kunnen zien en je er bewust van zijn welke schakel je in dat geheel vervult. Het gaat tenslotte om de hele ketting van systemen om de eindklant een optimale dienstverlening te kunnen bieden.
Samenwerken met een enterprise architect is daarbij van wezenlijk belang. Stel dat iemand aan je team vraagt om een nieuwe feature te ontwikkelen, dan is het wel zo slim om met een enterprise architect te checken of deze wellicht al ergens anders in de organisatie is gebouwd.
Twee groepen, één doel
Welke achtergrond of focus je ook hebt, het is belangrijk om je te realiseren dat alle architecten uiteindelijk hetzelfde doel dienen en dat is het doel van de organisatie als geheel. Voor solution architecten betekent dat dat ze er baat bij hebben om nauw samen te werken met enterprise architecten om te voorkomen dat er iets wordt ontwikkeld wat al aanwezig is of wat juist niet aansluit bij andere omgevingen. Je moet een goed beeld hebben van het totale bedrijfsproces en de rol die jouw bijdrage daarin speelt.
Dat betekent dat je als solution architect verder vooruit moet kijken dan één of twee sprints. Ook is het belangrijk om na te denken over toekomstige scenario’s; als we over een aantal sprints een vraag krijgen voor een bepaalde functionaliteit, past die dan nog binnen de architectuur?
Wat voor soort architect je ook bent, uiteindelijk zijn we samen niet alleen verantwoordelijk voor het succes van ons eigen team, maar voor dat van de gehele organisatie.
Bovenstaand artikel is ook verschenen in twee delen in agconnect en het onderwerp is daarbij nog meer uitgediept.
In deel 1 wordt de vraag bekeken of een enterprise architect nog wel nodig is. In deel 2 worden ook tips gegeven hoe de kloof te overbruggen.