True architects understand the art of omission and know where to dig deeper

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.