Wouter Schmitz, chief architect ABN AMRO

Daan Rijsenbrij, woensdag 17 juni 2009

Wouter Schmitz geeft leiding aan een groep van 17 business- en enterprisearchitecten. Deze groep vormt het ‘Center of Expertise’ voor architectuur bij het gedeelte van ABN AMRO dat in handen is van de Nederlandse staat. Wouter is met zijn team eigenaar van de architectuurmethode en tooling. Tevens supervideert hij de totale architectuurcommunity van alle architecten binnen ABN AMRO.
Wouter is verantwoordelijk voor het uitvoeren van de architectuurgovernance binnen de ABN AMRO. Voorts ligt bij hem het beheer van de architectuurkennis en de Current State Architecture, een diepgaand systeemoverzicht van de ABN AMRO organisatie.

In 2004 / 2005 heeft Wouter naast businessarchitectuurwerk in diverse domeinen, bijgedragen aan een multi-channel BPM-architectuur, waarvoor hij momenteel een patentaanvraag heeft lopen. In 2006 is Wouter leiding gaan geven aan een groep enterprisearchitecten bij ABN AMRO. Hij heeft de groep uitgebreid en het architectuurportfoliomanagement geprofessionaliseerd. Samenwerking met de businessarchitecten leidde tot een samenvoeging van beide groepen. Wouter heeft daarbij een werkmodel ingevoerd dat tegenwoordig geldt als een voorbeeld voor hoe een ‘Center of Expertise’ binnen de bank moet worden ingericht.

Daan: “Hoe wordt architectuur formeel gedefinieerd binnen ABN AMRO? Zijn er aangepaste definities voor de verschillende stakeholders?”

Wouter: “Er is slechts één formele definitie van architectuur, die niet afhangt van de verschillende stakeholders. Deze definitie valt uiteen in een formele beschrijving van missie, visie, en aanpak.

Missie: Architectuur creëert waarde voor ABN AMRO door te assisteren bij het bepalen van oplossingsrichtingen voor producten en diensten, gebaseerd op het businessmodel en de bedrijfsstrategie.

Visie: Onze architectuurvisie is erop gericht om de diversiteit aan klantgroepen, producten en kanalen te ondersteunen met één samenhangende set van informatiesystemen. We kijken naar overeenkomsten om efficiënte en gebruiksvriendelijke oplossingen te realiseren. Wij zorgen voor de balans tussen het snel realiseren van commerciële kansen en het borgen van samenhang & duurzaamheid van onze dienstverlening.

Aanpak: Onze aanpak bestaat uit drie fasen: Creatie, Communicatie & Controle.

  • Creatie behelst het vaststellen van de structuur van de bedrijfsprocessen en de informatiesystemen die het beste past bij het bedrijfsmodel van de ABN AMRO N-share en de strategische keuzes van de Value en Services Centers in het bijzonder.

  • Communicatie bestaat uit het uitdragen van genoemde structuur naar de organisatie door deze structuur toegankelijk te maken, uit te leggen en breed gedragen te krijgen.

  • Controle bestaat uit het bewaken dat deze structuur wordt ingevoerd en gevolgd binnen de (IT) projecten van ABN AMRO N-share.”

PS. N-share is de formele term waarmee het gedeelte van ABN AMRO wordt aangeduid dat door de Nederlandse staat is overgenomen.

Daan: “Hoe leg je architectuur uit aan je vrienden en kennissen die niet in de IT zitten?”

Wouter: “Ik gebruik vaak een metafoor uit de stadsplanning. Als men de ontwikkeling van een stad volledig in de handen van projectontwikkelaars zou laten, dan is de kans groot dat er wel mooie gebouwen worden gebouwd, maar dat de functies niet op elkaar worden afgestemd (wonen, werken, winkelen, scholen, etc) en dat de infrastructuur niet goed zal passen bij de behoefte (openbaar vervoer, wegen, water, riool, dijken, etc). Daartoe is stadsplanning nodig. Deze maakt en onderhoudt het bekende bestemmingsplan, maar ontwikkelt ook principes waar bouwers zich aan moeten houden. Bij ABN AMRO worden op jaarbasis al gauw meer dan honderd projecten uitgevoerd en zij heeft vele honderden applicaties in beheer. Het lijkt wel een stad. Als die applicaties niet goed op elkaar zijn afgestemd en de infrastructuur niet goed geregeld is, gaat de IT niet werken. De rol van architectuur is te zorgen voor een bestemmingsplan en principes om de bouw in goede banen te leiden.”

Daan: “Waarom is architectuur eigenlijk nodig bij ABN AMRO?”

