Fields marked with a * are required


ENOVIA Data Management: Less PDM-ish, More PLM-ish

References Cited

Dassault Systèmes, Mechanical Computer Aided Design (MCAD), Product Lifecycle Management (PLM), Product Data Management (PDM)

All CAD data management is the same, right?

You create a 3D model. You save the file. You check it in. You move on.

That might have been the story for the last 15 years, but now, it is changing in many ways. At the beginning of 2013, I wrote about how The PDM Revolution is Upon Us, Brought to You By CAD in the Cloud. My points there still hold true. However, after a briefing with the folks at Dassault Systèmes, I’ve realized  there’s a lot more changing with PDM than I thought.

This post provides details on ENOVIA data management capabilities as well as my perspective on how it can impact an engineering organization’s ability to collaborate.

ENOVIA Data Management Capabilities

How does ENOVIA manage design data? To really answer that question, we need a little context.

CAD and the Evolution of PDM

When 3D modeling first emerged, there was a figurative explosion of CAD files. Each individual component had a file. Each assembly had a file. Each drawing had a file. Additionally, many of these files were interconnected. A change to a part updated the assembly associatively. Very quickly, engineering organizations realized they needed PDM to manage it. And interestingly, PDM systems initially were developed to solve this problem.

That, however, wasn’t the only problem. CAD models have never been simple files. Lots of stuff have been, and continue to be, jammed into them. They contain far more than just geometry. They contain part numbers, so drawing BOMs  populate automatically. They contain material properties, such that mass properties can be calculated. Over time, as more and more enterprise considerations needed to be taken into account, more non-geometry stuff has been jammed into CAD files.

The problem with all this stuff in CAD files was that, unlike many other types of files, operating systems couldn’t understand the structure of information in CAD files. Windows couldn’t pluck out a part number out of a part file and present it to a user. Instead, that file had to be opened by the user so they could see it. Ultimately, this was another problem that PDM solved, but that was secondary.

What is ENOVIA Doing Differently?

How is that context related to ENOVIA’s data management capabilities? Well, the folks at Dassault Systèmes are trying to liberate all that stuff jammed into the CAD file. Here are some notes from my briefing with them.

In short, they are taking non-geometric items in CAD files an turning them into meta-data that lives in ENOVIA. They are being turned into individual pieces of information that can be modified separately and independently from every other piece of information and the geometry. Of course, this meta-data is related and will live as a database item right alongside the file that contains the geometry.

OK. Got it? Now, let’s discuss the important question: why is this important?

So this is the critical capability. I know. It might seem like a very nuanced thing. But there are some big implications. That is coming up next.

Commentary and Analysis

Let’s start with the most important part, which is…

Simultaneous Modifications

To show why this is import and different, let’s walk through an example.

Let’s say that we have two users that need to edit a part. One wants to change the part number. The other wants to change the material. To date, the way this would be accomplished would be as follows. User 1 would check out the CAD file. They would modify the part number. They would check it back in. User 2 would then check out that CAD file. They would switch the material. They would check it back in.

The important point here is that those changes occurred serially, one after the other. With two users, that may not be a big deal. But once you scale that up to, say, twenty users collaborating on 100 parts, users need to get in line to modify a part. Or worse yet, users simply own a part with no one else touching them, eliminating any collaboration.

With Dassault Systèmes’ approach, the need to explicitly coordinate change or wait in line for modifications is removed. All that meta-data can be modified simultaneously and independently. Design teams can work more collaboratively and quickly.

Design Information Management

Now, given the context of what we just went over, it feels like this is a pretty fundamental change. To date, PDM breaks down into three areas. There is CAD data management, which is essentially very specialized file management. There is engineering data management, which is getting all your other specifications, calculations spreadsheets and whatnot alongside your CAD files. There is enterprise data management, which is getting all the deliverables created by the rest of the company alongside the engineering artifacts. Put all together, these three areas make up a fairly complete product record. My point here is that the unifying trait of all three of those PDM areas is managing files.

PLM, on the other hand, doesn’t really manage files. It manages traits and characteristics of processes and products, and there certainly is a lot of that, as meta-data in a database.

And that’s is what strikes me as interesting. PDM has basically always been about managing files. PLM has basically always been about managing meta-data. But here I am talking about managing what used to live in CAD files, and therefore used to be PDM, that is now living in a database, which used to be PLM.

