Earlier posts in this series covered specific symptoms of how engineering software fails to work together: the time engineers spend moving data between tools, and the specific case of structural analysis and engineering calcs. This one zooms back out.
The goal: a working theory of where engineering software integration is heading, and why now feels different from the previous fifteen years of "this is the year we'll fix integrations."
Three eras
Engineering software's relationship with integration has gone through three rough phases.
Era 1, Monoliths (roughly 1985 to 2000). AutoCAD, Mathcad, Excel, ArcGIS, the structural-analysis suites of the era. Each one was the place a particular kind of engineering work got done. Integration happened by file: you exported a CSV from Mathcad, opened it in Excel, did your calcs, exported a DXF, opened it in AutoCAD. Slow, but workflows were also slower, and tools were expected to work this way.
Era 2, APIs and unbundling (roughly 2000 to 2020). The number of specialised engineering tools exploded. Each one was meaningfully better at its specific job than the previous monolith had been. Vendors added APIs and SDKs because they had to, since the alternative was being unintegratable. But the integration model was bilateral: every pair of tools that needed to work together required someone, somewhere, to write code that connected them. The result was a tangled mesh. A typical structural workflow might pass through six tools, each pair-wise integrated by a different junior engineer's Python script written in a different year.
This is where most firms still are.
Era 3, platform-mediated integration (now). A new generation of tools is built around the assumption that they'll be one node in a connected workflow rather than the whole workflow. The integrations aren't bilateral; they're hub-and-spoke, with a platform in the middle holding the data and the connections. The platform's job isn't to be a better Excel or a better ETABS, since those tools are already excellent at their jobs. The platform's job is to be the connective tissue.
CalcTree is one of these, focused on engineering calculations and the connections around them. A handful of others take the same architectural approach in adjacent areas, for example geometry, drawing, BIM modelling, and building physics. Different focus areas, same pattern.
Why now is different from previous "this is the year" moments
Three things have changed structurally that didn't use to be true.
Cloud-first products are designed differently. When the platform expects to run in the browser and hold state on a server, the integration surface is the product. There's no "we'll add an integration story later." The schema, the API, the auth model, the streaming layer: they're built day one because they have to be. This is a structural advantage over desktop-era tools that bolted integrations onto a single-machine assumption.
Type-aware no-code is finally good. Connecting two tools used to mean writing code. The no-code tools that promised to fix this for the last decade weren't quite enough. They could do simple value-mapping but stumbled on engineering-specific requirements like unit safety, structured trees, and live updates. The current generation handles that. Engineers can wire connections themselves without depending on a senior with Python skills.
AI as glue. A meaningful share of integration work is schema-matching: figuring out that "Length" in Tool A maps to "L_total" in Tool B and needs a unit conversion. That's a task language models do well. Tools that lean on this can offer integration breadth that pre-AI tools couldn't economically support.
None of these is sufficient on its own. Together they're a different game.
What this means for the three groups
For engineers. The practical change is in how design exploration feels. Workflows that today require manual updates between tools will become live-connected. The cost of trying one more variation drops. The shape of design work shifts toward more iteration and fewer guesses.
For firms. The integration burden is currently distributed across senior engineers' time. As platform-mediated integration matures, that burden moves into the platform layer. Firms that adopt early get the productivity gain. Firms that don't keep paying the time tax their competitors stop paying.
For software vendors. "We don't play well with others" stops being a defensible product position. Tools either become connectable nodes in the platform-mediated layer or get edged out by ones that are. The smart vendors are already partnering with the platform layer rather than fighting it.
What to watch over the next 18 months
A few specific things worth tracking if you care about this transition.
Whether desktop-first tools find a clean path into the platform layer. Most engineering software still runs on the desktop and isn't going to move to the cloud. The platforms that handle this gracefully, by running native desktop runtimes that integrate with web platforms, will dominate. Ones that demand cloud-only will see slower adoption from the engineering middle.
Whether standards bodies and vendors agree on a few common schemas. IFC has shown both how valuable shared schemas are and how slowly they evolve. Whether something like "calculation as a structured object" gets even loose convention around it is a load-bearing question for this whole transition.
Whether the workflows themselves become first-class objects. Connecting tools is one thing. Capturing the connection, the workflow, as a documented, versionable, shareable artefact is another. The firms that get this right will turn what's currently held in individual engineers' heads (and individual engineers' Python scripts) into firm-level IP. The shift from "we can connect tools" to "we can package workflows" is where most of the real value compounds.
Whether end-user-built integrations actually scale. No-code is good now, but engineering workflows have edge cases that test it. The proof point is whether non-developer engineers actually wire up production-grade workflows themselves, or whether it stays a power-user thing.
The era of best-individual-tool engineering software is closing. The era of best-connected-tool engineering software is opening. We've been quietly building toward the latter for a while, and we're now deploying it with enterprise teams. If your firm is thinking about where its integration burden sits, we're happy to talk.
.webp)