Wouter: “Een voorbeeld, tien jaar geleden was er de wens om klanten met een klein vermogen multi-channel te kunnen bedienen. Het karakter van de toenmalige systeemset (red.: onder systeemset wordt bij ABN AMRO een grote groep samenhangende applicaties bedoeld) kon dat niet bieden. Onder architectuur is gewerkt aan een nieuw karakter van de systeemset die wel multi-channel is. Nu, na tien jaar, is veel daarvan gerealiseerd en kunnen we klanten beter (en eenduidiger) multi-channel bedienen. Tevens kunnen we makkelijker (combinaties van) producten inrichten. Dit systeemkarakter had zonder architectuurbegeleiding nooit uit zichzelf kunnen ontstaan uit de honderden losse projecten die in die periode zijn uitgevoerd.

Iedere systeemset heeft een karakter, dat zijn een aantal kwaliteitskenmerken zoals: duur of juist goedkoop, moeilijk aanpasbaar of juist flexibel. Vergelijk het met het karakter van een stad. Dat karakter verandert niet snel. Ik heb bijvoorbeeld een kaart van Amsterdam uit 1750. De stad is nog steeds perfect herkenbaar, terwijl de binnenstad een totaal andere functie heeft gekregen (meer recreatief) met totaal andere (mobiliteits)eisen dan 250 jaar geleden. Klaarblijkelijk verandert een complexe structuur niet snel.

Dat betekent drie dingen:

  1. Op de lange termijn verandert het karakter van je systeemset. Alleen architectuur biedt je de tools om te borgen dat dit karakter een gewenst karakter is en blijft, in lijn met de strategie.

  2. Je kunt niet met je bedrijf de strategie omgooien en verwachten dat op korte termijn de systeemset die nieuwe strategie gaat ondersteunen. Dat duurt zeker tien jaar. Als ABN AMRO ineens een Postbank zou willen worden, dan is de huidige systeemset te duur met teveel functionaliteit om op korte termijn omgevormd te kunnen worden naar een low cost systeem met alleen basisfunctionaliteit.

  3. Als je je architectuur veronachtzaamt, dan verandert het karakter van de systeemset in de loop van de jaren maar niet in lijn met de strategie. Als je dan ontdekt dat je systeemset te duur, te inflexibel is of niet de juiste klantengroep kan ondersteunen dan moet je ook niet verwachten dat je dat karakter even snel aanpast.”

Daan: “Wordt die noodzaak ook daadwerkelijk door de businessmanagers bij ABN AMRO ervaren?”

Wouter: “Nee, vaak niet want men denkt graag op de korte termijn. Het is daarom steeds weer zaak om de businessmanagers te wijzen op de gevolgen van hun acties en beslissingen. Aan de andere kant zijn er door de lange historie waarmee we dit doen ook businessmanagers die overtuigd zijn geraakt van het nut en de noodzaak van architectuur.

Juist ook doordat we langere tijd architectuur hebben kunnen bedrijven, zijn er belangrijke voordelen ontstaan zoals goed herbruikbare services.

Het meest extreme voorbeeld dat ik heb meegemaakt betreft een project dat geen architecten had ingeschakeld. Zij hadden een businesscase opgesteld van ongeveer 15 miljoen euro. Toen een architect er lucht van kreeg en naar het ontwerp ging kijken, kon hij zoveel herbruikbare services aanwijzen dat de kosten in de businesscase daalden tot minder dan 1 miljoen euro!”

Daan: “Hoe heb je trouwens architectuur ‘verkocht’ aan de business?”

Wouter: “Dat is geen eenmalige actie geweest, maar meer een continu proces. Dat is ook goed, want het houdt je als architect scherp: architectuur moet toegevoegde waarde leveren! De aanpak is daarom ook iedere keer weer anders.

Voorbeelden:

  • Wij hebben een cursus ‘systemenlandschap’ ontwikkeld. Deze cursus geeft voldoende inzicht om de samenhang te zien, maar onvoldoende om zelf architect te kunnen zijn. Uiteraard zit in de cursusmap het overzicht van architecten en wie je waarvoor kunt bereiken. Inmiddels hebben meer dan 1000 mensen de cursus gevolgd. Men heeft behoefte aan overzicht over de systemen omdat men er continu mee te maken heeft. Van daaruit weet men breed in de organisatie de architect te bereiken en in te zetten.

  • Nu met de ontwikkeling van het ‘nieuwe’ ABN AMRO zoeken we de hogere leidinggevenden van de business op om te sparren over onze principes en de (deels nieuwe) strategie. Hen mee laten werken aan het ontwikkelen van de principes maakt ze deelgenoot en levert het beste draagvlak op.

