Systeemarchitect moet begrijpen hoe je waarde genereert, binnen tijd en binnen budget

Als projectmanager, systeemarchitect en crisismanager in de hightechindustrie heeft Luud Engels de reputatie dat hij geen blad voor de mond neemt. Naast zijn advieswerk is hij sinds vorig jaar ook trainer systeemarchitectuur bij High Tech Institute. Een (hernieuwd) kennismakingsgesprek met de nadruk op duidelijk communiceren in complexe ontwikkelomgevingen.

René Raaijmakers

Kom bij Luud Engels niet aan met de opmerking dat we in de Nederlandse hightech zo open en goed communiceren. Hij laat zelfs enkele krachttermen vallen om duidelijk te maken dat het hypocriet is om dat te geloven. ‘Hier in Brabant zijn we helemaal niet zo open. Ga maar eens luisteren bij koffieautomaten. Wij praten niet met jou, we praten over jou.’

Wat direct communiceren – of beter confronteren – betreft, heeft Engels een zekere reputatie. Al weer even geleden mocht hij na enkele maanden zijn biezen pakken nadat hij zich – volgens zijn opdrachtgever – in te sterke bewoordingen uitdrukte wat er mis was binnen het bedrijf. ‘Ik ben er heilig van overtuigd dat alles kan worden gezegd op het goede moment. In een team of tussen twee personen. Dat doen we niet. Maar ik blink er zelf blijkbaar ook niet zo in uit, want ik zeg af en toe iets zo duidelijk dat ze zeggen: sodemieter nu maar op.’

Zijn waardering voor feitelijk en helder communiceren komt uit zijn jarenlange ervaring als projectmanager, systeemarchitect, crisismanager en als lid van het managementteam bij ingenieursbureau TMC. Zijn advies over communicatie in ontwikkelomgevingen: ‘Maak het feitelijk. Spreek uit wat er aan de hand is. Dat mag best persoonlijk zijn. Je kunt zeggen: dat blauwe hemd van jou stoort mij. Maar aan statements als ‘Microsoft is niets en Apple is alles’ heb je niets. Maak het feitelijk: gaan we objectgeoriënteerd of procesgericht werken? Gaan we het in glas of in titanium maken? Wat zijn de voordelen? Wat de nadelen? Een top vijf van belangrijkste criteria is voldoende, niet honderdduizend. Als we het hebben over glassoorten, dan hoef ik niet de hele historie van de glasblazerij te weten, ik wil gewoon de vijf dominante criteria, in getallen, niet in plussen en minnen. Als je weet wat de dominante parameters zijn, weet je ook hoe we deze gaan meten en kunnen we het eens worden over de eerste ontwikkelstappen om de metingen mogelijk te maken.’

Hij onderstreept dat er in de ontwikkeling van hightech systemen meerdere wegen naar Rome leiden en dat het belangrijk is om vast te houden aan een keuze als die eenmaal is gemaakt. ‘Zorg dat het hele team in ieder geval op dezelfde weg zit, in plaats van eindeloos te zoeken naar de enige juiste weg. Die is er per definitie niet.’

Soms gaat het met eenvoudige zaken al fout. ‘Ik kreeg na een gesprek met een klant ooit het gespreksverslag in plat Brabants. We waren het immers eens met de klant. Ik vroeg of de klant de tekst had goedgekeurd. Nee natuurlijk. Dus heb ik er op aangedrongen om een en ander in het Engels op te schrijven zodat het later in het ontwikkelteam kon worden gebruikt, aan de klant voor te leggen en hem akkoord te vragen – het gaat immers vaak over verreikende beslissingen – maar dat bleek toch moeilijk op te brengen.’

Volgens de letter van de wet software ontwikkelen

Engels’ uitgebreide technische loopbaan begon met een studie elektrotechniek, waarna hij aan boord stapte bij Sattcontrol, een Zweedse speler in de industriële automatisering. Hij programmeerde plc’s voor eiersorteermachines, melkfabrieken en geautomatiseerde magazijnen. Later stapte hij over op Fortran voor PDP- en Vax-minicomputers. Het leuke van technische software, zegt Engels, is dat je iets in beweging zet. Hij merkt op dat ‘de rest van programmerend Nederland’ vaak neerbuigend doet over plc-omgevingen. Engels: ‘Ik zou mensen willen adviseren: probeer het eens een keer.’

