Piecing together the systems puzzle is a collaborative effort

In the past twenty years, high-tech systems have become incredibly complex. ASML and its supplier VDL ETG discuss how this has impacted the role of the system engineer. Architecting, they conclude, is becoming more and more a team effort – and so is the training of architects.

Driven by trends like digitalization, globalization, servitization and systems-of-systems, the complexity of high-tech equipment is growing by the day. “More and more disciplines have gotten involved and the amount of information that needs to be managed has increased substantially,” observes Ton Peijnenburg, deputy general manager at VDL ETG and fellow at Eindhoven University of Technology’s High Tech Systems Center (HTSC). “It’s becoming harder and harder for architects to keep the overview.”

Roelof Klunder, competence lead for ASML’s electrical architects, concurs. “Our machines are getting bigger and bigger, containing ever more parts. While most architects can handle a single subsystem, overseeing the impact of changes on a system level is quite a different story. But that’s exactly what’s required from system engineers.”

According to Jan van Vlerken, vice president of System Engineering at ASML, collaboration is key to keeping his people’s work manageable. “The increasing complexity has made it almost impossible for a single system engineer to have a complete overview. For a group, the odds are much better. That’s why architecting is becoming more and more a team effort.”

Training

As systems engineering is evolving into a team effort, so is the training of architects. Over the past years, organizations like TNO’s ESI have shifted their educational focus from teaching individual courses to providing (in-company) programs involving multiple stakeholders on multiple levels, sometimes even from multiple companies. Taking a real-life business case in a learning-by-doing approach, these programs explicitly aim to develop the participants’ leadership and people management skills, in addition to their technical competencies.

Peijnenburg highly values the hands-on approach. He points out that although architects have to have a solid background in the basics of systems engineering, their skills get honed on the job, so that’s also the logical place for training. “You need to realize that you’re not the architect because you know all the details but because you can mold the general picture. You mostly learn that by doing.”

A key prerequisite is technical assertiveness – the ability to give pushback to stakeholders. “It’s a combination of persuasiveness and steadfastness,” explains Peijnenburg. “As a system engineer, you engage in discussions with stakeholders using substantive arguments based on your intimate knowledge of the general picture, and the details to a certain extent. But there are always people looking for holes in your reasoning. So, not only do you need to be convincing, but you also have to stand your ground in the dialogue. ESI’s system architecting program has proven to be very instrumental in mastering these skills.”

“During my time at Philips CFT, thirty years ago, starting engineers were given two years to grow into their new role, two years to earn themselves back and another two years to make money for the company,” Peijnenburg recalls. “Today, we don’t have that luxury anymore. Architects are thrown in the deep end straight away. And then they get so consumed by their day-to-day work that they hardly have the time to reflect on what they’re doing and discuss it with their peers, while I see a growing need for just that. Coaching and training on the job are efficient ways to fulfill that need.”

ASML has its own supplementary program for system engineers. “Starting architects get assigned a senior colleague as their coach,” details Klunder. “Next to that, they can participate in our Architect Development Program, with all kinds of technical and non-technical exercises involving stakeholders from different disciplines. In the next level of our architect training, the Senior Architect Masterclass, their social and behavioral skills are deepened. As things change continuously, there’s also a need for a regular kind of training. We still need to close this gap.”

Common sense

System engineers are trained to perform a balancing act. “You’re never going to build something that 100 percent adheres to all the requirements because then you’re either never going to finish it or it’s going to be very expensive,” asserts Van Vlerken. “It’s up to you as the architect to decide what’s important and what’s less important in order to arrive at a system that’s good enough.” Peijnenburg also sees a balancing act between two responsibilities. “On the one hand, system engineers need creative space as lead constructor. At the same time, they need to structure information to make decisions as leader of a design team.”

