You are here

Database Considerations for Moving PLM to the Cloud

database considerations for moving plm to cloud

The following is an excerpt from a new eBook published by Tech-Clarity, “Cloud Considerations for the PLM ISV.”

In my last post, I highlighted the business ramifications and high-level technical considerations for PLM vendors moving to a cloud model. In this post, I’ll talk about some of the deeper considerations - specifically around the database and architecture - that impact success.

Technical Considerations

Delivering PLM on the cloud obviously brings about technical issues. PLM vendors have had to deal with some unique challenges in their traditional software to support scalability and distributed solutions. Delivering the full stack in a cloud model makes it even more important to address these unique considerations.

The demands on PLM systems are unique, and must be addressed in the cloud. Many of these challenges are related to PLM data and data usage. First, PLM manages complex data relationships. It also typically has very large files. The combination of these two makes for significantly “spikey” demand to load or save large / complex data, and requires numerous validation checks as data is saved.

Other considerations include the need to synchronize data across locations and archive information for long periods of time. These needs are very different from traditional transactional systems. These challenges demand some unique decisions in their architecture – and make transitioning to the cloud more challenging (and even less cookie cutter).


“Existing PLM architectures were created at the time it was absolutely reasonable to leverage a single database platform such as RDBMS. … To take the same architecture and migrate it to the cloud can be a reasonable step for ‘cloud servers’ stage of cloud IT transformation. But, these architecture will cause the highest total cost of ownership and will introduce limits in elasticity of the systems.”

- Traditional PLM RDBMS Architecture Is Too Expensive And Won’t Scale For The Cloud – Beyond PLM
 

Web and App Tiers More Cloud Ready

Today’s solutions take work to make them cloud-ready. Fortunately, web interface and application tiers have already undergone some of the necessary changes. They have been transitioning for some time as user interfaces and 3-tier architectures have evolved and moved towards services.

In addition, some PLM vendors have already begun a transition to reduce the monolithic nature of of their solutions and begin rearchitecting them as “apps” on top of a platform infrastructure. This evolution has moved the web and app tiers to a more cloud-ready model as opposed to their monolithic origins.

But PLM applications will still require investment, particularly as underlying infrastructure changes. For example, many were designed to support multiple database solutions to provide customers a choice. This is no longer required in a SaaS model. They may have also incorporated a lot of rules, constraints, and assumptions based on the monolithic nature of the architecture (and database), for example incorporated special approaches in the code to enable performance, scalability, and synchronization. These will have to be re-evaluated during the migration to the cloud.

A Closer Look at the Database

Database architectures have not evolved at the same pace as the web and app tiers. For the most part, they are still a part of the monolithic infrastructure. Depending on the cloud model adopted, the database is likely to require significant rework to perform in the cloud.

Databases have a big impact on scalability. Traditional approaches, typically a file server and a relational database management system (RDBMS), require specialized, expensive infrastructure. In a distributed, cloud deployment they rely on complex, inflexible techniques such as “sharding” or replication for performance. These are some of the reasons that many vendors have moved away from RDBMS for their cloud solutions, adopting web-based databases that take a different approach, sometimes called “NoSQL.”

The NoSQL approach solves some issues, but require more work on the app tier because SQL embedded in applications insulates code from the complexities of the database(s) supported. NoSQL is also harder for customers to deploy if the vendor chooses a hybrid model. This creates a dilemma, where vendors have to either rework software for the web or stay with more of a “hosted” model with high costs and limited scalability.

Other options are emerging that aim to provide the benefits of a web-based architecture with the familiarity (and less rework) of a traditional RDBMS that supports SQL. At least one major PLM vendor is adopting an “elastic SQL database” of this kind. They are transitioning to a modern, atomic database architecture that provides horizontal scalability with a RDBMS layer that supports existing SQL. This approach provides the benefits of an RDBMS with significantly less need to rework applications and retrain employees.

Another consideration that some PLM companies are evaluating is evolving to a graph database. Graph structures are very well suited to the complex relationships inherent to PLM data. However, they are a significant departure from traditional RDBMS and may require extensive application rework. Adoption of graph databases is beyond the scope of this eBook, but it’s important not to shut the door on the opportunity when considering a technology shift.

Conclusions and Recommendations

PLM vendors can, and are, making the transition to the cloud. The key considerations in this eBook are a guide to help identify the implications of the change. PLM vendors considering shifting to the cloud should:

  • Recognize that the cloud opportunity for customers is compelling
  • Understand the impacts on them as an ISV
  • Develop a strategy – even if it’s not to move solutions to the cloud
  • Create a business plan to support the strategy and educate customers and investors about it
  • Understand and address likely operational impacts, considering a DevOps approach
  • Recognize and address technical issues
  • Look for an architecture that provides cloud benefits to customers as well as the ISV (scalability, lower total cost of ownership) and room to grow over time
  • Don’t underestimate the role of the database. Look for a DBMS aligned to your business needs and don’t force your business or application to radically change to fit the choice

---

Jim Brown

Jim Brown is the President of Tech-Clarity, an independent research and consulting firm that specializes in analyzing the business value of software technology and services. Jim has over 20 years of experience in software for the manufacturing industries. He has a broad background including roles in industry, management consulting, the software industry, and research.

Jim’s experience spans enterprise applications including PLM, ERP, quality management, service lifecycle management, manufacturing, supply chain management, and more. Jim is passionate about improving product innovation, product development, and engineering performance through the use of software technology.

Jim is an experienced researcher, author, and public speaker and enjoys the opportunity to speak at conferences or anywhere he can engage with people with a passion to improve business performance through software technology.

Add new comment