Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Author:
Reading time: 10 minutes
Naast een fulltime job als innovatie- en technologiemanager bij Hotraco in Horst verzorgt Ger Schoeber een van de populairste trainingen bij High Tech Institute, die voor systeemarchitectuur. Schoeber over de rol, het nut en de valkuilen voor de systeemarchitect.
Ger Schoeber bezocht in 2002 een bijeenkomst van de System Architecture Study Group van Gerrit Muller. Die laatste had op basis van zijn ervaring bij ASML en Philips een nieuwe training opgezet: Sysarch, afkorting voor ‘System architecting’. Deze vijfdaagse cursus liep al een paar jaar en was inmiddels zo populair dat Muller tijdens de meeting vroeg wie er interesse had om bij te springen als docent.
De vraag intrigeerde Schoeber. Hij had volop ervaring opgedaan in de systeemontwikkeling bij High Tech Automation en Ordina en werkte nog niet zo lang als zelfstandige. ‘Op een podium staan is niet mijn eerste natuur en dit gaf me een mooie kans om mijn comfortzone op te rekken. Toen ik september 2002 mijn vuurdoop kreeg, had ik absoluut de indruk dat de zestien deelnemers eigenlijk veel meer systeemarchitectuur-ervaring hadden 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 training. Na Mullers promotie in 2004 nam Schoeber diens methode Cafcr (Customer Objectives, Application, Functional, Conceptual, Realization) over. Dit framework groeide in de jaren daarna uit tot de kern van de systeemarchitectuurtraining. ‘Zelf ben ik de Cafcr-methode als systeemarchitect voor het eerst in de praktijk gaan toepassen in 2005. Dat heeft me heel veel inzicht, waarde en ervaring opgeleverd’, aldus Schoeber.
Vooral die praktijkervaring is waardevol en die deelt Schoeber volop met de cursisten van wie hij er inmiddels ruim duizend zag langskomen. Zelf is hij al bijna drie decennia betrokken bij kleine en grotere multidisciplinaire projecten bij oem’s. Sinds 2011 is hij in dienst bij Hotraco, een agri-onderneming waar hij de rol van innovatie- en technologiemanager invult. ‘De afgelopen jaren heb ik de Sysarch-theorie ook in de praktijk kunnen toepassen. Het leverde mij veel waarde op voor mijn eigen projecten en directe ervaringen met het toepassen van het materiaal, iets dat ik weer mooi kon inzetten als voorbeelden in de training.’
Businesscase-denken
De systeemarchitect is verantwoordelijk voor de technische realisatie van een product of subsysteem. Altijd is het iemand met vele jaren ontwikkelervaring. Die achtergrond en technische bagage zijn onontbeerlijk. Maar de systeemarchitect moet vooral over sociale vaardigheden beschikken om zijn rol te kunnen vervullen, want hij staat in contact met alle belanghebbenden. Niet alleen met de mensen in zijn ontwikkelteam en toeleveranciers, maar ook met zijn management, investeerders, klanten en eindgebruikers.
Schoeber ziet sporadisch niet-gemotiveerde cursusdeelnemers. Vaak zijn het technici die door hun baas zijn gestuurd. Schoeber acht ze ongeschikt voor een rol als systeemarchitect. ‘Systeemarchitecten zijn proactief en moeten de leiding willen nemen in de technische ontwikkeling. Ze zijn per definitie gemotiveerd, willen vooroplopen. Ze hebben ook een visie: daar gaat het naartoe. Het geloof en vertrouwen daarin moeten ze ook uitstralen.’
Dat heeft consequenties voor de manier waarop systeemarchitecten zich opstellen binnen een organisatie. Ze moeten sterk in hun schoenen staan en nee durven zetten. ‘Als ze onvoldoende vertrouwen hebben in de succesvolle afronding van een project, dan moeten ze de opdracht niet aannemen. Eigenlijk dienen ze dan per direct te zeggen: deze doe ik niet. Want als systeemarchitecten er geen vertrouwen in hebben, dan slaat dat meteen terug op de mensen in hun team. Dat stralen ze uit. Non-verbaal en noem maar op.’
Inschatten of een ontwikkeling kan slagen, of iets technisch realiseerbaar is en tot commercieel succes kan leiden, hoort bij de taak van een systeemarchitect. Schoeber: ‘In dat laatste zit vaak de uitdaging. Technisch kan iets een leuke klus zijn, maar heeft het ook waarde voor de klant en voor de business? Die twee laatste stappen benadrukken we ook in de training. Systeemarchitecten moeten verder denken dan alleen aan het fantastisch leuke technische aspect. Het moet ook passen voor een klant. Dat betekent dat ze vanuit een klant moeten kunnen denken.’
Behalve dat ze moeten beschikken over empathisch vermogen dienen systeemarchitecten de waarde voor de business niet uit het oog te verliezen. ‘Je kunt iets fantastisch maken en de klant heel blij maken door het haast voor niets aan te bieden, maar dan heeft het geen businesswaarde. Dus ook businesscase-denken is belangrijk voor de systeemarchitect.’
Wat zijn de grootste valkuilen voor systeemarchitecten?
‘Dat ze onvoldoende voor hun team gaan staan en zeggen: ik heb er vertrouwen in dat dit gaat lukken. Want als je dat zelf niet hebt, dan gaat het ook niet lukken. Een nog grotere uitdaging is vanuit de klant denken. Vaak zeg ik dat je niet puur moet maken wat de klant vraagt, maar wat hij nodig heeft. Ik stel dan de vraag: probeer eens aan de andere kant te gaan staan. Verplaats je. Wat zou je als klant willen hebben? Waar wil je mee geholpen zijn? Als je een subsysteem moet maken dat in een groter geheel wordt geïntegreerd, stel je dan op als de partij die jouw stuk moet integreren. Waar wil je dan mee geholpen zijn? Is er iets extra’s nodig dat het integreren of verifiëren makkelijker maakt? Als je vanuit die positie gaat denken, dan ontdek je dat je meer moet doen dan eenvoudigweg uitvoeren wat er in de requirements staat.’
Waarom is dat verplaatsen in een andere positie zo moeilijk? Het klinkt juist zo makkelijk?
‘Dat is het allermoeilijkste. Niet iedereen beschikt over voldoende empathisch vermogen. Inleven is misschien voor mannen nog wel moeilijker. Vrouwen kunnen beter emotie ervaren en zich verplaatsen in een ander. Daarvoor moet je je ook kwetsbaar durven opstellen. Mannen zijn toch meer macho: kijk eens wat ik gemaakt heb. Het zou mooi zijn als meer vrouwen de rol van systeemarchitect pakken.’
Dus het is niets voor de diehard technicus die graag technisch wil uitmunten?
‘Die moet geen systeemarchitect willen worden. Die moet ook vooral blijven doen wat hij leuk vindt: met die techniek bezig zijn en daar specialist in zijn en blijven. Techneuten kunnen heel goed oplossingen bedenken, maar om een commercieel succesvol product te maken, moet je je ook afvragen wat nou eigenlijk het probleem is. Dat betekent dat je moet kunnen doorvragen: waarom wil je dit eigenlijk hebben? Daarmee dring je dieper tot de werkelijke behoefte door. Want een klant, ook een van de stakeholders, denkt zelf vaak in de oplossingsrichting, in plaats van dat hij probeert uit te leggen wat eigenlijk zijn probleem is.’
Dat is de valkuil voor de klant?
‘De klant heeft zelf al vaak een oplossingsrichting bedacht. Het is verleidelijk om daar als systeemarchitect in mee te gaan: o ja, dat moeten we doen! In plaats daarvan moet je tegengas geven en zeggen: waarom wil je dit eigenlijk en waarom wil je het zo oplossen? Dit is juist waar het door Gerrit Muller bedachte Cafcr-model helpt.’
Wat behelst Cafcr?
‘Het draait helemaal om het verplaatsen in de klant. Daarbij kijk je vanuit vijf gezichtspunten naar de systeemarchitectuur. Slechts twee daarvan gaan over techniek, over de oplossing. De c van ‘conceptual view’ zegt bijvoorbeeld: ik wil draadloos communiceren. Dat is wat algemener dan de r van ‘realization view’, die over de technologie gaat die nodig is om de oplossing te realiseren, bijvoorbeeld bluetooth, wifi of zigbee.’
‘De andere drie gaan over het klantperspectief. Daar zit in mijn beleving de meeste waarde van het Cafcr-framework. De f van de functionele kijk gaat over de specificatie, de requirements: wat verwacht de klant nou eigenlijk van het product of wat verwachten de stakeholders in functionaliteit, kwaliteit en performance? De a van ‘application view’ vraagt dat je naar de bredere context kijkt. In welke omgeving komt het subsysteem of het systeem? Hoe wordt het toegepast? Als je daar een goed beeld van hebt, dan snap je ook wat wel of niet handig is. Dat stelt je in staat om de requirements te verbeteren.’
‘De c van ‘customer objectives’ gaat helemaal over de klant: wat is eigenlijk zijn business? Hoe verdient hij zijn geld? Wat is eigenlijk de leefwereld van zijn klant of de collega die mijn subsysteem gaat inbouwen? Als je dat beter snapt, dan zie je beter wat hij nodig heeft om nog betere business te kunnen doen. Cafcr dwingt mij om niet alleen naar de techniek te kijken, maar ook naar de specificatie en naar de rationale van de requirements. Het stelt me in staat om met oplossingen te komen waar klanten nog meer mee geholpen zijn.’
Inleven in de klant
Als voorbeeld verwijst Schoeber naar Gerrit Muller, die voor zijn promotie bij Philips Medical eind jaren negentig de ontwikkeling van een nieuwe generatie radiologische apparatuur meemaakte. De medische wereld zat toen midden in de overgang van analoog naar digitaal. Bij Philips hadden ze een prachtig systeem ontworpen waarmee radiologen en andere specialisten alles op hogeresolutieschermen konden beoordelen. De Philips-technici ontdekten pas in een laat stadium dat dit niet aansloot op de praktijk. Radiologen hingen foto’s in een lichtbak en als ze tussendoor even de tijd hadden, dan pakten ze hun dictafoon en al wandelend bespraken ze de diagnose en behandeling.
Het team bij Philips kwam tot de conclusie dat ze het niet alleen digitaal moesten aanbieden, maar ook printbaar. Dit kwam pas tijdens de systeemontwikkeling naar boven en is later toegevoegd. Schoeber: ‘Muller liet zien dat het nuttig is om mee te lopen met een radioloog om te kijken hoe die zijn dag vult. Die printfunctie was oorspronkelijk niet ontworpen, maar kwam er naderhand bij. De les is dat je je in een vroeg stadium moet inleven in de belevingswereld van de klant.’
Schoeber raadt systeemarchitecten dan ook aan een dag mee te lopen met klanten om te ontdekken wat ze echt nodig hebben. ‘Océ doet dat ook. Ze parachuteren hun techneuten in een klantomgeving om te ervaren hoe ze daar met kopieerapparaten en printers werken. Die kennis nemen ze mee terug naar de organisatie.’
‘Ik dwing mezelf ook om regelmatig in een stal te zijn of bij de installateur van onze spullen. Daarmee krijg ik volop ideeën over handige aanpassingen of betere werkwijzen. In de jaren negentig stak ik me tijdens een project voor patiëntmonitoringsystemen een keer in een groene jas met een groene pet en maakte ik in een ziekenhuis vier operaties mee. Toen zag ik wat een anesthesist deed met een patiëntmonitor in een omgeving met bloed en stress. Ik zag daar pas wat er écht nodig was in bediening en functionaliteit. Dat kon ik niet verzinnen achter een bureau. Je snapt de prioriteiten pas als je met de klant meegaat en een dag met hem beleeft.’
De productmanager dient dat toch ook te weten?
‘Ja, die hoort dat te weten. De systeemarchitect hoort van hem wat nodig is en moet dat vertalen naar een specificatie die een multidisciplinair engineeringteam vervolgens onder zijn leiding kan realiseren. Maar als een architect dat alleen hoort en nooit zelf beleeft, dan mist hij die emotie. De productmanager is bovendien vaak buiten, niet op het bedrijf. Dus moet de systeemarchitect af en toe naar de klant.’
Dat is geen verspilde tijd?
‘Dat verdient zich meteen terug. Ooit heb ik een architect mogen begeleiden bij Vanderlande. Die man ging kijken bij een inbedrijfstelling van een systeem voor bagageafhandeling. Daar werken zogeheten commissioning engineers. Hij zag dat die installateurs een workaround hadden bedacht. Ze wrongen zich in bochten, maar herkenden dat niet meer als probleem omdat ze eraan gewend waren. ‘O, kan het ook anders?’, reageerden ze verbaasd toen ze van de architect hoorden dat hij in het systeem een functie zou kunnen opnemen die hun veel werk zou besparen. Je zou naar al die installateurs een enquête kunnen sturen, maar je krijgt waarschijnlijk veel meer informatie door een dag mee te draaien.’
Het is ook een vaardigheid om de kennis goed over te brengen op het team. Toen Schoeber bij Philips aan een high-end afstandsbediening werkte, gaf hij de opdracht aan een teamlid om alle infrarood-protocollen in te leren. De technicus kwam trots terug met het resultaat: zijn prototype kon behalve 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 remote control moest de infraroodsignalen in het omgevingslicht juist uitfilteren.’
Hoe leer je dat goed over te dragen?
‘Het is geen zaak van zo goed mogelijk specificaties opschrijven en dat naar je engineeringteam sturen. Je moet het tot in den treure blijven uitleggen en herhalen. Het menselijk brein werkt nou eenmaal anders dan een computergeheugen. Systeemarchitecten kunnen zich niet verschuilen achter een uitspraak als: ‘Maar dat had ik toch al gezegd?’ Je moet steeds opnieuw hetzelfde uitleggen, blijven herhalen, anders komt het niet binnen.’
‘Dan gaat het niet om technische details, maar meer om de strategie en de visie van het project. Wat is het doel dat we willen bereiken? Wat is het eindpunt? Dat moet helder zijn. Het eindpunt is iets dat technisch werkt en betrouwbaar is, maar er is ook een deadline. Als je een product op een beurs wilt introduceren, dan is dat de keiharde deadline. Dan moet je soms een weg binnendoor pakken om het voor elkaar te krijgen.’
Balans is de sleutel
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 business en kunnen de salarissen niet worden betaald. De architect zit midden in dat spel. Zijn eigen engineers willen het beste product maken, maar het moet geen gold plating worden. De klant moet uiteindelijk wel waarde krijgen voor zijn geld. Hij betaalt. De architect moet ook zorgen dat er blijvende business is. Denk aan productie, eenvoudig onderhoud en toekomstige generaties. Rekening houdend met al die belangen en stakeholders moet hij iets realiseren.’
