The Day the Strength of PDM Failed

IsildursPDMTraditional Product Data Management (PDM) has been under a protracted siege on multiple fronts. From the West, the cloud invasion approaches, with the technology potential to reduce traditional PDM in all its file-handling, server-dependent glory into little more than a forgotten curiosity. From the East march legions of engineers who despise PDM in their very hearts. They feel justifiably wronged by the pains that traditional PDM has wrought upon them. As engineering focused IT resources give way to outsourced interests, PDM’s list of allies grows thin. Not that such allies were particularly strong to begin with, especially among freelancers and small business forever unaligned with traditional PDM. Now, from the cloud ranks comes a new battle cry, as CAD upstart Onshape greets the world with a first ever blog. There’s some exciting stuff in that first post for certain (for which I’ll be writing more soon), but there’s also one particular conceit buried in the comments: that a truly cloud-native CAD platform can break all bonds with PDM. PDM is defeated, the evil reign is… now hold on a minute.

Onshape’s bottom-up re-imagining of CAD is certainly refreshing, and is something the industry would benefit to see more of. They are to be commended. But where does the prophecy start to stretch a bit? It all starts with a comment which essentially translates to “PDM is dumb, don’t you think PDM is dumb? It was less costly when PDM was on paper.” It’s an understandable position because frankly, quite a bit of PDM is dumb. Especially how the Eldar have traditionally designed and implemented PDM. There have been successes, failures, open fires, and everything in-between. From the sound of it, the gentleman suffered through one of the BBQ’s failures. And so John Hirschtick of Onshape dutifully replied:

“We tried with traditional PDM, but fundamentally the architecture of copying files around, to and from servers and desktops, is just not a good basis for solving version control and collaboration problems. We think we have a better way to solve the problems, and no PDM system is needed.”

Now we’ve wandered off the road. There’s folly in contending that cloud-based CAD, by simply eliminating files to and from servers and desktops, ergo necessarily eliminates PDM. Why? It’s all a matter of collaboration and landfills. Let’s think this through for a moment. Why on earth did the kings of old bring forth PDM in the first place 3000 years ago? There were a couple of main problems:

  1. We were having trouble finding anything because as humans we are completely awesome at making landfills everywhere, be it garbage or files. Especially files.
  2. Two or more people could work on the same exact thing and royally hose themselves. Letting them fight to the death as a resolution was ultimately impractical (and unsanitary).

So PDM came forth, creating a centralized repository, and a check-in/check-out paradigm to let versions enter and exit the repository without collisions. Whether the repository is in the cloud or not is irrelevant – you need check-out to draw from the repository and maintain control in the CAD application. Now let’s suppose we compress the layer between CAD and cloud so there’s no way for files to exist outside of the repository – such CAD is the repository. We can throw away checkout because the data only exists in one place integral to the authoring application – but you’re still having to provide some enforcement. Not to mention it won’t help the landfill problem – seen the landfills in Google Docs lately? But what If we wanted two people to work on the same exact thing in parallel? Centralization and file abstraction could permit new modes of collaboration similar to what I described in It’s Time for Check-In to Check-Out. But you’re merely replacing one manner of PDM principles with another (source control). You haven’t eliminated PDM – it’s only different. Buy why, do you ask, should that matter? It’s more about control.

It’s no secret many engineers hate PDM. Real blood-curdling hatred. There are two primary reasons. One is legitimate, the other is not. The legitimate reason is the software is painful, ugly, slow, and generally a PITA. That takes away from the engineers time, concentration, and sanity. It’s a legitimate gripe and one that has long plagued enterprise software in general and PDM in specific. The second reason, which is not so legitimate, is a loss of control. The reason so many engineers pine about the days of paper-based PDM in document control departments (or instead nothing at all) is that world could be circumvented in a pinch. It was flawed because it was run by humans, and consequently also replete with errors. Replaced with immutable and uncaring software, engineers working in groups nonetheless become irritated because they can’t just do whatever they want. You see this very conflict happening with regard to source control in software development circles. The order needed to manage a complex product necessarily makes manipulating pieces of that engineering more cumbersome. It’s one thing to be creating some widget in a freelance environment, it’s another matter entirely when that end product needs traceable configuration for a serialized certification basis. And that will happen regardless of how the software operates.

So maybe we can assume that all engineers will accept loss of absolute control if the interface is so refined it will be more awesome than Elrond riding on a robot unicorn towed by a space battleship? Is PDM independence guaranteed then? Please? Nothing is certain.

The moment you have to deal with a subcontractor, supplier, a second, third, or fifth CAD, or any PLM/ERP integration, your argument is invalid. It would be great if the data and all the changes to it just lives in one vertically integrated cloud repository solely controlled by a single vendor. But the days of the isolated data islands are long over, and the Multi-CAD, multi-system reality prevails. In that eternally heterogeneous environment, PDM fights to live again.