Category: Interviews

Electro-mechanic actuators, driven by highly efficient and accurate power electronic circuits, are the working horses of the industry. They determine the performance and quality of many industrial processes. High-Tech Systems spoke with Jeroen van Duivenbode, power electronics specialist at ASML, fellow at the Eindhoven University of Technology and trainer at High Tech Institute.

He needs a couple of moments to consider, but then he nods affirmatively: “Yes, there are still products circling the earth that I have designed.” Jeroen van Duivenbode may be working at ASML for close to a quarter of a century, his roots are in aerospace. This background sometimes give him interesting and radically different ideas in the semiconductor world.

Jeroen van Duivenbode: ‘The nice thing about power electronics is that it contains all subdomains of electrical engineering.’

After his MSc degree in power electronics at the Delft University of Technology, Van Duivenbode moved to France to work at – what was then called – Alcatel Espace in Toulouse, now part of Thales Alenia, where he designed power converters for satellite instruments. “That usually concerned radio transmitters and receivers that had to get their power from on-board batteries and solar panels”, he says. “The other side of my work involved simulation models. I did a lot of calculations on power systems for satellites and space stations. Nowadays, you have all kind of tools for that, but back then – in the late eighties and early nineties – we had nothing.”

After five years in France, Van Duivenbode made the switch to Norway, to Norspace, also a specialized company in space electronics. “Among other things, we built surface acoustics wave filters, small quartz-based components that we used to develop high-quality band pass filters. We also delivered systems to the Ariane 5 rocket. You can imagine that we were a little stressed out when her first test flight failed. Luckily, it wasn’t our fault; the malfunctioning was caused by an error in the software. Afterwards, our units were found back in the swamps of French Guiana. They still were operational, although they had fallen back to earth from four kilometers in the air.”

Cosmic radiation

Back in the Netherlands, Van Duivenbode starts working for ASML. In almost 25 years, he has become one of the go-to guys for power electronics. It’s an area of expertise that is certainly not of minor importance for the chip manufacturing systems from Veldhoven. All movements from, for instance, the wafer and reticle stages need hefty power levels, while margins are extremely small. “In the total error budget of the design we are talking about several percent. That translates to the requirement that we have a tolerance of about a tenth of an atom”, Van Duivenbode explains.

As with ASML in general, the work of Van Duivenbode is dictated by Moore’s Law. ‘Furthermore, productivity is an important feature of ASMLs machines. A shorter scan time means faster movements and more power.” And a lot more power because there is a cubic relation between productivity and peak power: doubling the productivity requires a eightfold increase in power. “We have been through several of these doublings. In the old days, the electronics for all motions would fit in a shoebox, now every machine needs several cubic meter of power electronics.”

Because the margin of error is so small, even the faintest disturbance can seriously hamper the system. “Once we were working on a new generation of amplifiers. We had increased the voltage and pushed the mosfets to the limits,” Van Duivenbode recalls. “Within two weeks quite a lot of those mosfets had malfunctioned. We tried to find the cause and eliminated every possible explanation, from EMC to system failures, but everything seemed in order. Only one option remained: cosmic radiation.”

In the old days, the power electronics for all motions in an ASML machine would fit in a shoebox, now every machine needs several cubic meter of power electronics. Credit: ASML

In his earlier career, cosmic radiation was his everyday’s business, but in the semiconductor industry it took Van Duivenbode some efforts to convince his fellow engineers. “Nobody wanted to believe it. So we built a test setup with thousands of transistors. In the lab several broke down every week. Than, we moved the setup to the Municipal Cave in Valkenburg, underneath a thick layer of earth and limestone. After eight weeks, not a single transistor had failed. Since that experiment it is known in the industry that you have to take cosmic radiation into account, not only for big chips, but for small mosfets as well.”

Broad profession

Next to his work at ASML, Van Duivenbode is research fellow at the Eindhoven University of Technology, of course in power electronics. Since several years, he is also trainer at High Tech Institute, for the course ‘Actuation and power electronics’. “That training is interesting for everyone involved in high-precision systems. And that doesn’t necessarily mean nanometers as at ASML”, assures Van Duivenbode. “On micrometer scale it is just as important to see how you can fit the power electronics into your mechatronic system. And even when you talk about something ‘rough’ as the drive system of a car, you still have to make sure it is stable and reliable.”

“Power electronics is a profession that doesn’t stand alone”, he continues. “It is always in the service of the system. No one will ask just for a circuit that can generate a couple of kilowatt. That is not interesting. ”

“The nice thing about power electronics is that it contains all subdomains of electrical engineering. Apart from all standard building blocks for power electronics, like mosfets, diodes and coils, you need to know about analog electronics as well, for accurate measurements, and about digital technologies and VHDL. Electromagnetic compatibility is a theme because high voltages and high currents play into the hands of failures. So you have to understand EMC, just as thermal design since components can heat up quickly. You have to cope with that heat. A heat sink might be the solution but than you have to be aware of capacitive coupling.”

And than there is reliability. “At those high powers, the electronics is pushed to its limits. The PCBs have to work hard, so they are more susceptible to failure”, says Van Duivenbode. “That means you got to know about reliability and lifecycle testing.”

Super conductivity

Van Duivenbode is one of multiple teachers of the training. Apart from power electronics and calculating on magnetic circuits – the parts that Van Duivenbode has taken on him – the course is also about actuators. Linear and planar Lorentz actuators, piezo actuators, they all are covered. Relatively new and promising are the so-called reluctance motors.

“That is a variety in which you let a current flow through a coil and use that to attract a piece of magnet steel, or soft iron”, Van Duivenbode explains. “Reluctance motors can deliver high power densities. The disadvantage is that those forces are highly non-linear and that the motor can only generate pull forces. At the university, in the group of Elena Lomonova, a lot of research is done to find a solution for this non-linearity. When that is found, the high power density makes reluctance motors very attractive for many applications.”

Another emerging technology is super conductivity. “That is already used in, for instance, MRI scanners. There also has been a successful Dutch test to use super conductivity in underground power lines. The principal was proofed, but the project didn’t get any follow-up”, Van Duivenbode explains. “The first windmill with superconducting magnets has been built as well. Those magnets were in the rotor, so the whole superconducting system had to rotate with the blades. Quite an achievement, if you ask me. The next step is to make it economically feasible; someone has to take that step and invest in it.” The industry is not there yet, so superconductivity is still considered exotic in the training.

This article is written by Alexander Pil, tech editor of High-Tech Systems.

When he was a student, he didn’t have the slightest interest in chips, let alone in testing them. Now, Erik Jan Marinissen is an authority in the IC test and design-for-test arena and even teaches on the subject.

Last year, when Erik Jan Marinissen heard that his papers on Design for Test at the IEEE International Test Conference (ITC) had made him the most-cited ITC author over the last 25 years, he didn’t believe it. “I had skipped a plenary lunch session to set up a presentation that I would give later that day when passers-by started congratulating me. For what, I asked them. They explained that it had just been announced that I’m the most-cited ITC author over the past 25 years. Well, I thought, that can’t be right. Of course, I had presented a couple of successful papers over the years, but surely the demigods of the test discipline – the people I look up to – would be miles ahead of me,” tells Marinissen.

