Frank Rustige is werkzaam bij DAF Trucks als manager Projects & Support bij PACCAR Parts & After Sales. Als businessmanager is hij verantwoordelijk voor menige vernieuwing. Hij ziet daarbij de rol van architectuur steeds belangrijker en waardevoller worden.

Frank wordt in het gesprek bijgestaan door Joost van Berkel. Joost is domeinarchitect voor het domein After Sales. In die rol is hij een gewaardeerde gesprekspartner voor Frank.

Wat roept het begrip ‘architectuur’ bij je op?

Frank: “Dan denk ik toch al gauw aan de parallel met de wereld van steden en gebouwen. Wat mij daar opvalt, is dat meer zaken vooraf uitgedacht en geregeld zijn. Die architectuur werkt vanuit concrete, uitgekristalliseerde kaders. Dat mis ik in de IT architectuur waar wij het hier over hebben. Het zou makkelijker zijn als er - net als bij huizen en steden - meer gebaande paden waren.
In de IT-archtectuur lijkt het alsof de architecten steeds alles nog moeten uitvinden tijdens de bouw.”

Wij gaan er vanuit dat de eigenlijke opdrachtgever van een IT-intensief verandertraject in de business zit. Het lijkt daarom logisch dat het de verantwoordelijkheid van de businessmanager is te zorgen dat er een duidelijke architectuur ligt voor een project wordt gestart?

Frank: “Ik wil niet zeggen dat we vanuit de business geen verantwoordelijkheid hebben om dat te checken. Aan de andere kant kun je ook niet altijd wachten tot een architectuur helemaal geformuleerd is.
Het komt voor dat de tijd om alle aspecten zorgvuldig van te voren te bekijken zo lang duurt en zo moeizaam is, dat je toch beslist om sneller te bouwen en misschien maar niet op de meest verantwoorde manier. Dat zijn dan risico’s die je vanuit de business moet nemen.
Het is echter aan de automatiseringsafdeling om ons scherp te houden, zodat we vanuit de business niet onverantwoorde beslissingen nemen. Het is goed dat er altijd nog een automatiseringsafdeling is die zegt: ‘ho, ho, hebben jullie wel gedacht aan architectuur en aan standaard pakketten?’ ”

Joost: “Dat zou je eigenlijk een stapje voor moeten zijn. Maar om eerlijk te zijn, is de ruimte om van tevoren naar architectuur te kijken vaak te weinig.”

Wat is de ware reden dat die ruimte er soms niet is?

Frank: “Dat ligt ook een beetje aan de manier waarop wij IT-vernieuwingen uitvoeren. Veel innovaties worden bij ons geboren tijdens businessprojecten. Dus als er iets nieuws in de IT-architectuur zou moeten worden aangeschaft, omdat dat gewoon verstandig is en omdat daar in de toekomst projecten op zouden kunnen gaan werken, dan is het bij ons het beleid om dat door het eerste project wat daar tegenaan loopt te laten financieren. Hoewel dat een heel praktische benadering is, betekent dat wel dat het eerste project eigenlijk altijd komt op het moment dat de architectuur eigenlijk al antwoord had moeten geven op bepaalde vragen of bepaalde zaken in de infrastructuur had moeten voorzien. Die vraagstukken komen dan in dat project. Dan is er pas het geld om die zaken te regelen dan wel aan te schaffen.”

Joost: “Daardoor ontstaat ook de situatie dat de business eigenlijk geen nieuwe technieken/methodes wil omdat dat gelijk een extra investering vergt in haar project, terwijl je vanuit de automatiseringsafdeling juist wel die stappen vooruit wil maken.”

Kan je hier iets dieper op ingaan?

Frank: “Als je architectuur serieus neemt, denk ik dat je ook een aantal stappen zou moeten zetten als je nog geen automatiseringsproject hebt. Dus op voorhand investeren. Dat je toch keuzes maakt, toch standaard pakketten aanschaft in de wetenschap dat er projecten zullen komen die daar gebruik van moeten maken.

