From Mercedes to NIO: What Defines Modern Engineering Toolchains

I am pleased to have Dr. Yousef Hooshmand on board for an interview on Systems Engineering Trends. Yousef has hands-on experience with product development and its IT landscapes in both the German and Chinese automotive industries: Before joining NIO, he spent several years at Mercedes-Benz working on the modernization of the PLM landscape. Today, as PLM & R&D Toolchain Lead Architect at NIO, he is responsible for designing and further developing a holistic PLM and engineering toolchain.

About Dr. Yousef Hooshmand

Dr. Yousef Hooshmand (LinkedIn) has more than 16 years of experience in the fields of PLM, systems engineering, MBSE, and semantic integration of engineering data. After completing his doctorate and postdoctoral work in product development at the University of Duisburg-Essen, he joined Mercedes-Benz. There, he served as a Digital Transformation Consultant, as well as a PLM Architect and Technical Lead. He has been working at NIO as PLM & R&D Toolchain Lead Architect since 2022.

A key focus of his work is the transition from application-centric to data-centric engineering landscapes. In particular, he has concentrated on driving end-to-end business and digital transformation in complex development and manufacturing environments across various industries, including the automotive and energy sectors. His focus is on the design and development of federated engineering landscapes that connect fragmented data sources and enable seamless interdisciplinary collaboration. He has presented the results of his work in numerous publications and presentations. Interview with Dr. Yousef Hooshmand

The interview was conducted in writing on August 9, 2026, by Michael Jastram. This allowed Yousef to explain his views on PLM, MBSE, data-centric systems engineering, and modern product development in detail.

You've experienced the transformation of an established premium OEM and now work for a Chinese OEM. Which assumptions about modern product development have turned out to be wrong in your experience?

Two assumptions in particular turned out to be wrong, in my view.

First, I underestimated the impact of data and data integrity while simultaneously overestimating the importance of application functionality. Many organizations invest enormous effort in determining which tool offers the most features. In doing so, they overlook the fact that the speed and quality of product development depend largely on whether the required data is complete, consistent, understandable, and available across system boundaries.

The application-centric mindset This often results in data being treated merely as a byproduct of a software application. Business logic and data semantics remain hidden within proprietary data models or in the application code.

Second, I underestimated the impact of mindset on product development. A good example is how we handle milestones. You can view a milestone as a binding commitment to delivery and monitoring that must be adhered to as precisely as possible, even if it means operating partly independently of new insights. Or you can view it as an intermediate step against which we measure our actual progress, learn, and adjust our course to gradually move closer to our product development goals. Formally, the process may look identical, but the underlying mindset leads to completely different behavior.

In the first case, the focus is on adhering to the plan; in the second, on achieving the best possible result. Milestones are effective only if the organization accepts uncertainty, facilitates learning, and views adjustments not as failures but as an essential part of product development.

Modern product development is not primarily enabled by more advanced applications, but rather by the right mindset and a consistently data-driven approach that spans domains and disciplines.

Many companies invest in new PLM, ALM, or MBSE tools, yet they still aren't any faster. In your opinion, what are the most common reasons for this?

One of the most common causes is the application-centric mindset, which, among other things, Dave McComb as he so aptly criticizes in his publications „Software Wasteland“ and „The Data-Centric Revolution.“ Companies expect a new tool to solve structural problems. In reality, however, outdated processes and inconsistent data are simply transferred into a new system. The result is often a platform that looks technically modern but tends to mask the actual causes of slow product development rather than eliminating them.

The fundamental misunderstanding often begins with the term „digital transformation“. What companies actually need is a Business Transformation. Technology can support these efforts, but it cannot replace them. At best, an externally led transformation can result in a successful IT migration. A sustainable change in the way the company operates, however, must come from within the company itself.

To that end, a few years ago I developed the model of the „5 + 1 Steps for Resilient Business Transformation“ Developed and presented in 2023 at the PLM Road Map & PDT Europe conference in Paris:

• Step 0 as a prerequisite: long-term commitment from management,
• Step 1: Defining the company's values and goals,
• Step 2: Creating a business capability map,
• Step 3: Mapping the existing engineering landscape,
• Step 4: Identifying specific measures—ideally technology-neutral ones—,
• Step 5: Only then should you select the tools and technologies.