In alle gevallen en op alle niveaus hanteer ik het uitgangspunt dat men alleen door samen te werken aan principes en oplossingen, de dilemma’s en keuzes gaat begrijpen. Alleen dan ontstaat degelijk draagvlak voor architectuuroplossingen.”

Daan: “Zijn er ondernemingen/organisaties met een architectuur waar je een beetje jaloers op bent?”

Wouter: “De architectuur van Schiphol. De CIO van Schiphol heeft ons eens een presentatie over architectuur gegeven en ik was onder de indruk van hun speelse manier van communiceren. Erg leuk en voor mij een voorbeeld.”

Daan: “Uit het CIO interview met Schiphol (red.: zie onder de rubriek ‘De CIO spreekt’ op Via Nova Architectura) valt mij op hun verregaande ontkoppelingen om maximale adaptiviteit te bewerkstelligen en het gebruik van cartoons om de cruciale principes aan de business te verkopen.

Kan jij iets zeggen over de filosofie achter jullie ontkoppelpunten en gebruiken jullie ook inspirerende plaatjes om jullie belangrijkste architectuurideeën te verkopen aan de business?”

Wouter: “Wij hanteren ook ontkoppelpunten. Deze zijn inderdaad cruciaal om maximale adaptiviteit te verkrijgen. Een mooi voorbeeld van een ontkoppelpunt ligt in het multi-channel platform. De filosofie is dat we op dat punt een ontkoppeling willen maken tussen de klantbediening via meerdere kanalen enerzijds en de productadministraties in de ‘back end’ anderzijds. De productadministraties stammen uit de tijd dat onze systeemsets konden worden gekarakteriseerd als ‘productsilos’, terwijl wij in de moderne tijd een eenduidige klantbediening vanuit één klantbeeld willen bieden. Het multi-channel platform vormt het ontkoppelpunt tussen die twee werelden.

Een tijdje geleden hebben we in navolging van Schiphol nagedacht over het representeren van onze principes in de vorm van cartoons. Echter, de overname van ABN AMRO gooide roet in het eten: de organisatie is zo aan het veranderen, dat we eigenlijk pas met goed fatsoen nieuwe principes kunnen definiëren als de nieuwe strategie van de nieuwe bank helder is. Dan lijkt het ons zinnig dit opnieuw op te pakken.”

Daan: “Hoe hebben jullie adaptiviteit gerealiseerd?”

Wouter: “Onze drie belangrijkste principes die de adaptiviteit verhogen:

  1. Daar waar mogelijk generiek.
    Het zoveel mogelijk generiek maken van veel gebruikte functies en het aanbieden van generieke services. Veruit de meeste applicaties maken bijvoorbeeld gebruik van de generieke security services en werken ‘single sign on’. Dat betekent dat iedere nieuwe applicatie of een wijziging in een bestaande applicatie snel kan worden bewerkstelligd. Ander voorbeeld: generiek outputmanagement maakt dat voor nieuwe output (nieuw product / dienst) niet meer over de outputstraat hoeft te worden nagedacht.

  2. Flexibele productarchitectuur.
    Door een productbroker te bouwen hebben we de mogelijkheid geschapen om snel nieuwe (combinaties van) producten in te kunnen voeren. In het verleden was dit moeilijk doordat men direct op allerlei oude productadministraties moest aansluiten. De adaptiviteit in het aanbieden van nieuwe producten is hiermee flink toegenomen. Overigens ook een mooi voorbeeld van een ontkoppelpunt.

  3. Een collectie bouwblokken.
    Sommige systemen zijn opgebouwd uit flexibele ‘building blocks’ waardoor snel nieuwe producten kunnen worden geleverd. Een voorbeeld is ons transactieverwerkend systeem voor binnenlands betalingsverkeer.”

Daan: “Welke speciale architectuurprincipes zijn er bij ABNAMRO? Op welke strategische uitgangspunten zijn die gebaseerd?”

Wouter: “Er is een lijst van ongeveer 20 principes die op hoog niveau zijn gedefinieerd.

Bijvoorbeeld:

  • Klantgegevens worden op één plek geregistreerd, waar iedereen op moet aansluiten. Dit principe volgt rechtsreeks uit de multi-channel doelstellingen.

  • Alle door of in bijzijn van de klant ingevoerde gegevens worden direct real-time in de betreffende proces-, contract- dan wel ABN AMRO transactiesystemen verwerkt. De uitkomsten daarvan staan direct weer ter beschikking van de gebruikers.

  • Alle klantgerichte applicaties maken gebruik van dezelfde ABN AMRO security services voor identificatie, authentificatie, toegangs- , bereik- en limietcontrole.”

Daan: “Wat zijn de cruciale businessdrivers bij ABNAMRO die van invloed zijn op de architectuur?”