Voorbeeld: enige tijd geleden werden we vanuit de business bij een bepaald project geconfronteerd met ‘Service Oriented Architecture’, waarbij we middels een webapplicatie gegevens van het mainframe zouden gaan gebruiken. Dan merk je in dat project dat je de allereerste bent om die toen nog voor DAF vrij nieuwe techniek te verkennen zonder relevante architectuurkaders. Het bleek overigens de enige oplossing te zijn om het businessprobleem op te lossen, want anders kun je nog zeggen ‘laten we daar maar niet de eerste in zijn, laten we dat op een andere manier doen’. Daarbij kwam ook nog dat op kosten van dat project er nog tools moesten worden aangeschaft om het kunstje te kunnen uitvoeren. En er moeten nog mensen worden opgeleid in het gebruik van die tools. Dan leg je dus alle risico’s van een architectuur bedenken en implementeren in een project waarbij het aan de businesskant al moeilijk genoeg was om überhaupt de projectdoelstellingen te bereiken.
Eigenlijk zeg je dan - even om de beeldspraak van de huizenbouw te hanteren – je bent bezig een huis te bouwen terwijl je nog geen tekening hebt. In zo’n specifiek geval ga je zo’n project dus met vallen en opstaan uitvoeren. Aan het einde van dat project heb je dan veelal wel ook een goede architectuur liggen.

Ik zeg niet per definitie dat het slecht is pas tijdens een project architectuur te formuleren. Het gevaar van te voren te veel zaken te regelen is dat voor je het weet je architectuur zit te bedrijven waarbij je een hele hoop dingen bedenkt waarnaar de business nooit zal vragen.
Aan de andere kant vind ik wel dat je door architectuur juist heel goed van tevoren keuzes kunt maken om wildgroei in de gebruikersorganisatie te voorkomen. Wat we vroeger hadden met de kantoorautomatiseringhulpmiddelen waar iedereen op z’n PC zijn eigen spreadsheet programmaatjes zat te ontwikkelen. Dat gebeurde omdat er toen geen goede architectuur en infrastructuur was om dat soort zaken te voorkomen en te zorgen dat je bijvoorbeeld zoiets als een datawarehouse kan gebruiken zodat niet iedereen op z’n eigen manier lokaal zijn data zit te veredelen. Daar zou je dus architectuuruitspraken over moeten formuleren.
Dat zijn zaken die bij ons gerealiseerd zijn, maar dat zijn wel lange trajecten.”

Zouden architecten gehoor krijgen, als ze de business eerder zouden waarschuwen?

Frank: “Ik denk het wel omdat iedereen die veel in projecten werkt uiteindelijk ook wel merkt dat als er gebaande wegen zijn, zijn project sneller kan verlopen. Het is immers niet efficiënt het wiel elke keer weer opnieuw uit te vinden.”

Hoe is architectuur begonnen binnen DAF?

Joost: “We begonnen met een referentiearchitectuur die heel beperkt was. Binnen Marketing en Sales werd geconstateerd: ‘Hebben we dat ooit eerder gedaan? O ja, dan kunnen we dat hergebruiken’.
Die behoefte aan architectuur is daarna veel breder geworden. Gebruiksrichtlijnen voor technieken die worden gebruikt binnen Finance, Operations of Product Development worden breder getrokken en hergebruikt bij Marketing en Sales. Ik vind dat je steeds meer merkt dat de voordelen daarvan zich tonen. Zo begint de waarde van architectuur zichtbaar te worden.”

Frank: “Ik vind de aandacht voor architectuur een goede zaak. De laatste jaren wordt bij elk project geëist dat er een architectuurdocument wordt geschreven. Je moet daarbij wel voorkomen dat het te lange verhalen worden. Binnen een project word je er op gewezen dat er op zijn minst een checklist nagelopen wordt van ‘ga je in dit project dingen doen die nieuw zijn in de architectuur? Of er haaks op staan?’.
Als dat soort zaken worden afgevraagd en in een vroege fase gecheckt, dan geeft dat meer zekerheid dat het project zal slagen.”

Wie vraagt naar dat architectuurdocument? Is dat de projectleider? Of is dat de opdrachtgever in de business die zegt ‘voordat we het project beginnen wil ik architectuurplaten zien zodat ik mee kan sturen en ik een duidelijk beeld krijg van wat ik als eindproduct kan verwachten’?

