The battle for the engineering workspace

Nobody rents DVDs anymore. The shift to streaming took a decade, but once it tipped, it was absolute.

The same shift is now reaching engineering. CAD, BIM, simulation, 3D plant design — applications that stubbornly clung to local workstations, or for the unhappy few who could afford it, to a Citrix virtual desktop infrastructure. A new category is emerging: cloud-native engineering workspaces.

And with it, a new battle — not just over technology, but over who controls the decision.

I have watched this scene unfold too many times. As co-founder of Designair, a cloud provider of engineering workspaces, I have spent years helping firms move CAD and BIM workloads off local hardware and into the cloud. The technology works. The business case is straightforward. And yet, the same obstacle appears with remarkable consistency.

Take a recent case. A major EPC contractor was struggling to design a pharmaceutical plant and facing a 6-figure penalty - for every day of delay. To catch up, they deployed sixty AVEVA E3D workspaces on Designair in days. The project was saved.

I have the thank-you letter framed in my office.

What happened next was an unpleasant surprise. While the engineering team wanted to roll out Designair across the organisation, the CIO and CDO had other plans. They preferred to build their own cloud solution — first with AWS AppStream, then with Azure AVD. Apparently, someone had asked: “Why don’t we check with the big boys?”

By the time the internal proof of concept creaked to life with months of delay, IT had spent more on consultants than engineering had spent with Designair to save the project.

That’s when you realise: this was never a technical conversation.

The cloud bargain

When enterprises embraced “cloud first” as policy, they accepted a bargain: trade control for capability. Stop building what others have perfected. Buy the utility; focus on your actual business.

“Cloud is not a destination; it’s an operating model,” as Bask Iyer, former CIO of VMware and Dell, put it. The point was never simply to move servers elsewhere. It was to access a fundamentally different economics of scale and focus.

Salesforce serves millions of salespeople. Workday serves millions of HR departments. ServiceNow serves millions of IT support desks. These providers invest more in their domains than any single customer could justify — because they spread that investment across thousands of organisations facing the same problems. Every customer makes the product smarter. Every edge case solved once is solved for all.

No CIO today argues: “We have databases, so let’s build our own CRM.” That argument was retired twenty years ago. Not because IT lacked the talent, but because building wasn’t the point.

A familiar script

IT’s case for building engineering workspaces in-house follows a well-worn script.

First: “Windows and desktops are our remit.” True — for ordinary desktops. IT owns the standard workplace: the commodity environments that serve finance, HR, marketing, and everyone else who needs Office and a browser. But engineering workspaces are not ordinary desktops. Red Bull has a car policy. It does not apply to their Formula 1 team. Drawing the line at “it runs Windows” ignores everything that makes engineering workspaces different.

Second: “We’re accountable for security.” This is true, and precisely why IT should demand more than they can build. Security is not a project with an end date. It is a continuous discipline — monitoring, patching, responding, adapting. A cloud provider does this for thousands of customers because failure is existential. An internal team builds once and maintains when priorities allow.

Third: “We already pay for Azure.” Every company pays for accountants. That doesn’t make them an accounting firm. Azure is a toolkit. It is raw material. Having Azure no more makes you a cloud workspace provider than owning Oracle licenses makes you Salesforce.

Fourth: “We need to prevent vendor sprawl aka shadow IT.” Sprawl is real. But the cure matters. The easiest way to prevent sprawl in a tool shop is to give everyone a hammer. How long would that business thrive? IT’s job is not to eliminate vendors. It is to govern them well.

Product versus project

When IT proposes to “build this,” they are proposing a project. Projects have timelines, budgets, competing priorities, and an end date. After go-live comes maintenance — the unloved phase where enthusiasm fades and resources drift elsewhere.

A product is different. It’s here, now. Someone wakes up every morning thinking about how to make it better. Bugs get fixed not when internal priorities allow, but because customers demand it. Features ship because the market competes.

And the difference between product and project isn’t subtle. A football club with a million fans plays in a different league than one with a thousand. The budgets are different. The players are different. The stadiums are different. A provider serving millions of engineers worldwide invests at a level no internal IT team can match —because the economics don’t justify it. Why would a company fund world-class R&D for a few hundred internal users?

Product specialization cuts even deeper than scale. A cardiologist doesn’t compete with your GP — they exist in different categories. A vertical cloud provider for engineering workspaces isn’t a generalist IT department that happens to know CAD. It’s a team that does one thing, for everyone who needs that thing, every day.

The “Hey Joe” problem

Every internal build creates a dependency. Joe built it. Joe understands it. Joe is the only one who knows why that configuration exists.

Then Joe gets promoted. Or leaves. Or goes on holiday the week everything breaks.

A provider does not have a Joe. It has teams, processes, and service descriptions. Knowledge is institutional, not personal. Support exists because support is the offering — not a favour from someone with twelve other priorities.

Who decides?

The real problem is not technical. It is organisational. The conversation gets framed as an infrastructure question — and infrastructure is IT’s domain.

Engineering does not need infrastructure. It needs to run engineering tools — and since the inception of CAD, that has required its own platform. These engineering applications demand specialised environments, because GPUs aren’t going away anytime soon. IT does not choose which CAD platform to standardise on, which BIM tools to license, or which simulation software to deploy. Those are engineering decisions. The workspace has always been part of that stack.

This does not mean cutting IT out. It means clarity about roles. Engineering owns requirements, vendor selection, outcomes. IT owns governance, security, and integration. That is how it works for every other cloud service.

How this ends

I know how this story ends. Last month, the EPC’s head of engineering called me directly to discuss the next major AVEVA E3D project.

IT was not on the call.

‍