I want to make a confession. I’m a data person. I have a passion for data and how data can be used. It is fascinating to see how modern data management technologies can help to design better software for engineering and manufacturing. And the data is the key foundation element of product lifecycle management.
For many years, data management architecture was a key difference between PDM and PLM systems. If you’re a long time in this industry, you might remember debates about proprietary vs relational databases. Another nostalgic topic is flexible object-oriented databases. While object databases weren’t a reliable option to build a PLM system, the object architecture became a foundation for many flexible data models in PLM architectures end of the 1990s. Predefined schemas vs flexible schemas were another topic for debates.
PLM industry is moving towards the development of matured cloud applications. And, it brings many questions about what are the options for data management in cloud PLM applications. Today, I want to give you a review of key architecture options to design data management solutions for cloud applications with the pros and cons of each one.
Hosted vs SaaS Applications
The hosting of existing PLM systems using IaaS technology was the easiest and the most obvious step to develop cloud applications. Maturity of IaaS platforms, as well as other hosting infrastructure, made it no brainer decision for PLM vendors.
The main pro of this solution is simplicity. You’ve got the existing matured system, hosted them using different solutions (there is a market of hosted platforms and IaaS infrastructure) and you’re done. The cons of the solution are high cost and complexity of maintenance. Also, this solution leaves all advantages of cloud and collaboration outside – because hosted systems are still the same and you cannot share data between tenants.
Single-Tenant vs Multi-Tenant
The main difference between single-tenant and multi-tenant application is, in fact, how applications are designed to serve multiple users of multiple companies. As you can see from the picture one application can be used by many companies.
However, this is where an additional level of complexity starts – how to manage users, how to separate data, how to provide a different level of flexibility for individual users and companies. You can take an existing PLM platform and use one of the existing access schema features (Eg. roles or groups to separate the data). Will it make it multi-tenant? Yes, of course. But will it be good enough for customers? I’m not sure, because existing applications are not designed to serve multiple companies. A lot of limitations will come up. Therefore existing PLM platforms are limited when it comes to cloud PLM.
Multi-Tenant Data Architectures
A multi-tenant PLM app can use three different database architecture. The first is to use separate databases for each tenant, the second option is to use the same database but separate data and schemas. And the third option is to use multi-tenant schemas and data. What are the pros and cons of each of these architectures?
The main advantage of one database per tenant is to ensure data separation. Instances are physically separated. Interesting enough, this is also a big con because it won’t allow you to share the data – one tenant cannot access other tenants data.
Separate schema and data, while using the same database can reduce the complexity of servers and managing multiple databases and costs as well. A disadvantage of this architecture – it brings a complexity of management of the data per each tenant.
Finally, the third option is multi-tenant (shared) schema and data provide many benefits. Among them no need to create data and schema for each tenant. Also, there is no need to run multiple database servers. It is also the only architecture that will allow real-time data sharing between tenants The cons are the complexity of development and maintenance. However, once it is developed, you will be able to add new users and tenants very easy and at no cost.
What is my conclusion?
Data management was always the most critical part of the PLM system. The data is complex and cannot be standardized without significant trade-offs. The flexibility of PLM data platforms was key to provide a scalable and robust solution in the last two decades.
These days, the level of complexity is growing. In the past, PLM vendors developed the system for a single company. It requires installation, configuration, customization, and tuning. Now customers are demanding connections beyond export/import of Excel and systems to serve multiple companies, New multi-tenant architectures can support new business models and provide a foundation for next-level product data intelligence.
As you can see, SaaS PLM systems are introducing a new level of sophistication – how to develop a system that can serve multiple companies. The manufacturing is complex – OEMs, suppliers, contractors. What will be the ultimate PLM data architecture for the 2020s? Ask the PLM vendors to disclose the architecture of the PLM system. This is not the information that typically shared in marketing materials. I’d expect more information to be shared by vendors to provide better transparency.
Get ready for new discussions next year. I think existing PLM systems developed 15-20 years cannot stand the level of complexity of SaaS PLM without significant re-architecture and refactoring. Just my thoughts…
PS. I will speak more about new data management PLM architectures next year. Meantime, enjoy the Holiday Season break. Happy New Year!
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.