Frank: “Dat is een goede vraag. Dat ik zelf, vanuit de business, vroeger niet zoveel behoefte had aan architectuurdocumenten kwam omdat ze te technisch waren. Ik merk nu in projecten – ook omdat de complexiteit toeneemt van de omgeving waarin we werken - dat ik steeds meer behoefte krijg aan het afzekeren door een architect dat wat we willen ook bouwbaar is en dat het ook binnen onze infrastructuur past. Als je geen rekening houdt met dergelijke zaken, kun je tegenwoordig je hele project onderuit halen. Als het vroeger niet paste binnen de architectuur kon je met veel kunst- en vliegwerk de zaak toch wel draaiende krijgen. Dan kreeg je weliswaar niet de mooiste oplossing, maar het werkte. Als je tegenwoordig zegt ‘we denken dit te doen en we lopen bijvoorbeeld tegen een groot security probleem aan’, dan is het een ‘no-go’ voor het project.

Kortom, het afbreukrisico als je bij de voorbereiding van een project over de mogelijke problemen met grote stappen heen walst is veel te groot. Je kunt niet meer zo eenvoudig als vroeger iets tot een goed einde brengen. Er zijn teveel componenten en de techniek is zo complex geworden dat je er van tevoren over dient na te denken. Alles hangt met alles samen, als ik hier druk doet het daar pijn. Ik heb architectuur nodig om mijn probleemgebied transparanter te maken en dat is nog een hele opgave. In ieder geval hebben we binnen projecten nu een verplicht architectuurdocument, en verplichte werkzaamheden die even wat verder kijken dan het project zelf. Activiteiten waarmee ook expliciet wordt gekeken naar de realiseerbaarheid. We zijn op de goede weg, maar het is een taaie leercurve.”

Voel jij je als businessmanager verantwoordelijk voor een project dat mislukt?

Frank: “Het is in onze organisatie zo dat de projecten die wij doen vanuit de business worden geïnitieerd. Als er iets in de hele keten fout gaat doordat ergens een stukje architectuur wordt overgeslagen, dan trekt de businessmanager het zich aan. Dan wordt er niet afgeschoven naar ‘ergens in het project is er een afdeling die z’n werk niet goed gedaan heeft’. Dat kun je wel zeggen, maar dat maakt naar de buitenwereld toe niet uit: het project is gewoon mislukt!
Bij DAF is het normaal dat de businessprojectmanagers eindverantwoordelijk zijn voor het project. En dat geeft ook wel eens conflicten want ieder deelprojectteam, bijvoorbeeld het automatiseringsteam, is deskundig voor zijn eigen stukje. Maar om tot een goed eindresultaat te komen is er uiteindelijk maar één eindverantwoordelijk, en die zit in de business. Daarom bemoeien we ons in de business soms nog wel eens teveel met zaken waar we ons vanuit de business niet mee zouden moeten bemoeien. Je kunt ook zeggen ‘ieder doet zijn eigen werk en het interesseert je verder niet hoe ze het doen’, maar dat is niet onze bedrijfscultuur.
Ik als businessmanager vind het niet genoeg dat er een architectuurdocument is. Ik wil weten wat er in staat en het kunnen begrijpen.”

Datzelfde geldt toch ook voor een huis? Als je een huis krijgt wat je niet wilt hebben, is dat je eigen schuld. Je laat een architect komen die een tekening maakt, dan zeg je ‘ik wil dit niet en dat wil ik veranderd hebben’, net zo lang tot jouw toekomstige huis lekker aanvoelt. De architect is wel verantwoordelijk voor de bouwbaarheid, maar uiteindelijk beslis jij – als businessmanager - wat je wilt hebben.