Back at home, Marinissen got to work. He wrote a piece of software that sifted through the conference data to produce a ‘hit parade’ of authors and papers. The outcome was clear: not only was he the most-cited author, but his lead over his idols was also actually quite substantial. ITC being the most prominent scientific forum in his field, there was no question about it: Marinissen is an authority in the test and design-for-test (DfT) disciplines (see inset “What’s design-for-test?”).

Credit: Imec

Once he was certain there had been no mistake, Marinissen felt “extremely proud. I’ve won some best-paper awards over the years, but they typically reflect the fashion of the moment. What’s popular one year, may not be anymore the next. My analysis confirms this, actually: not all awarded papers end up with a high citation score. Being the most-cited author shows that my work has survived the test of time; it’s like a lifetime achievement award.”

What’s design-for-test?
A modern chip consists of millions or even billions of components, and even a single one malfunctioning can ruin the entire chip. This is why every component needs to be tested before the chip can be sold. It’s turned on and off, and it needs to be verified that it changed state.
The hard part is: you can’t exactly multimeter every transistor as you’d do with, say, a PCB. In fact, the only way to ‘reach’ them is through the I/O, and a chip has far fewer I/O pins than internal components. Indeed, the main challenge of testing is to find a path to every component, using that limited number of pins.
This task is impossible without adding features to the chip that facilitate testing. Typically, 5-10 percent of a chip’s silicon area is there just to make testing possible: adding shift-register access to all functional flip-flops, decompression of test stimuli and compression of test responses, on-chip generation of test stimuli and corresponding expected test responses for embedded memories. Design-for-test (DfT), in its narrow definition, refers to the on-chip design features that are integrated into the IC design to facilitate test access.
Colloquially, however, the term DfT is also used to indicate all test development activities. This includes generating the test stimulus vectors that are applied in consecutive clock cycles on the chip’s input pins and the expected test response vectors against which the test equipment compares the actual test responses coming out of the chip’s output pins. Chip manufacturers run these programs on automatic test equipment in or near their fabs.

Diverse and interesting

Verifying the calculations that entitled him to a prestigious award might be considered an instinct for someone who has dedicated his life to checking whether things work correctly, but Marinissen and testing weren’t exactly love at first sight. “As a computer science student at Eindhoven University of Technology, I didn’t have much affinity with chips or electrical engineering. We CS students used to look down on electrical engineers, actually. Electrical engineers are only useful for fixing bike lights, we used to joke. I’m sure they felt similarly about us, though,” Marinissen laughs.

Testing seemed even less appealing to Marinissen, for reasons he thinks are still true today. “If you don’t know much about the field, it may seem like testers are the ones cleaning up other people’s messes. That’s just not very sexy. For IC design or process technology development, it’s much easier to grasp the creative and innovative aspects involved. Even today, I very rarely encounter students who have the ambition to make a career in testing from the moment they set foot in the university.”

It took a particular turn of events for Marinissen to end up in testing. “I wanted to do my graduation work with professor Martin Rem because I liked him in general and because he worked part-time at the Philips Natuurkundig Laboratorium, which allowed him to arrange graduation projects there. Like most scientists in those days, I wanted to work at Philips’s famous research lab. But, to my disappointment, professor Rem only had a project in testing available. I reluctantly accepted, but only because I wanted to work with the professor at the Natlab.”

“I soon realized how wrong I was about testing. It’s actually a diverse and interesting field! You need to know about design aspects to be able to implement DfT hardware, about manufacturing to know what kind of defects you’ll be encountering and about algorithms to generate effective test patterns. It’s funny, really. Initially, I couldn’t be any less enthusiastic about testing, but by now, it has been tattooed on my forehead.”

Stacking dies

After finishing his internship at the Natlab in 1990, Marinissen briefly considered working at Shell Research but decided that it made more sense to work for a company whose core business is electronics. He applied at the Natlab, got hired but took a two-year post-academic design course first. Having completed this, Marinissen’s career started in earnest in 1992.

“At Philips, my most prominent work was in testing systems-on-chip containing embedded cores. A SoC combines multiple cores, such as Arm and DSP microprocessor cores, and this increases testing complexity. I helped develop the DfT for that, which is now incorporated in the IEEE 1500 standard for embedded core test. When the standard was approved in 2005, many people said it was too late. They thought that companies would already be set in their ways. That wasn’t the case. Slowly but surely, IEEE 1500 has become the industry default.”

Marinissen is confident the same will eventually happen with another standard he’s helped set up. He worked on this after transferring from Philips, whose semiconductor division by then had been divested as NXP, to Imec in Leuven in 2008. He actually took the initiative for the IEEE 1838 standard for test access architecture for three-dimensional stacked integrated circuits himself. He chaired the working group that developed the standard for years until he reached his maximum term and someone else took the helm. The standard was approved last year.

“Stacking dies was a hot topic when I was hired at Imec. Conceptually, 3D chips aren’t dissimilar from SoCs: multiple components are combined and need to work together. By 2010, I’d figured out what the standard should look like, I’d published a paper about it and I thought: let’s quickly put that standard together. These things always take much longer than you want,” Marinissen sighs.

His hard work paid off, though. Even before the standard got its final approval, the scientific director at Imec received the IEEE Standards Association Emerging Technology Award 2017 “for his passion and initiative supporting the creation of a 3D test standard.”

Credit: Imec

Flipping through the slides

As many researchers do, Marinissen also enjoys teaching. He accepted a position as a visiting researcher at TUE to mentor students who – unlike himself when he was their age – take an interest in DfT. At an early stage, he also got involved with the test and DfT course at Philips’ internal training center, the Centre for Technical Training (CTT). “Initially, most of the course was taught by Ben Bennetts, an external teacher, but I took over when he retired in 2006. I remember having taught one course while still at NXP, but not a single one for years after that – even though Imec allowed me to. There just wasn’t a demand for it.”

“Then, in 2015, all of a sudden, I was asked to teach it twice in one year. Since then, there has been a course about once a year.” By then, the training “Test and design-for-test for digital integrated circuits” had become part of the offerings of the independent High Tech Institute, although, unsurprisingly, many of the course participants work at companies that originate from Philips Semiconductors. “Many participants have a background in analog design or test and increasingly have to deal with digital components. I suppose that’s understandable, given the extensive mixed-signal expertise in the Brainport region.”

“I might be the teacher, but it’s great to be in a room with so much cumulative semiconductor experience. Interesting and intelligent questions pop up all the time – often ones I need to sleep on a bit before I have a good answer. It’s quite challenging, but I enjoy it a lot. As, I imagine, do the students. I’m sure they prefer challenging interactions over me flipping through my Powerpoint slides.”

