Month: May 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 enrollment 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 – docent training System 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 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 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 systeem architect 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, die 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 gives one of the most popular training courses at the High Tech Institute, in system architecture. He does this in addition to his full-time job as group leader and domain expert system engineering at Lightyear. Schoeber about the role, usefulness and pitfalls for the system architect.

Ger Schoeber attended a meeting of Gerrit Muller’s System Architecture Study Group of in 2002. Muller had set up a new training course based on his experience at ASML and Philips: Sysarch, short for ‘System architecting’. This five-day course had been running for a few years and was now so popular that Muller had asked, during the meeting, who would be interested in joining him as a teacher.

The question intrigued Schoeber. He had extensive experience in system development at High Tech Automation and Ordina and had not been working as a self-employed person for so long. ‘I was not at home standing on a podium and this gave me a great opportunity in which to stretch my comfort zone. When I received my baptism of fire in September 2002, I had the absolute impression that those sixteen participants actually had a lot more experience in system architecting than myself, ‘ Schoeber laughs.

Gerrit Muller received his PhD in system architecture during those years, a subject that was not taken very seriously in the academic world. His findings were often immediately translated into subjects for the training. After Muller’s promotion in 2004, Schoeber took over his method CAFCR (Customer Objectives, Application, Functional, Conceptual, Realization, pronounced as: kafkar). This framework grew into the core of the system architecting training in the years that followed. ‘I myself applied the CAFCR method as a system architect for the first time in practice in 2005. That gave me a lot of insight, value and experience,’ says Schoeber.

Above all, practical experience is valuable and Schoeber shares this with the participants in his courses, of whom there have been over a thousand. He has been involved for almost three decades in small and larger multidisciplinary projects at OEMs. Since 2011 he has been employed by Hotraco, an agri company where he fulfills the role of innovation and technology manager. ‘In recent years I have been able to apply Sysarch theory in practice. It has given a lot of value to my own projects and provided direct experiences with the application of the material, something that I have been able to use once again as examples in the training courses.’

Putting yourself into the client’s shoes seems natural, but it is the most difficult thing of all, says Ger Schoeber.

Thinking business-like

The system architect is responsible for the technical realization of a product or subsystem. System architects always have many years of development experience. Both this background and technical baggage are indispensable. But system architects must have social skills in order to fulfill their role, because they are in contact with all stakeholders. Not only with the people in the development team and suppliers, but also with the management team, investors, customers and end users.

Schoeber sporadically sees non-motivated course participants. These are often technicians who have been sent on the course by their boss. Schoeber considers them unsuitable for a role as a system architect. ‘System architects are proactive and must take the lead in technical development. They are motivated by definition, want to be at the forefront. They also have a vision: that’s what it is all about. They must also radiate their faith and trust in it.’

This has consequences for the way that system architects work within an organization. They have to be strong and confident and dare to say no. ‘If they do not have enough confidence in the successful completion of a project, they should not accept the assignment. Actually they should immediately say: I’m not going to do this. Because if system architects don’t trust it, the people in their team pick up on that immediately. They radiate it, non-verbally.’

Assessing whether a project can succeed or not, whether something is technically feasible and can lead to commercial success or not, is part of the task of a system architect. Schoeber: ‘The challenge often lies in the latter. Technically, something can be a fun job, but does it also have value for the customer and for the business? We also emphasize the last two steps in the training course. System architects need to think beyond just the fantastic technical aspect. It must also be right for a customer. That means that they have to be able to think from a customer’s point of view.’

In addition to having empathy, system architects should not lose sight of the value of the project for the business. ‘You can make something fantastic and make the customer very happy by offering it for nothing, but then it has no business value. So thinking business-like is also important for the system architect. ‘

What are the biggest pitfalls for system architects?

‘That they do not stand up enough for their team and say: I’m confident that this will work out. Because if you do not have that feeling yourself, then it will not work. An even bigger challenge is thinking from the customer’s point of view. I often say that you do not just have to make what the customer asks for, but to make what the customer needs. I ask the question: try to stand on the other side. Change places. What end result would you like to have as a customer? What do you need help with? If you need to create a subsystem that will be integrated into a larger whole, then imagine yourself as the party that needs to integrate that piece. What is it then that you need help with? Is there something extra that makes integration or verification easier? If you start thinking from that position, you discover that you have to do more than simply perform what is in the requirements.’

Why is putting yourself in someone else’s shoes so difficult? It sounds so easy?

“That’s the hardest thing. Not everyone has sufficient empathic ability. Empathy is perhaps even more difficult for men. Women can experience emotion better and put themselves in someone else’s position. For that you also have to dare to be vulnerable. Men are more macho: look what I made. It would be nice if more women took on the role of system architect.

So it’s nothing for the diehard technician who wants to be technically excellent?

‘No, technicians should never want to become system architects. They should, above all, continue to do what they like doing: being active with their technique and being a specialist in that. Technicians can be very good at thinking of solutions, but in order to make a commercially successful product, you also have to ask what the problem is. That means you have to be able to inquire: why do you really want this? With this you penetrate deeper into the real need. Because a customer, also one of the stakeholders, often thinks of the solution, instead of trying to explain what their problem is. ‘

In collaboration with Incose-NL (International Council on Systems Engineering) and the high-tech magazines Bits & Chips and Mechatronica & Machinebouw, the High Tech Institute recently organized the Dutch System Architecting conference. Schoeber was Chairman.

