De die-hard technische expert moet vooral geen systeemarchitect worden

Gepubliceerd op: 09 mei 2018

Auteur:

René Raaijmakers

Technisch schrijver, auteur, algemeen directeur

Lees meer over René Raaijmakers

Expert:

Ger Schoeber

Content partner, course leader, trainer

Lees meer over Ger Schoeber

Deel

---

Ger Schoeber geeft een van de populairste trainingen aan het High Tech Institute, in systeemarchitectuur. Hij doet dit naast zijn fulltime baan als groepsleider en domeinexpert system engineering bij Lightyear. Schoeber over de rol, het nut en de valkuilen voor de systeemarchitect.

Ger Schoeber woonde in 2002 een bijeenkomst bij van de System Architecture Study Group van Gerrit Muller. Muller had een nieuwe opleiding opgezet op basis van zijn ervaring bij ASML en Philips: Sysarch, kort voor ‘Systeemarchitectuur’. Deze vijfdaagse cursus liep al een paar jaar en was inmiddels zo populair dat Muller tijdens de bijeenkomst had gevraagd wie er interesse had om bij hem als docent aan de slag te gaan.

De vraag intrigeerde Schoeber. Hij had ruime ervaring in systeemontwikkeling bij High Tech Automation en Ordina en werkte nog niet zo lang als zelfstandige. Ik was niet thuis op een podium en dat gaf me een mooie kans om mijn comfortzone op te rekken. Toen ik in september 2002 mijn vuurdoop kreeg, had ik absoluut de indruk dat die zestien deelnemers eigenlijk veel meer ervaring hadden met systeemarchitectuur dan ikzelf’, lacht Schoeber.

Gerrit Muller promoveerde in die jaren op systeemarchitectuur, een onderwerp dat in de academische wereld niet erg serieus werd genomen. Zijn bevindingen werden vaak meteen vertaald naar onderwerpen voor de opleiding. Na de promotie van Muller in 2004 nam Schoeber zijn methode CAFCR (Customer Objectives, Application, Functional, Conceptual, Realization, uitgesproken als: kafkar) over. Dit raamwerk groeide in de jaren daarna uit tot de kern van de systeemarchitectuurtraining. Zelf heb ik de CAFCR-methode in 2005 voor het eerst in de praktijk toegepast als systeemarchitect. Dat gaf me veel inzicht, waarde en ervaring,’ zegt Schoeber.

Bovenal is praktijkervaring waardevol en Schoeber deelt dit met de meer dan duizend deelnemers aan zijn cursussen. Hij is al bijna drie decennia betrokken bij kleine en grotere multidisciplinaire projecten bij OEM’s. Sinds 2011 is hij in dienst bij Hotraco, een agri-bedrijf waar hij de rol van innovatie- en technologiemanager vervult. ‘De afgelopen jaren heb ik de theorie van Sysarch in de praktijk kunnen toepassen. Het heeft veel waarde gegeven aan mijn eigen projecten en directe ervaringen opgeleverd met het toepassen van de materie, iets wat ik weer als voorbeelden heb kunnen gebruiken in de trainingen.’

Jezelf verplaatsen in de klant lijkt vanzelfsprekend, maar het is het moeilijkste van alles, zegt Ger Schoeber.

Zakelijk denken

De systeemarchitect is verantwoordelijk voor de technische realisatie van een product of subsysteem. Systeemarchitecten hebben altijd jarenlange ontwikkelervaring. Zowel deze achtergrond als de technische bagage zijn onmisbaar. Maar systeemarchitecten moeten ook sociale vaardigheden hebben om hun rol te kunnen vervullen, want ze staan in contact met alle belanghebbenden. Niet alleen met de mensen in het ontwikkelteam en leveranciers, maar ook met het managementteam, investeerders, klanten en eindgebruikers.

Schoeber ziet sporadisch ongemotiveerde cursisten. Dit zijn vaak technici die door hun baas op cursus zijn gestuurd. Schoeber vindt ze ongeschikt voor een rol als systeemarchitect. Systeemarchitecten zijn proactief en moeten het voortouw nemen in de technische ontwikkeling. Ze zijn per definitie gemotiveerd, willen voorop lopen. Ze hebben ook een visie: daar gaat het om. Ze moeten ook hun geloof en vertrouwen uitstralen.’

