Fasten all seatbelts, seal all entrances and exits, close all shops in the mall, cancel the tree ring circus, secure all animals in the zoo, prepare the ship for… an upgrade. Software upgrades should be a time of unbridled anticipation, celebration, and joy; after all upgrades bring new features, performance enhancements, improved interfaces, and don’t forget about all that bug squashing. Why then, in the world of Computer Aided Design (CAD) are upgrades met with such trepidation? More importantly, as cloud technologies continue to permeate the tools of engineering design, and the Software as a Service (SaaS) model becomes more commonplace, what does the future hold? Continuous upgradability is often quoted as one of the primary advantages of SaaS, supplanting the traditional model where upgrades must be purchased outright. Is this a welcome development, or is it time to push the self-destruct button?

Joe Barkai’s excellent exploration of long-term product data retention in an article entitled On PLM (In)Compatability, is accompanied by an ongoing survey that illustrates the state of CAD and Product Lifecycle Management (PLM) upgradability:

” …there is a lingering pain of periodically upgrading PLM and CAD software, and exchanging CAD models across the fragmented design collaboration chain. Users feel new releases happen too frequently, and often they are not sure about the value the new software provides. They want to know how long, how disruptive, how much will it cost, what’s the value? From an ongoing survey I am running, it appears that companies often skip a version or two (sometimes more) before they endeavor an upgrade.”

The survey results ring true. But why? Several factors are at work here. For smaller firms or individuals, the financial burden of purchasing every upgraded version is often overwhelming and unjustifiable. In theory, that’s where SaaS should come to the rescue – by providing a more attractive pricing platform. While SaaS solutions certainly undercut the cost of buying each and every discrete upgrade according to the developer’s release cadence, they fail to actually save money for customers not married to that cadence. The costs of upgrading only every other (or third) version remains the low-cost leader. When forced into an elevated pricing model via subscription services, those same customers will be, shall we say, perturbed. Some will no doubt make for the escape pods.

Upgrade cost is only a portion of this conundrum, especially since larger firms on average can afford to plunk down the coin. Yet those firms are just as reluctant to upgrade and keep pace with current software releases. One reason is the inherent complexity of CAD or PLM software is often detrimental to software quality. Because such software is most often evaluated and monetized on a feature basis, overall quality takes a back seat (or sometimes gets thrown off the bus). Some things break, and often they don’t break in obvious ways. So the old saying goes in CAD circles, always upgrade to last year’s version. Wait until the software has been broken in and stabilized over the combined suffering of those less vigilant.

There’s something else; it’s not just the CAD software that’s impacted during an upgrade. The larger the company, the more pieces are involved. There may be Product Data Management (PDM) or PLM integrations to worry about, all of which may have their own Java, display driver, and operating system dependencies, not to mention any customizations that have been layered on top of any of these things. Integrations have to be tested, customization tweaked, and individual data files tested for resiliency. It’s a huge task. Even the smallest maintenance pack is weighed with suspicion if you’re going to subject it on 10,000 engineers. Or an entire supply chain. Not being prepared could have dire implications for productivity and cost effectiveness, which by the way is the central purpose of most of these tools. Come to think of it, it’s a miracle anyone upgrades at all. Which is why the CAD and PLM market can follow what would otherwise be considered a rather geologic pace compared to other software, yet still have most customers completely overwhelmed by the pace change. Complexity brings problems.

And along comes SaaS with the philosophy of continuous upgrades.   Most proponents will argue this should drive customers to customize less. But is that really a solution, or more of a mandate? The approach certainly drives solutions to be tighter and more focused, but arguably at the cost of flexibility. Will that work for CAD and PLM? My guess is probably not.

What are you preparing? You’re always preparing. Just go!  

A simple example comes to mind that illustrates an important point: a recent UI change in LinkedIn. Several features I was accustomed to simply fell off the home page one morning with little warning – it was obvious they pushed out an update. After filing a support ticket I received a reply from a support tech happily asking for a screenshot of what I thought was missing. Let’s think about that. A screenshot. Of the old version. Which has been overwritten by a pushed update over the web. I’m supposed to do that how?   Fortunately, LinkedIn is common enough I could Google someone else’s screenshot, but you can see where this is going. Understanding regressions in CAD or PLM often requires careful analysis of what is versus what was. Now if we take that away… sure, that will be just awesome. I later was informed I was part of an A/B test on Linked in. It’s a useful technique only possible with SaaS, in which different versions of the software are pushed to different users/groups, enabling scientific evaluation of how new features are used or received. Well, in theory anyway. But it begs the question: Should I be taking preemptive screenshots of everything?

So here’s the thing, the continuous upgrade model, while sufficient for your burrito finder app, or markup text editor, may not be such a great idea for complex software, especially software with external dependencies and proprietary data stores. So what can be done to improve the CAD upgrade situation? SaaS doesn’t have to be a forced upgrade model – pushes could easily be timed to coincide with other system changes – even if they were completely independent SaaS implementations. It also should be technically be possible to deploy multiple versions – even use the A/B technique to pilot upcoming changes in controlled groups. With the right amount of finesse, SaaS upgradability could open new possibilities in software configuration management. Think vendors will take that option or will they just go to plaid?