Many programs start right at step five—selecting a tool—before it is clear which business problems need to be solved. A successful transformation, on the other hand, requires a holistic approach as well as consistent top-down and bottom-up commitment.

You've been advocating a data-centric approach for years. What does data-centric engineering actually mean in day-to-day development, and why do you think this approach is important?

Data-Centric Engineering, or Data-Centric Systems Engineering (DCSE) is an approach in which data and its relationships are placed at the center of systems engineering as the primary asset. This ensures traceability across disciplines, life cycle phases, and software tools.

Based on a unified semantic data model, DCSE enables inherent semantic interoperability. Isolated artifacts are linked into an integrated graph that supports informed, data-driven decisions. This results in a semantic network that integrates heterogeneous data from structured sources such as databases, from unstructured sources such as documents, and from domain models such as CAD, Modelica, SysML, or ECAD, linking them into a coherent whole.

In practical terms, this means the following in day-to-day development work:

• Data is the core, long-lasting asset. Software applications are used to read, generate, and modify data, but they can be replaced.
• The architecture is application-agnostic. Business units can continue to use specialized, best-of-breed tools without tying engineering expertise permanently to a single software application.
• The semantics are explicit and machine-interpretable. Applications can therefore not only read data, but also understand and process its meaning, context, and relationships.
• Federated IT environments are supported. Data can be made available across decentralized domains and teams without requiring a centralized, monolithic system.
• Governance remains decentralized, but consistency is ensured collectively. Only cross-domain aspects are governed globally.

DCSE thus extends MBSE and creates contextualized data for new applications and deterministic AI solutions. You can find out more about DCSE in my article „Data-Centric Systems Engineering (DCSE) Based on the Semantic Digital Thread (SeDT)“.

The term „Digital Thread“ is used almost excessively these days. What distinguishes a Semantic Digital Thread from traditional approaches to integration between tools?

Traditional integrations primarily link information through technical identifiers, APIs, files, or point-to-point mappings. They can determine that two data sets are linked, but they cannot reliably explain what that link means. The Semantic Digital Thread In contrast, it establishes explicit, machine-interpretable relationships between system artifacts, thereby generating a context-sensitive graph.

The Semantic Digital Thread (SeDT) is the backbone of DCSE. It is based on a unified, machine-interpretable Semantic Data Model, or SeDM for short. The SeDM serves as a blueprint that defines the entities, relationships, and constraints. The SeDT, on the other hand, is the instantiated knowledge graph that brings these definitions to life with real data from enterprise systems. This knowledge graph is continuously updated and can thus map the state and evolving configuration of a system in near real time.

Furthermore, the SeDT does not stop at corporate boundaries. It must be able to map relationships and provenance across life cycle phases and value chain partners—from raw materials and mining, through suppliers, development, and production, all the way to the final product and its use.

You've experienced both monolithic and more federated tool landscapes. Which architectural principles have proven effective in practice, and which ones haven't?

For me, it's not so much individual architectural principles that are crucial as clear Decision-Making Guidelines:

• User-centric: Design for Greater User Satisfaction,
• Data-centric: Consistently treat data as a first-class citizen,
• Build for Change: Design systems from the outset to accommodate change, rather than a supposedly perfect end state.

Added to this is a fundamental principle: the idea of a universal A "single source of truth" (SSOT) is usually an illusion in engineering organizations. Data is generated and evolves across different domains and contexts. The SSOT concept can even be misleading and is sometimes used almost like a charlatan’s promise. Those who believe in it unconsciously seek, above all, monolithic applications designed to solve every problem.

On the other hand, anyone who rejects the principle Nearest Source of Truth Based on a Single Source of Change remains open to alternative solutions and strives to take the entire engineering landscape into account. You can find more on this in my post „From a Monolithic PLM Landscape to a Federated Domain and Data Mesh“.

This means that a specific object has a clearly defined, responsible source where authoritative changes are made. However, its information may be available in multiple systems and supplemented with the relevant context. This ensures that responsibility for changes and data integrity remain unambiguous without having to force all information into a single system.

Architectural approaches such as Domain-Driven Design, Data Mesh, and Semantic Web Technologies are particularly well-suited to these principles. DDD helps with domain boundaries and responsibilities, Data Mesh with federated data ownership, and Semantic Web technologies with cross-domain semantic consistency.

