Ben Pronk gained fame as a system architect at several Philips divisions. A year ago, he decided to round off his career by joining a startup in robotic surgery. In the run-up to his keynote at the Bits&Chips System Architecting Conference, we ask him about his 30 years of experience as a system architect.
In the autumn of 2019, Anupam Nayak and Maarten Steinbuch contacted Ben Pronk. With their startup Eindhoven Medical Robotics (EMR), they were working on devices that can drill, saw and mill bone independently during medical interventions. With this technology, they promise to change the surgery game and have the ambition to be a market leader in robots for the operating theatre in 2028. Pronk, a system architect who made a name for himself in countless Philips divisions and spinoffs, saw an opportunity and decided to prove himself once more.
A few weeks later, Pronk selected a chair and a desk between a team of youngsters and a few experienced guys. “I’ve passed the age of sixty and wanted to do something fun again. The medical world and the application are very interesting. What mainly appealed to me was the small scale. The organizations in which I worked consisted of thousands of people. At Philips divisions and later Signify, you have a specialist on hand for each area, or at least someone who can arrange it. Little or nothing has been arranged here. I have to go out for a thermal simulation and order my own PC. I also program it myself,” he says, adding laughingly: “If I have to.”
In the past 30+ years, Pronk saw the system architecting profession evolve. In the 1980s, a system architect was often a domain specialist. Someone with expertise in the dominant technology, such as X-ray or MRI in medical diagnostics. Somebody like that knew everything there was to know about X-rays.
But with digitalization, everything became computer controlled and more intertwined. The boundaries of disciplines blurred. Mechanics, electronics, mechatronics, optics – it all became interwoven with software. Wherever possible, electronics shifted from analog to digital and in the last decade, products also became networked and connected to the cloud.
As a result, the system architect became less and less a specialist in the dominant discipline. Pronk: “Very few products are really monodisciplinary mechanical. Nearly every product these days has an app to go with it. In any case, system thinking is almost a necessity. Of course, there are still architects who work purely on basic techniques such as optics for lenses, but they’re niche specialists. Even small companies can’t develop anything without networking and Wi-Fi.”
How do you see the role and tasks of the system architect?
“For me, there are two sides: the multidisciplinary aspects in R&D and the broader view. The system architect must keep an overview, connect all disciplines and distribute them across the system. The challenge is to organize it optimally. What do you do in software? What in mechatronics? You shouldn’t design everything in mechanics if you can do it in electronics. You shouldn’t do it in electronics if you can do it in software. How do you ensure coherence?”
“Second, the system architect needs to look wider, not just at R&D. He needs to coordinate with marketeers and the people who deal with logistics and manufacturing. You can make a beautiful design, but it also has to fit in with your logistics flow and manufacturing.”
With the growing palette of options and technologies, system architects have to oversee more and more. At the same time, R&D organizations are asking their employees to start thinking at a system level earlier in their careers. This is a problem because experience is essential to be able to do that. Pronk observes that organizations are paying more attention to this in their training and course offerings. “But more effort is needed there.” The nice thing, he says, is that it’s easy to spot system thinking talent. “They’re curious by nature. You recognize them pretty quickly.”
What was the big challenge for system architects in medical systems?
“Optimization. To achieve maximum results with minimal development. Diagnostic devices are large machines and have an almost unlimited demand for new functionality and expansions. You always have to keep up with technological developments: new generations of processors and new programming languages.”
With the digitalization of medical devices, functionality grew overwhelmingly in the nineties. “Everything was possible and we knew that competitors were also chasing after all these new possibilities. In the meantime, we had limited resources, people and knowledge. To fulfill all these wishes, you have to keep innovating your platform. First, you make a coffee grinder with some mechanics, then, suddenly, chips and software have to be embedded. Soon, the 286 microprocessor and your real-time operating system are no longer up to date. That also means you have to work on architectures for your platforms.”
In the nineties, the Fusion project was launched at Philips Medical, with the ambitious goal of covering the entire X-ray portfolio with a single platform. The sharing of operating systems and the reuse of software components had to justify this extensive operation, but at the end of the decade, the effort collapsed.
“One of the solutions to reduce the need for development capacity is to work with platforms and share the software that runs on it. But that’s complex. That was the problem with the Fusion project: we were trying to cover the entire X-ray portfolio. In the end, it was reduced to cardiovascular intervention, to the Allura systems (which support interventions like implanting stents, RR).”
Pronk sketches the R&D rat race for billion-dollar markets where technological opportunities are constantly increasing. “Because of the digital explosion and the necessary software, the development demand is endless. If we at Philips Medical had had ten times as many people or had been able to develop ten times faster, we could have used it all.”
“In software, there have been waves and trends to deal with this growth. Platforms and re-use are examples of this. It’s a treadmill. You have to keep running, deliver sufficient functionality and at the same time keep your system technologically up to date. If you don’t do that, you keep leaning on your old system and at some point, there’s only one solution: starting all over again. That, too, is often an almost deadly action. The Fusion project was such a moment. We had to take a big technological step and nearly suffocated.”
How do system architects ensure that they keep an open view of their world?
“To be perfectly honest, at some point, you have to leave your organization. System architects run the risk of becoming demigods after twenty years. The real risk of such a guru status is that people will no longer question you, even if you say that the earth is flat. Moreover, they hinder the continued growth of others.”
Pronk himself moved from the medical world to the semiconductor division of Philips and later to Signify, the spun-off lighting business. These kinds of moves provide new experiences for system architects but are also a major hurdle. “You may know the tricks of the trade, but you have to build up the domain knowledge for a totally different market from the ground up.”
For the new environment, such a switch also means a substantial investment. “They’re attracting a very expensive colleague who won’t be productive for a while.” At multinationals such as Philips, this job switching is policy. Pronk acknowledges having had exploratory talks with other employers during his time there. During these discussions, potential new employers always asked how long it would take before he would be worth his salary again. Pronk: “For very complex developments in a specialized branch, it can take one or two years before you’re really back on track.”
This isn’t only depressing for the company, but also for the person involved. The new environment sets high expectations. On a new site, system architects have to win the confidence of a team all over again. “I once spoke to a colleague who had just come from another location. He hadn’t proven himself yet and thought it was terrible not to receive the respect he was accustomed to. That’s what’s stopping some people from taking this step.”
How about your switch to semiconductors?
“Chips for the consumer market was a different world compared to medical devices. At Philips Medical, we sold three hundred expensive systems a year. At Semiconductors, we shipped 10 million one-chip TVs in just a few months. You can’t enter a hospital with bad stuff. Diagnostic instruments have to have the right functionality and reliability. Delivery time is important, but if you end up six months late, you won’t go bankrupt. Only when you sell rubbish, you have a real problem. In medical markets, the order of priority was: quality, functionality, costs, delivery time.”
Pronk points out that reality is completely different in the semiconductor market. “You simply have to be on time to enable customers to deliver at Christmas. Otherwise, your chip won’t make it into their TV design and you miss a year’s revenue. Chip factories keep running, costs are huge. That means that time to market comes first, before functionality and quality. Really a totally different mentality.”
This also results in other development considerations. “For three hundred machines a year, the total size of the code isn’t that important. For one hundred million pieces per year, that’s completely different. In that case, it’s worth using a bunch of extra software developers of ten thousand euros a month each to squeeze the software in the cheapest memory possible.”
When you were at Philips Semiconductors, much of the software development shifted to India.
“For us, this was about the availability of people, not about cost. At the turn of the millennium, we couldn’t get them anymore. India was cheaper in the short term, but with Asian salary increases of 10 percent a year, that wasn’t where we profited.”
At Philips Semiconductors (later NXP) in the nineties, R&D was already distributed across several sites worldwide, with software development in Sunnyvale, California, chip integration in Hamburg and systems and software in Southampton. Software in Bangalore was added shortly after 2000. “This kind of distribution inevitably gives more overhead and is at the expense of efficiency. Doing everything in one location remains the most efficient. But at the same time, we had to build up an organization with experience in India. That’s why a few projects, in the beginning, got completely out of control. The problem wasn’t India or Asia, but the initial lack of domain experience. That’s often underestimated. In the beginning, the turnover of people in Bangalore was also very high. That made building a good organization even more challenging. But over time, the departments started to execute very well.”
What impact did distance have on your work as a system architect?
“Apart from traveling, it’s about getting used to cultural differences. Working together is the easy part. In architecture, however, you have to divide the work: where and who has the right competencies? That basically means defining good interfaces: don’t let two sites work on one module. Having complicated interfaces between sites is a disaster waiting to happen.”
“Yes, of course, I overlooked a lot,” Pronk responds to the question to reflect on his biggest mistakes. Over the years, he says he has become more interested in non-technical aspects. “By that, I mean that your organization has to be fit for the task. You can make an architecture, but you also have to have the people to carry out the development and production.”
You also cause problems if your architecture is at odds with the organization. “For example, if you merge or replace functionality that was built by two departments before, you can be sure that there will be conflicts and struggles. The introduction of an architecture is therefore not possible without adjustments in the organization. If you have to change the existing organizational structure, or worse: if departments become superfluous, then there’s work to be done.”
Experience taught Pronk to make more down-to-earth decisions. For example, in the past, he had a strong inclination towards making platforms very future proof by taking into account a lot of reuse. “That meant many layers of abstraction. Over the years, I’ve come to realize that you tend to build in too much extendability too quickly. You’ll never use 90 percent of those extra features again. But what’s much more annoying is that I always found out that the extensions I needed later weren’t there. Customer or product managers always come up with questions you didn’t foresee. My point is: the system architect doesn’t have a crystal ball either. You often put a lot of money and effort into a future that doesn’t come.”
The 10 percent extensions that do turn out to be useful don’t make up for the 90 percent unnecessary costs?
“That’s the question, of course. I don’t dare pass judgment on that.”
Pronk doesn’t have to think long about examples of decisions that have turned out surprisingly well. “I’ve never regretted switching to standard components. At the time of the Fusion project at Philips Medical, for example, we replaced dedicated operating systems with Windows. At Philips Semiconductors, we switched to Linux for TV.”
Those choices weren’t obvious at the time. “Both at Medical and Semiconductors, we had strong internal headwinds. There’s always hesitation. Are Windows and Linux suitable? The general view was that they would be too big, too heavy or not stable enough. But it paid off. It almost always does,” he says. With some self-mockery: “Once you get your own stuff stable.”
So it’s important to use parts of the shelf wherever possible. “Even if standard components don’t seem quite fit for purpose at first glance. It often delivers a lot of benefits. I’ve never regretted that. By the way, the worst thing you can do is rebuild standard components. Then you have the worst of all evils.”
As a system architect, you fight against the urge of your colleagues to add their own tastes and fun ideas?
“There’s often a very big tendency to add bells and whistles. You should limit that as much as possible because particularities make it expensive. But I’m a technician myself, and I admit that I, too, sometimes have a blind spot for that sort of thing.”
Once a colleague said to him, “Ben, I’m not worried until you start to worry.” Without saying it in so many words, Pronk clearly sees the remark as a compliment. It says a lot about the position and responsibility of the people within the organization who keep the technical overview at the highest level.
The disadvantage is that the top architects spend a large part of their time managing managers. “The higher up in an organization you are, the more you’re busy keeping the management calm. You’re the first point of contact for all technical problems. If a difficult project makes little progress, you have to sit down with the CEO every day. Fusion influenced the crown jewels of Philips Medical and had the attention at the highest management levels. When I came to work in the morning, I’d meet the business unit manager at my office, so to speak. At some point, you’re mainly trying to reassure those people.”
“Managers obviously have a frustrating profession. They have very little grip themselves and have to motivate others to execute. If things don’t go well, they’re going to be upset, asking for three reports a day. The senior technicians and the project leaders are the ones who suffer the most from that behavior. They have to keep their bosses well informed and ask for their backing.”
“As a technician, you really need to want this and be able to deal with it. Gaining confidence and speaking a language that non-technicians understand is a skill you can develop, Pronk says. “Not everyone likes that. It’s not just technical in the long run. It’s also about strategy and budgets. As technicians often experience: more nagging on your mind.”
You’re supposed to be a psychologist as well?
“I wouldn’t put it like that. But indeed, you have to be able to deal with people. Because in technical development environments, you have colleagues who don’t like authority, some need a pad on their back and others are quite squarely minded. Then there are the pessimists who always think that things are going wrong and the optimists who always say that tomorrow they’ll meet their deadline. You have to learn to assess those signals. It’s not a job for someone who has a problem communicating.”
Where can things go wrong in contact with managers?
“Transparency is essential. You have to provide inspiration, but at the same time, you have to sketch a reliable picture of product development. That means balancing. No political correctness, but also no doom stories. You always have to paint a realistic picture: the biggest risks, the delays. You have to include managers in scenarios and point out to them that things get technically deadlocked if they don’t make specific interventions or investments.”
“It’s very important to adjust your tone. With a CEO without a technical background, you don’t have to go into the details. Don’t shout at young technicians that we’re going to go bankrupt next month if things continue like this. You have to convey a certain degree of urgency, but not sow panic.”
Pronk underlines that it matters what kind of manager is sitting across the table. “There are big differences.” He experienced seasoned marketing managers who understood how the R&D of a large organization worked, but also the ‘boys in shorts with walnut spectacles’ who mainly went for a fast career.
Customers didn’t respect the latter group. Clients often ask the system architect to be present in discussions to avoid elaborate marketing stories. “Because they know system architects will tell them what’s really going on,” says Pronk.
Forced by corona, Pronk exchanged the hectic startup environment for the kitchen at home at the time of the conversation. “People work at home, their children don’t go to school and we have suppliers who can’t deliver. You see: all our contacts with the medical world are on hold for a while. We don’t send people to a hospital right now. They have a different focus now.”
EMR focuses on robotic systems for operations in the head and neck area. This presents the startup with a major challenge. Anatomically, it’s one of the most complex regions of the human body. There’s a great shortage of surgeons with knowledge and skills in this area. Before specialists are allowed to operate independently in this region, they have to complete a process of eight to twelve years. EMR says that there are at most two competitors in its field. The first systems will assist with the insertion of hearing implants.
To insert an electrode into the cochlea of the ear, a surgeon or robot has to drill through the very hard skull bone. This requires navigation with accuracies of less than a tenth of a millimeter to avoid damaging nerves and blood vessels. Once the narrow entrance to the complex helical cochlear structure has been reached, the electrode must be inserted without damaging the remaining hearing. Due to the lack of experienced surgeons, only one in ten people can currently be helped. The use of robots can potentially change this situation substantially.
EMR focuses its device on the most difficult part of the body. From a system architecture point of view, is it smart to raise the bar that high right away?
“The market evaluation shows that there’s a clear opportunity. Of course, there are piles of technical challenges. Of course, it’s going to be difficult. But we’re in an environment here with extensive experience and knowledge in precision mechanics.”
What’s the biggest challenge?
“The acceptance of the robot. On Dutch roads, an average of two people per day are killed in accidents, but if a Tesla on autopilot kills someone tomorrow, it’s immediately on the front page of the newspaper. People die in traffic every day, but it still takes a while before we drive autonomously. Acceptance for machine mistakes is lower than for human errors.”
“With us, the greatest challenge of all is to get people to accept that a machine drills into a skull by itself. If the robotic arm fails, it penetrates the brain. Even a surgeon sometimes makes a wrong move during an operation. Usually, this ends well, but sometimes it doesn’t. Where things go wrong, that’s annoying, but accepted. The acceptance of a robot only comes with safety and it’s, therefore, a very long process before doctors start working with it in a clinical environment. The whole regulation around it is horrendous.”
“Apart from that, an instrument that drills autonomously into a skull with tolerances of sub-tenths of a millimeter has all kinds of nice challenges, such as image processing to see where you are and real-time control that reacts immediately when a patient starts coughing.”
What role does the system architect play in this?
“Safety is just the first design principle here. Very often with architecture functionality, it’s first and foremost: what does the device have to do? On top of that comes error handling. Safety first applies to all medical equipment these days, but in diagnostics, for example, it’s a little simpler. With treatment machines, safety really is the most important point of attention.”
On the impact of corona: “We don’t yet know what impact this will have. We’re still making progress and in our market, quality is paramount. This whole crisis is causing delays throughout the market, but the need for higher quality and more interventions isn’t getting any less.”