From begrudgingly accepting a graduation assignment to sharing his authoritative DfT expertise in class – the young Erik Jan Marinissen would never have believed it.

RF energy systems have undergone a huge transformation since the early days of the tube-based magnetrons. But according to High Tech Institute trainer Klaus Werner, while the crude power of the tube is tough to match, the new generation of solid-state RF integrated circuits offers unprecedented control, efficiency and reproducibility.

Klaus Werner didn’t get a usual start in the field of RF energy solutions. After studying physics at the University of Aachen, he came to Delft University of Technology to further develop CVD systems for semiconductor technology. “At the time, I was just meant to be there for six months,” remembers Werner. But eight years and a PhD in silicon germanium growth in CVD-type systems later, Werner found himself still in Delft. “It was definitely time for a new challenge,” he recalls. Then, in 1995, Werner joined the MOS-3 fab in Nijmegen for 10 years before going to Eindhoven to the Philips team responsible for laser displacement sensors – those that are still used in computer mice today.

The fit wasn’t quite right for Werner, and the 3+ hours of commuting every day for work simply wasn’t working. So back to Nijmegen he went, becoming part of the RF power group at NXP. “The group was mostly concerned with the development of semiconductor technology and devices for high-power, high-frequency applications of RF. Most notably, in the areas of base stations for the cellular network, telephone, radar systems, and to a large extent, radio-TV transmission,” Werner describes. But it was while he was there at NXP that he saw people were applying the electromagnetic waves not for communications and data but using their sheer energy to power plasmas for lasers, lights and even medical applications, for example in hypothermia.

White goods

Suddenly, activity in the solid-state RF energy realm really started to heat up, specifically driven by white-goods companies, which got their name from the standard of white-coated exteriors of home appliances. “Whirlpool and several others saw a business opportunity to improve microwave ovens in the way they heat food,” explains Werner. “That’s when we started the RF Energy Alliance, an industry consortium that set out to establish standards, create roadmaps and develop new generations of the technology to build consensus and bring down cost.” But a few years in, and the white-goods companies pulled out, as it was simply taking too long for them to bring down costs to have a competitive offer against the magnetron-powered ovens.

“NXP, as a semiconductor company, wanted to focus on components and the technology behind the components. At the same time, I was focused on pushing forward with openly spreading the knowledge and interest of the technology and its applications, and in the end, we decided to split,” says Werner. “That’s when I decided to jump into the gap that I saw in the RF-energy field, and created Pink RF – taking on the name ‘pink’ as a nod to the breast cancer support organization Pink Ribbon – with an overall desire to develop the technology for wide use in areas that could really help people’s lives, for example in medicine.”

Sharing knowledge

Despite the RF Energy Alliance folding, Werner was a firm believer in the promise of the technology and knew there was real value in the efforts of the failed consortium. “One of the major hurdles in getting this technology known and used by broader audiences is sharing the knowledge about it,” asserts Werner. “I was writing articles, preparing workshops and trainings, anything to increase the knowledge. I found that many people just didn’t have a solid idea of how to approach this unusual heat source.” Refusing to give up, Werner came across the International Microwave Power Institute (IMPI), which was doing a lot of the same outreach and promotional work on microwave power that he was looking for in the old RF Energy Alliance. Today, he serves as the chairman of IMPI’s RF energy section and is responsible for diffusing information around the unique technology and creating training opportunities to share his knowledge.

“That’s one of the reasons I wanted to join High Tech Institute. It’s a real institution that goes beyond simply giving workshops. It allows us to better reach technical people and connect with a specific audience and cater to its specific needs,” Werner says enthusiastically. “One of the best parts is that many participants already have a good understanding of what the technology entails. Everything they’ve already learned in school, about the behavior of waves and diffraction and refraction, still absolutely holds true. That idea alone has major implications, from a foundational aspect. It helps loosen the minds and starts to build perspective around this technology.”

New training

Werner’s first edition of the new “Solid-state generated RF and applications” training is aimed to do just that. The three-day course will give participants an inside view into the developments of the technology, from the previous generation of high-frequency tube-based magnetrons to the modern-day solid-state electronics-based energy source. “In terms of crude power, the magnetrons are tough to beat. The problem, however, stems from the lack of optimization and control of the tube and the degradation of the signal over time,” illustrates Werner. “The new generation of solid-state RF is really being driven by cellular communications, where there’s a need for high power linearity that’s created by transistors and semiconductors. This method creates a stable, efficient and, more importantly, controllable and reproducible signal that could never be realized by the magnetron.”

“There are many factors that come into play when determining how best to utilize RF energy and we’ll cover a lot of them in the new training. We’ll use a mixture of theory and practice to dig deeper into the technology. From safety aspects like radiation exposure – which is not a thing – to frequencies, behavior and interaction with matter,” describes Werner. “The reality is that this technology is extremely useful and completely scalable. From heating minute amounts of liquids under very well-controlled circumstances for Covid testing, up to cooking 1,000 liters of soup every hour. This modular technology is applicable from microjoules up to megajoules, with nearly unending possibilities.”

This article is written by Collin Arocho, tech editor of Bits&Chips.

System architects are in increasing demand in the high-tech industry. They provide focus, overview and results in complex development projects. This means value for customers and euros for their own business. We ask Gerrit Muller, founder of the Sysarch training courses at High Tech Institute, about the secrets of good system architects.

The image that most people have of system architects resembles that of architects of buildings and constructions. They expect these professionals to divide complex machines or products into parts, give them properties and define the interfaces between them. It all boils down to sketching and drawing. In practice, these tasks are also the most visible. In buildings, but also in the technical industry, where sketching is expressed in block diagrams, CAD drawings or piping and instrumentation diagrams. All the parts are made visible and you can see how things connect.

An architect indeed has to make a system or product transparent. But that’s only the basis and not what the job is really about. “If you cut it up into pieces, look at those pieces and at the connections between them, all you have is a static image,” says Gerrit Muller, professor at the University of Southeast Norway in Kongsberg and founder of the Sysarch training courses at High Tech Institute.

Of course, drawings are useful. “The interfaces allow us to disconnect the components. They’re important and interfaces need to be well defined, but with them, you still have a collection of parts, a box of parts.”

The problems, Muller explains, arise when those parts start interacting with each other. “That’s where the value of the system is. Because together, they take care of the intended function and together, they do it well enough, accurately enough, fast enough, reliably enough, safe enough – a lot of that kind of namable qualities.”

Behavior and qualities, therefore, stem from the parts that are interacting with each other. “As a system architect or systems engineer, you design to get the desired behavior and the desired properties and you prevent undesired behavior and annoying properties.”

Far from trivial

But in practice, this interaction is so complex that we can’t foresee and understand everything. “Getting the behavior we want is far from trivial. Designing a system without undesirable properties is also far from easy. In the integration phase, when parts are made, usually unforeseen things pop up – you don’t get the desired performance. Usually, things don’t turn out the way you intended.”

The better the system architect, the better he or she can assess whether the design will work?