Na vijf jaar maakte hij de overstap naar Cap Volmac (later Cap Gemini), waar hij projecten deed. Engels werkte vooral in de techniek, maar Cap’s kernactiviteit was de zakelijke automatisering. ‘Daardoor leerde ik oneindig veel over hoe je volgens de letter van de wet computersystemen en software moet ontwikkelen.’

Hij startte voor Cap bij ASML, werkte aan snelwegsignalering bij Rijkswaterstaat en kreeg meer leidinggevende rollen. Ook kwamen er audits bij. Hij schat dat hij zo’n twintig projecten heeft beoordeeld. ‘Je weet na een dag rondlopen wat er aan de hand is en waar het project fout is gelopen’, zegt Engels. Met een glimlach: ‘En zeker niet omdat ik zo slim ben, of zoveel gezien heb, maar vooral omdat ik buitenstaander was.’

Daar gelooft hij heilig in: in de kracht van de buitenstaander. ‘Je komt in bedrijven waar het helemaal is misgelopen en dan mag je een rondje maken en vijf tot tien mensen spreken. Die hebben allemaal een mening over het project in crisis. Je krijgt het hele verhaal te horen. Mensen willen hun ei kwijt. Je hoort wat er fout is en vooral: wat anderen niet mogen zeggen.’

De koppige eigengereide technicus

Dan komt hij op de zwakke plek van technici – een koppige, eigengereide groep waartoe hij ook zichzelf rekent. ‘Wij zijn engineers hè, wij hebben gelijk. Zo denken wij: ‘Ik ben elektrotechnicus en ik heb berekend dat er 5 volt uit de berekening komt. Als jij dat niet snapt, dan reken ik het nog een keer voor je uit, maar het blijft 5 Volt. Jij bent gek, niet ik.’ Terwijl het in projecten vooral om effectief samenwerken gaat. Dat is moeilijk. De een praat in Newtons per vierkante meter, de andere in bits per seconde. De hightech is een grote toren van Babel. Dat begint bij requirements en gaat door tot design en integratie en test. Even zo goed: als ik zelf een project doe en er komt een buitenstaander binnen, dan schiet hij of zij daar ook gaten in.’

Hij komt het liefst binnen als de crisis het diepst is. Een voorbeeld was het Fusion-project, eind jaren negentig bij Philips Medical Systems. Fusion had de ambitieuze doelstelling om bij Philips met één platform de mechanische , elektrische en software constructie voor medische diagnostische systemen af te dekken. Kostenbesparing door hergebruik zou de omvangrijke operatie rechtvaardigden. ‘De directeur schetste zijn probleem simpel: elke maand kwamen er dertig nieuwe ontwikkelaars bij en elke maand kwamen ze hem vertellen dat het project nog twee maanden uitliep.’

Hij komt weer op de kracht van de buitenstaander. ‘Die mag iets zeggen. Hoe dieper de crisis, hoe meer ontvankelijk men is voor de boodschap. Meestal hebben er al mensen naar gekeken. Die legden vingers op zere plekken waar niet naar gewezen mocht worden en konden hun biezen pakken. Of ik de zittende projectleider wilde vervangen, want die kreeg de vertraging ook niet weggewerkt. Maar een crisis gaat niet weg door mensen weg te sturen die de vinger op de zere plek leggen en ik ben de zittende projectleider gaan helpen en samen hebben we ‘crisis contained’ behaald door de scope aan te passen en met early feedback te gaan werken. Een van mijn wetten is: als je een opdracht krijgt van iemand om een crisis te bezweren dan ligt de helft van de schuld bij degene die jou die opdracht geeft. Die is de oorzaak of draagt daar voor een belangrijk deel aan bij.’

Is het tunnelvisie?

