SolidWorks As A Service – Part 3

Here are the links to Part 1 and Part 2.

Lets assume that SolidWorks manages to deploy SolidWorks as a Service using the Level 4 method I mentioned in Part 2. This means that they have a server farm with high end servers running precisely the same version, build and service pack of SolidWorks on precisely the same version and service pack of Windows and precisely the same version of God knows what else on each and every server. Lets assume that these servers are connected to each other with direct cables as fat as possible, have RAM chips the size of toast and processors running at the speed of light. And finally, let’s assume that all of this works the way it should. Basically, lets assume that they have solved the hardware issues and life is good on that front.

Henceforth, I will use each post in this series to discuss an issue and explain why for that particular issue the idea of SolidWorks as a Service is completely nuts. In this post I would like to talk about an issue that is very close to my heart – data exchange.

SaaS assumes that all of your data exists in the cloud, basically on the hard disk of a server that is beyond your control. Lets assume that bad things do not happen and your data will always be there when you want it. Lets also assume that your CAD data (which is basically your intellectual properly and the reason that you make people sign NDA’s before you share it with them) will never be proliferated. As an aside, just so that you know, I will never ever store a copy of my source code (let alone the original) on the server of another company, even if God himself promised me to keep an eye on it.

But what happens when you get data from someone else? Say an IGES or STEP file that arrives in your inbox or you download from someone’s FTP site. Normally you would simply click File->Open to view and/or edit it in SolidWorks. Now you need to upload it to the cloud before you can start working on it because SolidWorks sits in the cloud, not on your computer. If you were pissed at the amount of time SolidWorks took to start up every morning, you will now feel a far elevated level of frustration every time you want to open or save an external file. SolidWorks as a Service will work well only if everyone you work with uses SolidWorks, and that too as a Service.

Another thing. SolidWorks does not save to previous versions of its own software. So when that time of the year comes and they upgrade their servers with a new version of SolidWorks, you will suddenly find that the models you create cannot be opened by people who are not using SolidWorks as a Service. Because, unless they upgraded their software the same day SolidWorks did they will still have the old version. One of the main highlights about this SaaS thing is the lack of the need to upgrade software since the developer updates it at his end. However, in our CAD world where vendors strategically use proprietary file formats to lock in users and force upgrades, this SaaS model will be a disaster of catastrophic proportions when it comes to data exchange.

If and when you use SolidWorks as a Service, you will not get an option to continue using the old version of SolidWorks till they release SP2 or SP3 of the new version, which appears to be the norm. In Level 4 SaaS all servers needs to be running completely identical software otherwise SolidWorks would need to set up another set of servers, one set for each old version of SolidWorks. You now have an option not to open that new SolidWorks box that came in the mail till you actually wanted to start using it. When using SolidWorks as a Service you will end up using the latest version of the software, in whatever state it is at that point in time, whether you like it or not.

Towards the beginning of this post I asked us to assume that SolidWorks has sorted the hardware issues. However, I cannot help but give some food for thought. If you have ever imported an external file that was missing faces or had gaps that needed to be stitched, you must have seen exactly how long the Import Diagnosis tool takes to fix the model. While SolidWorks works its gut out, your computer all but freezes up. The reason is that this is an extremely resource intensive task. Each face needs to be analyzed with respect to it neighboring faces, extended and trimmed accordingly, stitched together, rechecked, etc. Geometry healing is no joke. Imagine a number of these tasks being performed by a number of servers while doing a rebuilds, shelling and other complex modeling operations.

My point is that SolidWorks is not a freakin’ spreadsheet or word processor like Google docs. Neither it is an online game, where no object manipulation occurs, just view manipulation. Even if objects are manipulated in an online game, they are simple transformations (translation, rotation, scaling, etc.). You don’t do complex shelling and boolean operations in an online game. If you shot a round bullet at solid object and stood there waiting for the game to show you the boolean difference between the object and the bullet’s trajectory, chances are that someone will shoot you down many times over.

Think about it. SolidWorks is high end engineering software, not some stupid business application that reads data from a database, passes it through a sorting alrogithm and spits it out into a report. Even that takes time for large data sets. You very well know how long it takes to do a rebuild of a mile long history based feature tree. There is a reason for that. The sooner you apprecaite it, the faster you will start agreeing with me that SolidWorks as a Service is completely nuts.