Terminology is always difficult in this industry. But in my mind, I can’t used the traditional file-based PDM term to describe it. This is more like Design Information Management, with a little geometry added in.


In this post so far, I’ve continually referenced the CAD file as the thing being transformed into meta-data. But what we’re talking about here isn’t just limited to CAD , it’s a movement that extends to simulation, manufacturing models and much more.

I haven’t verified this explicitly with Dassault Systèmes. However, I fully expect that loads and boundary conditions, mesh constraints, material properties and much more from simulation models will be teased apart and managed as separate items in ENOVIA. Similarly, I expect tool speeds and feeds, tool selections and NC sequence and operations will likewise be plucked out of the manufacturing model file and managed as individual things in ENOVIA. Basically, anything that isn’t geometry will be going in this direction

The rationale, by the way, holds true in each of these cases. Simultaneous modification of these entities to enable collaboration.

The Objections

In the modern era of this industry, I haven’t really seen any other CAD-PDM interaction like this. Obviously, for Dassault Systèmes, that provides differentiation. However, because it is so different, it also poses some interesting questions with respect to interoperability.

Let’s say, for example, someone wanted to take a CATIA model and push it over into a different CAD application. It will be relatively straightforward to get the geometry out of ENOVIA. After all, that’s just a file. But the key question is this: what else should come with it? I expect that ENOVIA can and would be able to dump in all sorts of meta-data into a file, but what parameters should go with it?

By the way, this issue exists in some form or shape between other CAD applications today anyway. The parameters that are tracked and managed in a CAD file for Creo are likely very different from that used in Inventor Fusion as well as NX. There’s some parameters tracked in one format that isn’t tracked in others and vice-versa. When it comes down to it, this kind of problem already exists.

Summary and Questions

Yes. Yes. I know that was a lot. But it’s a complex issue with nuances that matter. Now, let’s recap.

  • To date, CAD files have been full of meta-data that is not geometry based. A modification to any meta-data item or geometry forces a uprev in the iteration of that CAD file. This can limit the ability of a team to collaboratively design because it forces users to sequentially change that file via PDM.
  • Dassault Systèmes is plucking practically all non-geometric meta-data parameters out of CAD, as well as other, files so that they become database entries. This allows them to be modified separately an independently from one another. This also enables users to modify them simultaneously instead of serially.
  • This marks a change for PDM, which has traditionally focused on a specialized version of file management, to now become more PLM-ish in that the focus is more on database management of meta-data.
  • I expect the scope of this database management of non-geometric items to not just be limited to CAD, but extend into simulation, manufacturing and beyond.
  • Because this stands as a different approach to managing design (and other) data, it raises questions with respect to interoperability. What meta-data should be exchanged? However, this problem exists today, in some form, between the most frequently used CAD application formats. There is no 100% match in what is tracked and managed within those CAD files currently.

Penny for your thoughts? I expect there will be some good discussions on this one. I’m looking forward to it. Leave your thoughts!

Take care. Talk soon. Thanks for reading.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

