Suppose you were a CAD developer, and you wanted to build a next-generation CAD system. How would you do it?

I’ve thought about that question for quite a while. Nearly 30 years, in fact. I’ve watched a bunch of attempts at building next-generation CAD systems. I’ve been involved in a few too. I can tell you this much: It’s not as easy as you think it is.

The folks at Dassault Systemes have also been thinking about it for quite a while. A few years ago, they previewed a new generation version of SolidWorks, called SolidWorks V6. They showed it in public one time, then shut up. And speculation about it has been rampant since.

Although I’m not a fan of the confusion that the name brings (See SolidWorks V6 is not SolidWorks), it’s possible that I might be a fan of the actual product, when it comes out.

Might. Because I’ve only seen one glimpse of it, and don’t know its details.

What DS has told us

Here’s what DS has been willing to say (or show), so far:

• SolidWorks V6 is built on CATIA/ENOVIA V6 technology.
• SoldWorks V6 uses the DS CGM (Convergence Geometric Modeler) kernel.
• SolidWorks V6 can be delivered as a cloud application
• SolidWorks V6 can run on Windows, OSX, or Linux
• The team that is creating SolidWorks V6 is being headed up by Gian Paolo Bassi

These slim facts, though, are enough to provide some useful clues to with which to speculate on the nature of SolidWorks V6.

A few guesses on architecture

Let’s start with the CATIA/ENOVIA V6 technology: DS spent about $2 Billion to rebuild their V6 technology on a service oriented architecture (SOA.) You can read all about SOA on Wikipedia, but suffice it to say that it’s a good way of modularizing a CAD system, so you can deliver scalable capabilities and scalable performance.

With SOA, the back-end of the CAD system is delivered as a set of loosely coupled interoperable services, which can be run on a remote server or cluster, on a private or public cloud, or even locally, on your own computer.

One of the nice benefits of SOA is that, if implemented properly, and run in a virtual machine, the back-end services can run on top of nearly any operating system or hardware.

The front-end user interface (or client) for SolidWorks V6 could be built in any number of ways. DS has some impressive technology in its 3DVIA Studio (formerly Virtools) product. The 3DVIA Player, which is a browser plug-in, seems to be capable enough to be a CAD client. Yet, there are clues that DS may not be going this way.

The first clue is the inconsistency of platform support with 3DVIA Player. For example, there’s no 3DVIA player for Linux. And, while 3DVIA Mobile HD (which only supports static models) is available for the iPad, it’s not available for Android. And there is no 3DVIA Composer mobile player yet – despite DS having talked about publically two years ago. Take all this together, and it’s not hard to infer that it’d be difficult for DS to build a multi-platform CAD client using 3DVIA.

The second clue is that fat clients, such as 3DVIA Player, have fallen out of favor in recent years. Consider that Adobe has divested Flex and deprecated Flash. Microsoft has moved from Silverlight to Metro. Even Apple, long known for its proprietary proclivities, has become an HTML5 advocate.

A more modern approach to building a CAD client might be to use HTML5 and WebGL, in a compatible browser. You can see an example of this type of client in Tinkercad (or Sunglass.) While not nearly a competitor for SolidWorks (as a professional tool), Tinkercad does a nice job of demonstrating the feasibility of a browser-based CAD interface.

The important thing here is that the client front-end and services back-end in an SOA CAD system are logically separate, and can communicate using standard web services protocols. If a computer, tablet, or phone has the capability to run a sufficiently good browser, it can be used as a front-end for such a CAD system. If it has enough memory and computing power, it can be used to run the back-end. If it has both, it can run the entire CAD system. At that point, a modern SOA CAD system would be pretty much indistinguishable from a traditional desktop CAD system.

This, incidentally, is one of the slickest ways to get platform independence in a modern desktop application: Implement the front end in a browser, the back-end as services running in a virtual machine on the same computer, and use web services to connect the two. Using this technique, DS could theoretically deliver SolidWorks as a cloud-based SaaS (software as a service) app, as an enterprise network app (with a federated database), or as a standalone desktop app. All using the same code.

The modeling kernel