Frank: “Als businessmanagers over architectuuraangelegenheden direct praten met de bouwer kan dat ook wel zijn nadelen hebben. Op het moment dat je je zo betrokken voelt en zeker wilt weten of iets goed gaat, ga je je ook bemoeien met zaken waar je je eigenlijk niet mee moet bemoeien.
Ik heb dat bij de bouw van mijn eigen huis meegemaakt. Er is mij tijdens de bouw door een bouwer een keer gevraagd ‘meneer Rustige, u heeft, volgens tekening, hier deze pijp lopen van de verwarming, maar dat gaat helemaal niet, dat kan niet want dan moet dit en dat worden veranderd’. Toen heb ik gezegd ‘hoe zou dat anders moeten?’. Die bouwer zei: ‘nou, die moet je hier neerleggen’. Toen heb ik daar ter plekke de beslissing genomen. Stom!, want daarbij moet een architect worden ingeschakeld. In het grotere geheel van het huis was deze beslissing totaal fout. Maar omdat je denkt te weten hoe het allemaal in elkaar zit - en dat gebeurt in situaties bij DAF net zo goed – besluit je hiervoor niet de architect te raadplegen. Bij DAF waken wij ervoor in projecten beslissingen te nemen waar je eigenlijk niet capabel voor bent.
Er zit dus een balans tussen proberen te snappen hoe zaken in elkaar zitten en dat gaan overdrijven omdat je je er teveel mee bemoeit en je daardoor op het vakgebied van anderen begeeft.”

Is er een beslissing waarvan je zegt ‘daar heb ik architectuur bij nodig’?

Frank: “Op CRM-gebied hebben wij de beslissing genomen om even een stap op de plaats te maken en goed na te denken wat we nu eigenlijk willen. Willen we onze data wel buiten DAF zetten of willen we het hier in huis houden. Dat geldt natuurlijk ook voor bepaalde applicaties.

Veel data die we hebben zijn een waardevolle asset voor DAF waar we heel zorgvuldig mee om willen gaan. Die data willen we niet aan derden ter beschikking stellen, zelfs niet onder allerlei condities. Daar zitten strategische vraagstukken aan vast. Daarom hebben we onszelf gedwongen goed na te denken voor we snel in een project weer van alles mogelijk maken.

Wij beseffen nu dat je in je architectuur dient na te denken over je data en over de consequenties.”

Wiens idee was dat ‘we gaan even een stapje terug doen, even kijken of we dat wel willen’?

Frank: “In dit geval was het een samenspraak tussen businessmanagement en de automatiseringsafdeling. We werken in dergelijke vraagstukken goed samen. We laten merken waar we mee bezig zijn, en we dulden ook wederzijds kritiek. Dan krijg je een sfeer waarin als een van de twee zegt ‘heb je ook hier aan gedacht’ er ook wordt geluisterd. Dat die openheid er in onze organisatie is, is erg belangrijk omdat nog niet alles op schrift staat waar je je aan te houden hebt. De strategische kijk op architectuur moet nog nader vorm krijgen: wat doe je nu wel en wat doe je nu niet.
Je moet, denk ik, ook wel een beetje oppassen om niet alles in architectuur te willen vastleggen. We moeten niet vergeten dat we ook vanuit de business soms dingen willen doen waarop we voorliggen op wat de rest van de wereld doet. Als je een architectuur hebt die iedereen heeft en waar je strikt aan moet vasthouden, dan heb je dus geen concurrentie voordeel meer.”

Hoe ligt de verdeling van verantwoordelijkheden bij DAF tussen informatiemanagers en architecten?

Frank: “Architecten en informatiemanagers zitten bij DAF aan de IT-kant. Alles wat met IT te maken heeft, van functionele ontwerpen, met architectuurvraagstukken tot en met het programmeren zit allemaal onder de IT-directeur.
Wat bij ons aan de businesskant zit is het overall projectmanagement, het opstellen van de business requirements en het testen van wat er terugkomt. Het opstellen van de business requirements loopt vaak door tot het meedenken in het functionele ontwerp.
De businessprocessen goed begrijpen, goed kunnen beschrijven, de wijzigingen op de businessprocessen goed definiëren, ligt aan de business kant. Daarom zitten bij ons ook de businessanalisten en business-strategen. Die staan met beide benen in de business en kijken wat er in de toekomst nodig is. Ze proberen dat zodanig te beschrijven dat er een businessproject van te maken is. Het is natuurlijk een ware uitdaging in deze tijd om de handen op elkaar te krijgen voor investeringen. Als het dan uiteindelijk een project is waarin daadwerkelijk systemen gebouwd worden, dan wordt de automatiseringsafdeling erbij betrokken. En dan zitten daar ook de architecten bij.

