13 minute read
High up in an organization, you’re busy with
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.
Advertisement
René Raaijmakers
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.”
System thinking
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. “Every
thing 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 spunoff 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.”
“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.”
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.
At the Bits&Chips System Architecting Conference, 24 September 2020 at Igluu in Eindhoven, Ben Pronk will deliver the keynote speech. He’ll talk about what has actually changed for system architects and what the constant factors are. Pronk will also extensively discuss whether there’s still room for system engineering with the speed of product development and digitalization. The complete interview is available on bits-chips.nl.
