Discover our story, vision, and impact.

Blog

The Digital Thread Isn’t Broken. It Was Never Woven.

For fifteen years, the digital thread has been the named ambition of digital engineering. Connected requirements. Live traceability across system, software and physical design. A configuration record that resolves itself, in real time, across PLM, ALM, MBSE, simulation and manufacturing. Most large organizations have invested heavily and with serious intent. Vendors have iterated through several generations of architecture and standards. Yet the thread in most organizations, is still discontinuous.

← Back to blog

The Digital Thread Isn’t Broken. It Was Never Woven.

Michel Quazza

Christophe Francois

May 21, 2026

share this post:

For fifteen years, the digital thread has been the named ambition of digital engineering. Connected requirements. Live traceability across system, software and physical design. A configuration record that resolves itself, in real time, across PLM, ALM, MBSE, simulation and manufacturing – an auditable line from stakeholder needs to part on the production floor, and back again when something changes.

By any measure engineering organizations report against – propagation time for requirement changes, percentage of traceability links maintained automatically, time-to-answer for cross-tool configuration queries – the thread that was promised is not the one that exists.

The reflex is to assume the gap is one of investment, urgency or tool maturity. It is not. Most large organizations have invested heavily and with serious intent. Vendors have iterated through several generations of architecture and standards. The thread, in most organizations, is still discontinuous.

Five recurring failure patterns

The default response to fragmented tooling is to connect tools in pairs: a requirement-to-test-case bridge, a CAD-to-PLM connector, an MBSE-to-simulation export. Each new tool multiplies the pairwise integrations a complete thread would require.
The accumulated bridges are not an architecture; they are a sediment. When a new cross-tool question is asked – show me every active design that depends on this requirement – the sediment cannot answer it.

A second response is to collapse fragmentation by adopting a single vendor’s stack. In practice this is a multi-year disruption with an uncertain endpoint. Engineering organizations are heterogeneous by structure: M&A introduces new stacks faster than the old ones retire; partner ecosystems require interoperability with tools the organization does not control. A “single source of truth” that excludes the simulation team, the supplier network and the division on a different vendor is neither single nor a source of truth.

The hardest part of integration is not connecting tools. It is reconciling what they mean. A requirement in one tool is a slightly different object from a requirement in another – different lifecycle states, different attributes treated as primary, different rules for what constitutes a change. OSLC defined a vocabulary intended to bridge this; implementations have been incomplete, and the reconciliation work has remained the integrator’s problem. The thread exists; it cannot be fully trusted.

Frustrated with sprawl and consolidation, many organizations build their own integration hub. The first version is elegant. Three years later, the architect has rotated out, documentation is partial, new tools have been wedged in with adapters that erode coherence, and the hub has become the kind of thing it was built to replace. A custom integration platform is not a permanent solution; it is a deferred procurement decision.

The fifth pattern is the one the others obscure. Even when the integration is built, it must be used. Engineers route around tools that ask them to learn a new interface to do work they already know how to do. They export, screenshot, paste into email and reconcile manually rather than work through an integration that pulls them out of the environment they trust. Adoption is not a soft problem layered on top of integration. It is a structural property of how the integration is designed.

What the five failures share

Three properties recur across all of them.

The integration is treated as a product, not as a property of the environment.
It is built, deployed and maintained as a thing – a connector, a hub, a standardized stack. Environments evolve faster than products do, and the integration is in permanent catch-up.

The semantic work is treated as a one-time effort.
Mappings between requirement, configuration, model, simulation and manufacturing artifact are encoded when the integration is built, and assumed stable. Unfortunately data models drift, lifecycle rules change, and the encoded semantics quietly stop matching the world they describe.

The user is the last consideration.
Success is measured by whether data moves, not by whether engineers depend on it. The point at which the thread becomes operationally real – where a working engineer trusts it enough to stop maintaining a parallel spreadsheet – is rarely a design target.

What working threads have in common

Threads that work and they exist, in scattered organizations, often built by teams who have lived through one or more of the failures above share a different shape.

Interoperability lives above the tool stack rather than inside any one tool. When a tool is replaced, the layer absorbs the change; the thread does not collapse.

The mapping between requirement, configuration and model is managed deliberately named, versioned, owned not buried in connector code.

The thread shows up where the engineer already works — inside the requirements tool, inside CAD, inside the simulation environment or it does not show up at all. Adoption is not a campaign; it is a property of the design.

Vendors will be replaced, acquisitions will introduce new stacks, standards will evolve. A thread that depends on a specific configuration of vendors is a snapshot. A working thread is a layer the underlying tool stack can change beneath without the thread breaking.

Closing

The honest answer to why has the digital thread been so hard to build? is not that the work is incomplete. It is that the dominant approaches are structurally limited in ways the next year of investment, applied along the same axis, will not address.

The next briefing in this series describes the alternative: a reference architecture for federated digital engineering, in which the thread is a layer rather than a product, semantics are a managed asset rather than a buried artifact, and the engineers whose participation makes the thread real are not asked to change how they work.

The Digital Thread Isn’t Broken. It Was Never Woven.

Compare

The Digital Thread Isn’t Broken. It Was Never Woven.

Michel Quazza

Christophe Francois

Five recurring failure patterns

What the five failures share

What working threads have in common

Closing

Explore OpsHub’s data migration solutions

Customer Logos