Als wij – in de business - met de benen op tafel denken ‘zou dit eigenlijk mogelijk zijn?’, dan halen we er natuurlijk een architect bij om mee te denken hoe wij dat zouden moeten aanpakken. We zijn niet zo van dingen over de schutting gooien – dat is denk ik het slechtste dat je kunt doen.”

Verwacht jij ook een innovatierol van de architecten?

Frank: “Ik probeer - en dat ligt in de aard van mijn afdeling – innovaties zelf te initiëren, zowel qua businessimpact als op IT-gebied.
De onderdelenvoorziening van DAF is een bedrijfsonderdeel dat behoorlijk van zijn systemen afhankelijk is. Naast de systemen voor onszelf, zij wij ook bezig met de systemen voor onze dealers.
In zo’n informatietechnisch intensief bedrijfsonderdeel kun je het niet permitteren om te wachten totdat je IT-afdeling innovaties komt melden. Nee, we lezen zelf de literatuur, je volgt zelf wat er gebeurt en je kijkt naar andere bedrijven.”

Zijn er specifieke gebieden waarvan je denkt ‘daar zou ik in de toekomst architectuur voor nodig hebben’. In het begin van het gesprek vertelde je immers al: ‘soms loopt architectuur er wat achteraan, het zou goed zijn als er al het een en ander was’

Frank: “Ja, als ik kijk naar gebieden waar we in zijn algemeenheid in het bedrijfsleven achterlopen, dan heeft dat te maken met de communities die ontstaan. Mensen in of buiten bedrijven die met elkaar communiceren en samenwerken via systemen. Dit gebeurt in niet-bedrijfsomgevingen allang. Forums bijvoorbeeld waar mensen met elkaar communiceren. Dit voorzie ik, niet alleen voor eigen medewerkers, ook met en tussen klanten. In feite tussen iedereen die onze systemen gebruikt. Er is architectuur nodig om dergelijke communicatiepatronen op verantwoorde wijze uit te bouwen.

De grens tussen hoe men zakelijk en hoe men privé met computers omgaat begint te vervagen. Wat mensen thuis doen op een pc - chatten met iemand, zaken plaatsen op een forum of informatie verzamelen – willen ze ook zakelijk doen. Ik denk dat we daar nog veel te weinig op voorbereid zijn.

Social computing in een business to business cultuur zal een iets ander karakter krijgen dan tussen onze vrienden, want hier op het werk chat je niet met collega’s over niets.

We denken inmiddels wel na over meer moderne manieren van communiceren. De automatiseringsafdeling is de trekker van een project waarbij SharePoint als centaal communicatieplatform wordt neergezet. Als ik zie wat er in de infrastructuurwereld allemaal gebeurt, mogen we in de toekomst nog veel grootsere dingen verwachten die we in het bedrijfsleven gaan gebruiken
Het lijkt wel of deze zaken eerst uitgeprobeerd worden in de wereld na werktijd.”

Zou je wat voorbeelden kunnen noemen?

Frank: “Je zou een dealergroep kunnen vormen om een forum te starten waarin je ervaringen over bepaalde onderwerpen uitwisselt. Bij DAF zouden we dan moeten gaan nadenken hoe we dat onder architectuur kunnen doen. We lopen dan wellicht tegen allerlei beveiligingsproblemen aan. Wat je thuis bij wijze van spreken klik klik kunt maken, daarover moet je in een bedrijf professioneel nadenken.”

Dus de factoren die dergelijke zaken tegenhouden zijn de security eisen en de eisen aangaande robuustheid?

Frank: “Dat klopt, security en robuustheid zijn cruciaal. Als we bij DAF iets aan onze dealers ter beschikking stellen, dan mag het niet omvallen. Ik ben een groot voorstander van solide kwaliteit.”

Wat voor soort architecten heeft DAF trucks?