Dit heeft gevolgen voor de manier waarop systeemarchitecten binnen een organisatie werken. Ze moeten sterk en zelfverzekerd zijn en nee durven zeggen. Als ze niet genoeg vertrouwen hebben in het succesvol afronden van een project, moeten ze de opdracht niet aannemen. Eigenlijk zouden ze meteen moeten zeggen: Ik ga dit niet doen. Want als systeemarchitecten er geen vertrouwen in hebben, pikken de mensen in hun team dat meteen op. Ze stralen het uit, non-verbaal.

Beoordelen of een project kan slagen of niet, of iets technisch haalbaar is en tot commercieel succes kan leiden of niet, maakt deel uit van de taak van een systeemarchitect. Schoeber: ‘De uitdaging ligt vaak in dat laatste. Technisch kan iets leuk zijn, maar heeft het ook waarde voor de klant en voor de business? We benadrukken ook de laatste twee stappen in de training. Systeemarchitecten moeten verder denken dan alleen het fantastische technische aspect. Het moet ook goed zijn voor de klant. Dat betekent dat ze vanuit het oogpunt van de klant moeten kunnen denken.

Naast inlevingsvermogen moeten systeemarchitecten de waarde van het project voor het bedrijf niet uit het oog verliezen. Je kunt iets fantastisch maken en de klant heel blij maken door het voor niets aan te bieden, maar dan heeft het geen zakelijke waarde. Zakelijk denken is dus ook belangrijk voor de systeemarchitect. ‘

Wat zijn de grootste valkuilen voor systeemarchitecten?

Dat ze niet genoeg voor hun team opkomen en zeggen: Ik heb er vertrouwen in dat dit gaat lukken. Want als je dat gevoel zelf niet hebt, dan zal het niet werken. Een nog grotere uitdaging is denken vanuit de klant. Ik zeg vaak dat je niet alleen moet maken waar de klant om vraagt, maar dat je moet maken wat de klant nodig heeft. Ik stel de vraag: probeer aan de andere kant te staan. Verander van plaats. Welk eindresultaat zou jij als klant willen hebben? Waar heb je hulp bij nodig? Als je een subsysteem moet maken dat geïntegreerd wordt in een groter geheel, stel jezelf dan voor als de partij die dat stuk moet integreren. Waar heb je dan hulp bij nodig? Is er iets extra’s dat integratie of verificatie makkelijker maakt? Als je vanuit die positie gaat denken, ontdek je dat je meer moet doen dan alleen uitvoeren wat er in de requirements staat.

Waarom is het zo moeilijk om je in iemand anders schoenen te verplaatsen? Het klinkt zo makkelijk?

“Dat is het moeilijkste. Niet iedereen heeft voldoende empathisch vermogen. Empathie is misschien nog wel moeilijker voor mannen. Vrouwen kunnen beter emotie ervaren en zich verplaatsen in de positie van een ander. Daarvoor moet je je ook kwetsbaar durven opstellen. Mannen zijn meer macho: kijk eens wat ik heb gemaakt. Het zou mooi zijn als meer vrouwen de rol van systeemarchitect op zich zouden nemen.

Dus het is niets voor de diehard technicus die technisch uitmuntend wil zijn?

Nee, technici moeten nooit systeemarchitect willen worden. Ze moeten vooral blijven doen wat ze graag doen: actief zijn met hun techniek en daar specialist in zijn. Technici kunnen heel goed zijn in het bedenken van oplossingen, maar om een commercieel succesvol product te maken, moet je je ook afvragen wat het probleem is. Dat betekent dat je moet kunnen vragen: waarom wil je dit eigenlijk? Hiermee dring je dieper door tot de echte behoefte. Want een klant, ook een van de belanghebbenden, denkt vaak aan de oplossing, in plaats van dat hij probeert uit te leggen wat zijn probleem is. ‘