‘Let op: je hebt het over zeer bekwame mensen met heel relevante argumenten en met honderd kilo verstand van zaken. Maar gaandeweg is de oplossing of werkwijze in verschillende silo’s ondergebracht. Heel bekwame mensen slijten paden uit waardoor loopgraven ontstaan die zo diep zijn dat je er nog net een beetje bovenuit kunt kijken. Ieder heeft zijn loopgraaf en verdedigt die hardnekkig. Dan hoor je geluiden als: ‘Dit is niet bespreekbaar!’ Als je dat hoort, dan heb je meestal iets te pakken waarop het fout is gegaan en waar dan ook mogelijk een begin van de oplossing ligt.’

Waar zit de oplossing?

‘De eerste wet van crisismanagement is: inperken. Bij Fusion betekende dat: geen dertig mensen per maand erbij maar twintig mensen per maand minder. Scope verkleinen. De diepere oorzaak – mijn mening – was pure zelfoverschatting. Het platformidee voor software alleen is al een forse uitdaging, maar nu ook een platform voor de mechanica en elektronica en dat voor alle diagnostische producten is te veel in een keer. Het is al moeilijk genoeg om elektronica, software en mechanica samen voor een enkel systeem te ontwikkelen, maar om in één project, één platform voor verschillende productlijnen te ontwikkelen, is op zijn minst naïef. Bij Philips Medical moesten ze destijds ook nog samenwerken met ontwikkelaars in Bangalore en ze wilden tegelijk van CCM level 2 naar level 3. Dat was een inkopper. Dat moest meteen stoppen. Je gaat bij een project in crisis niet ook nog eens een verbeterslag doorvoeren.’

‘Vaak is het zo dat de technici allang weten waarop het fout gaat en de bestuurders ook. Beiden hebben gelijk, maar ze vinden elkaar niet in de oplossingsrichting. Heel veel later overigens nog een klus gedaan bij Philips DPS waar ik gezien heb dat Philips forse verbeteringen heeft doorgevoerd. Alleen vingers op zere plekken leggen, mocht nog steeds niet helaas.’

Hoe moet het wel?

Klein beginnen, zegt Engels. ‘Je moet vroege feedback hebben, bij voorkeur een launching customer. Later heb ik het Martin van den Brink bij ASML vele malen horen uitleggen: schroef het eens in elkaar, laat zien dat het werkt. Dan daagde hij mensen uit door te roepen: ‘Die fysica van jou, die werkt niet’. In die vroegtijdige integratie, daar zit ontzettend veel in. Veel later zijn ze dat scrum, agile en rapid development gaan noemen. Elke keer weer die terugkoppeling, vroegtijdig bouwen. Elke zes weken een oplevering, maar wel iets werkends leveren. Zo niet, dan ga je niet verder en dan heb je geleerd waarom het faalt. Dan maar te laat. Wat je zeker niet moet doen, is meer mensen aannemen.’

‘Als technici roepen dat ze tijd nodig hebben om iets te gaan onderzoeken, dan moet je op je hoede zijn. Dat op waarde schatten of afstraffen, daar is Van den Brink ook meester in.’

Een andere noodzaak: ‘Mensen eigenaar maken van een probleem. Zeker in omgevingen met complexe ontwikkelingen, waar ook nog wat moet worden uitgevonden, voelt iedereen zich meester over zijn idee, zijn inzicht. Wij Nederlanders zijn er ook nog eens erg goed in om elke gelegenheid aan te grijpen om daar heel breed over te vertellen. Maar je wilt een volgende stap kunnen zetten. Dat is het enige waarbij een project is gebaat. Als je dus met dertig mensen in een kamer zit en de problemen komen op tafel dan moet de projectmanager, de crisismanager of de systeemarchitect voor elk probleem een verantwoordelijke aanwijzen. Daar hoort ook een deadline en een keiharde beslissing bij.’

Hij zegt dat het bij ASML in de cultuur zit, maar dat ze er daar in het verleden ook wel eens zijn doorgeschoten. ‘Alles krijgt daar een owner. Dat heet daar projectleider. McKinsey heeft bij ASML ooit een analyse gedaan naar projectleiders en de gemiddelde projectgrootte. Waar kwamen ze op uit? Op elk project zaten gemiddeld 1,2 mensen, inclusief de projectleider! Dan loop je het risico dat je mensen gaan strijden om beschikbare resources en de inhoudelijke voortgang naar de achtergrond verdwijnt.’