Fields marked with a * are required


  • InsidePLM

    Good day Chad, Thank you for the interesting article. So anything non geometry is separated… that I presume is a technical challenge in CATIA going forward. The separation I believe is not a game changer rather a technical evolution. So all non-geometric information will reside as objects in the RDBMS and each of these objects can be modified according to its own change dynamics/clock-speed. That is fair, but this is synonymous with a model in which the drawing (object) is separated for reasons that the change dynamics of the drawing compared to the model may be higher. Although the non-intelligent drawing as we know it today may vanish over time. A similar notion may apply to for example PMI/FTA (object) being a part/drawing/PMI data set. Adobe wants to follow this route also creating a PMI document “report” in 3MBD; how one would register such report with its dependencies is a different topic. Is that fair?


    • Hey P. I think you characterized it correctly.

      In fact, I think individual pieces of PMI, like a note, a surface finish, a dimension and other forms of PMI will each be their own database entity. And the example you gave is also accurate, these items will change at their own rates different from the geometry, just like an engineering drawing does with the 3D model.

      I think it would be interesting if more of the CAD / PDM / PLM interactions went in this direction because of the implications on interoperability. Cleanly translating the geometry would be one objective, but it would be separated from transferring non-geometric information. That actually might become far easier as a result. I am, however, just speculating.

  • PLMInsider

    Hi Chad,
    Yes I share your speculation.. The 3DS Enovia/CATIAV6 strategy is far from clear (still) and I presume that the approach in your post is to implement a proper master model (read model separation) paradigm that would have caused a painful journey going forward when NOT implemented.
    Sorry I obscured my name. BR Peter

  • Very interesting stuff, Chad.

    Well that finally explains why CATIA V6 requires ENOVIA V6 – but I also imagine that has thrown a giant turd into the Wheaties of any company using a PLM system other than ENOVIA to manage their CATIA data. This object decimation of CAD metadata will no doubt be darn near impossible to deal with in those scenarios I might imagine.

    The step towards concurrent editing is the way to go – though some edit scenarios may seem quite chaotic, I wonder if they have accounted for ways to reconcile easily across multiple individual metadata change histories. That could be quite confusing to the average user if not done correctly. I also think the scenarios where other users need to edit metadata while the geometry is edited by someone else is a rather limited use case, but that shouldn’t stop them from overselling it. But I think this stops just short of the true holy grail – which would have been to allow multiple simultaneous edits on the geometry itself.

  • This is a very interesting topic and will be following it closely.

    The problem of just dealing with CAD files is definitely restrictive. I work in the ship building industry which requires over 200, 000 parts and over 70, 000 drawings to model a typical ship as well as the documentation to build it.

    Back in 2005 we rewrote our entire application to be database driven with all information including geometric information to be stored in the database. The geometry stored was not the final result of the part but rather the definition of the components which created the part. This in essence allows drawings to be recreated by the information in the database and allow an easy way to access any information you need in numerous different ways.

    The geometric information is not tied to specific application and therefore can technically use any system which has an API. We have had partners take the information from our solution and integrate it directly to other systems such as automatic benders and cutters on the production floor. This is all without using a single drawing.

    The CAD system becomes the GUI allowing the user to interact with the model as well as provides a method to interface with other file-centric applications. Taking into account some realities of ship building we have simplified the storage of the geometry. I do realize other industries will not have the same luxury as the ship building industry, however I think the concept of being more information/data-centric than file-centric is very interesting.

    I cannot help read the above as a sales pitch but it was intended just to provide context to why I feel once we get rid of being file bound the amount of opportunities to leverage all our information is very exciting.

  • Jens Krueger

    Thank you for the article, Chad.
    I think it is a good summary of Dassault’s vision on CATIA data management. And I think that DS really brought some innovations to the PLM world by attacking issues such as concurrent engineering and global collaboration. This approach raises some interesting questions though, e.g.:
    – how to implement this approach for multi-CAD
    – can the meta-data that is extracted from CAD be manipulated in PDM, e.g. to drive geometry changes
    – can the meta-data (e.g. configurable product structure) come from non-DS applications -> openness
    Best regards,
    PS: I wouldn’t agree with your notion of PDM=files and PLM=meta-data. We have product structure and ECO/ECR meta-data in PDM, and PLM is also about providing files from engineering to downstream processes such as aftersales.

  • Good stuff, Chad.

    I think it’s a mistake for the externalized information to only exist as metadata in Enovia. I’ve heard anecdotally that the evaluation of the v5 to v6 transition broke against Dassault on more than one occasion. “You mean that in order to upgrade we (a) have to convert all our legacy data to a new format and (b) use Enovia instead of what we’re using now? Hmm, where’s that quote from Siemens again?”

    Maybe within Enovia the data can live in database tables, but there should be some mechanism for exporting the data out. Could it not be stored as multiple data files within a directory of related files. This would free customers to use Dassault’s CAD with someone else’s PLM — or vice versa if and when other vendors start doing the same thing. Maybe they think their approach will help them gain or lock in Enovia customers, but I may end up costing them more Catia customers.

    Breaking the monolithic data model down into smaller modules has advantages for change management and tracking. I have two revisions of my Creo model – how do I know for sure what exactly changed? But if it’s a V6 model I can tell exactly if it was the geometry or the properties or the whatever.

    In an ideal world the data formats for the different model pieces would be open.

    Eventually the geometric data could itself broken down into discrete units so we can track who changed that particular hole feature and when, or support branching and merging capability at the individual feature level.