Wouter: “De twee belangrijkste tot nog toe zijn multi-channel dienstverlening en focus op de preferred banking klantengroep. Dit zijn klanten die voldoende inkomen of kapitaal hebben om geïnteresseerd te zijn in meerdere bancaire producten, zoals effecten, maar niet tot de (kleine) groep zeer kapitaalkrachtigen behoren die we aanduiden met private banking klanten. De groep preferred banking klanten is groot genoeg om voldoende massa te vormen (groot aantal klanten), en betreft een doelgroep die veel bankproducten af wil nemen. Daar hoort wel een bepaald niveau aan dienstverlening bij die eisen stelt aan de systeemset. Zowel de bediening van deze klantengroep als de nadere specificatie daarvan in het multi-channel dienstverleningconcept hebben een grote impact op de architectuur.”

Daan: “Welke architectuurconcepten heb jij geïntroduceerd waarop je echt trots bent?”

Wouter: “Ik wil er twee noemen: ons multi-channel businessprocessmanagement (architectuurinhoud) en de professionele inrichting van het ‘Center of Expertise’ architectuur (architectuurproces).”

Daan: ”Kan je iets meer zeggen over dat multi-channel businessprocessmanagement? Architectuurconcepten hebben voor mij als doel om een grotere mate van ordening te bewerkstelligen, zoals het zaakdossier bij gemeentelijke automatisering. En wat is de essentie van de CoE architectuur?

Wouter: “Multi-channel businessprocessmanagement betreft een concept waarmee op een andere manier naar BPM wordt gekeken dan gebruikelijk. Overigens hebben we een patentaanvraag lopen op deze architectuur, aangezien we in de tijd dat deze ontwikkeld werd nergens dit concept aantroffen, en wij wel behoefte hadden aan de toepassing ervan. Het concept behelst in de kern dat er twee lagen van BPM worden onderscheiden. Die lagen moeten in de eerste modellering van een proces al worden aangehouden, en komen ook in de implementatie terug. In de bovenste laag wordt een proces opgedeeld in procesfasen die kanaalonafhankelijk zijn. Dat wil zeggen dat het proces, zoals opgedeeld in die fasen, in elk kanaal hetzelfde is. In een proces zit bijvoorbeeld de fase ‘tekenen van een contract’. Zonder die fase uit te werken (want dat is de tweede laag) geldt dat het niet uitmaakt in welk kanaal je zit, een contract moet getekend worden om verder te kunnen. Zo kun je cross channel je proces monitoren en aansturen op basis van die fasen. Het tweede niveau betreft de invulling van die fasen. Bijvoorbeeld, het tekenen van een contract of transactie is op internet anders geregeld (met challenge-response, d.w.z. je bankpas en zo’n ‘calculator’) dan in het bankkantoor (handmatig tekenen of ook met je bankpas), of in het fulfillment center (handmatig tekenen). Door echter de grens van iedere fase nauwkeurig vooraf te definiëren kun je faciliteren dat op die grens een klant van kanaal kan wisselen. Zo kan een klant in een bankkantoor een hypotheek aanvragen, via de post over de offerte communiceren, en (in de toekomst) op internet de offerte tekenen. Overigens kan de klant dus steeds zelf kiezen binnen dit concept welk kanaal hij op enig moment gebruikt. Inmiddels zijn alle klantgerelateerde processen binnen de bank gemodelleerd in deze twee lagen en vastgelegd in ons ‘common process framework’.

Het ‘Center of Expertise’ architectuur hebben we ingericht om centraal allerlei aspecten van architectuur te kunnen beheren, zoals cross domeinarchitecturen, de current state architectuur, een cursus systeemlandschap, etc. Doel is ook om te zorgen dat we één eenduidig architectuurbeeld hebben voor het hele bedrijf. Nadeel van zo’n club architecten is dat ze doordat ze boven de domeinen staan vaak in een ivoren toren terecht komen. Ze missen dan aansluiting met de realiteit. Mijn uitgangspunt is dat architectuurconcepten alleen zin hebben als alle stakeholders ze begrijpen. Daarom moeten die stakeholders met architecten meewerken, en moeten architecten met die stakeholders meewerken. Stakeholders zijn onder andere domeineigenaren, managers, maar ook ontwikkelaars. Al die groepen moeten de architectuur zien als ‘hun’ architectuur. Daartoe moeten de architecten vanuit hun CoE werken in de domeinen. Zij hebben een fysiek bureau in het domein waar ze zitten, ze organiseren het domeinarchitectuurteam, en ze draaien mee in de belangrijkste projecten van hun domein. Dit alles wordt vanuit het ‘Center of Expertise’ georganiseerd, zodat het beste van twee werelden wordt bereikt: een eenduidig architectuurbeeld met bijbehorende middelen en toch ook direct contact in de domeinen.

