For the past several months, I've been studying how large organizations are approaching digital twins, reality capture, geospatial systems, asset management, and operational intelligence.
One pattern keeps surfacing: the most advanced organizations are no longer chasing a single digital twin application. Instead, they describe a broader shift, one in which a shared model of the physical world becomes the primary interface to operational information, with the visible 3D scene serving as merely the tip of the iceberg. The real work happens in the integrating architecture beneath the surface: how data, context, decisions, and action are bound together across the lifecycle.
Across these conversations, the goals sound remarkably similar:
Reduce time spent searching across disconnected systems
Connect operational, engineering, and geospatial data around physical assets
Create a trusted representation of "what exists" and "where it exists"
Enable field workers, planners, engineers, and operators to work from a shared contextual view
Support future capabilities such as AI, automation, robotics, and XR
The recurring vision goes something like this:
Click on an asset, location, machine, building, facility, or piece of infrastructure and immediately see everything relevant to it (based on your role and/or need to know) not another dashboard, not another document repository, not another point solution. A model-driven way of working.
Here's an angle I'm increasingly convinced by:
What actually allows many digital twins to compose into a system of systems, without collapsing into a monolith, is that they share space and time, not that they share one schema or one master model. A shared coordinate frame is what enables a facility twin, a network twin, a city twin, and an organizational twin to coexist and interoperate, each federating to its own authoritative systems (PLM, ERP, BIM, historians, control systems) rather than being absorbed into a single model.
I'd like to test that hypothesis against what you're actually seeing.
What I am Curious About
1. Is your organization trying to build a "system of reality"?
Not necessarily branded as a digital twin, but a trusted, shared representation of the physical world that multiple teams can build on. Examples include facilities, industrial plants, utilities, transportation infrastructure, campuses, cities, construction projects, and manufacturing environments.
Or is the focus still primarily application-specific and siloed?
2. What is the biggest obstacle?
Which of these sounds most familiar?
- Reality data is captured but rarely reused
- Asset data lives in too many systems
- Lack of interoperability between vendors
- No common asset identity across systems
- Spatial and temporal context is missing
- Digital twins become expensive to maintain
- Inconsistent data governance and standards
- Difficulty connecting operational data to physical assets
Which one is actually slowing you down the most?
3. How foundational is geospatial context... really?
A recurring theme: location (and increasingly, time) becomes the common language connecting otherwise disconnected systems, because nearly every operational record already carries both.
Is space-and-time becoming foundational in your architecture, or is it still treated as a specialized GIS capability?
Do you see location as a core organizing principle for enterprise data, the frame on which the rest of your context sits, or as just one domain among many?
I'm genuinely interested in pushback here.
4. Have organizations moved past the visualization-first framing of digital twins?
Digital twins were never meant to be just 3D viewers, but marketing and the natural tendency to focus on what's visible pushed many implementations in that direction. The visualization layer is only the tip of the iceberg; the real value lives in the integrating architecture beneath it, powering things like:
In your experience, are organizations moving past that framing and treating the visualization layer of the digital thread as the surface of decisions made in the layers underneath?
5. Where is federation working and where is it breaking down?
The organizations making real progress aren't replacing PLM, ERP, BIM, or historians. They're federating those authoritative systems into a shared context and connecting them across the lifecycle.
Where is federation actually working in your environment?
Where does it keep breaking down? ...governance, identity, temporal alignment, vendor politics, something else?
6. Where are these capabilities painful to implement and where have you seen them done well?
Most of the capabilities on the usual wishlist: interoperability, asset-centric search, reality data management, real-time positioning, semantic knowledge graphs, automated contextualization, open standards, AI-ready twins already exist in some form. The harder question is whether they hold up under real conditions.
Which of these patterns have been the most painful to implement or integrate in your environment?
Where has reality fallen short of the pitch? Which capabilities looked promising but failed to meet expectations at scale, under governance, or across the full lifecycle?
Conversely, where have you seen a pattern executed genuinely well and what made it work? The architecture, the team, the constraints, the vendor discipline, the underlying data foundation?
I care more about what you’ve experienced, what it actually took to move from slide to deployment, than about any wishlists.
A Working Hypothesis
The next generation of digital twins won't win on better 3D models. They'll win by becoming the interface to a shared operational foundation, one where a common spatial-temporal frame allows bounded twins to compose across reality data, enterprise systems, asset knowledge, and workflows, without any single vendor owning the entire stack.
Put differently: the value isn't in the twin itself. It's in what the twin allows you to integrate at the seams while PLM, ERP, BIM, historians, and control systems remain authoritative within their own domains.
Two honest boundaries I'd defend:
Orchestration engines, agent runtimes, and physical actuators are not geospatial functions. Spatial reasoning contributes to decisions; it doesn't execute them.
"Space and time" is a claim that must be earned through real temporal and versioning maturity, not just maps.
I'd love to hear perspectives from anyone working in:
Oil & Gas · Utilities · Manufacturing · Mining · AEC · Transportation · Defense · Smart Cities · Telecommunications · Facilities & Real Estate · Technology vendors · Digital transformation leaders