Maand: mei 2018

Met een kleine twintig jaar ervaring in systeemarchitectuur verhuisde Gerrit Muller in 1999 van ASML naar Philips Research. Hij vroeg of er interesse was in een cursus op zijn vakgebied. Hij broedde daar al een paar jaar op: hoe hij mensen kon bekwamen in zijn vak systems architecting.

Muller startte in die tijd ook zijn inmiddels vermaarde Gaudi-website waarop hij informatie over systeemarchitectuur vrij toegankelijk maakt. ‘Ik zag dat er weinig mensen waren die het vak begrepen, laat staan konden uitoefenen’, zegt hij daarover. ‘Ik was zo onbescheiden om te denken dat ik het wel wist.’

De kiem werd twee jaar eerder gelegd, toen Muller overstapte van Philips Medical Systems naar ASML. Om de kennis die hij in de medische apparaten had opgebouwd over te dragen, organiseerde hij een week lang interactieve sessies. ‘Dat ging niet erg gestructureerd, maar de deelnemers waardeerden het zeer’, herinnert hij zich.

Gerrit Muller – Grondlegger van de SYSARCH training

Deze kennissessies herhaalde hij, toen hij ruim twee jaar later van ASML naar Philips Research overstapte. ‘Bij ASML had ik veel bijgeleerd. Ik ontdekte bovendien hoe leuk het is om anderen te helpen om het onder de knie te krijgen. Toen ik in Veldhoven wegging heb ik aangeboden om één week training te geven in systems engineering.’

Muller zag dat bijna alle bedrijven een tekort hadden aan architecten. Hij constateerde ook dat dit leidde tot problemen in de systeemontwikkeling, iets dat vooral in de systeemintegratie de kop op stak en zich daarnaast uitte in problemen in het veld. Vooral het laatste is kostbaar en pijnlijk. Terwijl je het kunt voorkomen door met een integrale bril te kijken naar de monodisciplinaire gezichtspunten die er al zijn’, aldus Muller.

Het was Vincent Ronteltap van Philips Centre for Technical Training (CTT) die Mullers aanbod zag zitten. De programmamanager voor trainingen adviseerde de aanstaande docent om deelnemers tijdens de systeem-architectuurtraining ook aan praktische opdrachten te laten werken. Daarmee leverde hij een cruciale bijdrage’, zegt Muller. Ook de huidige trainers bij High Tech Institute kiezen steeds opnieuw een unieke case waaraan de deelnemers gedurende de hele week werken en die ze op de laatste dag ook daadwerkelijk moeten pitchen.

De opdracht – het is altijd een praktische case op maat – loopt als een rode draad door de vijf trainingsdagen. Elke dag werken de deelnemers een aantal uren aan de case, geïnspireerd door de theorie en talloze praktijkvoorbeelden die aan bod komen.

Zoals alle trainingen bij Philips CTT was Sysarch in de beginjaren alleen toegankelijk voor deelnemers binnen de Philips-organisatie. Dankzij mond-tot-mondreclame werd de cursus snel populair binnen de productdivisies van het gloeilampenconcern en kon CTT de training zonder probleem vier keer per jaar uitrollen.

Naast open inschrijving startte Muller ook met in-huis varianten. Met open inschrijvingen zit er veel waarde in kruisbestuiving’, legt Muller uit. ‘Het is vaak een feest van herkenning: mensen ontdekken dat in andere organisaties, domeinen en systemen dezelfde soorten problemen spelen.’ In-house cursussen geven juist weer de mogelijkheid om iets dieper op specifieke systemen en organisaties in te gaan. Ook dat heeft duidelijk zijn waarde.’

In de kern behandelt de training tien gezichtspunten op systeemarchitectuur, zoals requirements engineering, key drivers en strategieën voor systeemintegratie – ieder gemiddeld een halve dag. Deze invalshoeken en kennisdomeinen evolueren overigens. Sinds een aantal jaren geleden komen bijvoorbeeld ook scrum en agile technieken aan bod. In de cursus simuleren we wat een systeemarchitect in zijn hoofd continu doet: heel snel meerdere gezichtspunten de revue laten passeren’, aldus Muller.

Mullers training was zo succesvol dat hij tijdens een bijeenkomst van de System Architecture Study Group vroeg om bijstand. De daar aanwezige Ger Schoeber voelde daar wel wat voor. Het leek hem een spannende uitdaging. Hij had volop ervaring opgedaan in de systeemontwikkeling bij High Tech Automation en Ordina en werkte nog niet zolang als zelfstandige. Schoeber: ‘Ik heb er kort over nagedacht. Het geven van presentaties of op een podium staan is niet mijn eerste natuur en dit gaf me een mooie kans om mijn comfort zone op te rekken.’

Na een gesprek met Gerrit Muller en de programmamanager van Philips CTT kreeg Schoeber september 2002 zijn vuurdoop met een vijfdaagse Sysarch. Ik had absoluut de indruk dat de zestien deelnemers eigenlijk veel meer systeemarchitectuur-ervaring hadden dan ikzelf’, lacht de man die de training inmiddels vijftien jaar met veel succes geeft.

Ger Schoeber – docentenopleiding Systeem Architect(ing)

Schoeber was in zijn eerste Sysarch-jaren getuige van een sterke groei. Het aantal edities steeg en er kwam meer trainingsmateriaal beschikbaar. Gerrit Muller was inmiddels begonnen aan een promotie op het onderwerp systeemarchitectuur en zijn bevindingen werden vaak meteen doorvertaald naar onderwerpen voor de training.

Daarnaast leerde Schoeber zelf veel van zijn eigen ervaringen in projecten. Hij was tien jaar lang betrokken bij kleine en grotere multidisciplinaire projecten bij OEM’s. Sinds 2011 is hij in dienst bij Hotraco en vult hij bij de agri-onderneming de rol in van innovatie- en technologiemanager. In al die gevallen 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.’

Nadat Gerrit Muller in 2004 promoveerde op CAFCR(Customer objectives, Application, Functional, Conceptual, Realization), gaf Schoeber dit framework steeds meer een expliciete plek in de training. ‘Ik ben de CAFCR-methode zelf voor het eerst gaan toepassen in 2005, waarbij ik in een project als systeemarchitect verantwoordelijk was. Dat heeft me heel veel inzicht, waarde en ervaring opgeleverd.’

In 2011 droeg Philips Centre for Technical Training zijn totale portfolio over aan expert-bedrijven in de regio Eindhoven. Dit leidde korte tijd later tot de oprichting van High Tech Institute, dat de trainingen in samenwerking met de expert-partijen op de markt brengt.

Van 2011 tot 2016 maakte de Sysarch trainingen een mooie evolutie door. In de Philips-tijd kwamen deelnemers vooral uit de Philips-productdivisies en grote spin-off bedrijven als ASML, Fei en NXP. Tegenwoordig is de bezetting veel meer gevarieerd. Tijdens de editie van oktober 2017 namen bijvoorbeeld veertien verschillende bedrijven deel. Slechts twee daarvan stuurden twee deelnemers.

Dat onderstreept de waarde die de Sysarch-training met open inschrijving heeft: deelnemers maken kennis met andere professionals die met dezelfde problemen worstelen.

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.