Future of PDM: complexity, functionality and open source

Future of PDM: complexity, functionality and open source


Product Data Management (PDM) is recently getting more focus and traction. You might think why so? PDM is a mature field with well known behavior, functions and value proposition. For example, if you follow Jim Brown of TechClarity, you can find a very nice infographic explaining the value of product data management (PDM). Another publication of TechClarity  – The business value of product data management can be found here. Note, the research was sponsored Siemens PLM, so you will need to get registered on Siemens PLM website to get access to the full report.

However, world is changing and so the technology around us. I’ve been reading GrabCAD blog earlier today – Interview: What hardware developers can learn from software developers. Read the full story and you will find some interesting facts related to development of Poppy Project – robot using an open-source humanoid platform based on robust, flexible, easy-to-use hardware and software. The part of the article I specially like was related to how engineers at Poppy Project are using PDM and other collaborative tools such as software source control. The comparison between PDM and SCM tools was stroke me as something very interesting. Here is my favorite passage:

With software development version control is important. Our software team uses Git, for example.  Now I can’t work without it even for CAD. Our robotics project is open source so I need to use developmental branches for this type of work. I use Git flows to keep repositories organized. What else have you used to manage your files? I tried SolidWorks PDM but it’s not great. For one, its too complicated. A simple interface is important because we want to attract people to participate not scare them away. I couldn’t find anything like SVN (Apache Subversion) or any modern source control system. At this point it looks like we’re probably going to use Git for individual work and GrabCAD Workbench for sharing work with others.

It is absolutely not surprising to hear about complexity of PDM tools. Even my truly believe, SolidWorks PDM is not the most complicated PDM tool, it was still okay to say SVN is simpler. However, what is specially interesting, Poppy Project people found PDM tool lacking some important functions such as branching, forking and merging requests. The following passage is nailing down the difference between collaboration of people in traditional engineering processes compared to open source projects.

With an open source project, especially an open source robot, people are making their own modifications but they don’t have editing rights for the main repository. They need to be able to make merge requests- send notifications from their repository to ours so their changes can be merged upstream. That’s better than everyone working on the exact same version.

It made me think more about why PDM should change these days. Our working environment is changing fast. What was strictly prohibited yesterday, becomes a norm today. Open source is one of these things. The new trend is to re-use models, software code and other elements of design from outside of your organization (or in the community). This is a new field for engineering organization and manufacturing companies these days. It brings a new requirement to PDM.

CAD/PDM integration and new functional challenges

New PDM functional requirements will point back on some fundamental problems of PDM such as deep integration with CAD tools. Navigate to one of my previous articles Multi-CAD PDM integration: yesterday, today and tomorrow. The complexity of CAD/PDM integration is going to be tightly dependent on functionality of CAD that needs to be supported by PDM. The ability of branch and merge version is tightly coupled with this cross CAD-PDM functional bundle. In my view, to merge CAD models is much more complicated task than merging software source code text files. There is no reliable technology today that can help you to do it easy.

What is my conclusion? Even PDM is 25+ years mature technology, it is a time for PDM to change. The changes are coming from the huge demand for simplification driven by consumer tools and technologies. At the same time, new functionality driven by trends such as social product development, open source and development communities will be challenging PDM vendors. In particular, CAD-PDM integration will be one of them. Just my thoughts…

Best, Oleg


Share This Post

  • Hi Oleg. I’ve been contemplating this subject myself. I spent several years as a CAD guy, then I got into programming, so I’m always trying to relate the one field to the other. I think of assemblies as being like source files, subassemblies like #included imports of other source files, and individual lines of code as the piece parts. And if you want you can dig down into a piece part and view the feature tree as the “source file” and the individual features as the lines of code. The analogy has flaws (it’s a lot cheaper to rewrite a line of code than remachine a piece part…) but it lends yourself to thinking about how tools like GIT and Subversion could apply to the PDM world.

    Software tools evolve at an amazing rate. I think I heard of GIT for the first time, blinked, and suddenly realized it had taken over the world. PDM is a bit more… reserved in its adoption of new ideas, to say the least. But man I think there could be some cool results.

    Imagine being able to do a diff between two versions of your CAD model and seeing exactly which features were added, deleted or modified. Or working on a redesign of an assembly in a feature branch that was completely isolated from the production “trunk”. Yeah, you can kind of do it with access rules and statuses and stuff, but it’s not a natural fit for the current tools (or at least the ones I know about).



  • beyondplm

    Scott, thanks for your comment! I like some of your associations and reflections. Especially GIT related. It was progressing with amazing speed. However, the key part I see in your comment (and I agree 100%) is related to CAD models diffs and ability to go with features diff, comparison, merge. Think about it in terms of software code – it is on a completely different level. When we will be able to do with CAD with we can do today with source code, our PDM tools will become closer to GIT we have today. Just my thoughts :). Best, Oleg

  • Thanks Oleg for another great and topical article.

    PDM evolved from the document and configuration control paper methodologies that predated it – so the technology has always been biased toward a formal, serial design process, rather than an informal, parallel one. What we’re seeing in the open source projects is a glimpse of what it takes to collectively design something in an organic nonlinear fashion. That’s the next step.

    The interesting thing is that there’s a good chunk of younger design engineers working in formal, serial projects in regular companies that have been trying to work this way for some time. But it’s been relatively impossible because of tool limitations and old traditions.

    Accomplishing the branch/merge with CAD is an amazing, colossal technical hurdle – but the technical feat alone is not enough – the resulting technology has to have the accessibility of GIT or it won’t be enough. I really see the existing players struggling to find a place for such a paradox in their current financial models.

  • beyondplm

    Ed, thanks for your comment! I agree- branching with CAD will be VERY complicated and hard to do without CAD vendors. And it is probably next big thing that might happen in PDM after cloud transparency. It seems to me most of dev efforts of everybody is focused is how to solve PDM delivery on the cloud. Best, Oleg

  • Pingback: PLM Weekly News: November 4th, 2013 - Zero Wait State()