SolidWorks As A Service – Part 2

Here is the link to Part 1.

Before I get into the implications of SolidWorks (or for that matter any other major CAD system) being offerred as a service by using the SaaS concept, let us first understand how SaaS is deployed. According to this Wikipedia page, there are four ways of implementing SaaS.

Level 1 – Ad-Hoc/Custom: Each user runs his own customized instance of the hosted application on the server. So if a server is serving a hundred SolidWorks users, it would essentially be running a hundred instances of SolidWorks, each one of which would have been customized for each user. We all know what is going to happen to that server, especially since we often have a hard time getting a single instance to respond quickly. So I am going to throw this option into the trash.

Level 2 – Configurable: Again each user uses separate instances of the hosted application but the developer does not need to customize each instance for each user. Rather he uses “configurable metadata” which makes each instance look and feel different for each user. Since this level also requires multiple instances of SolidWorks to run I am going to trash this option as well.

Level 3 – Configurable, Multi-Tenant-Efficient: This level adds multinenancy to Level 2. Multitenancy basically involves using a single instance of a hosted application to serve multiple users. So if one server is serving a hundred SolidWorks users, it will have only one instance of SolidWorks running which will have loaded the models of all hundred users in memory. So if a hundred users are busy modeling one assembly each and each assembly contains ten parts, then the SolidWorks instance on the server will have to manage a thousand parts loaded in memory all at once. This, I believe, is the best case scenerio. I leave it up to you to imagine the worst case scenario, and for which reason I trash this option as well.

Level 4 – Scalable, Configurable, Multi-Tenant-Efficient: This adds scalability to Level 3. Scalability essentially means runing the exact same application on different servers by using load-balancing techniques so that you get maximum and efficient utilization of the CPU’s, hard drives, memory and other resources of each server. Taking the example of our hundred SolidWorks users, there would be a number of servers (not sure how many) each running the same version of SolidWorks which will be handling a hundred assemblies and a thousand parts between them. When I say handling I mean simultaneously performing complex modeling operations on them while passing them around to each other. Not a pretty picture but I can imagine such a thing happenning, at least theoretically.

This, ladies and gentlemen, is Software as a Service. In a comment to my previous post, a reader wrote:

“Dassault may already have many of the technology pieces necessary to do a cloud-based solid modeler. (I’m thinking particularly of the technology that’s currently sold under the 3DVIA name.)”

3DVIA is anything but SaaS. 3D Via Shape 3.0 is an application that run on a user’s computer, not on Dassault’s server. It simply connects to Dassault’s server on start up in order to authenthicate the user, that’s all. All the modeling done in 3D Via Shape is due to the CPU, hard disk, memory and other resources of the end user’s computer.

Needless to say, in subsequent parts of this series, I will refer to Level 4 of the SaaS implementation described above. I see no point discussing how the other three could be used to deliver SolidWorks as a Service.