In samenwerking met Incose-NL (International Council on Systems Engineering) en de hightech tijdschriften Bits & Chips en Mechatronica & Machinebouw organiseerde het High Tech Institute onlangs de Nederlandse conferentie System Architecting. Schoeber was voorzitter.

Is dat de valkuil van de klant?

De klant heeft vaak zelf een oplossingsrichting bedacht. Het is verleidelijk voor de systeemarchitect om zijn voorbeeld te volgen: Oh ja, dat moeten we doen! In plaats daarvan moet je dat tegengaan en zeggen: Waarom wil je dit en waarom wil je het op die manier oplossen? Dit is precies waar het CAFCR-model van Gerrit Muller helpt.

Wat betekent CAFCR?

Het gaat erom dat je in de huid van de klant kruipt. Daarbij bekijk je de systeemarchitectuur vanuit vijf gezichtspunten. Slechts twee daarvan gaan over technologie, over de oplossing. De C van ‘conceptual view’ zegt bijvoorbeeld: ik wil draadloos communiceren. Dat is algemener dan de R van ‘realization view’, die gaat over de technologie die nodig is om de oplossing te bereiken, bijvoorbeeld bluetooth, wifi of zigbee. ‘

De andere drie gaan over het perspectief van de klant. Naar mijn mening ligt daar de grootste waarde van het CAFCR raamwerk. De F van de functionele kijk gaat over de specificatie, de eisen: Wat verwacht de klant van het product of wat verwachten de stakeholders aan functionaliteit, kwaliteit en prestaties? De A van ‘application view’ vereist dat je kijkt naar de bredere context. In welke omgeving komt het subsysteem of systeem? Hoe wordt het toegepast? Als je daar een goed beeld van hebt, dan begrijp je ook wat nuttig is of niet. Dat stelt je in staat om de requirements te verbeteren. ‘

Bij ‘De eerste C van klantdoelstellingen’ draait alles om de klant: Wat is precies hun bedrijf? Hoe verdienen ze hun geld? Wat is de leefomgeving van de klant of de collega die mijn subsysteem gaat installeren? Als je dat beter begrijpt, zie je ook beter wat zij nodig hebben om beter zaken te kunnen doen. CAFCR dwingt me om niet alleen naar de technologie te kijken, maar ook naar de specificatie en het waarom van de eisen. Het stelt me in staat om met oplossingen te komen die klanten nog meer helpen.

Als voorbeeld noemt Schoeber Gerrit Muller, die eind jaren negentig bij Philips Medical de ontwikkeling van een nieuwe generatie radiologische apparatuur meemaakte. Op dat moment zat de medische wereld midden in de overgang van analoog naar digitaal. Bij Philips hadden ze een prachtig systeem ontworpen waarmee radiologen en andere specialisten alles konden beoordelen op schermen met een hoge resolutie. De technici van Philips ontdekten pas in een laat stadium dat dit niet overeenkwam met de praktijk. Radiologen hingen foto’s in een lichtbak en als ze tussendoor even tijd hadden, pakten ze hun dictafoon en bespraken ze al lopend de diagnose en behandeling.

Schoeber: ‘Muller liet zien dat het nuttig is om met een radioloog mee te lopen om te zien hoe hij zijn dag doorbrengt. Die printfunctie zat niet in het oorspronkelijke ontwerp, die is later toegevoegd. De les is dat je je in een vroeg stadium moet inleven in de ervaring van de klant.’

Schoeber adviseert systeemarchitecten dan ook om een dag met klanten mee te lopen om te ontdekken wat ze echt nodig hebben. ‘Océ doet dat ook. Ze parachuteren hun technici in een klantomgeving om te ervaren hoe zij met copiers en printers werken. Die kennis nemen ze mee terug naar de organisatie.’