“Yes, but I want to take it one step further. They mustn’t only make estimations but also be able to visualize and communicate. That can be done with sketches and models. The goal is to communicate with many stakeholders such as designers, product managers, customers, the boss and other architects. Good architects make the system explicit and thus discussable and reasonable. In this way, they ensure that everyone can think about it and contribute their ideas. For example, by asking questions such as: suppose we do this or that, what will happen? This leads to better decisions in the design or specification. Making this communication optimal in teams and companies is the core function of the architect.”

As an example, Muller remembers a description Guido de Boer made when still working at ASML. De Boer wrote down on paper the path a silicon wafer travels through a lithographic stepper: via the wafer handler and wafer stage, including all operations such as moving, measuring and exposure. He called the story “Life of the wafer.”

“‘Life of the wafer’ was a set of drawings that showed what was happening. It helped to understand what happens to a wafer, during alignment, measuring the profile and all that sort of things. The downside was that everyone used it to discuss their problems, precisely because it was such a handy tool.”

This proved to be ineffective. “To discuss a so-called aerial image, for example, it’s useful to know what happens in the light path of a stepper: from the light source via the illuminator, mask and lens to the photoresist. Such descriptions of dynamic paths next to each other provide a great deal of insight into how a system works. They provide understanding and the opportunity to discuss and reflect on the whole. To grasp the dynamic behavior, you often need a whole lot of complimentary drawings or models. This way, you make the whole system discussible.”

Everything to get a better grip on the dynamic behavior?

“Yes, because there’s infinite dynamic behavior of a system and its environment. In that infinite mountain of interactions, you want to visualize the context. This means making the events visible that have the greatest impact. It means the system architect has to know what he can delegate to others and what he can ignore because it will have too little impact. That’s where true architects come in, the professionals who know where to dig deeper and who understand the art of omission.”

How does that process of omitting work in practice?

Muller explains that this is a real art because system architects operate in an environment with a lot of noise. “There will always be a team member asking for more detail, while someone else is shouting that his part isn’t visible. But as soon as you see too much, details start to dominate and the function and application disappear to the background. You no longer see how it works and what the effect is.”

Hiding the details is part of getting to grips with the complexity. System architects are aware of the software stacks, circuit boards and chosen alloys, they can also discuss them with their software engineers, electricians and mechanics, but they shouldn’t exaggerate. They’re forced to focus on the more abstract levels.

The first level is quite recognizable for everyone, that of the modules, units or subsystems. “Whatever you want to call it,” says Muller. “It’s the things that are produced, that you can touch. These fit well into the mindset of technicians. In lithography, for example, these are units like a stage, a wafer handler or a lens.”

On top of that comes an abstraction layer, which usually is about functionality. “Placing the wafer or moving a wafer plane.”

On the level above that, the qualities are discussed. “Good overlay, good depth of focus, speed – that sort of thing.”

Then comes the layer where the qualities come together in properties of the application. “Those are the things your customers are waiting for, such as yield,” Muller points out. “So you need to understand what role that depth of focus has and what depth of focus is exactly essential and what deviations the patterns on a processed wafer may have. At that level, you place everything more in context.”

According to Muller, system architects should be able to switch between multiple viewpoints at all those levels. “Is your product about speed or accuracy? If it has to be accurate and fast, exactly how accurate and fast? I can make something fast or super accurate, but most of the time, you want both speed and accuracy. Then you have to find the sweet spot – that’s what it’s all about.”

How do you recognize the potential system architect?

“I’m sorry to say, but I don’t have a recipe for that. I know good system architects. They’re often peculiar figures, each with their own qualities. They often entered into the profession from different angles. In the first place, they’re generalists by nature. They shouldn’t shy away from the broad picture, never be afraid of things they don’t know or that are out of their sight. They shouldn’t shy away from new things. In fact, they should be energized by them.”

“An architect is somebody that everyone can talk to. Imagine a large building with a room where colleagues always drop by. That’s probably where the system architect has his desk, even though he may not officially have that job title. The interaction with him is a naturally occurring phenomenon in the team because others experience that this person helps them.”

If a company doesn’t have a system architect yet, this is the person to look for?

“Exactly. If you put the system architect’s profile next to that, as we define it in the Sysarch course, it usually matches nicely. One more thing: system architects are always multitasking.”

What exactly do you mean by that?

“Being able to continuously change viewpoints, as we call them. Looking at a problem from different angles. You can learn that or might be forced to learn it. This multitasking is essential but can be very tiring. Some people are very good at systems thinking but are completely lost when they need to multitask.”

What are the biggest challenges for people who are new to the role?

“People often concentrate too much on the system and the technology. You have to help them get out of the system and into the world of customers, the product lifecycle and the business. They need to get out more and they need a push to do so. Communication or soft skills are also useful.”

“Imagine a big building with a room where colleagues always walk in. That’s probably the office of the system architect, even though he may not officially carry that job title”

The complexity of systems is increasing. Does this increase the need for system architects?

“You’d hope the problems of twenty years ago are so well known that we can now solve them in a more structured way. That would enable today’s architects to focus on the more complex problems. There’s almost no system that’s not connected to other systems anymore. There are almost no functions and features that don’t depend on multiple systems anymore. I need to understand the system I’m working on but also other systems, including the interaction and the people around it. That complexity, that growth, that’s a fact of life.”

You’re a professor in Norway and are working one day a week at ESI in Eindhoven. What’s the nature of the problems that companies ask you about?

“All questions that are also in the Sysarch training. What’s the role of the architect in my organization? How do I take long-term strategy into account? How should I help architects do their job in the best way?”

“Some companies say right away: I want to do model-based system engineering, MBSE. Then I’m always curious about their real question. Do they have an administrative need? Do they have to comply with the rules imposed by the American FDA? Or do they need to investigate or communicate better? You can model for many different reasons.”

“A lot of companies are struggling with the same question: they want to create a platform because they have products 1, 2 and 3 with a lot of synergy between them, but all different. Or they constantly have projects to make different product variants. Platforms, standardization – I often get questions about that. For an architect, this is a balancing act because standardization can make things rigid, thereby reducing the value for customers.”

Can the knowledge in the field of system architecture be packaged in manageable chunks?

“This begs the question: what’s the ability and what’s the art? What can we offer people in terms of methods and means, and what can’t you transfer as a teacher? Competent system architects have gone through quite a development. That’s an accumulation of time and experience. But if you’ve done something for a long time, it doesn’t mean you’ve developed the skill. Seasoned experience is needed. It’s about recognizing situations and thinking about them. Knowing why some things don’t work because you’ve experienced it and the next time, you know how to do it right the first time. Such a cycle of reflection is actually essential for a system architect to learn and reach a useful level of experience.”

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

Although machine learning security research is still in its early stages, it’s clear that input possibilities without barriers increase threats. You don’t need to touch a keyboard anymore to fool a machine learning system. Software security expert Balázs Kiss touches upon a few points in this new field and gives advice on the basic protection measures.