It’s no surprise that DS is planning to use CGM instead of Parasolid in SolidWorks V6. If they wanted to, they could actually use both, for backwards compatibility with SolidWorks V1 (that’s what they call the current version), though at an additional cost in licensing fees. (IronCAD, for example, uses both ACIS and Parasolid. And, though they don’t talk about it in public, DS almost certainly had internal test versions of SolidWorks running both ACIS and Parasolid many years ago. They would have been nuts not to, if only to cover their downside risk were their relationship with Siemens/Unigraphics to have soured.)

The real question with CGM is whether it will be compatible enough to Parasolid to provide 100% (not 99%) downward compatibility with SolidWorks V1. No one outside of DS’s development labs really knows the answer to that question.

Compatibility will come at one of two levels: Boundary representation (Brep), or feature-level.

CGM does support foundation-based tolerant modeling, so it should, in theory, be able to read Parasolid Breps accurately. But it’s not that simple.

Paul Stallings, VP of R&D for Kubotek pointed out the problem for me last year: “The most difficult problem with tolerances is not that one system uses one tolerance and another system uses another tolerance. The biggest problem is that some systems depend on curves in three dimensional space, and other systems depend on curves in the different two dimensional parameter space of the surfaces that they are on. The mis-match between parameter space and three dimensional space is a very big problem with ACIS and Parasolid using three dimensional space and Catia and ProE using parameter space.”

There are other problems on top of this. Parasolid and CGM likely define topology and geometry in different ways. Even seemingly simple shapes such as cylinders and spheres can be represented and parameterized differently. (I understand that CATIA represents cylinders as two half-cylinders.) Advanced procedural surfaces can involve many undocumented, cryptic, or even unimplemented options. When these surfaces are near-tangent to neighboring NURBS surfaces, fitting can be very difficult. And then there are problems with multiple flipping flags, for faces, edges, and curves. If you get one of them wrong, all is lost.

Still, DS has had some of their best people working on CGM for a long time. Their Spatial division has a really good understanding of Parasolid (they support it in their 3D InterOp data exchange products.) So, I give DS the benefit of the doubt, that they can work through any CGM/Parasolid Brep interoperability problems. At least to the 99% level. For the last 1%, technologies exist, such as Capvidia’s CompareWorks, which 100% validate translated model integrity.

Feature-level interoperability between SolidWorks V6 and SolidWorks V1 may be a shakier proposition. It depends on whether, given a feature’s recipe as an input, CGM is capable of generating the same exact same result as Parasolid.

Consider blending (or filleting.) Blending functions in CAD systems, no matter what kernel they’re based on, are often unpredictable, counter-intuitive, and prone to failure. No vendor—not Siemens, not DS, not PTC, and not Autodesk—has “solved” blending. Here are a few examples of Parasold blending problems:

CGM will have its own blending problems, but it’s unlikely that they’ll be the exact same ones that Parasolid has. SolidWorks users are a hardy bunch, and have spent the last 17 years or so finding ways to work around strange blending behavior. So, even if CGM is actually technically better at blending than Parasolid, it could create problems when users are actually relying on getting identical results.

The important question may be: does it really matter?

If SolidWorks V6 doesn’t have feature-level compatibility with SoldWorks V1, it’ll be in good company. No other CAD system does either. Unless the two products are used in an iterative workflow, it’s likely that Brep level compatibility will suffice. And, while SolidWorks V1 doesn’t have advanced direct modeling tools for editing dumb Breps, that’s no reason to assume that SolidWorks V6 won’t. In fact, DS does have interesting direct modeling technology in CATIA V6. It would make sense that it might show up in SolidWorks V6. If that happens, SolidWorks V6 users may be able to import and reparamaterize SolidWorks V1 models. That opens up interesting possibilities.

Not just another CAD new system

So far, everything I’ve been talking about with respect to SolidWorks V6 is speculation, based on the small amount of information that DS has let out about the product. And this last bit is speculation too.

Gian Paolo Bassi, who is in charge of developing SolidWorks V6, is not a stranger to people in the CAD industry. If you check his patents, you’ll find that he’s one of the inventors of functional modeling. While I’m not going to explain functional modeling here, I will say that it’s a step beyond traditional feature-based modeling.