In principle, however, an organization may choose other architectural approaches. The key point is that the three Decision-Making Guidelines and the principle Nearest Source of Truth Based on a Single Source of Change must be strictly adhered to.

If you could redesign the toolchain of a large software development company today, what three decisions would you make as early as possible?

First of all, I would explicitly consider the toolchain overhaul to be part of a Business Transformation and not as an isolated IT or digital transformation project. That is why all of the aforementioned „5 + 1 Steps“ are relevant.

From a technical standpoint, I would consider the following three decisions to be critical and would make them as early as possible:

First: Align the architecture with business capabilities and business domains.
Before selecting products, responsibilities, domain boundaries, and data products must be clarified. The IT architecture should not be derived from the limitations of the tools currently in use.

Second: Establish a common semantic foundation.
These include an Enterprise Upper Ontology, an Integration Model, a Terminology Model, and modular Domain Models. This foundation does not need to be complete right away, but it should grow iteratively along with prioritized use cases.

Third: Make adaptability an explicit architectural goal.
The toolchain should be modular, independent of specific software applications, and semantically integrable. Software applications must remain expandable or even interchangeable in the short term, while data and semantics can be preserved in the long term.

MBSE has been part of the industry for many years now. Where do you see the greatest successes today, and where do you think expectations have not been met?

MBSE He began his career with grand and outstanding visions. In my view, one of his most important contributions was to make these visions known to the industry in the first place: to view complex systems holistically, to explicitly model relationships, and to systematically link requirements, functions, system elements, and their verifications.

Good results have been achieved in certain areas, such as early development phases. However, the broad promise of end-to-end model-based product development has so far been only partially fulfilled, for both technical and non-technical reasons.

One of the main reasons is that MBSE is often model-centric and application-centric remains. The model is viewed as a central, long-lasting asset; however, its semantics often remain confined to a single modeling language and a specific tool ecosystem. In practice, important engineering information remains scattered across CAD, ALM, simulation, manufacturing, and quality systems, as well as in documents. This is precisely why I have been intensively engaged with data-centric systems engineering for many years.

DCSE does not replace MBSE, but rather expands upon its vision. Data and its connections become a central, long-lasting asset; the architecture is application-agnostic, semantically interoperable, and designed for federated IT landscapes. If the Semantic Digital Thread is the infrastructure, then DCSE is the methodology built upon it. Within this framework, MBSE becomes a key building block as well as a producer and consumer of semantically interconnected engineering data.

SysML v2 has become widely adopted in practice. What impact do you expect it to have on MBSE, tool integration, and the day-to-day work of development organizations?

SysML v2 In my view, this is an important step forward. The precise semantics, improved machine readability, and standardized APIs can significantly enhance automated analysis, integration, and reuse. This makes it easier to programmatically query, validate, and transform system models.

Nevertheless, SysML v2 is not a panacea. A more precise language and a better API do not automatically solve organizational problems, data silos, or the semantic heterogeneity of an entire engineering landscape. Furthermore, other domains will continue to have their own models and software tools.

SysML v2 should therefore not be made the foundation of a new, centralized monolith. Rather, I see it as a very good A component of DCSE. Through a Semantic Digital Thread, SysML v2 models can be semantically linked to CAD, simulation, test, production, and field data. In this way, SysML v2 contributes to a larger, application-agnostic, and federated engineering ecosystem.

If you could give a CTO or head of development just one piece of advice to sustainably improve collaboration between people, data, and tools, what would it be?

Don’t treat improving collaboration as a tool project, but rather as a business transformation, and consistently follow the „5 + 1 Steps for Resilient Business Transformation.“.

Start with the business values and objectives. Use them to identify the necessary business capabilities and create transparency regarding the existing engineering landscape. Next, define specific actions, and only then decide on the tools and technologies. At the same time, ensure that both senior management and employees are committed to the process in the long term.

The most important shift in perspective, therefore, is not to ask which new tool should be introduced, but rather how we need to transform the business in order to achieve the company’s goals. Only then can an initiative develop into a solid and sustainable business transformation that has a positive impact on both the organization and the IT toolchain.