Just like software in general, machine learning systems are vulnerable. “On the one hand, they’re pretty much like newborn babies that rely entirely on their parents to learn how the world works – including ‘backdoors’ such as fairy tales, or Santa Claus,” says security expert Balázs Kiss from Cydrill, a company specialized in software security. “On the other hand, machine learning systems are like old cats with poor eyesight – when a mouse learns how the cat hunts, it can easily avoid being seen and caught.”

Things don’t look good, according to Kiss. “Machine learning security is becoming a critical topic.” He points out that most software developers and experts in machine learning are unaware of the attack techniques. “Not even those that have been known to the software security community for a long time. Neither do they know about the corresponding best practices. This should change.”

Security expert and experienced software trainer Balázs Kiss recently developed a new course on machine learning security to be rolled out shortly by High Tech Institute in the Netherlands.

Machine learning (ML) solutions – like software systems – are vulnerable in various ways and they increase the security needs. Last year, this was pointed out in a quite embarrassing and simple way by two students from Leuven. They easily managed to mislead Yolo (You Only Look Once), one of the most popular algorithms to detect objects and people. By carrying a cardboard sign with a colorful print of 40 by 40 cm in front of their body, Simen Thys and Wiebe Van Ranst made themselves undetectable as human persons. Another example comes from McAfee researchers who managed to fool the Tesla autopilot by misclassifying speed limit signs and made the car accelerate past 35 mph.

Know your enemy

“An essential cybersecurity prerequisite is: know your enemy,” states Kiss, who is also an experienced software trainer and recently developed a brand new course on ML security to be rolled out shortly by High Tech Institute in the Netherlands. “Most importantly, you have to think with the head of an attacker,” he says.

Let’s take a look at what the attackers are going to target in machine learning. It all starts with exploring what security experts call “the attack surface,” the combination of all the different points in a software environment where an unauthorized user can try to enter or extract data. Keeping the attack surface as small as possible is a basic security measure. Like the students from Leuven proved: to fool an ML system you don’t even have to touch a keyboard.

A common saying in the machine learning world is “garbage in, garbage out.” All algorithms use training data to establish and refine their behavior. Bad data results in unexpected behavior. This is possible due to the model performing well on the training data but unable to generalize the results to other examples (overfitting), the model being unable to capture the underlying trends of the data (underfitting) or due to problems with the dataset. Biased, faulty or ambiguous training data are of course accidental problems, and there are ways to deal with them. For instance, by using appropriate testing and validation datasets. However, an adversary feeding in such bad input intentionally is a completely different scenario for which we also need special protection approaches.

Attackers are smart

Kiss: “We simply must assume that there will be malicious users. These attackers don’t even need to have any particular privileges within the system, but they can provide raw input as training data and see the system’s output, typically the classification value. This already means that they can send purposefully bad or malicious data to trigger inadvertent ML errors.”

“But that’s just the tip of the iceberg,” finds Kiss. “Keep in mind that attackers are always working towards a goal. They will target specific aspects of the ML solution. By choosing the right input, they can actually do a lot of potential damage to the model, the generated prediction and even the various bits of code that process this input. Attackers are smart. They aren’t restricted to sending static inputs – they can learn how the model works and refine their inputs to adapt the attack.”

In case of supervised learning, it encompasses all three major steps of the ML workflow. For training, an attacker may be able to provide input data. For classification, an attacker can provide input data and read the classification result. If the ML system has feedback functionality, an attacker may also be able to give false feedback (“wrong” for a good classification and “correct” for a bad one) to confuse the system.

Crafted inputs

Many attacks make use of so-called adversarial examples. These crafted inputs either exploit the implicit trust an ML system puts in the training data received from the user to damage its security (poisoning) or trick the system into mis-categorizing its input (evasion). No foolproof method exists currently that can automatically detect and filter these examples; even the best solution, where a system is taught to recognize adversarial examples, is limited in scope.

By carrying a cardboard sign with a colorful print of 40 by 40 cm in front of their body, Simen Thys and Wiebe Van Ranst made themselves undetectable as human persons. Credit: KU Leuven/Eavise

There are defenses for detecting or mitigating adversarial examples, of course. However, an intelligent attacker can defeat solutions like obfuscation by producing a set of adversarial examples in an adaptive way. Kiss points to some excellent papers that highlighted these, like those from Nicholas Carlini and his colleagues at Google Brain.

All in all, ML security research is still in its early stages. The current studies mostly focus on image recognition. However, some defense techniques that work well for images may not be effective for text or audio. “That said, there are plenty of things you can still do to protect yourself in practice,” divulges Kiss. “Unfortunately, none will protect you completely from malicious activities. All of them will however add layers of protection, making the attacks harder to carry out.”

Most important, maintains the Cydrill expert, is that you think with the head of an attacker. “You have to train neural networks with adversarial samples to make them explicitly recognize this information as incorrect.” According to Kiss, it’s a good idea to create and use adversarial samples from all currently known attack techniques. A test framework can generate such samples to make the process easier. There are existing security testing tools that can help with this – like ML fuzz testers Tensorfuzzs and Deeptest, which automatically generate invalid or unexpected input.

Sanity checks

Limiting the attacker’s capabilities to send adversarial samples is always a good mitigation technique. One can easily achieve this by simply limiting the rate of inputs accepted from one user. Of course, detecting that the same user is behind a set of inputs might not be easy. “This is the same challenge as in the case of distributed denial-of-service attacks, but the same solutions might work as well.”

As always in software security, input validation can help. It may not be trivial to automatically tell good inputs from bad ones, but it’s definitely worth trying. We can also use machine learning itself to identify anomalous patterns in the input. “In the simplest case, if data received from an untrusted user is consistently closer to the classification boundary than to the average, we can flag the data for manual review, or just omit it.”

Applying regular sanity checks with test data can also help. Running the same test dataset against the model upon each retraining cycle can uncover poisoning attack attempts. Kiss: “Reject on negative impact, Roni, is a typical defense here, detecting if the system’s capability to classify the test dataset degrades after the retraining.”

The most obvious fact about ML security is often overlooked, notes Kiss. “Machine learning solutions are software systems. We program them in Python – or possibly C++ – and thus they potentially carry all common security weaknesses that apply to those languages.” The Cydrill trainer especially advises us to be aware of point 9 from the OWASP Top Ten. The Open Web Application Security Project is a document that summarizes the ten most critical security issues in web applications to raise awareness and help minimize the risk of attacks. Point 9 warns developers about using components with known vulnerabilities. “Any vulnerability in a widespread ML framework such as Tensorflow or one of its many dependencies can have far-reaching consequences for all of the applications that use it.”

Potential attack targets

The attackers interact with the ML system by feeding in data through the attack surface. Start to think with the head of the attacker and ask questions. How does the application digest the information? What kind of data? Does the system accept images, as well as audio and video files? Or are there restrictions? If so, how does it check the types? Does the program do any parsing or does it delegate it entirely to an open-source or commercially available media library? And after preprocessing the data, does the program have any assumptions (empty field, requirements on values)? Is data stored in a relational database or in XML or JSON? If so, what operations does the code perform on this data when it gets processed? Where are the hyperparameters stored, and are they modifiable at runtime? Does the application use third-party libraries, frameworks, middleware or web service APIs as part of the workflow that handles user input? If so, which ones?