Methodologies and tools can help bring structure, but they can also be perceived as constraining. “When we tried to introduce requirements engineering at VDL to supplant the traditional Word-based process, this was met with a lot of resentment,” Peijnenburg gives as an example. “People are very reluctant to change their way of working, fearing that it will make things more bureaucratic and less efficient.” Klunder has a similar experience at ASML. “We’ve also been piloting and are now rolling out improved ways of working and tooling for requirements engineering because we, too, see the advantages of having everything written down and managed in a structured way. At the same time, we see the bureaucracy that this brings. The challenge is to find a balance such that the advantages of requirements engineering are evident and the creativity and flexibility of the architects aren’t impacted.”

“It’s not about checking boxes for the sake of checking boxes, but it’s not just about creativity either,” Van Vlerken adds. “It’s also about common sense. As a system engineer, you should be creative but at all times use your sound judgment.” Peijnenburg agrees. “You need to have the common sense to switch from the details to the general picture,” he says. “When you focus too much on the details, you won’t be able to argue about the general picture – which is an essential capability for an architect.”

To keep a grip on things, many companies are jumping on model-based systems engineering (MBSE), in collaboration with partners like ESI. “In the aerospace and automotive industries, they completely rely on modeling and they’re very successful in using it to create products that are extremely reliable,” notes Peijnenburg. “In our high-tech equipment industry, however, MBSE hasn’t really taken off yet.”

Van Vlerken has a hard time seeing it fly on a system level anytime soon. “Mechanics, electronics, software – every domain has its own digital version of the system. How can these models help a system engineer make the right choices, in a way that the benefits outweigh the costs? In my view, we’d need to have a system-level metamodel, but how do we construct and maintain something like that? Our systems are really complex and require regular revisions over time, and therefore maintenance. We have yet to find a practical and pragmatic solution for a digital twin on the system level.”

Ecosystem

In another effort to deal with the increasing system complexity, ASML has started to travel down the route of commonality – reusing identical design elements in multiple places throughout the architecture. “This allows us to do more with the same development effort,” says Van Vlerken. “We use a common element unless there’s a solid business case for introducing something new – putting the brakes on adopting technology for the sole reason of it being new and fancy. Commonality isn’t a goal in itself but a way for us to advance in different areas – not just development effort and cost but also improved learning cycles, risk mitigation and sustainability through reuse.”

Commonality is also a topic in ASML’s close collaboration with VDL ETG on the wafer handler. “We’re discussing how we can introduce common elements in the architecture of that module,” Peijnenburg explains. For Van Vlerken, this exercise, as he calls it, has already yielded some valuable observations. “One of the insights we’ve gained in this case is that it’s unwise to keep the module common on the top level, while configurability with commonality on the lower architecture levels can be very useful.” To Peijnenburg, the discussions nicely demonstrate the value of good architecting skills. “Here, too, we see the importance of being able to look at the bigger picture – from both sides. Technical assertiveness is playing a similar big role, stimulated by ESI’s system architecture training, where a combined team from ASML and VDL used the commonality case to advance their skills.”

The wafer handler collaboration is illustrative of the ecosystem’s growing involvement in ASML’s product realization, making this process more complex and the role of system engineers even more important. “Having external modules like VDL’s wafer handler means that our system engineers have to work with suppliers, their architects and engineers and their ways of working,” observes Van Vlerken. “This takes the stakeholder game to a whole new level. We need to build bridges to learn to understand each other.”

Klunder sees room for improvement there. “Our suppliers have dedicated knowledge that we’re not fully utilizing yet. By expanding our architecting network outward, we could take better advantage of that knowledge, for example, to make our product realization simpler, cheaper or more reliable. And instead of handing them a finished design, we could involve them earlier by tapping into their innovative strengths.”

Working for a supplier, Peijnenburg acknowledges that there’s still something to gain. “We can definitely contribute to our customers’ architecting processes. For this to fly, however, both sides need to really get to know and appreciate each other. We have to move even closer together and act as one. After all, in the end, our interests are intertwined: we benefit if ASML sells good systems and ASML benefits if we deliver good modules. Our architects need to become more aware of that.”

This article was written in close collaboration with ESI (TNO). Main picture credit: ASML