Esri’s Technology Director for AEC spent roughly three decades on the industry side, most of it at Arcadis, before joining Esri to work the problem from the platform side. His case for digital twins starts with the mix of expertise required inside an AEC firm and ends with a flood-control system in South Florida he built before the term “digital twin” existed.
Micah Callough spent roughly three decades on the industry side of AEC before joining Esri in 2019 — nearly 18 years at Arcadis, where he held a series of technology and digital-solutions leadership roles, with earlier geospatial work tied to Bechtel-run U.S. Department of Energy site services. “I think I’ve fought this fight over years, trying to get people to even leverage technology,” Callough said, recalling a period when project managers wouldn’t let him near their projects for fear a network model would jeopardize a wastewater treatment plant bid. He framed digital twins less as a new technology than as the latest name for a transformation the industry has been inching toward for a long time. “A lot of people don’t necessarily realize they’ve all been part of this journey in small pieces, over time,” he said. “We finally kind of nailed down a word that we all seem to be willing to use, and it sets the north star.”
Three Brains in Every Firm
Callough’s framework for where AEC firms actually stand today starts with the mix of expertise inside the organization, not with a particular technology. Alongside leadership and project management, he identified three professional groups as especially important to digital transformation: engineers, scientists, and what he calls technologists — a group he is careful to distinguish from IT staff. “IT people still do IT things. They keep the lights on, they keep the tools running, they keep us secure,” he said. “The technologists I’m talking about are the people that apply technology for business outcomes. They’re the data scientists, the geospatial people, the photogrammetrists.”
He put GIS specifically ahead of building information modeling on that curve, not as a rivalry but as a head start. “If you look at the history of GIS and the history of BIM, GIS was at what BIM is doing now 20 years before BIM was doing what it’s doing,” Callough said. “BIM just got the benefit of the long runway that GIS did to figure it all out, and they accelerated it because they learned and the technology got better. So they got there faster.” His broader point was less about which discipline leads than about why the divide persists at all. “Why does a design engineer or surveyor bring information in and not understand the context in which they’re working? Doesn’t design influence, or get influenced by, the world around it? It should, because everything that exists is geographic. Full stop.”
Field, Reality, Real Time
Asked how a firm actually understands the real world well enough to design against it, Callough offered a three-part framework he returns to often: field collection, reality capture, and real time. Field collection is the traditional model — someone with expertise, survey-grade or otherwise, physically observes and records a condition. But Callough was careful to note that not every problem is a survey problem in the strict sense. “The problem might just be, find me where they painted the things on the road in order to figure out where the lines are,” he said. “Somebody already surveyed the line bit. Now I’m just figuring out the secondary bit.”
Reality capture is what fills in around that targeted field work at scale — capturing broad conditions in mass, accepting a lower accuracy threshold where the problem doesn’t demand better. Callough, who described himself only half-jokingly as the inventor of billions of manholes, recalled pushing back on clients who insisted on centimeter accuracy for problems that didn’t need it. Clients often changed their minds once they saw what obtaining that accuracy would cost, he said. “What are you really trying to do? You’re trying to say, if I put a backhoe in the ground and swing it, am I going to hit the manhole? That’s your accuracy level.”
The third leg, real time, is the newest and the one Callough said most professional engineers still underestimate. He pointed to Bechtel’s Big Dig project in Boston, where a concrete-curing problem cost the project heavily, as the kind of failure a cheap embedded sensor could now prevent — reporting when concrete has actually set to spec before the next phase of work proceeds, rather than finding out much later. The industry is beginning to deploy more of these sensor-enabled applications, Callough said, although most current digital twins remain narrow, component-level systems — a utility network here, a highway network there, an environmental model somewhere else — built around whatever domain the team building them actually understands. Location, he argued, is what allows those otherwise separate systems to connect into a broader operational picture.
South Florida, Before the Term Existed
Callough’s clearest example of a working digital twin predates the term by roughly two decades. While working with the South Florida Water Management District, Callough encountered a landscape of roughly a million SCADA systems controlling flood-control pumps across South Florida, each purchased from a different manufacturer and each operated locally — a system that depended on one operator knowing to call another operator to coordinate a response during a hurricane. Working with Arcadis, IBM, and another consultant, Callough’s team built a connected SCADA environment that aggregated those independently manufactured systems into one operating picture, tied to geographic location and made accessible through an Esri ArcIMS interface — Esri’s web mapping product at the time. An administrator could manually adjust pumps through that interface, or let a rules-based system flag a developing condition and adjust multiple SCADA systems automatically. Callough estimated that the connected system allowed operators to respond to developing flood conditions 50 to 60 percent faster. “In the long run, that is a digital twin.”
Callough said he would build the same kind of system today through ArcGIS Velocity, which he described as a highly scalable, Kubernetes-based framework for ingesting independent sensor feeds, either directly or through a broker such as AWS IoT or Azure IoT, and tying each one back to a geographic location. That geographic tie is what turns isolated sensor data into something operationally useful across a wider system — in Callough’s framing, understanding not just what a given pump station is doing, but how changing that pump station’s operation changes water levels somewhere else entirely.
Whose Twin Is It, Anyway
Callough’s most direct criticism was reserved for AEC firms that adopt digital twin language before answering a more basic question. “Who’s the digital twin for, first and foremost? What’s it for?” A twin built to support design, engineering, and construction is fundamentally an operational tool for managing the asset being built. A twin built to meet a regulatory obligation — Callough gave the example of a five-year EPA Superfund remediation agreement — is a risk-management tool with real financial consequences attached if it fails. A twin built explicitly for a client represents yet another kind of deliverable, and one Callough said AEC firms sometimes assume exists without confirming the client actually wants or understands it. “Sometimes AECs just kind of get ahead of their skis to try to sell something,” he said. The resolution, in his account, is less technical than organizational: agreeing on shared language with the client before building anything, so that design models, as-built documentation, and mapping data all feed the same downstream story rather than three incompatible ones.
Connected, Not Common
Callough was pointed about one piece of industry vocabulary he avoids. “I don’t like the word CDE — common data environment. It works if you’re just talking about design, but I’ve always hated the word, because there’s never going to be one database to rule them all. Never, ever, never. It’s just not going to happen.” His preferred framing is a connected, rather than common, data environment — discrete systems that stay distinct but link back to each other through shared geographic location, rather than an assumption that every stakeholder will eventually migrate into a single unified database. He pointed to a recent Esri demonstration using AI to extract information from soil boring logs — PDF files that, in most organizations, are used once for a project and then archived, never to be read again — as an example of the more achievable path: pulling structured, mapped, dated information out of files that already exist rather than waiting for everyone to adopt a common format going forward. “If you put enough holes in the ground,” Callough said, “you’re going to get a pretty comprehensive picture of what’s going on underneath your area.”Asked what brought him from three decades on the industry side to Esri specifically, Callough described a career-stage calculation as much as a technology one. “I looked at my ramp from here to retirement, and I started thinking, you know, I really would like to affect the industry as a whole,” he said, noting his work today spans Esri’s partnerships with Microsoft and Autodesk as much as it does Esri’s own platform. “I think we can ultimately completely and utterly change the way engineering is