Joost: “We hebben een paar enterprise architecten. Daaronder hebben we technische architecten, die echt met infrastructuur bezig zijn en alles wat daar mee samenhangt. Voorts hebben we een aantal domeinarchitecten, die meer aan de businessunit zijn gerelateerd.
Echte business architecten hebben we niet bij naam en toenaam, maar die functie kennen we wel.”

Welke eisen stel je aan een architect?

Frank: “Een architect moet los van zijn eigen vak kunnen aanvoelen wat er in de business gebeurt, uitgezonderd degenen die alleen met technische infrastructuur bezig zijn. Met name domeinarchitecten moeten wel degelijk snappen wat zich in de business afspeelt, anders denk ik dat je geen goede architectuur kunt formuleren.”

Weet je dat dat in de bouw niet wordt onderschreven. Toparchitecten tekenen net zo makkelijk een gevangenis als een ziekenhuis. Twee organisaties met een totaal ander businessmodel. Een gevangenis is bedoeld om mensen binnen te houden, bij een ziekenhuis moeten ze snel weer weg.
Een fysieke architect krijgt een hoeveelheid specificaties waar die materiekennis al inzit en hij gaat het vormgeven.

Frank: “Misschien moet ik dan wel opbiechten dat we niet altijd gelijk vanaf het begin alle specificaties helder hebben, zodat een architect meteen uit de voeten kan. Dat zou misschien wel moeten, alhoewel je daar ook niet in zou moeten overdrijven.
Ik vind het wel belangrijk dat een domeinarchitect kennis heeft van z’n domein. Ik denk dat hij daarom ook een domein heeft. De architectuur dient dienend te zijn aan de business, het moet een enabler zijn om het businessprobleem om te lossen.
Een duidelijke relatie met de business en feeling voor welk probleem moet worden opgelost, zou ik wel op prijs stellen.”

Joost: “Je moet aan de ene kant businesskennis hebben, en aan de andere kant heb je kennis nodig van de systemen en de automatiseringsmogelijkheden. Dat geldt ook voor de enterprise architect, maar dan op een iets hoger niveau. Die heeft minder kennis van de domeinen, maar overziet nog beter hoe die domeinen met elkaar in verband staan.”

Een architect moet een vertrouwensrelatie hebben met de opdrachtgever. Als die er niet is, dan moet de opdrachtgever een andere architect nemen.

Joost: “Ik denk dat toen wij net met architectuur begonnen, er in de IT-sfeer wel degelijk een stukje weerstand was tegen de architectuur. Hè, weer zo’n club die zich er tegenaan gaat bemoeien hoe we het gerealiseerd moeten krijgen.”

Frank: “Met scepsis: ‘eerst zien, dan geloven’. Weer een partij die het potentieel moeilijker maakt en ons afremt. Ik zie dat dat door de jaren heen aan het veranderen is. Het gaat steeds beter en de architect wordt steeds meer gewaardeerd. Zeker als we zelf wat blunders maken omdat we denken dat we het wel zonder architect kunnen.”

Zijn er zaken waarvan jij vindt dat architecten daarmee moeten ophouden?

Frank: “Al te methodisch werken. Sommige architecten kunnen doorschieten door het mechanisch gebruiken van check lists. Dat dient in het algemeen niet de kwaliteit van het architectuuradvies.
Je moet je als architect echt verdiepen in de ontwerpproblematiek. Wat je opschrijft is een product, maar dat is geen doel op zich. Het denkwerk dat je doet en het korte en bondige advies dat je geeft, vind ik het belangrijkste. Ik vind het gevoel dat je wat aan een architect hebt om je te helpen een probleem op te lossen, veel belangrijker dan een stukje papier.

Een architect is ‘part of the team’ en niet toevallig een instantie waar je langs moet om een kwaliteitsstempel te halen, of waar je doorheen moet om je project er door te krijgen. Zo zou het niet moeten zijn, hoewel dat wel op de loer ligt als de architecten te weinig tijd hebben. Je moet je architecten voldoende tijd geven om hun werk goed te doen, anders krijg je dat architectuur bedrijven verwordt tot alleen maar een formuliertje invullen. Dat is geen echt inhoudelijke bijdrage.”

[PDF]