If you believe the buzz in the blogosphere, there are a lot of engineers and designers who are not at all happy at the prospect of some day being forced to use cloud-based CAD.
The public lashback on cloud CAD started building several years ago, and it’s hardly abated since. The conversation has taken on political/religious overtones.
In the best of all worlds, clould CAD could be a revolutionary tool, allowing people to work where, when, and with whom they desire. The troika of cloud, mobile, and social offer intriguing possibilities.
Yet, there are potential problems with cloud CAD, at multiple levels.
The issues are substantial enough that it’s not practical to address them all at once. So, with this article, I’ll dig into with just one issue: the difficulty in actually creating a cloud CAD program.
CAD is difficult
CAD, even without being cloud-based, is difficult to create. Mike Riddle, one of the best known CAD architects, estimates that CAD is about an order of magnitude more complex than typical Office type applications. He ‘s not talking about lines of code (though CAD programs do clock-in with tens of millions of lines of code.) Rather, he’s referring to the Chess-like complexity and difficulty of creating a CAD program that can actually model the things that its users want to model.
Understanding CAD architecture
CAD programs are built up out of a large number of software components. Some, such as geometric modeling kernels, constraint managers, graphics pipelines, and translators, are developed by fairly well-known companies, and licensed to a large number of CAD developers. Other components, such as those for manipulating raster images, zip files, or unicode characters, are available through open-source repositories, such as SourceForge. Many more components are created by CAD developers themselves.
The real magic in creating a CAD program comes in how the software compenents are arranged and connected. This is the essence of software architecture. It is largely what distinguishes great programs from lousy programs.
Once the architecture for a CAD program has been set, it can be really difficult to change.
Consider, for example, how CAD programs, almost as a rule, seem to take very poor advantage of multi-core processors. This isn’t because the CAD vendors (and the programmers who work for them) don’t want to provide good multi-core support. It’s because the architecture of their software, and of the component libraries which comprise their applications (particularly the geometric modeling kernel, if we want to point fingers) were not initially designed to support concurrency (the underlying requirement to support multi-core processors.)
Though CAD vendors could rip their software down to the ground, and re-architect it to support concurrency, it’s not so easy as just putting a team of programmers on it, and giving them a budget for coffee and Red Bull.
CAD software architectures generally creep, in an organic fashion, from release to release. Initial versions of CAD programs are often architecturally consistent because they are created by small development teams comprised of very experienced CAD programmers. Yet, over time, demands to add new features and capabilities on too-short schedules, and the addition of more programmers to development teams, can lead to hacks which compromise the architectural integrity of later versions of the software.
The result can be a CAD program that works pretty well in most cases, but which has persistent instabilities that can’t be easily fixed—either because no one actually completely understands the CAD program’s architecture, or the instability has become “baked into” the architecture. (Not to point fingers, but there are a number of well-known CAD programs which suffer from persistent instability.)
For a CEO of a CAD software company, the prospect of embarking on a re-architecture project has got to be chilling. Too many of these projects (the most infamous being AutoCAD Release 13) end up being expensive disasters.
Cloud CAD architecture
There are two ways to approach cloud CAD. One way is to use an existing desktop (e.g., Windows, OSX, or Linux based) CAD program, and run it, mostly unchanged, on virtualized servers. This is the approach that companies such as Citrix and CloudSwitch enable—and it’s nothing new. The other way is to build a CAD architecture that’s optimized for use on the cloud.
An optimal cloud CAD architecture would support scalability, both in the number of concurrent users, and in the size of CAD models. That means, essentially, breaking the CAD software down in to a number of interoperable services, which can run concurrently on multiple loosely-coupled server instances.
The problem that CAD developers run into is that, even though their existing desktop CAD systems are built from a large number of software components, those components were never designed to work in a loosely-coupled environment, and they were not, except in rare cases, designed to support concurrency. It’s simply not practical to take an existing CAD program, break it down to its components, then use those to build a cloud CAD system.
The only practical way to build a scalable cloud-based CAD system is to start from scratch, with a new architecture. While some components from existing CAD systems may be reusable as is, most are not.
Where are the cloud CAD programs?
The buzz about cloud CAD started in early 2010, with DS SolidWorks Corp previewing the cloud-based SolidWorks V6 at their user conference, and Autodesk opening up Project Butterfly, a cloud-based CAD application, on their Autodesk Labs site.
SolidWorks V6, despite its name, is built on the Dassault Systems V6 platform. It won’t be available until 2013, at the earliest, and even then, it won’t be entirely compatible with today’s SolidWorks program (because, among other reasons, it will be using a different geometric modeling kernel—one that’s quite different from the Parasolid kernel used in SolidWorks for the last 17 years.) SolidWorks V6 will be a functionally different program than SolidWorks.
AutoCAD WS, the released version of Project Butterfly, is the only notable cloud CAD application currently available. Despite its name, it’s not based on AutoCAD. It’s based on technology developed by PlanPlatform, a company acquired by Autodesk in 2009. While it does read and write AutoCAD compatible DWG files, AutoCAD WS is not a functional match to AutoCAD.
What of the other cloud CAD products?
There are none that are notable. (Or, rather, I don’t know of any that are particularly notable. I expect someone will send me straight on this if I’m wrong.)
While it’s possible that Siemens PLM or PTC have secret projects to develop cloud-based CAD programs, it’s likely that, if they do, those programs won’t be a functional match to their existing desktop CAD programs. Just like DS SolidWorks and Autodesk, they’ll need to start from scratch with cloud-based CAD.
Desktop CAD is here to stay
There are many CAD-related things you can do well on the cloud, including storage, rendering, CAE, and collaborative markup. But CAD itself? It’s easier to say than to do.
Cloud CAD is really difficult, if you want to do it right. As much as CAD company CEOs might like to talk about their visions of the future, they know that cloud CAD won’t replace desktop CAD for a very long time, if ever.
