CAD data management marketing

CAD data management marketing

I like data and databases. It is one of my favorite topics. Especially when it comes intertwined with PDM, PLM, and CAD. Therefore my attention was caught by Onshape blog article giving some sort of Database Marketing 101 course. Check this out here – The Difference Between Files and Databases – and What it Means for CAD and Product Design by Neil Cooke. Read it and draw your conclusion.

The article is briefly describing 4 different data management approaches – File(s), PDM database, File-less , and Non-relational databases. I can see Onshape’s point about importance of eliminating files.  I agree with Neil and Onshape – files are really bad things if you need to collaborate on data. Some of my earlier articles about the same topic are here PDM bad experience – it is all CAD system fault and Cloud CAD can make check-in / check-out process obsolete. Onshape made a revolutionary solution by eliminating files and providing modern data management and mechanical design solution.

The article explained that Onshape is using document-based databases, also known as “non-relational database” (NoSQL). I believe NoSQL databases has some advantages over RDBMS when it comes to data schema flexibility, but this is where my agreement with Neil Cooke ends. I found database marketing rhetoric of article a bit confusing for engineers.

In the past, PDM and PLM systems used databases as a competitive source. As such, alignment with a specific database vendor (eg. Oracle or IBM) gave IT approval and marketing advantage. At a certain moment in history, Microsoft became a stronger database and enterprise player. It allowed to PLM vendors to use Microsoft SQL server as a competitive advantage as well.

The things are different in data management these days. We live in the era of Cambrian Data Management Explosion. Web and new data management development introduced us to a wide range of databases. NoSQL databases is not a single database type and contain a variety of data management systems such as key-value, column, document, graph. There is a variation of databases. Even more, there is a growing trend called polyglot persistence, which basically explains how web architecture is using multiple databases similar to how multiple programming languages used to deliver a more efficient data management solution. More traditional databases and market leaders vendors such as Oracle and Microsoft are actively developing NoSQL features in SQL databases. At the same time, NoSQL database vendors (eg. MongoDB) are after features that traditionally attributed to ACID type of databases. By itself, it is a complex field and mechanical engineers should not be involved in database business because in many situations databases are secondary to features of the CAD, PDM and PLM system.

Here is my take on how different databases used in PDM/PLM development in the past 20-30 years.

1- Files and Proprietary databases

To be honest, a file is also a kind of database. The marketing language can be tricky, but going back to 1980s, most data management systems were proprietary using specific binary file format to manage data. It before RDBMS were taking mainstream adoption and standardizing on SQL query language. Check the following Oracle blog article about database architecture history and you will see how actively “file” is used in database architecture.  I used Cobol database organization (picture above) to illustrate how file term is used database organization.

Historically, most of CAD and PDM packages were developed as a workstation and lately desktop applications and was using files to store data (sometimes using binary and sometimes text formats).

2- Relational databases (RDBMS)

Relational databases are taking their roots back in the 1970s and development of Codd’s relational model. This model organizes data into one or more tables (relations) of columns and rows. Read more here.  The first development of RDBMS belongs to IBM. But Oracle was first commercially available RDBMS. Other well-known systems are DB2, Informix, SQL Server, MySQL, and a few others. Majority of relational databases are all supporting SQL language.

Most of PDM and later PLM systems are using RDBMS systems as a foundation. Although some of PLM systems that used in production today (eg. MatrixOne) originally were developed using Object Oriented database and later migrated to Oracle.

3- NoSQL and beyond

There are a variety of solutions in the market today that using multiple databases. It became especially popular for SaaS and cloud solutions (Onshape is one of them, in my view). Modern data management technologies are enabling these new products and allow them to deliver a more efficient solution from every standpoint – functionality, cost, maintenance, and others.

In my article – PLM and data management in the 21st century. I explained how different database management technologies can be used for a variety of PLM solutions. Here is a table I created back in 2013. I can certainly improve it based on the last 6 year of development experience, but I prefer to leave it as is for the purpose of this blog as it is a good reflection of the time when Onshape development was started.

By itself, each database cannot give an advantage to CAD or PLM technology or product. A solution is what makes it different. Onshape has a very unique approach to deliver 3D CAD system in a browser, which differentiates it from many others. However, it is possible that NoSQL document databases are used by other CAD vendors these days.

From my experience engineers are pretty much ignorant of database technologies. Actually, Onshape made the best recommendation about what CAD engineers should do with databases at the beginning of the blog. Here is the passage I like:

All engineers really need to know is what they can and can’t do with their data and the implications that may have on their daily workload. They may need to know how much setup is involved and if a certain workflow or sequence of events must be followed in order to make the system work the way they want. The more an engineer has to think about data management, the more it negatively impacts their design processes, their deadlines and potentially, their budgets.

Speaking about database marketing, I cannot avoid the story of Highway 101 billboard and database wars. It goes back to the time Oracle and few other database vendors actively marketed advantage of specific databases. Check this article – it is fun.

What is my conclusion? We live in a very intense technological world. We tend to use techno-marketing language, but it a very dangerous thing that should be taken very carefully. Onshape developed a very unique technology and product enabling functions that never been available before in a single CAD product. However, to build a product is only one step. To develop a solution, market and business are needed to make product successful and this is where I see Onshape is focusing these days. Databases have very little to do with building solutions and business. Just my thoughts…

Best, Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing cloud-based bill of materials and inventory management tool for manufacturing companies, hardware startups and supply chain. My opinion can be unintentionally biased.


Share This Post

  • Pingback: GHZ Partners | IT Services, Software()

  • pgarrish

    Having read the blog, I’m struggling to see why not needing checkout on a part model is a good thing? Why would you want more than one person changing the same thing at the same time? Its not like a document where you can allocate sections of the document to different people. Or do you think he’s thinking more about modelling at assembly level, so conceivably you have several parts in the single ‘model’?

    Now if the adoption of NoSQL stuff means you can augment the data model more easily and search much faster and more flexibly, then I’m all for it, but that doesn’t rule out files for the actual data

  • beyondplm

    @pgarrish:disqus NoSQL by itself doesn’t mean anything, IMO. Solution matters. The question about simultaneous editing is one of the most trickiest to ask. Onshape is managing data changes differently and as a result you can simultaneously edit. Is it a feature user need, time will show. But it is very cool. On the other side, you can see that even Files are not used by Onshape, the logical structure (folders and documents) is still in place. You can ask why? I think, because this is how people (engineers) are thinking. So, Onshape added folders support and other related features.

  • pgarrish

    Re NoSQL, as I understand it, the database doesn’t have to be ‘pre-structured’ for queries the way it has to be with an RDBMS, so if you change the data model and want to search on a new attribute, it should just work, without needing a new index, or new search tables.

    As for file vs db storage of models, I’m not sure it makes any practical difference – you are managing a chunk of data. In my mind, controlling that piece of data via checkout makes perfect sense, but it depends on how big and rich that piece of data is as to whether there may be several potential concurrent editors

  • beyondplm

    NoSQL means different model of data and different data schemas. There is a schema and indexes in any database. Therefore I pointed on a different flavors of NoSQL- Key value, Document, Graph. Just to say “NoSQL” is pointless and pure marketing.