Ik dwing mezelf ook om regelmatig in een kippen- of varkensstal te zijn of samen te werken met de installateur van onze spullen. Dat geeft me volop ideeën over handige aanpassingen of betere werkmethoden. In de jaren negentig heb ik tijdens een project voor patiëntbewakingssystemen eens een groen jasje met groene pet aangetrokken en vier operaties in een ziekenhuis bijgewoond. Ik zag wat een anesthesist deed met een patiëntmonitor in een omgeving met bloed en stress. Toen pas zag ik wat er echt nodig was bij een operatie en welke functionaliteit daarvoor nodig was. Achter een bureau had ik dat niet kunnen bedenken. Je begrijpt de prioriteiten pas als je met de klant meegaat en een dag met ze doorbrengt.

Moet de productmanager dat ook weten?

“Ja, dat zouden ze moeten weten. De systeemarchitect hoort van de productmanager wat er nodig is en moet dat vertalen naar een specificatie die een multidisciplinair engineeringteam vervolgens onder hun leiding kan uitvoeren. Maar als een architect het alleen hoort en nooit ervaart, dan mist hij die emotie. Bovendien zit de productmanager vaak buiten het bedrijf, niet intern. Dus de systeemarchitect moet af en toe naar de klant toe.

Is het geen tijdverspilling?

‘De tijd is meteen terugverdiend. Ik heb ooit een architect mogen begeleiden bij Vanderlande. Hij ging kijken naar de inbedrijfstelling van een bagageafhandelingssysteem. Daar werken zogenaamde commissioning engineers. Hij zag dat die installateurs een workaround hadden bedacht. Ze wrongen zich in bochten, maar herkenden het niet meer als een probleem omdat ze het gewend waren. “Oh, kan het anders?” Ze reageerden verbaasd toen ze van de architect hoorden dat hij een functie in het systeem kon inbouwen die hun werk zou besparen. Je zou een enquête naar al die ingenieurs kunnen sturen, maar je zou waarschijnlijk veel meer nuttige informatie krijgen door gewoon een dag met hen door te brengen.

Het is ook een vaardigheid om de kennis over te dragen aan het team. Toen Schoeber bij Philips aan een high-end afstandsbediening werkte, gaf hij een teamlid de opdracht om alle infraroodprotocollen te leren. De technicus kwam trots terug met het resultaat: zijn prototype kon, naast signalen voor de videorecorder en tv, ook het infrarood van tl-buizen en de zon nabootsen. ‘Mijn collega had me dus letterlijk genomen, want de afstandsbediening moest de infraroodsignalen uit het omgevingslicht filteren.’

Hoe leer je de kennis goed over te dragen?

Het is geen kwestie van specificaties zo goed mogelijk opschrijven en naar je engineeringteam sturen. Je moet het blijven uitleggen en steeds herhalen. Het menselijk brein werkt nu eenmaal niet als een computergeheugen. Systeemarchitecten kunnen zich niet verschuilen achter een uitspraak als: “Maar dat zei ik toch al?” Je moet hetzelfde steeds opnieuw uitleggen, blijven herhalen, anders wordt het niet geregistreerd.

Het gaat niet alleen om technische details, maar ook om de strategie en visie van het project. Wat is het doel dat we willen bereiken? Wat is het eindpunt? Dat moet duidelijk zijn. Het eindpunt is iets dat werkt zoals gespecificeerd en dat betrouwbaar is, maar er is ook een deadline. Als je een product wilt introduceren op een marktevenement, dan is dat de strikte deadline. Dan moet je soms een kortere weg nemen om het voor elkaar te krijgen.”

Uiteindelijk is balans het grote toverwoord voor de architect, zegt Schoeber. Je kunt de beste architectuur bedenken, de beste technologie toepassen, maar als de ontwikkeling te lang duurt, heb je geen bedrijf en kunnen de salarissen niet worden betaald. De architect zit midden in dat spel. Hun eigen ingenieurs willen het beste product maken, maar het moet niet verguld zijn. De klant moet uiteindelijk waar voor zijn geld krijgen. Zij betalen. De architect moet er ook voor zorgen dat er blijvende business is. Denk aan productie, eenvoudig onderhoud en toekomstige generaties. Rekening houdend met al die belangen en stakeholders moet er iets gecreëerd worden.

Dit artikel is geschreven door René Raaijmakers, tech-redacteur van Bits&Chips.