The art of architecting meets software sculpting

In a virtual roundtable, Canon Production Printing, NXP, Philips, Thales, Thermo Fisher Scientific and Vanderlande discuss how the increasing system complexity has impacted the role of the system engineer. Their consensus: software has shuffled the cards.

The high-tech systems engineering landscape has been profoundly reshaped by digitalization. “Our products are no longer confined to the boxes they’re being shipped in,” observes Klaas Wijbrans, fellow architect at the Chief Architect Office of Philips. “They’ve become part of a network, an ecosystem, a system of systems, interacting with the cloud and other IT infrastructures. Our architects now have to think about a system with components at different locations and a business case that’s about continuous value delivery, across the product’s entire lifecycle.”

With new technologies like artificial intelligence and digital twin, systems are increasingly interacting with the real world. “They’re connecting in more ways, collecting more data and also generating more data,” says Clara Otero, senior director of system innovations at NXP Semiconductors. “As a result, our business focus has shifted from just the chip to the entire edge, and the scope of our architects has expanded to include the data needs of our customers. We’re delivering products with more digital functionality and more software.”

“Digitalization is opening up a plethora of new functionalities we can offer to our customers. At the same time, our customers are operating in an increasingly digital environment that they want to connect to our products,” notes Henk Thomassen, department head of platform development and planning at Canon Production Printing. “This has a considerable impact on our systems, which need to be much more flexible to be able to cope with the ever-changing environment they’ve become an integral part of. This calls for a smart architecture that offers that flexibility and accompanying ways of working like Agile and Scaled Agile.”

Maarten Verhoeven, executive director of architecture and integration at Vanderlande, is seeing a similar spillover of the software mindset. “In the past, system engineers had to be extremely careful as the whole supply chain counted on them to deliver a flawless design. Mistakes cost a lot of money. Software has changed that completely, with the Agile mindset of failing fast encouraging them to quickly learn from their mistakes and deploy an improved version. That’s quite a turnabout.”

Software has become the dominant discipline and that has upset the relationships on the system level. “System engineers used to throw work over the fence, to put it bluntly, relying on the hardware and software specialists,” says Roel Aalbers, technical director of systems at Thales in the Netherlands. “Now, they need to understand what’s going on there. They need to know their fair share of the digital transformation and the challenges it brings, for example in cybersecurity and the cloud.”

At Thales, the Agile mindset is causing a bit of a clash of cultures. “Our system engineers have strict requirements to adhere to, regarding legal matters, safety and security, for example. Those have to be set first, calling for a more traditional waterfall approach. This is at odds with the agility advocated by some software engineering methods,” explains Aalbers.

His colleague and system architecture expert, Jacek Skowronek, points out that because of the short cycles in software development, it’s getting increasingly hard for system engineers to keep up. “Software is already very fluid, but things like Agile and DevOps make it even more so. System engineers want to know exactly when a component will be finished and what features it will have. An agile software team usually is unable to answer those questions. That can feel like a disconnect.”

“In systems engineering, it’s all about keeping the overall overview,” says Vanderlande’s Verhoeven. “I don’t see that as much in the agile software community, where the focus is more on quickly delivering small improvements. The challenge is to keep the system working in this continuous stream of updates. Sometimes, the scale tips too far to the other side. We’re still learning to maintain the balance.”

The director and expert from Thales would like to see more interaction between the system and software side. “Both engineering disciplines should think more about the implications of their work on each other’s level,” Aalbers believes. Skowronek agrees. “In a cloud-based environment, they have access to virtually unlimited resources,” he gives as an example. “In our systems, however, hardware constraints also matter.”

Wijbrans subscribes to the sentiment. “In the past, software people had to think about making their code fit. With the cloud giving them unlimited resources, they don’t have that worry anymore. But they have to realize that they aren’t getting this for free. I’ve seen my share of poorly designed systems result in customers getting huge bills from their cloud provider, especially when data traffic scales.”

At Thermo Fisher Scientific, they, too, recognize the disconnect. They’ve chosen to partially resolve it by connecting the two worlds on the core functionality only. “We have a hardware update every 2-3 years but a new software release every three months,” illustrates Olivier Rainaut, system architecture R&D manager at the company’s Eindhoven site. “We link the two on the so-called minimum viable product of the system or module and find agreement on the interfaces and requirements there.” This approach has its price, Rainaut admits. “With frequent software updates, lifecycle management becomes a challenge.”

“We make a conscious effort to bring both sides together,” adds his colleague and principal system architect, Jamie McCormack. “In a system reference architecture, for example, we make explicit that each part of the functional system decomposition is a jointly owned exercise between hardware and software. I’m the reference architect for our TEMs, our transmission electron microscopes, and I have a software architect working right next to me on that reference architecture.”