Kiss: “Each of these questions can indicate potential attack targets. Each of them can hide vulnerabilities that attackers can exploit to achieve their original goals.”

These vulnerability types are not related to machine learning as much as to the underlying technologies: the programming language itself (probably Python), the deployment environment (mobile, desktop, cloud) and the operating system. But the dangers they pose are just as critical as the adversarial examples – successful exploitation can lead to a full compromise of the ML system. This isn’t restricted to the code of the application itself. Researcher Rock Stevens from the University of Maryland explored vulnerabilities in commonly-used platforms such as Tensorflow and Pytorch.

Real threats

Kiss’ main message is that ML security covers many real threats. It isn’t just a subset of cybersecurity, it shares many traits of software security in general. We should be concerned about malicious samples and adversarial learning but also about all the common software security weaknesses. Machine learning is software after all.

ML security is a new discipline. Research has just begun, we are just starting to understand the threats, the possible weaknesses and the vulnerabilities. Nevertheless, ML experts can learn a lot from software security. The last couple of decades have taught us lots of lessons there.

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

As a project manager, system architect and crisis manager in the high-tech industry, Luud Engels has a reputation for not mincing words. In addition to his consultancy work, he recently started as a system architect(ing) trainer at High Tech Institute. “Clear communication is key in complex development environments.”

You don’t want to start with Luud Engels about how open-minded and communicative we are in the Dutch high tech as a system architect. He’ll be forceful in his response, underlining just how hypocritical it is to believe that. “Here in the Brabant region, we’re not that open at all. Just stand at a coffee machine and listen. We’re not talking with you, we’re talking about you.”

When it comes to direct communication – or rather, confrontation – Engels has a reputation. A few months ago, he was sent packing after strongly expressing – according to his client – what was wrong within the company. “I’m convinced that at the right time, you can say anything to anyone – be it in a team meeting or a discussion between two people. Of course, most Dutch don’t do that. But I don’t seem to excel at it either because I sometimes put things so bluntly that people tell me to get lost.”

Engels’ appreciation of factual and clear communication comes from his many years of experience as a project manager, a system architect, a crisis manager and a member of the management team at engineering firm TMC. His advice for development environments: “Speak your mind. Also, about personal stuff. It’s perfectly fine to tell someone his blue shirt bothers you. But statements like ‘Microsoft sucks and Apple is good’ don’t help. Make it factual: are we going to work object-oriented or process-oriented? Are we going to use glass or titanium? What are the advantages? What are the disadvantages? Talking about glass, I don’t need to know the whole history of glassworks. I want the five key criteria – in numbers, not in positives and negatives. If you know the dominant parameters, you also know how to measure them and we can agree on the first development steps to make the measurements possible.”

Engels emphasizes that in the development of high-tech systems, several roads lead to Rome and that it’s important to stick to the choice made. “Make sure the whole team is at least on the same path, rather than endlessly searching for the only right solution – which, by definition, doesn’t exist.”

But sometimes, even the simplest of things can go wrong. “Once, after a positive conversation with a client, I received the report in colloquial Dutch. I asked if the client representatives had approved the text. Of course, they had not. So I insisted on writing it down in English, presenting it to the client and asking them for their approval. After all, it’s often about decisions with far-reaching consequences. Still, syncing with the customer proved a daunting task.”

The laws of Luud

• If the financial people take over, the engineering interest becomes secondary; if the engineers take the lead, it will be financially broken
  (About balancing tech and money in high-tech OEMs)
• The client who asks for a crisis to be averted is half the culprit or part of the crisis in question (About crisis management)
• I firmly believe in the power of the outsider (About the crisis manager)
• We talk past each other: one talks in Newtons per square meter, the other in bits per second (About communication and collaboration in high tech)
• A crisis doesn’t go away by getting rid of the people who put their finger on the sore spots (About stranded development projects)

The outsider

Engels’ extensive technical career started with a study of electrical engineering, after which he joined Sattcontrol, a Swedish industrial automation specialist. He programmed PLCs for egg-grading machines, dairy factories and automated warehouses. Later, he switched to Fortran for PDP and Vax minicomputers.

After five years, Engels moved to Cap Volmac (later Cap Gemini), where he did projects. While he mainly worked in engineering, Cap’s core was business automation. “I learned a great deal about developing computer systems and software according to the rules.”

Engels started for Cap at ASML, he then worked on highway signaling at the Dutch Department of Waterways and Public Works, eventually taking on leadership roles. Later, audits were added to the mix. He estimates that he’s assessed about twenty projects. “After a day of walking around, you know what’s going on and where the project went wrong,” he says. Smilingly: “And certainly not because I’m so smart, or because I saw so much, but mainly because I was an outsider.”

Engels firmly believes in the power of the outsider. “You arrive at companies where things have gone completely wrong and then you’re allowed to walk around and speak to 5-10 people. They all have an opinion about the project in crisis. You get to hear the whole story. People want to pour their hearts out. You hear what’s wrong, and above all: what others aren’t allowed to say.”

The headstrong technician

Technicians are a stubborn, headstrong type – and Engels should know, as he certainly fits that mold. “We’re engineers, aren’t we? We think like this: ‘I’m an electrical engineer and according to my calculations, it’s 5 volts. If you don’t get it, I’ll explain again, but the outcome remains 5 volts. You’re crazy, not me.’ While in projects, it’s mainly about effective collaboration. That’s the difficult part. One talks in newtons per square meter, the other in bits per second. One talks about the goal, the other about the solution. The high tech is one big Tower of Babel. That starts with requirements and continues through to design, integration and testing. Just as well: if I do a project myself and an outsider comes in, he or she will also shoot holes in it.”

Luud Engels will lead the mid-November edition of the System Architect (Sysarch) training in Leuven.(Belgium).

Engels prefers to step in when the crisis is at its deepest. Take the Fusion project that ran at Philips at the end of the nineties. Its ambitious goal was to use a single platform to cover the mechanical, electrical and software construction for medical diagnostic systems. The idea was that cost savings through reuse would justify the extensive operation. “The director outlined his problem as follows: every month, thirty new developers joined the project and every month, they told him that completion was delayed for another two months.”

Engels, again, applied the power of the outsider. “The outsider is allowed to speak up. The deeper the crisis, the more receptive one is to outside messages. Usually, other people have already had a look at it. But often, they put their fingers on sore spots that they weren’t allowed to point to and ended up having to leave. They asked me to replace the current project leader because he couldn’t make up for the delay. But a crisis doesn’t go away when you get rid of the people who put their finger on the sore spots. Instead, I went to help the incumbent project leader. Together, we contained the crisis by adjusting the scope and working with early feedback. One of my laws is: the client who asks for a crisis to be averted is half the culprit or has at least a dominant part in it.”