Daan: “Wat is de (business)waarde van architectuur?”

Wouter: “Architectuur is niet hard in geld uit te drukken. Ik probeer het echter wel.

Sinds januari dit jaar verzamelen we meer gegevens over de kosten die projecten moeten maken. Mijn interesse gaat uit naar kosten die projecten maken om wijzigingen in bestaande systemen uit te voeren. Het idee daarbij is dat 20% van de systemen 80% van de wijzigingen betreffen.

Ik wil toe naar een jaarlijks overzicht van de meest gewijzigde systemen, de kosten die daarmee gemoeid zijn en de aard van de wijzigingen. Uiteindelijk wil ik zo businesscases kunnen ontwikkelen voor het uit productie nemen van oude systemen en het flexibeler maken van bestaande systemen. Tevens kan de architectuurinspanning daardoor wellicht beter worden gerechtvaardigd.”

Daan: Welke referentiearchitecturen zijn er voor jullie sector?

Wouter: Er zijn geen referentiearchitecturen in de sector die ik ken. Op kleine schaal bestaan wel voor bepaalde onderwerpen standaards, maar niet echt wat ik een referentiearchitectuur zou noemen. Voorbeelden zijn SWIFT interfacing, SEPA standaards voor internationaal betalingsverkeer, of wat zich nu aan het ontwikkelen is t.a.v. de bankentaxonomie (een standaard voor het elektronisch uitwisselen van informatie tussen accountants en banken).

Daan: “Wat zijn volgens jou de belangrijkste kwaliteitscriteria voor een waardevolle architectuur?”

Wouter: “Allereerst moet architectuur gebaseerd zijn op de strategische doelstellingen, waarbij het gewenste karakter van de businessprocessen en de systeemset uiterst helder moet zijn. Voorts dient architectuur te zijn opgesteld in brede samenwerking met stakeholders zoals businessmanagement, maar ook IT-ontwikkelaars. Allen moeten het gevoel hebben dat het hún architectuur is. Alleen door samen dilemma’s en keuzes te doorleven worden die ook begrepen. Alleen dan is er voldoende draagvlak om de consequenties van de architectuur te aanvaarden. Dit leidt er toe dat ook in projecten men beter bereid is de architectuur te volgen. Ook daar spelen dilemma’s, waar men korte termijn doelstellingen goed moet afwegen tegen lange termijn effecten.”

Daan: “Kan je iets zeggen over het architectuurproject dat op dit moment jouw hoogste aandacht heeft? Welke grote uitdagingen zitten daarin?”

Wouter: “De samenvoeging van Fortis en ABN AMRO.

Grote uitdagingen zitten in het creëren van de gewenste systeemset, waarbij soms Fortis en soms ABN AMRO betere systemen hebben. De grote valkuil is echter dat een integratie van een lappendeken aan Fortis en ABN AMRO systemen uiterst kostbaar is en veel te veel tijd kost. In principe is een integratie alleen vlot uitvoerbaar als men één platform kiest en daarin problematische verschillen oplost. Dat is nog niet zo eenvoudig.”

Daan: “Wat wordt de rol van architectuur bij de fusie tussen ABN AMRO en Fortis?”

Wouter: “Architecten hebben een rol bij de integratie. Zij bepalen in belangrijke mate de oplossingsrichting, deploymentviews en samenhang tussen systemen tijdens en na de integratie. Wat de formele rol van architectuur in de nieuwe organisatie wordt, is nog niet helder. Die organisatie is nog niet bedacht.”

Daan: “Ik neem aan dat het proces van het opstellen van een architectuur bij ABN AMRO niet altijd goed is verlopen. Kan je iets zeggen over de consequenties van een verkeerde architectuur?”

Wouter: “Over het algemeen raakt een verkeerde architectuur in de vergetelheid en merk je dat niemand er veel aandacht aan schenkt. Binnen de afdeling stellen we vast dat de architectuur niet voldoet en wordt deze uit de roulatie genomen. Indien er behoefte aan een goede architectuur is, dan vindt wijziging of vervanging plaats.

Een architectuur waarvan men denkt dat deze goed is, maar die bij implementatie blijkt niet op te leveren wat beloofd is, is veel schadelijker en tast in belangrijke mate het geloof in architectuur aan bij de stakeholders. Extra probleem is dat vaak niet duidelijk is wie de ‘schuldige’ is. Vanuit architectuur kunnen we wijzen naar projecten en bouwers die niet gebouwd hebben zoals bedoeld was, terwijl anderen juist weer naar architectuur wijzen. Van al dat wijzen wordt niemand wijzer.