My guess is that DS wouldn’t have put Gian Paolo in charge of the SolidWorks V6 team if they were planning a me-too product.

In total, I’m guessing that SolidWorks V6 is going to be a really interesting product, but, at the same time, it’s going to be a very different product from SolidWorks V1. Giving up one for the other probably won’t make sense for quite a while.

User concerns

Over the last couple of years, I’ve watched a number of forums and  blogs, where users—often smart and experienced users—have expressed serious concerns about SolidWorks V6.

The concerns seem to come in several areas: compatibility with SolidWorks V1, cloud hosting (particularly of data), and SaaS licensing.

The compatibility issue is a technical issue driven by a business need. The choice of CGM over Parasolid is a strategic decision for DS. It doesn’t make business sense for DS to build a next major generation product on a competitor’s core technology. It’s true that this choice is going to impact users. The question that can’t be answered is how effectively DS will be able to minimize the impact.

But the other issues—cloud hosting and SaaS licensing—aren’t even technical issues. They’re business issues driven by technical capabilities. If Gian Paolo Bassi and his team build the V6 product right, it will open up the option of cloud hosting and SaaS licensing. It won’t close down the possibility of the software running on the desktop, with standard perpetual licensing.

Over the last few years, I’ve seen a lot of concern about the performance, reliability and security of cloud hosting, with respect to SolidWorks V6. They’re legitimate concerns—but they’re not inherent to SolidWorks V6. Consider this example: You can run the MySQL database or Apache web server on a cloud. Or you can run them right on your own computer. It’s your choice. You never see anyone fretting about their reliability, because experienced people recognize that the programs themselves are rock solid, and it’s the choice of hosting environment that can create issues.

The issues of performance, reliability, and security are key for SolidWorks V6. But, guess what? The core technology underlying SolidWorks V6 is already proven in CATIA V6. DS spent a couple of billion dollars to make sure it was up to the task. Now the question becomes one of hosting environment. That’s not a technical issue. It’s a business issue.

Business issues

I certainly have technical concerns about SolidWorks V6. But my biggest concerns have to do with business issues. Even if they get the product right, business decisions DS makes about deployment and licensing could create big problems.

To understand why this is an issue, you have to look at the shift in how DS has managed SolidWorks (the company) over time. Up until about 5 years ago, they pretty much left SolidWorks alone. Many SolidWorks users didn’t even know that the company was owned by DS. But, starting in about 2007, that began to change. Today, SolidWorks is very much a part of DS. While many of the same people are there, it’s become clear that the company’s strategy is driven by the DS executive committee, in France.

In the past, SolidWorks management was exceptionally open and transparent in their communications (at least, compared to most other big CAD companies.) Over time, SolidWorks management earned their users’ trust.

DS management, however, has a reputation for being notoriously tight-lipped when it comes to talking about anything they perceive might weaken their competitive advantage. It seems to be cultural, possibly born out of competing for the largest aerospace and automotive accounts.

To the extent that DS retains that tight-lipped tendency when engaging with SolidWorks users, it may not serve them well.  DS top management, particularly the people driving strategy, haven’t paid their dues, and earned SolidWorks users’ trust.

There are a million plus existing SolidWorks users, and many of them seem to be imagining the worst possible scenarios about SolidWorks V6.

While in many cases, FUD (fear, uncertainty, and doubt) are sewn by competitors, in this case, the FUD comes, in part, from DS’s reticence to reassure users that SolidWorks V6 is going to be a good thing (and not a tool to lock them in and bleed them dry), and, in part, from users’ legitimate concern that DS might be losing interest in SolidWorks V1.

SolidWorks 2013

It’s possible that the best answer for the concerns of existing SolidWorks customers will be in SolidWorks 2013. To the extent that the new release improves stability, and adds significant value over the previous version, users may be willing to relax their concerns that DS might be losing interest in the existing SolidWorks product line.

While the 2013 product is now in beta, SolidWorks will be officially launching it in September. I understand that they’ll be sharing their product roadmap at that time. This may be SolidWorks CEO Bertrand Sicot’s best chance to quiet the concerns, and build anticipation about SolidWorks V6—a product that could ultimately turn out to be a truly great next-gen CAD system.