In kleinere ontwikkelprojecten met tien tot twintig ontwikkelaars kan één persoon zowel de rol van projectmanager als systeemarchitect pakken. Bij grotere projecten met vele tientallen of honderden ontwikkelaars en tien tot honderden leveranciers is het zaak om op te splitsen. Engels heeft ervaring met beide rollen. ‘De productmanager [projectmanager?] definieert het product dat straks in de markt goed zal presteren. Hij stelt budget beschikbaar – vaak te weinig – en onderhandelt met de systeemarchitect of het voor dat geld in die tijd valt te maken. Het is een balanceeract. Bij volwassen producten werkt het anders, maar bij een eerste ontwikkeling wil je zo snel mogelijk een proof of concept. Of in ieder geval een bevestiging dat je ideeën kloppen en je op het goede spoor zit. De projectmanager stelt dus harde deadlines en daarmee moet een systeemarchitect aan de slag.’

‘De projectmanager moet definiëren welk vraagstuk de systeemarchitect nog moet oplossen en met wie. Samen bespreek je de ins en outs, weegt de benefits en **concerns* , voor- en nadelen en dan roept de projectmanager tegen de systeemarchitect: eind volgende week nemen we een besluit! Dat aanjagen, een format verzinnen, mensen betrekken om tot gekwantificeerde uitspraken te komen waarmee je ook echt een afweging kunt maken, daar draait het om.’

In hoeverre moet de systeemarchitect net als de productmanager direct met klanten praten?

‘In de hightech staat dat buiten kijf. Daar trekken productmanager en systeemarchitect samen op. Dat moet. De ene heeft meer businessfocus, de andere kijkt naar de technologie en of het realiseerbaar is. Het zijn twee kanten van dezelfde medaille. En waar deze samenwerking tussen productmanager en systeemarchitect steeds meer gemeengoed wordt, zie ik nog best wel systeemarchitecten die de nodige afstemming met de projectmanager of operationeel management bagatelliseren. Je loopt dan het risico dat een oplossing die perfect aansluit bij de marktbehoefte, uiteindelijk strandt in de realisatiefase.”

Een systeemarchitect heeft grote impact op de productontwikkeling, maar toch vaak een weinig zichtbare rol.

‘Het is een ervaren technicus, maar zijn waarde zit vooral in zijn kijk op de business. Negenennegentig van de honderd keer kent de systeemarchitect de markt waarin zijn product of systeem gaat landen door en door. Dat is nodig om de markt- en producteisen te vertalen naar de systeemeisen en om vervolgens op hoofdlijnen het ontwerp te maken.’

Er is nogal wat ervaring voor nodig om dat niveau te bereiken. Engels constateert dan ook tegelijkertijd dat het begrip systeemarchitect aan inflatie onderhevig is. ‘Tegenwoordig heet alles architect. Een softwarearchitect is meestal een senior softwareontwikkelaar, requirements engineer of iemand die de leiding heeft over de engineering. En waar ik niets ten nadele van zo’n lead engineer zou willen zeggen, is het verschil met de systeemarchitect dat die laatste de business moet kennen, moet begrijpen hoe er waarde wordt gegenereerd en dus snapt waarom het binnen deze tijd en dat geld moet gebeuren.’

‘Dat is ook zo in de bouw. Jouw architect vraagt wat je met je toekomstige huis gaat doen en past daar zijn ontwerp op aan. Ga je veel koken of wil je vooral wijn drinken? Daarom heeft Martin van den Brink het ook zo goed gedaan bij ASML. Hij gaat naar klanten en legt uit wat voor lithosystemen ze nodig hebben. Hij kent de markt als geen ander, sterker, hij dicteert de markt. Dat betekent dat hij de doelen, de timing in de business van chipfabrikanten als geen ander begrijpt. Hoe hun productieprocessen eruitzien. Als ze het hebben over critical dimension en overlay dan kan hij uitleggen dat zijn machine dat ook kan en bovendien onderbouwen waarom.’

Wil je meer weten over systeemarchitectuur en systeemengineering? Kom dan naar de corona-proof Bits&Chips System Architecting Conference op 24 september 2020 bij Igluu in Eindhoven of bekijk de mogelijkheden voor systeemarchitectuurtrainingen bij High Tech Institute.