SSI and Autodesk

This will be my first “Behind the Curtain” type of post. Every now and then I will share something about SSI or ShipConstructor that is obvious from the inside, but perhaps is not as clearly seen from without. Better aligning these two viewpoints benefits us all.

Two weeks ago Denis Morais, Pat David and I returned from Autodesk One Team Conference in Las Vegas. This is the annual sales summit for all Autodesk sales partners. SSI attends because we are one of the most significant Autodesk developers and because we are an Autodesk reseller in the Americas in our own right.

Spending that much time with Autodesk employees and other Autodesk resellers, you begin to get an idea of how many of them think of ShipConstructor. Especially with such a heavy focus on Autodesk’s own products, it becomes clear that a majority Autodesk thinks of ShipConstructor as a plugin to AutoCAD. Any overall implementation including other Autodesk products is thought of as an Autodesk solution. (I should take a minute to be fair to those of our champions within Autodesk and say that not everyone in Autodesk thinks that way. There are an increasing number of people who have indeed drunk the SSI Kool-Aid)

And frankly, the longer a client has been with SSI, the more likely it is that they think of ShipConstructor this way too. In the case of our clients it is mostly because earlier versions of ShipConstructor were plugins to AutoCAD.

Newer clients, who were never exposed to older versions of ShipConstructor, tend to think of ShipConstructor in more or less the same way as we do ourselves. With our Marine Information Modeling approach to shipbuilding software, and with AutoCAD being mainly a viewport into our product model database, we think of ShipConstructor as a range of products built on an AutoCAD foundation. Essentially ShipConstructor becomes the Autodesk solution for shipbuilding.

Why does this matter? It matters because the workflows users implement inside an engineering department are ShipConstructor workflows, not AutoCAD workflows. Once you realize this, you just as quickly realize that the rest of the Autodesk products that form a complete ShipConstructor solution can be (and need to be) implemented in the context of the ShipConstructor workflows.

This was perhaps less important when clients were only using Autodesk Navisworks for engineering review and perhaps Autodesk Inventor for some 3D equipment modeling. However, in just the last few years Autodesk has significantly extended their range of reality capture, simulation, visualization, collaboration, and engineering tools. It is critical that client’s think of all of these capabilities in a ShipConstructor context, as they are in many cases both the best answer to each particular challenge, and the one SSI looks at as our answer.

If you don’t already think of SSI and ShipConstructor this way, I would challenge everyone to ask yourself if it’s time you did…