Wijbrans fully agrees that to bridge the “huge awareness gap,” as he calls it, both sides need to better understand each other. “Modern system architects need to have sufficient knowledge about software. They don’t have to be able to write it themselves, but they do need to know how it can benefit the product. This background partly comes from training and partly from coaching. At Philips, we’re putting together people who are aware of this gap with those who are less aware, for example, as sparring partners or peer reviewers in projects.”

The key, Skowronek believes, lies in close collaboration, forced if necessary. “I once participated as an architect in a software scrum team. Now I’m quite senior, but I initially struggled to comprehend their world. Gradually, however, I started to understand it better. Likewise, it can benefit software experts to become more involved in system issues. By stimulating this on both sides of the fence, we can bridge the gap between waterfall and Agile. I’m convinced the solution lies somewhere in the middle.”

Modeling can be very instrumental in bridging the gap, too. “In the past three years, we’ve completely drawn our system reference architecture in Visio,” Rainaut explains. “These models show all the constituent parts and their interfaces. We see that new system engineers quickly get an overview and software people are eager to dive into the Visio files to get to know the system, how it works and how everything is connected.”

“It works both ways,” says McCormack. “The software guys did Visio drawings as well and when they showed them to me, I started understanding their world better, in the same way that they’ve come to understand our world better by looking at our models. As our mutual understanding grows, our way of drawing also changes for the better. In our newest models, our decompositions and interface descriptions show much more a meeting of the hardware and software world.”

Skowronek feels that such ‘lightweight’ models are often undervalued. “When many people talk about modeling these days, they’re thinking of extensive tools with all kinds of bells and whistles like code generation and validation techniques. It’s not about tooling; modeling is a basic technique I think everyone should master without a tool. Every engineer – system and software – should be able to draw a picture of a module and its interfaces using only pen and paper.”

“Whether it’s in Visio, Powerpoint or on a piece of paper, simple diagrams can be very powerful, very telling, next to model-based systems engineering,” Aalbers finds. “You can hang them on the wall and look at them with a team to get an immediate overview of the system or parts of it. These kinds of simple models are very helpful to share knowledge with new people or in a new project. For example, we have a couple of big new developments where we’re using such diagrams to make insightful what the stakeholders want.”

The well-known A3 method, named after the size of the paper the diagrams are put on, is based on exactly these principles. It helps to capture relevant architectural aspects for a specific goal, such as an architectural refactoring or handover of responsibilities. Developed by the University of Twente, Philips and ESI’s Gerrit Muller, the method has been applied within many companies.

For Thermo Fisher’s Rainaut, the lightweight modeling in Visio was a great stepping stone to full-fledged model-based systems engineering (MBSE). His people are now using the open-source Capella tool, through the cloud-based offering from Obeo, for system decomposition in a SysML-like way – hardware and software, up to interface mapping. Rainaut sees this catching on quickly. “Especially with our architects who already have some background in other types of modeling, like finite element analysis, or scripting, for example in Matlab.”

MBSE is also Vanderlande’s answer to the challenge of bridging the gap between systems and software engineering. “Our system architects use models to capture the complete system behavior. Our software engineers contribute to these models from their area of expertise,” outlines Verhoeven. “Thus, by modularly expanding the systems engineering model, as it were, they keep the overview together so that they can keep building together.”

At Philips, MBSE is of growing importance. “It does create a tension,” Wijbrans notes. “A systems engineering model needs to be complete as it specifies the whole design, whereas architecting is about creating an abstraction of the key issues. The challenge we’re looking into now is how to keep the two consistent.”

Canon Production Printing is increasingly using modeling to bring together the disciplines in virtual prototypes. “We’re putting our system architecture and the resulting designs in what we call digital lab models,” explains Thomassen. “These are fairly complex, multidisciplinary models that allow us to test our actual software before the hardware is available. Thus, virtual prototyping helps us bring our products to the market more quickly and at lower costs.”

Together with partners like ESI, the companies are making strides to get MBSE to really fly in their organization. They’re participating in multiple projects focusing on the adoption of methodologies and tools to support the modeling process itself as well as the maintenance of the resulting models. Through training programs and workshops, their architects are cranking up their MBSE skills.

With MBSE getting more and more established, this creates a whole new challenge – an interfacing conundrum in the ecosystem. “Through co-development, insourcing and outsourcing, we’re partnering with a host of suppliers and other companies,” elaborates Rainaut. “How do we ensure that they can use our models? That’s becoming increasingly difficult as we’re collaborating with more and more partners, all with their own tooling. At some point, it’s going to impact our efficiency. When we’re fully running on models that we can’t share with them, the chain will be blocked.”