De belangrijkste les is dat de architect tijdens het gehele traject goed op moet letten en steeds wijzen op consequenties van bepaalde bouwbesluiten die niet in lijn met de architectuur zijn. Aan de andere kant moeten architecten goed opletten of de gedefinieerde architectuur ook goed implementeerbaar is en desnoods hun architectuur daarop aanpassen. Daarbij moet dan weer niet het gewenste systeemkarakter verloren gaan.”

Daan: “Laten jullie cruciale architecturen onafhankelijk, onpartijdig auditen, gezien de enorme impact van een foute architectuur?”

Wouter: “Nee, dat doen we niet formeel. Wel is er contact met audit, compliance en andere partijen binnen de bank zodat consequenties op gebied van compliance en allerlei risicofactoren worden meegewogen. Ik vraag mij overigens af of het onafhankelijk auditen van architecturen gaat helpen om de architecturen beter te maken, d.w.z. dat we minder te maken krijgen met foute architecturen of fouten in architecturen? Onze architecturen worden al door collega’s en alle betrokken partijen gereviewd, zodat als er nog fouten in zouden zitten deze waarschijnlijk niet meer door een extra controle kunnen worden gevonden. Veel inspanning met weinig opbrengst dus, denk ik. De factor onpartijdigheid zie ik niet veel toevoegen, aangezien onze architecten zelf zoveel mogelijk onpartijdig acteren. Ik denk dat een architect vanuit zijn discipline moet acteren en zo objectief mogelijk in de organisatie. Het zou mij verbazen als mijn architecten zich tot foute architecturen laten verleiden door teveel met één partij in de organisatie mee te gaan.”

Daan: “Welke rol speelt architectuur bij het (her)inrichten van de businessorganisatie? Moeten business- en architectuurdomeinen op elkaar aansluiten? En hoe hebben jullie dat gerealiseerd?”

Wouter: “De huidige ABN AMRO organisatie voorziet in een organisatieonderdeel dat is ingericht om de generieke systemen in eigendom te hebben. Domeinen binnen dat organisatieonderdeel zijn bijvoorbeeld ingericht rond de generieke security systemen of rond het generieke outputmanagement. Zo vindt de architectuur een reflectie in onze organisatie. Ik denk ook dat businessdomeinen die de rol van eigenaar hebben van met name generieke systemen moeten zijn ingericht in overeenstemming met de architectureel bepaalde grenzen van die generieke systemen. Dit is een goede manier om het karakter van de systeemset te behouden. Wij hebben dat zelf niet gerealiseerd. Wel hebben we klaarblijkelijk een deel van de organisatie goed kunnen overtuigen van het nut van deze aanpak. Managers hebben vervolgens zelf voor deze inrichting gekozen.

Het zou niet goed zijn om architectuurdomeinen aan te laten sluiten bij organisatiedomeinen, als dat niet tot een goede architectuur leidt. Het kan in de praktijk praktisch lijken (één stakeholder, duidelijke afspraken, etc), maar als de organisatorische grens architectureel niet past dan komt de architect in de problemen en zal nooit een goede architectuur opleveren. Dan liever een architectuurdomein definiëren dat architectonisch klopt en met meerdere eigenaars overleggen.”

Daan: “Speelt architectuur een rol bij de besluitvorming in de Raad van Bestuur?”

Wouter: “Niet direct. Wel heeft men zicht op de rol van architectuur en wanneer deze in te schakelen. We hebben twee concrete supporters van architectuur in de raad van bestuur zitten, die ons ook weten te vinden.”

Daan: “Hoe vindt besluitvorming ten aanzien van architectuur plaats, wie is accountable voor de architectuur? En wie is de eigenaar van een architectuur?”

Wouter: “Onze voorkeur is dat een proceseigenaar ook eigenaar is van een procesarchitectuur en een systeemeigenaar van een systeemarchitectuur. De praktijk is echter ook vaak dat we zelf eigenaar zijn van de architectuur, maar dat we in voldoende mate het gevoel van mede-eigenaarschap bij veel stakeholders kunnen realiseren / oproepen. Bijgevolg zijn wij meestal zelf accountable voor de architectuur. De besluitvorming rond architectuur laten we situationeel plaatsvinden met de betrokken stakeholders.

Dit lijkt niet professioneel, want het is niet gestandaardiseerd in ons bedrijf. Maar in de praktijk zitten dan wel altijd de juiste mensen aan tafel. In een geformaliseerde architectuurboard zitten vaak mensen die teveel afstand hebben tot de praktijk waarover de architectuur gaat. Ik vind dat niet nuttig. We bereiken meer met onze aanpak.”

