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.

  • You do bring up some good points. But, based on the conversations I’ve had with developers, they’re well aware of the issues you raise — and more.

    SaaS is not just shrinkwrapped application software loaded onto a bunch of servers.

    Incidentally, Develop3D magazine has an article on SaaS this month.

  • You do bring up some good points. But, based on the conversations I’ve had with developers, they’re well aware of the issues you raise — and more.

    SaaS is not just shrinkwrapped application software loaded onto a bunch of servers.

    Incidentally, Develop3D magazine has an article on SaaS this month.

  • Deelip,

    Just one note at the end… It may be time to get a Second Life or OpenSim account and start building. Much of the success of Linden Labs is based off the idea of “user generated content”. I agree that the shoes and cars and guns are less geometrically complex but that is partially due to not needing the extra precision.

    On the plus side, bullets do bounce off things or knock you down (thanks to them using a physics engine) and the cars you build you can sit in and test drive.

  • Deelip,

    Just one note at the end… It may be time to get a Second Life or OpenSim account and start building. Much of the success of Linden Labs is based off the idea of “user generated content”. I agree that the shoes and cars and guns are less geometrically complex but that is partially due to not needing the extra precision.

    On the plus side, bullets do bounce off things or knock you down (thanks to them using a physics engine) and the cars you build you can sit in and test drive.

  • Mark,

    I did fiddle around with Second Life when it first came out.

    Talking about user generated content, I am not sure now, but back them it was all simple mesh based stuff and subdivision, if I remember correctly.

    But you hit the nail on the head by saying “not needing the extra precision”. For today’s games, Second Life, etc. we simply need the objects to look good on the screen. For that an approximate triangle mesh would do just fine with a texture thrown over it. In CAD the render mesh a mere byproduct of the smooth and accurate NURBS model which is what we set out to create.

    These lie on two very different planes. But we will get there, one day.

  • Mark,

    I did fiddle around with Second Life when it first came out.

    Talking about user generated content, I am not sure now, but back them it was all simple mesh based stuff and subdivision, if I remember correctly.

    But you hit the nail on the head by saying “not needing the extra precision”. For today’s games, Second Life, etc. we simply need the objects to look good on the screen. For that an approximate triangle mesh would do just fine with a texture thrown over it. In CAD the render mesh a mere byproduct of the smooth and accurate NURBS model which is what we set out to create.

    These lie on two very different planes. But we will get there, one day.

  • Yes, and no, as some are hopping onto our plane.

    The user generated content for Second Life and OpenSim are spheres, torii (toruses), cones, prisms, etc. They can be hollow, incomplete (i.e, 1/2 a shere, 1/3 a cone), skewed, all kinds of things. So the direction is certainly toward an analytical representation.

    I don’t mean to imply they can do what a real solid modeler can do -there are no booleans (but people are asking for it) or even the basic stuff a solid modeler had 20 years ago. However, I do see some of the new geometry “pipelines” being closer to what we have today (analytic geometry) than the old “mesh” ones.

    Some of this is coming because of performance needs for them. Its certainly takes less data to send the definition of a sphere across the wire than a mesh that approximates one.

  • Yes, and no, as some are hopping onto our plane.

    The user generated content for Second Life and OpenSim are spheres, torii (toruses), cones, prisms, etc. They can be hollow, incomplete (i.e, 1/2 a shere, 1/3 a cone), skewed, all kinds of things. So the direction is certainly toward an analytical representation.

    I don’t mean to imply they can do what a real solid modeler can do -there are no booleans (but people are asking for it) or even the basic stuff a solid modeler had 20 years ago. However, I do see some of the new geometry “pipelines” being closer to what we have today (analytic geometry) than the old “mesh” ones.

    Some of this is coming because of performance needs for them. Its certainly takes less data to send the definition of a sphere across the wire than a mesh that approximates one.