With a handcart, you cannot reach the moon

The provocation in the title shows the main message of this article: To reach a dedicated goal you need the right tools. Going to the moon obviously needs something else than conventional transportation. The Cloud is on the way to the moon.

This article explains and comments a session of Ilya Baran, responsible for the architecture of Onshape, held on #OnshapeLive21. He called it ?Under the Hood". He explains underlying technologies and the engine of Onshape on it's way to the moon, to remain in the pictorial term. This presentation showed me, that the value of a good and a software has to be measured also looking also under the hood. It was for me an important brick in the wall of my decision and my passion to promote Onshape as private person.

Picture stories tell well obvious things, like this one: The fundament of a building determines, what you can build upon, a skyscraper, a decent one floor building or a doghouse. This is the same with the architecture of a software and the software itsself.

The unique capabilities and the potential of Onshape have the root in an early decision to build something new, totally based on Internet and Database technology. This makes capabilities of secure sharing designs, branching & merging design alternatives and other capabilities to meet today design challenges more easily possible.

The architecture is built without compromises on Multi-Tenancy and Cloud. This has the result, the Onshape users are communicating only with one single system and that they are sharing one pool of ressources. This is not equal with giving a user an instance of a software in the cloud, like the Siemens NX Cloud connected solution. This is ,,Cloud-washed", a real cloud application has to have inbuilt common ressources for sharing, collaboration and others and is much smarter in maintenance and costs, because only one system has to be maintained and scaled up and down.

In consequence first foundations were built, then special capabilities followed. Already early versions like the ones in 2014 had the base workflows of merging/branching, simultanous editing etc.. You must build a system in mind of the intended architecture, the trial to mix some new in combination with old technology have the ?cloud-washed" result, like the market followers of Onshape have.

If you look onto the on the current offerings, you have the classical quadrant model:

Lower left - all current desktop CAD' s like Inventor, Solid Edge, SolidWorks, NX, Creo.

Then you have to half way solutions:

Hosted CAD solutions offering a virtual machine with the CAD installed. You have access from anywhere and not to invest in expensive hardware. But you still have the same CAD system with collaboration as it is, version and data management headaches. Examples are the eval trials of SolidWorks old desktop version or recent NX offerings.

The other halfway are Thick Clients. They install locally and serve the data through the cloud. The sharing support and collaboration is better. You still suffer of having the appropriate hardware and with upgrade issues. You do not take full advantage of a common database, no branching and merging, no simultanous editing etc. An example here are Fusion360 of Autodesk or the earlier steps of the Dassault SolidWorks cloud offering, Conceptual Designer and Industrial Designer.

There is no way from a thick client or a hosted CAD to a real cloud solution. Half Way Solutions are one way streets in the wrong direction.

The Onshape architecture is unique in the CAD world. The client handles all UI interactions and the graphics. On the other side different servers handle different tasks and some communication with the client. All boxes represent a number of machines. All are designed for redundancy. If one fails, there is an immediate replacement with another machine.

The great advantage to go central to AWS servers is, that you can scale computer power according current traffic. You can deliver high performance to a reasonable price. The underlying multi tenancy concept uses hardware efficiently. Scaling up and down with a desktop is not possible. It has to be configured upfront. Most of the usage time the computer power is running idle.

If a geometry server crashes, not the whole app crashes, like in a C++ historical monolith.

The advantages of described architecture are obvious and result of the fact, that there is no segmentation of data due to hardware infrastructure.

Everything is one one place. Imagine your bank account would suffer from losses due to instable client- server infrastructure. This does not happen, guess why?

Your data are 100% safe, references never break, you profit from big security and much better desaster szenario than traditional structure can ever provide.

Only incremental changes in your design are stored, they are not merged with before design steps. That makes design more flexible and data storage low. It opens 100% use of all design steps ever made, e. g. elegant branch and merge of design alternatives.

The good news about industry specific or customer specific customizations is: You are on the eye level of the Onshape developers. You have the same tools like the Onshape developers to create custom features. In the beginning of Onshape the founders created Feature Script to build their own, generic features. This was initially and later more available for the whole Onshape community.

One short example from my before world: Some SolidWorks resellers are pretty successful in building furniture and wood industry specific applications, mention only one, SWOOD from Eficad. I guess, having tools like Onshape delivers, life and delivering a customized CAD application is easier than with an API on top of the developer tools, which may have in addition version issues.

The Onshape service organisation has mighty tools to make availability high, security high, performance high. They do not need an offline RX tool like SolidWorks users may use to report to their support their problems and crashes. The Onshape users get more productivity, because Onshape support has prevention tools. Prevention is much mightier than Aftercare. They sometimes see problems upfront, they feel maybe the ?feaver" before you can feel it.

Imagine a development team can focus on new functionalities and is not distracted by following up regression bugs and making new functions, developed in an isolated C++ developer island, working proper in the production environment.

The 3 weeks release schedule of Onshape gives the proof, the architecture makes changes and innovation easy to deliver.

The upgrade costs and efforts are minor compared to the ones of the big Desktop Brothers!

Onshape is a strategic invest of PTC, not an invest to consume a customer base, like others do. PTC decided with the purchase to build with and around Onshape a SaaS platform for product development. This is good for all customers, competition wakes up the lazy and arrogant ones, who believe they are doing well. This is good for all PTC customers, they may have smooth options to go once, when time is there, step by step to the moon - not with a handcart.

My final words:

I have the deep impression, this path without technical and political compromise works and will work in future with more power. Precondition is, that PTC uses well the Onshape / SolidWorks heritage. Onshape is more or less flesh and blood of the world, I spent in nearly 25 years - SolidWorks.

You find the video presentation of Ilya Baran in the recordings of #Onshapelive21: https://events1.social27.com/onshapelive21/home