The solution, in the eyes of Rainaut, lies in the interface between the partners. “The ideal situation would be if everybody were to use open-source models that can be easily exported and imported. Unfortunately, that’s not going to work because we simply can’t impose our choice of tooling on our partners. The only way to ensure an unobstructed exchange of models is to connect both sides through standard interfaces. Otherwise, we’ll be left with no other option than sending back and forth Word and Excel documents.”

Sometimes that actually is the only option. “In our part of the industry, you’d have a very hard time finding organizations that have adopted MBSE, especially on the customer side,” Skowronek from Thales notes. “Our customers almost all have their own environment. I don’t see them switching to our tooling anytime soon, let alone to an open-source alternative. Of course, we’d like to have an all-encompassing model-based environment across the value chain, but it would take many, many years to get there. For now, we mostly communicate with them through Word and Excel. I admit that it’s not very fashionable, but it works.”

Aalbers does see some progress. “Particularly in the hardware department. Systems engineering seems to be a bit lagging. In my view, there’s some more bridging work to be done there. It would already be a step in the right direction if we could have a collaborative digital platform where we could share architecture and design information with partners and customers.”

Digitalization has also added to the growing system complexity. To keep the development manageable, companies have set their sights on platformization and modularization. “Technological progress is accelerating at such a rate that it’s become very hard to monetize innovations for one-offs. That’s why we’ve moved to an approach where we base multiple products on the same platform,” explains Thomassen. “We’re basically cutting up our monolithic software architecture into functional blocks with standardized interfaces and interactions. These blocks can be developed by smaller teams, relatively independently. Like bricks, they can be combined to form complete systems by iteratively building bigger units, each of which has to be testable on its own.”

At Vanderlande, they’ve made a similar move from customer-specific projects to more generic developments. “We’re creating modular building blocks, as small and as confined as possible,” details Verhoeven. “This approach allows us to have multiple teams simultaneously working together on the same system without the complexity getting out of hand. The big challenge is to keep the interfaces in tune and decoupled, which is where the art of architecting comes in again.”

A platform-based architecture, Thomassen maintains, creates synergy in two ways: through the reuse of existing functions and components and by providing flexibility for the future. “We need to look ahead more, to product avenues that aren’t very tangible yet but that hold potential. With a flexible platform architecture, we can easily take advantage of those opportunities as they present themselves.”

Vanderlande has tasked a special group of specialists with ensuring that the platform developments align with the overall systems engineering efforts. “Our architecting guild actively monitors this alignment,” says Verhoeven. Canon Production Printing has set up platform reference projects to take care of this, Thomassen points out. “Next to the traditional product projects, we have special teams of architects watching over a technology platform and defining a reference architecture for it.”

All the new methodologies and tools are very useful to provide insight and overview to system engineers, but they’re no substitute for good ‘old-fashioned’ knowledge sharing. To support this, training providers like ESI have shifted their educational focus from teaching individual courses to offering (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 stimulate the cross-fertilization.

“Agile only gets you so far. So does comprehensive tooling,” Aalbers contends. “You won’t really get anywhere without a solid background in systems engineering. That’s partly education but mostly training on the job. You learn the most from experienced colleagues. Sharing knowledge with other high-tech companies, for example through the ESI network, is very important as well. To advance in this complex world, we can learn a lot from one another.”

At Philips, too, there’s a strong focus on knowledge transfer. “I lead the company’s architecture community,” Wijbrans clarifies. “This community currently encompasses about 900 people – system, software and solution architects. We bind them together through coaching and an extensive internal program of cross-training. Our system engineers can strengthen their ‘digital’ side with courses on cloud, connectivity and data, for example. Having such a network is extremely valuable as, in my opinion, people can only gain experience by doing and sharing.”

With the increasing digitalization, NXP’s system engineers need to raise their level of knowledge to include the customer application. “In the past, they ‘only’ needed to know about our components. Now, they also have to understand how our customers are using them, what systems they’re making with them,” says Otero. “That’s a big step – a struggle for some – but a necessary one to be able to identify future requirements. For our customers, sharing that knowledge with us can be an equally big step.”

Too much customer or product focus can also create local heroes – system engineers who know everything about a very specific development. Having worked in such a culture for a long time, the older generation still tends to be old-school like that. However, in a world where increasingly multidisciplinary groups of architects are taking on the ever-growing system complexity by sharing models and platforms, local heroship doesn’t work anymore. At Canon Production Printing, Thomassen is already feeling a new wind blowing. “In our architect community, I notice the younger generation using shared models and teaming up more easily.”

This article was written in close collaboration with ESI (TNO).