Is it tunnel vision?

“Please note: you’re talking about very competent people with very relevant arguments and tons of knowledge. But gradually, the solution or working method has been placed in different silos. Very skilled people wear down paths, creating trenches that are so deep that you can barely look over the edge. Everyone has his trench and is defending it stubbornly. You hear people say things like: ‘This isn’t negotiable!’ When you hear that, it points you to where it went wrong and where a possible beginning of the solution lies.”

Where does the solution start?

“The first law of crisis management is containment. With Fusion, it meant that they had to stop adding thirty people per month. Instead, they had to cut twenty a month and reduce scope. The deeper cause – in my opinion – was pure self-overestimation. The platform idea for software alone is a major challenge. But when you start including mechanics and electronics, for all diagnostic products, it becomes too much at once. It’s difficult enough to develop electronics, software and mechanics together for a single system, but trying to develop one platform for different product lines in one project is naive, to say the least. At the time, they also had to work with developers in Bangalore, and they wanted to go from CCM level 2 to level 3 at the same time. That had to stop right away. You need to limit the scope of a project in crisis and postpone long-term improvement initiatives.”

“It’s often the case that the technicians already know what’s wrong and so does management. Both are right, but they won’t reach a solution together. Much later, I did a job at Philips DPS, where I saw that Philips had made significant progress. Putting fingers on sore spots, however, was still not allowed, unfortunately.”

How does this get done the right way?

Start small, says Engels. “You need early feedback, preferably a launching customer. I’ve heard Martin van den Brink say it many times at ASML: put everything together, show me that it works. Then he challenges people by stating: ‘Your physics don’t work.’ There was a lot of that during early integration. Much later, the industry introduced fancy words for it, calling it Scrum, Agile and rapid development. But the point is that you need feedback, and it’s important to start getting it at an early stage. The goal has to be to deliver every six weeks and to deliver something that actually works. If not, you have the means available to find out why it failed, why the physics didn’t work. At that point, you might have to accept that you’re not going to meet your deadline. What you definitely shouldn’t do is bring in more people.”

“When technicians tell you they need more time to investigate something, you have to get suspicious. Van den Brink is also a master at assessing or challenging that.”

Another necessity: “Make people owners of a problem. Certainly in environments with complex developments, where there’s not even a beginning of a solution and new inventions are required, everyone feels like the master of their idea, with their personal insight. We Dutch are also very good at seizing every opportunity to talk about this in a very broad sense. But you simply need to take the next step. That’s the only thing from which a project benefits. So if you’re sitting in a room with thirty people and problems come up, the project manager, the crisis manager or the system architect must assign a person responsible to each problem. This also includes deadlines for results and decisions.”

According to Engels, it’s definitely in the culture of ASML, but there was a point in time when it got out of hand there. “They appointed an owner for everything and called him a project leader. McKinsey once did an analysis at ASML of project leaders and project sizes. They found that, on average, there were 1.2 people on each project, including the project leader! Then you run the risk that these owners, these project leaders, start competing over available resources and the underlying issue disappears into the background.”

Engels has extensive experience as a project manager, system architect and crisis manager in the high-tech industry.

The product manager defines the product that will perform well in the market. He determines the available budget – often too little – and negotiates with the system architect whether it can be made for that money. Engels: “It’s a balancing act. With mature products, it works differently, but with a first development, you want a proof of concept as soon as possible. Or at least a confirmation that your ideas are right and that you’re on the right track.”

To what extent should the system architect, like the product manager, talk directly to customers?

“In high tech, that’s beyond dispute. That’s where the product manager and the system architect come together. They have to. The former has more business focus, the latter looks at the technology and whether it’s feasible. They’re two sides of the same coin. This collaboration between the product manager and system architect is becoming more and more commonplace. However, I still see system architects who downplay the necessary coordination with the project manager or operational management. You then run the risk that a solution that perfectly meets market needs will ultimately fail in the realization phase.”

In smaller development projects, with ten to twenty developers, one person can take on the role of both project manager and system architect. In larger projects, with tens or hundreds of developers and several dozen suppliers, it’s important to split up. Engels has experience in both roles. “The project manager sets hard deadlines and a system architect has to work with them.”

“The project manager must define which issues the system architect still has to solve and with whom. Together, you discuss the ins and outs, weigh the benefits and concerns, decide on key parameters, and then the project manager calls the system architect: at the end of next week, we’ll make a decision! It’s all about direction, coming up with a format that involves knowledgeable people to arrive at quantified statements with which you can really make an assessment.”

A system architect has a major impact on product development, yet often has a less than visible role.

“He’s an experienced technician, but his value lies primarily in his view of the business. Ninety-nine times out of a hundred, the system architect knows the market in which his product or system is going to land. This is necessary to translate the market and product requirements into the system requirements and then outline the design.”

It takes quite a bit of experience to reach that level. At the same time, Engels observes that the concept of a system architect is subject to inflation. “Nowadays, there are architects all over the place. A software architect is usually a senior software developer, a requirements engineer or someone in charge of engineering. I wouldn’t say anything to the detriment of such a lead engineer. Still, the difference with the system architect is that the latter has to know the business, understand how value is generated and thus understand why it has to be done within a certain amount of time and money.”

“This is also the case in construction. Your architect asks you what you are going to do with your future house and adapts his design accordingly. Are you going to cook a lot, or do you mainly want to drink wine? That’s why Van den Brink does so well at ASML. He goes to customers and explains what kind of litho systems they need. He knows the market like no other. Even stronger, he dictates the market. That means he understands the goals and the timing of chip manufacturers like no other, including what their production processes look like. If they talk about critical dimension and overlay, he can explain that his machine can do that and also substantiate why.”

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

With the growing reliance on software in an increasingly high-tech world, it’s more important than ever to master the art of software engineering as software architects. Trainers Robert Deckers and Bart Vanderbeke have taken it upon themselves to turn developers into craftsmen.

“A colleague once told me about one of his former project managers, who, upon realizing that the estimates didn’t align with his timeline, just cut them in half to make them fit. I find it unheard of, not only that you’d do such a thing as a project manager but also that people stand for that kind of behavior. You don’t have to scold him, but you can open your mouth. Instead, at the end of the project, when everything has gone haywire, everyone complains about how this has happened to them.”

Inspired by Google executive Fred Kofman and his book “Conscious business,” Bart Vanderbeke calls on software architects to stop playing the victim. “It’s unacceptable and unhealthy,” he claims. “You’re the craftsman. When someone tells you that you need to do something in half the time, or skip the design, or refrain from reviews, you say no – constructively. Software architects are scarce, so you’re in a comfortable position, certainly no position to self-victimize. Don’t hide behind ‘management.’ As a software craftsman, using a term coined by Kofman, you’re ‘unconditionally responsible’ for everything you do or don’t do.”

“You need to take unconditional responsibility, which literally means that you need to have the ability to respond – in a meaningful way,” says Bart Vanderbeke. Credit: Bart Vanderbeke