Daan: “Wat zijn volgens jou de karaktereigenschappen en competenties van een goede architect? Trouwens wanneer is een architect goed? En door wie/wat wordt dat eigenlijk beoordeeld?”

Wouter: “Een architect is goed als hij resultaat bereikt. Resultaat is in mijn ogen dat hij erin slaagt een architectuur te ontwikkelen die door alle stakeholders wordt begrepen en aanvaard als hun architectuur, en die als gevolg daarvan ook tot implementatie komt. Lastig voor een beginnend architect, want resultaat ligt volgens deze definitie meestal ver in de toekomst. Als de architect dit bereikt, dan zullen alle stakeholders positief zijn over zijn inzet. De stakeholders beoordelen dus de architecten.

Karaktereigenschappen / competenties van een goede architect:

  • kan goed samenwerken

  • sociaal en organisatiesensitiviteit

  • kan goed structureren

  • kan goed overzicht creëren

  • kan complexiteit vereenvoudigd weergeven

  • hoge mate van zelfstandigheid

  • kan de kar trekken en tot resultaat komen

  • is in staat met 80% tevreden te zijn

  • kan vasthoudend zijn

  • spreekt taal van de business én van IT

  • kan strategisch denken; lange termijn consequenties

Kortom, een goede architect kan verbinden. Hij zit midden tussen specialist en generalist en midden tussen business en IT.”

Daan: “Maken jullie een expliciet onderscheid tussen businessarchitecten en IT-architecten? En hoe werken die samen?”

Wouter: “Zeker, het grensvlak is echter niet scherp te maken. Voorheen was er een aparte groep enterprisearchitecten, met een duidelijke IT-focus, en een aparte groep businessarchitecten. Beide groepen zaten regelmatig in elkaars vaarwater. Een businessarchitect laat zich snel verleiden ook wat over de systemen te zeggen, terwijl een IT-architect zich snel laat verleiden ook wat over de businessarchitectuur te zeggen. Daarom was het van belang dat beide groepen samengingen. Gezamenlijk naar buiten treden met één architectuurbeeld maakt architectuur veel krachtiger in de organisatie dan verschillende afdelingen, ook al hebben die afdelingen formeel een ander aandachtsgebied. Op dit moment zitten de business- en IT-architecten in één afdeling. Ik heb vervolgens het model gehanteerd om de architecten ieder hun domein toe te wijzen waarbij steeds een business- en een IT-architect samen op een domein zitten. Daarnaast heeft iedereen ook cross domeinfuncties: men werkt o.a. aan cross domeinarchitecturen.”

Daan: “Wat versta je precies ‘cross’?

Wouter: “Cross domein wil zeggen dat een architectuur in meer dan één domein van toepassing is. Bijvoorbeeld, de businessprocessmanagement architectuur geldt voor alle klantgerelateerde processen binnen de bank, onafhankelijk of je in het effectendomein of het kredietendomein zit. Ook de technische referentiearchitectuur is een voorbeeld van een architectuur die geldt voor elk te bouwen systeem, onafhankelijk in welk domein je zit.”

Daan: “Impliceert het feit dat jij leiding geeft aan zowel de businessarchitecten en de enterprisearchitecten dat alle architectuur bij ABN AMRO start in de business?”

Wouter: “Ja, het ‘Target Operating Model’ van onze IT-dienstverlening start formeel met wat wij noemen de delta (wijziging) in het businessproces. Ieder idee dat gaat leiden tot een project kun je beginnen te formuleren als een delta in een businessproces. Dan geef ik onmiddellijk toe dat infrastructurele wijzigingen (om maar een voorbeeld te noemen) die wel tot kostenreductie leiden maar niet gemerkt worden in een businessproces wat minder goed passen in deze aanpak. Aan de andere kant kun je altijd aanvoeren dat een bepaald businessproces of groep van businessprocessen in dat geval een kostenreductie gaan ervaren. Uiteindelijk is dat ook een delta. Het kan er bijvoorbeeld toe leiden dat bepaalde businessprocessen zo goedkoop worden dat je ook prijzen van producten of diensten kunt aanpassen. Dat kun je zien als een delta in het businessproces.

Daan: “Hoe belangrijk is een goede architect? En waaruit blijkt dat? Hoeveel mag een architect verdienen (intern) / kosten (extern)?”

