What an enterprise digital twin is – and what it is not

The term has been stretched so far that it excludes almost nothing. That makes it useless in conversation – and worth drawing a clean line around.

Where the term comes from

Originally a digital twin meant something very concrete: the image of a machine, fed by sensors, with a physical model behind it. You could compute with it: how does the turbine behave under higher load? When will the bearing fail?

Three things made it work: there was an original, a live connection to it, and a model that predicts behaviour.

Transferred to an organisation, rarely more than the word survives.

Four meanings worth keeping apart

Kind	Original	Currency	Typical question
Machine twin	a device	sensors, continuous	When will it fail?
Process twin	a flow	event data from systems	Where does it back up?
Enterprise twin	the organisation	mostly maintained, not measured	What depends on what?
Data catalogue under a new name	–	–	none

The last row is not a joke. A considerable share of what is sold as a digital twin is a collection of metadata with no connection to the original.

What an enterprise twin is not

Not a simulation

An organisation cannot be computed like a gearbox. Anyone promising to simulate a reorganisation in advance is confusing a model with a physics. You can show dependencies and estimate consequences – you cannot calculate them.

Not real time

With a machine, currency comes from sensors. In an organisation there are no sensors for responsibility. Who is accountable for a process today appears in no data stream – only a person knows, and they have to enter it.

The currency of an enterprise twin comes not from measurement but from maintenance at the source.

That is a disadvantage compared with the machine, and it should not be talked away. What helps: put the maintenance where the work already happens, instead of in a separate upkeep exercise.

Not a data lake

A lake collects. A twin represents. The difference is the connection: in the twin you know that this process step is owned by that role and reaches into that system. A lake holds the same data – just without the edges between.

What makes it one, when it is

Four characteristics separate it from documentation:

Characteristic	How you recognise it
Shape	There is a form you can look at – not only tables
Reference	Elements point to each other, across views
Actors	Whoever acts is named on the element: human or agent
State	What applies today, since when, confirmed by whom

Without the state it is a map. Without the references it is separate pictures. Without the actors it is a description without responsibility.

And what about LeanIX, Signavio and ADOIT?

That is the question that comes next in the conversation – rightly so. Anyone already running an enterprise architecture tool has spent money and wants to know whether the same thing is being sold again.

The short answer: no, but the line does not run where most people expect.

What an EA tool does well

The core of SAP LeanIX is an inventory of fact sheets: applications, interfaces, data objects, business capabilities – described and linked to each other, with lifecycle, cost and risk. From that come the analyses: what is being retired? Which applications are redundant? How well is a capability supported?

That is a mature discipline, and there is no reason to replace it. If you want to clean up your application portfolio, that is the right place.

An EA tool answers: what do we have – and what of it can we switch off?

Where it stops

An inventory knows objects and their relationships. It does not know the work step someone is sitting at right now.

Take a real question from an audit interview: “Who approved that this posting runs without dual control – and when?” An EA tool can say which application performs the posting and which capability it belongs to. It cannot say who carried the decision.

That is not a shortcoming of the tool. It was built for the portfolio view, not the execution view.

The difference in one table

	EA tool	Enterprise twin
Smallest unit	Application, capability	Process step
Typical users	Architecture, IT governance	Business, project, audit
Time horizon	Years – portfolio, roadmap	Weeks – work in progress
Responsibility	business owner per object	RACI per step, with confirmation
Best question	What can we switch off?	Who decides here – and have they agreed?

Both columns are useful. They answer different questions, and the answers overlap less than the shared word “architecture” suggests.

The honest part

There is an overlap, and denying it would be dishonest: the system landscape sits in both. Maintain it in the twin and in the EA tool and you maintain it twice.

That is why the rule that applies to any coexistence of tools applies here: One field has one owner. The application portfolio belongs to the EA tool – the twin points to it instead of rebuilding it. The process step with its responsibility belongs to the twin. Maintain both in both places and you get two truths and end up believing neither.

And Signavio?

Signavio sits closer, because it models processes – it too now belongs to SAP and is run there alongside LeanIX under Business Transformation Management. The same applies: a process model is the foundation, not a replacement. The question is whether the model states who is accountable, since when, and who confirmed it – or whether that sits in a table beside it.

The question that makes the difference

It works with any vendor:

With a twin that is a query. With documentation it is an excuse.

When the effort is not worth it

For a single, well-bounded process in a stable company: it is not. A good description is enough there.

It is worth it when the same question arrives from several directions – the auditor asks for evidence, the project for requirements, IT for systems, the business for the flow – and all four answers today come from different files that contradict each other.

Read on:
TAOM Digital Twin ·
Seven views, one context ·
Attribute directory