Cloud PLM provider check list

Cloud PLM provider check list

cloud-plm-checklist

Cloud is everywhere these days. Despite high popularity of cloud solution, I still can see some confusion on the side of a customer trying to make a decision about moving towards specific cloud services. The discussion I had at COFES 2015 earlier this month made me think about key questions you want to ask your potential cloud PLM provider before signing your SLA.

A server, which is connected to the internet is not automatically cloud (SaaS) application. The devil is in details and by understanding specific cloud characteristics you will save time and money for your organization.

Here is a check list you might consider for your cloud provider due-diligence process. .

1- Infrastructure

Most of cloud PLM vendors are not running their own infrastructure layer to bring cloud solutions to you. This is so-called IaaS (infrastructure as a service) layer is pretty important for the architecture of your solution.

Professional cloud provider and partners used for IaaS should be responsible for maintenance of infrastructure layers. Then this partner is also responsible for the entire maintenance of the infrastructure (servers, operating systems, databases, backups, etc.). Patches are published on a weekly basis (usually for good reasons) and this is alone is a valuable service which reduce a pressure on your IT department. The level of availability guaranteed usually lies close to 99.99%; a level which the market leaders in the cloud segment also actually achieve.

2- Maintenance and upgrades

From the perspective of cloud vendor, the maintenance of cloud based apps is much simpler than on-premise solution. User can see it as a clear advantage. However, you should validate how is that aligned with customization and test environment. It can take an interesting turn on your own IT upgrades to leverage the same time frames and also identify the impact you your own company maintenance schedule.

3- Multi-tenancy

This is one of the key things, in my view. Compatibility to multi-tenancy has nothing to compare with the ability to set an environment for many customers. This is about how application architecture was developed in the way to be used by multiple clients. I touched few years ago in my post, which can give you more details.

Essentially, it is separated into two topics – application multi-tenancy and data multi-tenancy. The first will insure all customers are running the same version of the application. It simplifies maintenance for vendor, but bring an additional level of complexity for application and service providers. To insure your environment and data are compliant with a new version takes time and you want it to be very efficient. Data multi-tenancy is a next level. In some cases, you can consider it as non-important. However, after more thoughts,  it might be wise to check how multi-tenant application is working with multiple customer databases. It might be too complex to maintain and it might make an upgrade more complicated.

Be aware, multi-tenancy is a key thing in cloud architecture and it require major re-architecture if you speak about existing on premise software. An on-premise solution cannot be made compatible to cloud overnight. Therefore, anyone who is trying to convince you that technology developed back in 1990s runs on both cloud and premise locations might have a great sales skills, but not much technological competency.

4- Security

One of the most often asked question is about security. For the last 3-5 years, cloud providers developed a set of security procedures. Good vendors have them available online in a very transparent way. Ask for a link. If you cannot get one, this is a red no go flag to work with this vendor.

What is my conclusion? Cloud technologies can be very different. But, as a customer, you shouldn’t take blind decision about what are you buying. The most important to understand – you are not buying product anymore. You are buying “service”. SLA is your marriage contract if you will. Whatever is in that contract will define how your PLM system will perform. So, check contracts upfront and look for technological and business differentiations. Just my thoughts…

Best, Oleg

Image courtesy of arztsamui at FreeDigitalPhotos.net

 

Share

Share This Post

  • Good list. I would also add “one version of software”. This goes along with Multi-Tenancy but is something that is a good question to ask a vendor. “Am I always on the latest version of the software?”

  • beyondplm

    Hi Brian, thanks for mentioning that! Yes, “last version of software” is a good non-technical explanation of multi-tenancy.

  • Good Blog Oleg – You are helping to clarify what cloud really means. It isn’t an on-premise company throwing up a shingle with a fleet of virtual machines and they are suddenly cloud. The reality is one needs to build a top-to-bottom architecture focused on performance, straight forward scalability, security-delivered by a security team, upgrades-by an operations team, backups using the latest tech, and disaster recovery -with regular testing. When a provider has one system (multi-tenant) for all customers this is very doable. When the provider has hundreds or thousands of servers for thousands of customers (isolated or single tenancy) -it becomes a quite difficult and expensive to operationally manage. Statistically inviting SLA non performance.

  • beyondplm

    Steve, thanks for your comment and clarification! Agree 100%. The difference between systems designed and architected for cloud and just set of virtual servers running existing client-server software is significant. It defines many factors related to operation, performance and cost. Best, Oleg