René Raaijmakers
28 May

‘System architecting under extreme circumstances’ is how you could describe Guido de Boer’s job at Mapper over the past fourteen years. In a series of interviews in the run-up to his keynote at the Dutch System Architecting Conference on 20 June, he shares with Bits&Chips his unconventional view on developing systems.

“We’ve done lots of things wrong at Mapper, otherwise we wouldn’t have had to file for bankruptcy. But we’ve also done a few things well,” says Guido de Boer. He was developing an electron lithography machine at Mapper from 2004 until the company closed its doors at the end of 2018. While Marco Wieland was the scientific brain and Bert-Jan Kampherbeek managed the organization, De Boer was responsible for the development and construction of the entire e-beam device.

Being asked what he did at Mapper, De Boer’s answer is “architecture”. “It’s thinking about what you need. To be able to do lithography with electrons, I needed a vacuum wall, a frame and a mu-metal shield to block the earth’s magnetic field. We also had to be able to maintain the machine and its footprint had to be ten times smaller than the competition’s.”

Where do you start?

“With simple addition. It needed an electron source and a lens. It took a 300-millimeter wafer. It also had to make a stroke of plus or minus 150 millimeters and we had to be able to access it for servicing. It needed sensors and a mirror. Everything takes up space. It’s a sum of wafer format, punching space, mirror space and some small details.”

De Boer fed everything into the Mathcad mathematical toolbox. With the push of a button, he got the footprint, the precious floor space his machine would occupy in the cleanroom. “No mechanical engineer worked on this. You can calculate it by recording everything in the Mathcad software. The mechanical engineers within our company found that very strange. They sit behind their 3D CAD station and create volumes. That’s what they call it: creating volumes. They don’t calculate, they adjust and measure, to see if they can meet the requirements. They’re very creative, but the maturity of their field is seriously lagging behind.”

What do you mean?

“It’s based entirely on experience. That’s why mechanical engineers are insufficiently able to bring their work to a higher level of abstraction. You can be a very good mechanical engineer, but if you only find pleasure in delivering the right solution, you’re sort of a circus artist. That’s a lot of fun. Every time you do your trick, you get applause, but there comes a time when you fall out of that trapeze.”

“Some engineers by nature construct in a very orderly manner, but to do so in six degrees of freedom is really a challenge. With every interface, you have to think about every part in six degrees of freedom. If you don’t do that in a very structured way, with a template, then you’re simply going to make mistakes. If you don’t think about tolerances and whether they still apply after an adjustment, you start adding quadratic errors. So it’s necessary to work more methodically. You can also deal methodically with volume claims and tolerances.”

De Boer underlines his view by pointing to the advantages of future-proof formulas as opposed to drawings with fixed volumes. When he was asked whether 450-millimeter wafers were also possible, he literally only had to change one parameter in his model. “All new requirements and all modules immediately rolled out. I liked that.”

His calculations resulted in tough requirements for his designers. “You have to push this with some dominance. After all, nobody likes it. They didn’t get a millimeter from me. Okay, the boys from the wafer stage had half a millimeter play. Yes, they were very angry.”

You’re not in favor of democracy?

“I’m not in favor of democracy at all, but certainly not in system design. Democracy is great if you want to become happy. But not if you want to be successful. I know few generals who have won the war by asking everyone in the country how many people they should send to which front. Everyone understands that. Litho is just Formula 1. That’s war. That’s about being the best.”

“I’m sure Max Verstappen won’t consult with his team boss when he catches up or starts to apply the brakes. He makes his own plan. That’s his job. He’s not necessarily involved in selecting the tires or the engine. He does have something to say about that. He can review. But someone else is responsible. The team boss determines the process: when the engine and tires and Max Verstappen come together. In engineering, the development boss is responsible.”

“In development, democracy really doesn’t work. Good design is simply a reflection of the organization. Bad design means a total lack of management, process management.”

What’s your approach?

“You can tell your team: boys, just go to a hotel for a day, I’ll order pizza for you and when you’re ready, let me know. That’s an approach, but not mine. I’m more like the Dutch soccer coach Louis van Gaal. I make a plan and want everyone to stick to their task. I make sure that everyone can perform their duties. I check that too. If the Van Gaal team is on the field, then his machine is running. That’s how I do it.”

According to De Boer, the Argentinian coach Alejandro Sabella showed how things should not be done during the 2014 football world cup. “Sabella had no control over Messi. That usually results in a disaster, but it can also turn out well. It did in 2014. Messi was actually the boss and took Argentina to the final, where they lost to Germany. So if you’re lucky, poorly led development teams have a Messi who prevents things from becoming a mess. I’ve seen this in various high tech companies: technicians at lower levels who are very good, bring structure to the organization and make agreements.”

What was the structure at Mapper?

“We had groups and they made parts of the machine. It was my job to specify those parts. I did that as a member of the design leaders group, which was responsible for the entire machine. The members of my team each had a group of thirty to forty people, each working on a module.”

“In my opinion, everyone in a large development organization, at every level of abstraction, needs to have a well-defined scope. Everyone has a clear problem, an interface, requirements, tests, a service with interfaces and a procedure. At Mapper, I was the owner of the whole thing and I broke it down into pieces, in the form of drawings. These included the volume, the interfaces and the names of those responsible.”

“I made agreements with everyone: do we agree that you own this interface? Do you find this sketch clear enough? Can you really use this drawing to agree on the mechanical interface with your friend on the other side? Do you understand that this is really a hard agreement? If so, make a drawing together, grab a couple of scissors and cut that piece of paper. One half goes to John, the other to Mike. That’s your agreement and in six months, we’ll put it back together and match what you’ve delivered.”

“I then regularly visited John and Mike, asking for their pieces of paper, to see if they still fitted. Only when they did, we integrated. Exactly the same we did with software: take a piece of paper, put agreements and protocols on it and cut it in half at the end of the meeting. When the work was finished, we all took the paper with the agreements, entered the commands and looked at the result: the data, the delay, the errors and so on. If this all looked right, they could integrate. I think architecture is about that. No more and no less.’

It’s about making agreements?

“In the form of drawings at an abstract level. In the beginning, I noticed that our software and mechanical engineers had a tendency to coordinate everything. There was a big contrast with electronics, physics and optics. Software people want everything in one release and in one software package. They argue about which operating system to choose and which protocols. All very interesting, but not for end users. So we finally had six operating systems at Mapper.”

This concludes part 1. Stay tuned for part 2 next week. Visit the Dutch System Architecting Conference on 20 June to hear Guido de Boer’s full story on how to apply systematicness and regularity when prioritizing R&D in a start-up and in choosing when to outsource or to purchase.