2024 PLM Technology Selection Deconstructed: A Guide for PLM Tech Architects and Decision Makers

Selecting PLM system and implementing product lifecycle management is not a simple process and many companies are struggling to make the choice. It is indeed hard – you can bet on big brand name or small startup. You can choose a tool and technology complimentary to your CAD system. Recently, the “cloud” element of the PLM technology choice became more and more important.

It is always important to remember that choosing PLM technology is only one element of your PLM strategy and PLM Implementation Playbook. Check my earlier article about PLM implementation stages Assessment, Process Analysis, People Change Management, Data Architecture, Implementation Services. Technology is a center of PLM implementation and it must be a foundation of you PLM playbook steps.

But today, I want to talk about about PLM technology selection in 2024. The article about cloud-native PLM and the discussing online on LinkedIn, made think more about how to help companies  to make right technology selections in 2024. In my article today. Let’s talk about 7 elements of technical assessment of PLM system and technology from a perspective of businesses in the 2024. I hope these recommendations will help large OEMs and small manufacturing startups to make right choices in the coming year.

Stop Using Generic “Cloud” Word

The word “cloud” is confusing and provides almost no value when it comes to the comparison betweed different PLM technologies and platforms in 2024.

As you can see in the picture above, mostly everyone in PLM business today will give you a “cloud system”. All platforms and tools can use a variety of cloud infrastructure in different ways to run from the “cloud”. Therefore, fo the purpose of selection, my recommendation is to go with 3 groups:

1. On premise. These solutions only can be installed on physical servers. The number of such systems is decreasing fast because vendors are quickly finding a way to “host” their platforms using variety cloud computing platforms (AWS, Azure, etc.)
2. Hosted. These solutions can be “hosted” using virtual machines or virtual computing services. the architecture of these “hosted” systems can be different. But, if you hear that the same system can be either “cloud” or “on-premise”. it tells you everything you need to know – it is a traditional PLM platform (e.g. Teamcenter, Windchill, DS 3DX) that can be also hosted and become a hosted environment (Teamcenter X, Whindchill+ and some others)
3. SaaS. These solutions require cloud infrastructure (AWS, GC, Azure, Oracle, etc.) and developed exclusively for cloud platforms. The architecture can be different, but it is important that those platforms cannot run on premise (even if you like it very much). The best of what you can get there is a private cloud to ‘deploy it to a specific customer PaaS account (eg. AWS, Azure or others)

There are differences in the architecture for #2 and #3 above and I will talk about them later in the article. They are related to how tenant management is organized and an architecture of data modeling and data management.

Tenant Management

Tenancy in the IT architecture is related to cloud computing and refers to the sharing of computing resources in a private or public environment that is isolated from other users and kept secret. Tenancy in SaaS is divided into two types: single-tenant SaaS and multi-tenant SaaS. Check my earlier article here.

Getting into the details and understand a full picture is extremely important, especially when you’re dealing with various combination of technical details, architecture and what is included in the definition of tenant and how implementation specifics are done – servers, data modeling and data sharing. Another important detail is who owns the infrastructure and performs IT tasks.

There are options when software is run on the cloud infrastructure fully own by a customer and PLM vendor only providing a software including DevOps. An alternative option is when the software is run on a public cloud and all customers are sharing the same multi-tenant instance of the application. Those are two extreme options and there are some variations.

Separately, you need to understand the implications of data management choices and capabilities. 

Data Management and Tenant Management

It is important details of any PLM technology is how data management is done, what databases are used, how they are hosted and who has a possibility to define data models, customize data schemas and sharing data between different tenants (in case of single and multi-tenant architectures).

Here are three possible options:

1. Separate database (usually on premise solution or hosted option)
2. Shared database server/services, but single tenant database (usually happens with hosted or multi-tenant SaaS, but logically limiting data management scheme per each ‘customer’ tenant)
3. Shared database server/service and multi-tenant data model (usually for SaaS and modern data management architecture allowing to share database and all data between multiple customers. Tenant separation is done using database logical model).

The solution’s difference from hardcoded inflexible  data model in multi-tenant environment (which is kind of limitation) to, single tenant database in multi tenant apps and multi-tenant data models allowing to customize each tenant, and also to share data between multiple tenants. Depending on your choice, you can get significant data modeling limitations (eg. cannot modify data model because old PLM platform was adapted for hosting with severe limitations about who and how can administer it. On the other side, multi-tenant data model is the only way to share data between companies and users. So, if your PLM strategy is to streamline data collaboration, you might need to consider multi-tenant data modeling, otherwise you will have to add everyone to your PLM system account.

Database architecture, Data Model flexibility and “PLM richness”

Data is the most important element of PLM architecture and the way PLM software is managing data and using database is absolutely critical for your choice of one or another PLM software. Most of PLM software even today is using SQL RDBs (eg. Oracle, SQL server and a few others). Modern PLM software is adopting noSQL databases (document, graph databases, and others). Polyglot data architecture of some modern PLM systems might give you a high level of efficiency of working with complex product data and queries that won’t be available in legacy PLM platforms. It is important to understand how these databases technology can enable functions, queries, reports, etc and, as a result, to decide what is the right database architecture for your company.

An important aspect of data architecture is data model flexibility. While it is great to have out of the box (OOTB) data model to be able to start system easily, there is very little a company can do when data flexibility is not sufficient. Without data model flexibility, your PLM system will be DOA when it comes to support flexible and adaptable solutions.

Last, but not list is the ability of data model to support “PLM specific” data modeling concepts to manage items, revisions, attachments, product structures (BOMs), effectivity, configurations, alternative and many other PLM concepts.

Openness, API and Integrations

The ability of PLM technological platform to be integrated with other tools is extremely important. PLM platform often play the role of a connecting hub between various data silos. Therefore, you need to check how PLM system allows to anyone else to get data (via export or instant sharing or federation). For old systems, most of integration were done using direct SQL access to the database. Modern SaaS solutions are oriented to REST API. Providing integrations with CAD, ERP and other systems is important. CAD integrations are mandatory for modern PLM tech. I’d be questioning any PLM architecture that is not supporting CAD and other engineering integration these days. It is a big con for any PLM tech.

Hosting, Security, Encryption, and Scaling

For hosted and SaaS platform, it is important to understand where the system is located, country, infrastructure and security certifications available. SOC2 and ISO certifications are customary these days. It is important to understand the capacity, maintenance, migrations, upgrades and all other aspects such as who gets access to the data, is data encrypted and all other related security requirement your company asks to maintain. Ask more questions and get in the details.

Support, Services and Educational resources

Last, but not least, please check how vendor of the PLM software provides support, customer implementation and development services as well as how to get training and educational resources.

What is my conclusion?

Selecting product lifecycle management (PLM) software technology is a complex task. PLM is a part of business systems setup to support product development process, document management, quality management, and overall process management and manufacturing process. Those systems are expecting to support an entire product lifecycle and manage engineering data as well as to be a platform that integrates data coming from multiple systems and data sources.

Therefore, to have a systematic overview of major aspects of technology and data management is important. Navigate to systems that provide you with required level of tenant/data management, support specific product lifecycle management, product data management support and overall product lifecycle feature sets. It is important to get in the details to understand the real technological difference of a PLM solution to make the right choice. Just my thoughts…

Best, Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital-thread platform with cloud-native PDM & PLM capabilities to manage product data lifecycle and connect manufacturers, construction companies, and their supply chain networks. My opinion can be unintentionally biased.