At NXP in Leuven, Vanderbeke leads a team of fifteen software architects, working on 2.4 GHz radio applications for personal health – think hearing aids, headphones and earplugs. “Tiny systems containing tiny software stacks,” he notes. “But even if you have a codebase of 100k or 200k, like us, software craftsmanship is of paramount importance. Building the hardware takes about a year, followed by maybe five years of software enhancement. I’ve developed a series of lectures to help my colleagues bring out their inner craftsman.”

The non-functional

A kindred spirit, Robert Deckers, too, aims to increase software craftsmanship, but with a focus on software architecture – “the most difficult trick of the trade,” as he calls it. “It already starts with the question: what is software architecture? You can find hundreds of books that try to give an answer. While some are bad, terrible even, most of them are meaningful, but they all tell a different story.” This was one of two triggers that led him to dive into the subject, develop his own view, write his own book and bestow his insights upon others.

The second trigger was the realization that in traditional methodologies, there’s too much focus on the functional requirements, whereas the non-functionals are the hardest to get to grips with and therefore take up the most time. “Way back when I was an OOTI trainee at Eindhoven University of Technology, I was the software architect for a copier,” reminisces Deckers. “After two months of design, the anomalous system behavior started to rear its ugly head and I realized that we had to do error handling as well – while obvious to someone with 20 years of experience, it hadn’t crossed my newbie mind. When we were finished, to my big surprise, no less than 85 percent of all our code turned out to be for error handling, so only 15 percent of our efforts had been focused on the functionality. That’s when I first experienced that the real challenge, the real complexity, is in the non-functional.”

After the OOTI traineeship – the PDEng Software Technology, as it’s known today – Deckers sharpened his views at several companies, including Philips Research and Sogeti. Since 2013, he’s running Atom Free IT, coaching organizations and their architects, helping them create architectures, set up the architecture process and embed it. The last five years, he’s combining this with a PhD project at the Vrije Universiteit Amsterdam, researching the cognitive aspects of systems engineering.

Come prepared

Vanderbeke and Deckers are the newest additions to the software and systems portfolio of High Tech Institute. Both want to help software architects be better at their work – become real craftsmen. “As a software craftsman, you know how to organize your work and you have the assertiveness not to accept compromises on the way of working. Instead, you go for the optimum, taking into account the influencing variables and conditions. You don’t do things because someone tells you to, but as you understand the need, you autonomously decide to do so,” summarizes Vanderbeke the values he intends to convey in his workshops.

Robert Deckers stresses the importance of focusing on the non-functional properties, aka the quality attributes.

Learning to say no in a constructive way is a key topic in Vanderbeke’s teachings. “That requires you to come prepared. When you’re asked to plot a course in a project, you need to have a couple of options readily available, not down to the minute detail but to such an extent that you can weigh them and make an informed choice. When someone steps up to you and says something can be done in half the time you estimated and you don’t have your facts straight, he may well be right – you have no way of telling. If you know what you’re talking about, that will not happen. You can have a constructive conversation and you might be challenged, persuaded even, but you won’t let yourself be blown away by unsubstantiated claims. Someone once asked me if we could speed things up by taking shortcuts, upon which I replied: ‘The only shortcut you can take is skimp on the specs’ – and that was the end of the discussion.”

“You need to take unconditional responsibility, which means that you need to have the ability to respond – in a meaningful way,” continues Vanderbeke. “In my workshops, I use several small examples, taken from my everyday work, to get my point across. For instance, someone escaping responsibility would say: ‘I cut my estimation in half because my project manager told me to,’ as opposed to someone keeping ownership, a ‘player’ in Fred Kofman’s terms, who would say: ‘I wanted to avoid a fight with my project manager, so I gave in.’ Likewise, a victim would say: ‘I make estimations because our process demands it,’ whereas a player would say: ‘I want to stay with the company, so I use the established process.’ By making them aware of these little things, people are more inclined to correct their behavior.”

A good architecture is correct, consistent and communicated. Credit: Robert Deckers

Fish nor fowl

In his training courses, Deckers relays his ideas about good architectures. “The role of architecture is to offer a solution approach for the key system properties that are the hardest to realize. As a system architect, you always have to make sure you’re working towards a solution, providing guidance and serving your stakeholders’ needs, while also keeping an eye out for things that could go wrong if not addressed in the architecture. If you’re not doing this, you’re probably not architecting. Also, I want software architects to understand that an architecture needs to offer business value and that it’s feasible to build the system within the organization at hand. You can only be an effective architect when you’re prepared to step out of your technology comfort zone.”

According to Deckers, a good architecture is correct, consistent and communicated. “A system has to be correct in that it has to adhere to the stakeholder concerns and the technical environment. The development process has to be consistent. At Philips in Bruges, I once witnessed a software architect testing all preconditions of all the functions he programmed because he wanted his code to be robust. Meanwhile, in the cubicle right next to his, a colleague was using pointers without testing anything because he wanted his code to be fast. Combined in one system, that gives you neither fish nor fowl. You need to be clear on the key properties – my advice: hang the top five on the wall. Finally, an architecture should be described in such a way that you can discuss it with the different stakeholders, which means using different views for different aspects.”

Deckers stresses the importance of focusing on the non-functional properties, aka the quality attributes. He acknowledges that this seems to be at odds with the popular Agile principle of delivering working software as quickly as possible. “People often ask me: how do you match Agile and architecture? My answer to them: you don’t. They’re two different mindsets. Architecture is about looking before you leap, whereas with Agile, you just go and adjust based on the feedback you get. That’s perfectly fine for some businesses, but not for a copier or a medical scanner, where aspects like reliability and safety are known beforehand. The closest way to match Agile and architecture is to bend the rules and dedicate the first few sprints to the key concerns.”

Descending down the management funnel, the focus narrows and the risk for conflict grows.

Better decisions

With collaboration, there’s bound to be friction. A software craftsman, therefore, also needs tools for conflict resolution. In his workshops, Vanderbeke presents a management funnel doubling as an inverse conflict pyramid. It goes from wide to narrow in three levels: strategic, tactical and operational – from the what to the how. Descending down the funnel, the focus narrows and the risk for conflict grows. When a conflict actually arises, going back up the funnel to try and find a shared goal or principle helps to smooth things over.

“Software architects who are in disagreement about the way to tackle a problem often are at the bottom, stuck in their own solution. Taking them up and discussing the problem criteria usually ends the stalemate as they establish common ground,” illustrates Vanderbeke. “It’s a very useful instrument in process management as well. When you’re in a meeting that’s going nowhere, revisit the reasons why it was set up in the first place and a way out will present itself almost automatically.”

Stocked toolbox in hand, software engineers are well equipped for craftsmanship. With Deckers, Vanderbeke concludes: “It would be great to see them make better decisions. To see them operate more autonomously. And, at the same time, to see them have more fun in what they do.”

This article is written by Nieke Roos, tech editor of Bits&Chips.