The die-hard technical expert should above all not become a system architect

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.