Ed McLeod, President, C-Level Training
Your PLM software provider may have several different environment options to deliver your solutions. They can range from you owning everything in-house via capital expenditures, to a variety of cloud solutions. Renting hardware only is called Infrastructure as a Service (IaaS). Renting hardware and some software is referred to as Platform as a Service (PaaS), and finally a vendor can supply all hardware and software via Software as a Service (SaaS). As you move through the continuum of in-house to SaaS, accountability and control shifts to your vendor(s). Each approach has advantages and risks. You must decide how much risk you can tolerate when outsourcing some or all of the components. Part of your decision is to determine what is best for your company at this point in time and for the foreseeable future. Circumstances change over time. Make sure you document “why” you select a given approach.
Traditionally, PLM has used an in-house approach. Your IT group configures and/or customizes the vendor’s software on their choice of the vendor’s approved hardware, operating system, and database software. This approach maximizes your business process flexibility, and focuses operational accountability on your internal resources. Customization should only be considered if your internal process provides you with a significant competitive advantage. Think long and hard before committing to a custom solution.
You can choose to rent hardware, software, and support capabilities. However when you rent a service, control and accountability transfers to the vendor. Keep in mind many suppliers in addition to your PLM partner offer environments (e.g. PaaS) on which you can host your solution. Choosing to go this route requires your Procurement organization vet them too.
nfrastructure as a Service (IaaS) is an offering to rent the physical hardware on which you install PLM and other software to build your solution. Many companies leverage this approach today, sometimes as a private cloud in their own data centers. They avoid capital expenditures by having a third party supply the physical hardware. This is a relatively low risk approach, especially if the stand-alone hardware resides in your data center. However, hardware shared with other customers in your supplier’s data center is riskier (see data security concerns below). The software remains a capital purchase for your company. Another risk is your inability to improve performance by swapping out components and/or tuning them differently. Performance may only be improved by procuring more of the same IaaS environment from your supplier. Further, your supplier will make environment upgrades / changes periodically, which could “break” some of your existing functionality, especially custom code.
Platform as a Service (PaaS) extends the IaaS concept by adding the software on which you can develop capabilities. In the case of enterprise software, your partner supplies you with the hardware and commercial off-the-shelf (COTS) software to configure / customize a solution meeting your business process requirements. Your organization builds and operates the configured / customized solution. The vendor owns all hardware and software upgrades and timing, which again can “break” any customizations you may have developed.
Software as a Service (SaaS) supplies you with COTS capabilities with no option to customize. No customization is a huge benefit, as future hardware and software upgrades are vendor-tested and should continue working over time. Further, the core process and associated analytical solutions will likely advance faster because of multi-customer learnings across the shared platform. Other reasons to leverage this approach include zero capital expenditures and a single supplier. If something goes wrong, everyone knows who is accountable to fix the problem. The SaaS approach enables you to purchase what you need, rather than securing and training your own IT resources. The solution must still be configured to include your master data, phase-gate criteria, etc., so it requires up-front development and testing.
Data security is the key concern most companies have when transferring accountability to a vendor. We frequently hear of data breaches and the corresponding financial loss. Your security risk lies not only with your supplier, but also with their other customers. Your PLM solution manages secret information, including formulas and making instructions. You must evaluate whether you can trust a partner to secure your data in a cloud environment shared with their other customers. In theory, cloud suppliers are the experts and have the best security resources. This is not always true. Be very careful about managing your data outside your firewall, as once it’s breached, it cannot be recaptured.
For each environment option a potential partner claims, ensure it applies to all of the applications you plan to use. If some of their application software requires a different operating system or hardware, you’ll have cross-environment integrations to design and build. They must deliver the full suite of environment requirements before you can quantify integration costs. Based on your analysis, a PLM partner may only be able to deliver an ETE integrated solution by using multiple physical environments.
If using anything other than an in-house approach, contract negotiations must include Service Level Agreements (SLAs) and maximum cloud cost increments over the coming years. Negotiating next year’s costs after transitioning all of your users leaves you with little leverage. Your cloud service metrics should be based upon the experience you choose to supply your users, rather than the number of CPU cycles consumed. If your contract is based on CPU cycles, your vendor has little incentive to upgrade hardware, as their profit increases by selling you more cycles on the slower processors.
Beyond environments offered, you must also drive clarity on your potential partner’s software support. This is critical to understand for in-house and IaaS approaches. Software isn’t perfect. Things break, and when they do, your partner, rather than you may need to supply the fix. Quantifying the number of back-versions your partner supports drives insights into how frequently you must upgrade your base software. Almost all vendors support their software at least two major releases back; most longer. This is important as most providers upgrade their software at least annually. Every time you upgrade hardware or software, you must test to ensure all of your functionality still works. Testing costs money. Your software partner will have a limited number of back-versions in which they’ll install fixes and/or new capabilities. Based on the number of versions back your vendor patches, and the frequency of their versions, you can calculate the maximum duration you can keep a given version of their software and receive fixes. This factors into your on-going operational costs.