We Mapped 1,240 Nodes: An Anonymized Enterprise Twin Teardown

Most posts about enterprise architecture stay abstract, because the concrete version means showing your work. So let’s show the work. We ran an Enterprise Twin Scan on a real mid-market company — anonymized here, but real — and mapped 1,240 nodes: every system, process, role, and data source, and the dependencies tying them together.

What the map found is the interesting part, and it’s the same shape of finding in almost every scan. The things holding the business together were mostly things nobody had written down.

What we mapped

1,240 nodes. Systems and applications, the processes running across them, the roles and people who own them, and the data sources feeding them — with the edges that matter most: what depends on what. Built read-only, from the systems the company already ran. The value isn’t the node count; it’s that for the first time, “what happens if we change this?” had an answer you could trace instead of guess.

The three undocumented integrations

Every scan turns up load-bearing dependencies that live nowhere in the documentation. This one had three, and each was one resignation away from a bad week.

• The CSV ritual. Every Monday at 9:15, someone in finance exported a file from the ERP, fixed a column by hand, and emailed it to operations. That “integration” had run since 2019. It was in nobody’s architecture diagram, and two downstream processes depended on it completely.
• The 2011 mainframe workaround. Roughly a third of a core process routed through a workaround built in 2011, owned by a contractor who left in 2019, documented nowhere. It worked. It was also invisible and fragile.
• The one-person script. A scheduled script written by a single engineer, running on their workstation, quietly reconciling two systems every night. If that machine went dark, so did the reconciliation — and nobody else knew it existed.

None of these showed up when we asked IT how the systems connected. They showed up when the twin traced the dependencies from the data itself. That’s the difference between the documented organization and the real one.

The key-person risk

The map also scored where a single person was the only path. Several critical processes turned out to hinge on one individual’s undocumented judgment — the Marta problem, made visible and rankable before anyone gave notice. Seeing it is what lets you act on it while there’s still time.

The readiness scoring and roadmap

With the map built, the scan scored each system for technical debt and AI-readiness and each process for automation-fit. This company came out at an AI-readiness of 68 out of 100 — not bad, with specific weak spots the score pointed straight at. The output was a ranked list of 12 automation opportunities and a 90-day sequence: not “do AI,” but “start here, then here, and leave that one until the system underneath it is stabilized.” This is the part process mining alone can’t produce, because it needs the systems and people layers, not just the process flows.

What the map changed

Before the scan, the automation conversation was a series of confident opinions with no shared evidence. After it, there was a single artifact everyone could point at: here’s what we run, here’s what’s fragile, here’s what’s ready, here’s the order. The map didn’t make the decisions. It made them decidable — which, for a leadership team staring at “where do we even start with AI,” is the whole unlock.

What you’d find in yours

Different numbers, same categories. A node count that surprises you, at least one load-bearing integration nobody documented, a couple of processes resting on a single person, and a readiness score with the weak spots named. The fastest way to see the shape of it is to read a real one — the sample Twin Scan is a redacted, real deliverable. Then the only question left is what your own 1,240 nodes are hiding.

Frequently asked questions