Basic Elements of SaaS PLM

Cloud and SaaS are getting high attention these days of PLM vendors and customers. The interest is driven by many benefits cloud technologies and SaaS applications can bring to both manufacturing companies and vendors. Multi-tenancy is a key element of SaaS applications, but unfortunately, the terminology is often misleading and actively used by PLM vendors and marketing making it hard for customers to understand what is behind.

In my earlier blogs this year, I provided various perspectives and shared my insight and knowledge about multi-tenancy, what it means for customers, and what vendors usually won’t tell you about multi-tenancy. Check these articles for more information – SaaS PLM: What do you need to know about cloud architecture and data management in 2020; Multi-tenant SaaS PLM: common misconceptions; What PLM vendors won’t tell you about the cloud, SaaS and multi-tenant technologies?

In my article today, I want to touch on the main elements of SaaS application layers and what is the implication of these layers on the architecture and functions of the SaaS PLM solution.

Infrastructure

This is a computing and storage foundation of every SaaS solution. Even, we observed a significant decrease in the cost of the infrastructure for the last decade, it can still be a major element that impacts security, architecture, availability, function, and cost. PLM vendors are using both major IaaS providers such as AWS, Azure, and GCP. At the same time, some vendors (Eg. Dassault Systemes has their own affiliated infrastructure hosting providers). Sharing infrastructure is a foundation of multi-tenant architecture. When you evaluate the solution for a specific vendor, pay attention to functions, and migration between subscription levels. You would like it to be transparent, otherwise, you can find yourself one day in the middle of migration between one infrastructure stack to another when you decide to move to more advanced features.

Database

For a very long period of time, the SQL database was a foundation of every PLM platform. These days you can host databases using cloud infrastructure or use one of the SaaS databases (eg. AWS Aurora). Sharing database or using the SaaS database can be a foundation of multi-tenant SaaS PLM, especially for vendors migrating their existing offerings to cloud/SaaS. But this is also a place where you can get easily confused. Running a multi-tenant SaaS database solves the problem of shared resources in place of installing database servers. At the same, it doesn’t solve a problem of granularity in data access, as well as the fact SQL database, is a sub-optimal tool in many PLM scenarios. To have polyglot persistence (see more here) is a better way to go. Think about databases as a set of tool multi-tenant SaaS platform can use. Modern SaaS tools can use multiple databases (SQL, NoSQL, Graph databases, search indexes, and others) is a way to organize a database for a modern multi-tenant platform. This is why platforms like Google, Facebook, Amazon, and others are not relying on a single Oracle database as our grandfather PLM system did.

Tenant Model

Unlike single-tenant PLM systems (on-premise or hosted), the tenant model is a foundation of the data model in a multi-tenant system. It defines the logic of how data is organized, data access provider, ownership model is organized and administration is done. A minimum tenant model can be a single user as well as a team, company, or similar organizational units. The tenant model gives a way to separate data belonging to different users, teams, and companies. Such a model doesn’t exist for single-tenant hosted PLM. Therefore, you cannot turn the existing PLM system into a multi-tenant without significant architecture modification.

Logical Data Model

Data can be organized using a logical model that provides a semantic layer or data used in applications. Think about specific data types, relationships, data models, and many other elements allowing customers to express the data and processes managed by the system. The logical data model also provides a foundation for sharing data between tenants. It can be a document, item, catalog, bill of materials, or anything else. It is usually a semantic layer that is used in customization and APIs provided by the system.

User Model

Users are created for each tenant, but a logical data model can provide expressive tools to access data across multiple tenants. In a single-tenant model, users are always defined in the scope of a single tenant. Not anymore. What if the same user has access to data from both tenants? It is an unimaginable scenario for single-tenant systems, but it is a completely different story for multi-tenant solutions. Users might be accessing data in multiple tenants and to have different roles in different organizations. It is all defined using the expressiveness of the logical data model and tenant schema.

Process Model

A process level is the highest abstraction level. The ability to organize processes across multiple tenants is a unique function and value proposition of multi-tenant architecture. The process model defines content, workflow, and tenant access.  A simple RFQ process can span across multiple tenants and sharing data between OEMs and suppliers and contractors.

What is my conclusion?

Multi-tenant architecture is a foundation of modern connected PLM systems. The first change is to change our state of mind about the PLM solution paradigm. The old PLM paradigm assumed a single source of truth for each company as a foundation of the PLM solution. A new paradigm is a network PLM focusing on connectivity through the data and collaboration and communications between tenants. Thinking about a multitenant solution as only sharing IT resources is very narrow view. The future of PLM belongs to network paradigm and multi-tenant architectures. Just my thoughts…

Best, Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital network platform that manages product data and connects manufacturers and their supply chain networks.