Is that the customer’s pitfall?

‘The customer has often devised a solution direction himself. It is tempting for the system architect to follow their lead: Oh yes, we have to do that! Instead, you have to counteract that and say: Why do you want this and why do you want to solve it that way? This is precisely where the CAFCR model devised by Gerrit Muller helps.

What does CAFCR mean?

‘It’s all about moving into the customer’s shoes. In doing so, you look at system architecture from five viewpoints. Only two of them are about technology, about the solution. For example, the C of ‘conceptual view’ says: I want to communicate wirelessly. That is more general than the R of ‘realization view’, which is about the technology that is needed to reach the solution, for example bluetooth, wifi or zigbee. ‘

‘The other three are about the customer’s perspective. In my opinion, that is where the greatest value of the CAFCR framework lies. The F of the functional view is about the specification, the requirements: What does the customer expect from the product or what do the stakeholders expect in functionality, quality and performance? The A of ‘application view’ requires that you look at the broader context. In which environment does the subsystem or system come? How is it applied? If you have a good idea of ​​that, then you also understand what is useful or not. That enables you to improve the requirements. ‘

‘The first C of customer objectives’ is all about the customer: What exactly is their business? How do they earn their money? What is the living environment of the customer or the colleague who is going to install my subsystem? If you understand that better, you will see better what it is that they need in order to do better business. CAFCR forces me to look not only at the technology, but also at the specification and the rationale of the requirements. It allows me to come up with solutions that help customers even more.’

As an example, Schoeber refers to Gerrit Muller, who experienced the development of a new generation of radiological equipment at Philips Medical in the late nineties. At that time the medical world sat in the middle of the transition from analogue to digital. At Philips they had designed a beautiful system that radiologists and other specialists could use to assess everything on high-resolution screens. The Philips technicians only discovered at a late stage that this did not match the practice. Radiologists hung photographs in a light box and if they had some time in between, they grabbed their dictaphone and whilst walking they discussed the diagnosis and treatment.

Schoeber: ‘Muller showed that it is useful to walk with a radiologist to see how they spend their day. That print function was not in the original design, it was added later. The lesson is that you have to empathize with the customer’s experience at an early stage.’

Schoeber therefore advises system architects to spend a day with customers to discover what they really need. ‘Océ does that too. They parachute their technicians into a customer environment to experience how they work with copiers and printers. They take that knowledge back to the organization.’

‘I also force myself to be in a chicken or pig house regularly or work with the installer of our items. This gives me plenty of ideas about handy adjustments or better working methods. In the nineties, during a project for patient monitoring systems, I once put on a green jacket with a green cap and I sat in on four operations in a hospital. I saw what an anesthetist did with a patient monitor in an environment with blood and stress. Only then did I see what was really needed in an operation and the necessary functionality required. I could not have thought of that behind a desk. You understand the priorities only when you go with the customer and spend a day with them.’

Does the product manager also have to know that?

“Yes, they should know that. The system architect hears from the product manager what is needed and must translate that into a specification that a multidisciplinary engineering team can then carry out under their management. But if an architect only hears it and never experiences it, then they miss that emotion. Moreover, the product manager is often outside the company, not in-house. So the system architect has to go to the customer every now and then.’

Isn’t it a waste of time?

‘The time is immediately recovered. I once had the opportunity to supervise an architect at Vanderlande. He started looking at the commissioning of a baggage handling system. So-called commissioning engineers work there. He saw that those installers had come up with a workaround. They wriggled around corners, but did not recognize it as a problem anymore because they were used to it. “Oh, can it be different?” They reacted amazed when they heard from the architect that he could incorporate a function in the system that would save their work. You could send a survey to all those engineers, but you would probably get a lot more useful information by just spending a day with them.’

It is also a skill to transfer the knowledge to the team. When Schoeber worked at a high-end remote control at Philips, he commissioned a team member to learn all the infrared protocols. The technician proudly returned with the result: his prototype could, in addition to signals for the video recorder and TV, also imitate the infrared of fluorescent tubes and the sun. ‘So my colleague had taken me literally, because the remote control had to filter out the infrared signals in the ambient light.’

How do you learn to transfer the knowledge well?

‘It is not a matter of writing down specifications as good as possible and sending them to your engineering team. You must continue to explain it and repeat it over and over again. The human brain just doesn’t work like a computer memory. System architects cannot hide behind a statement like: “But didn’t I say that anyway?” You have to explain the same thing over and over again, keep on repeating it, otherwise it will not be registered.’

‘It is not just about technical details, but also about the strategy and vision of the project. What is the goal we want to achieve? What is the end point? That must be clear. The endpoint is something that works as specified and that is reliable, but there is also a deadline. If you want to introduce a product at a market event, then that is the strict deadline. Then you sometimes have to take a shortcut to get it done.”

In the end, balance is the great magic word for the architect, says Schoeber. ‘You can think of the best architecture, apply the best technology, but if the development takes too long, you have no business and salaries cannot be paid. The architect is in the middle of that game. Their own engineers want to make the best product, but it shouldn’t be gold plated. The customer ultimately has to get value for their money. They pay. The architect must also ensure that there is lasting business. Think of production, easy maintenance and future generations. Taking into account all those interests and stakeholders, something has to be created.’

This article is written by René Raaijmakers, tech editor of Bits&Chips.