Wouter: “Wij hebben onlangs een onderzoek gedaan naar de bijdrage van architecten aan projecten. Daarbij bleek een verband te bestaan tussen de mate van ervaring van een architect en de reductie in doorlooptijd van het project. Een ervaren architect is dus belangrijk. Wat ik niet kan is dat met harde cijfers omslaan naar kosten. Geen idee hoeveel een architect mag kosten. Uiteraard weet ik wel wat ze kosten in onze organisatie, maar of dat te weinig of teveel is? Ik denk dat niemand met zekerheid kan vaststellen wat een architect mag kosten of opbrengt. In het voorbeeld dat ik noemde op jouw vraag over de noodzaak van architectuur (red.: dat was de vierde vraag) was de architect verantwoordelijk voor een reductie in kosten van vele miljoenen die anders zouden zijn uitgegeven. Wat is zoiets waard?”

Daan: “Horen de toparchitecten op jullie eigen loonlijst of huur je die liever in?”

Wouter: “Deze horen op de loonlijst van ABN AMRO. Het is mijn ervaring dat een architect meer gaat bereiken als hij goede kennis heeft van de processen, businessfuncties, en systemen binnen het bedrijf. Het is de combinatie van architectuurvaardigheden en bedrijfskennis die een architect echt goed maakt, hetgeen niet betekent dat een architect met weinig bedrijfskennis niets kan bereiken. Er zijn ook bepaalde voordelen van het niet hebben van bedrijfskennis (situationeel bepaald). Over het geheel genomen is bedrijfskennis een belangrijk attribuut van de architect. Daartoe moet hij langere tijd in dienst zijn. Het blijkt bij ons dat er een lineair verband bestaat tussen het aantal jaren in een architectuur(achtige) functie en de hoeveelheid kennis van lokale systemen en processen die iemand heeft.”

Daan: “Welke tools gebruikt ABNAMRO in het architectuurproces?”

Wouter: “Word, Excel en Powerpoint. Daarnaast diverse databases voor current state architectuur, architectuuraudit, en voor de building permit. ARIS gebruiken we voor ons procesframework en mogelijk straks ook voor onze current state architectuur.”

Daan: “Ik neem aan dat je de functies van MS-Office gebruikt in het prille voortraject van architectuur en dat je verderop tools gebruikt met een repository om de overall consistentie te borgen?

Gebruiken jullie eigenlijk geen tekentools om de architectuur te visualiseren voor de business?

Wouter: “Wij zijn al een tijd bezig om tooling te krijgen om onze current state architectuur beter te kunnen representeren. Om betere overzichten en platen daaruit te krijgen zonder dat we die zelf hoeven te tekenen. Echter, de voordelen zijn beperkt: een goede plaat doet het erg lang goed, en hoeft maar af en toe te worden aangepast. Op dit moment tekenen we onze platen in powerpoint. Voor future state architectuur blijft dat voorlopig sowieso.

Daan: “Welke eigenschappen/gedragingen bij andere architecten keur je af en waarom?”

Wouter: “Twee gedragseigenschappen van architecten, die ik soms zie tijdens congreslezingen en in vakbladen, die ik niet goed vind zijn:

  • Weinig interactie met collega-architecten en teveel zelf doen.
    Het is immers belangrijk dat het gezamenlijk beeld hetzelfde is en ook hetzelfde wordt geuit naar de buitenwereld (one voice).

  • Niet afdoende de samenwerking zoeken met stakeholders.
    Stakeholder zijn o.a. business- / systeemeigenaren, maar ook ontwikkelaars. Allen moeten bij voorkeur de dilemma’s en keuzes doorleven die spelen bij het bepalen van een bepaalde structuur / inrichting / oplossing. Alleen dan ontstaat echt draagvlak voor het resultaat in alle gelederen. Dus ook draagvlak van de architect voor een keuze die niet architectonisch de beste is, maar die wel in het volle besef van de consequenties is genomen om andere (goede) redenen.

Daan: “Welke opleidings-/bijscholingsadviezen heb je voor aankomende architecten?”

Wouter: “Een eerste opsomming in willekeurige volgorde:

  • Zorg dat je kennis hebt/krijgt van je businessdomein.

  • Zorg dat je kennis hebt van de strategie van je bedrijf.

  • Zorg dat je je eigen sterke en zwakke punten kent.

  • Zorg dat je kunt structureren conform moderne methodes.

  • Zorg dat je kunt presenteren.

  • Zorg dat je groepen kunt begeleiden in een workshop. Niets is beter dan (bijvoorbeeld in een workshop) samen de dilemma’s te doorleven en met een gedragen resultaat te komen.

  • Zorg dat je kennis hebt van architectuurmethoden en –processen.

  • Zorg dat je kennis hebt van je business.

  • Zorg dat je kennis hebt van systemen.”

vragen/opmerkingen kunnen worden gestuurd via: daan@rijsenbrij.eu

[PDF]

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

15-02: GIA sessie over digitale transformatiespel meer...

19-03: NAF Insight met Jeanne Ross meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden