You're the Application Portfolio Manager for your Enterprise and all of your key software suppliers are introducing their new "cloud variant" of the data center solution you've been running for years. The CIO journals and IT trade publications you follow urge you to run to the "cloud" as fast as you can, or risk losing your competitive edge.
While a little excitement around the potential advantages of cloud-based computing is certainly warranted, as an IT sourcing pro you know that "the devil's always in the details." More specifically, you understand that converting from a traditional technology platform to a cloud-based product-as-a-service model involves dramatic change as well as significant risk.
So when Microsoft, Oracle, SAP or IBM sing the praises of their hosted versions of productivity suites, CRM, ERP or HCM, you don't delude yourself with the idea that the journey to the cloud is painless.
While many technical and architectural aspects of a migration from a legacy on-premise workload to a cloud-based variant must be considered, we'll focus here on the user and licensing implications of such a migration.
The Business Model
With virtually no exception, when moving to user-based licensing, all of the traditional on-premise licensing modalities such as CPU, core, MIPs, device, server and site no longer apply.
Consuming legacy on-premise workloads as SaaS will likely introduce other new pricing items such as storage, network and redundancy support, as well as new costs for any special developer needs workload(s) may require.
All of these costs typically take the form of a monthly subscription fee and expose many service options that end-user organizations must properly align and assign to their teams.
Virtually all SaaS-based offerings are characterized by the absence of product versions or versioning. User experiences, as defined by the interface they work with, are completely controlled and managed by the SaaS provider. Updates are delivered by the SaaS provider when they are ready and users need to adapt to changes in UI or functionality on the fly. Since real-time new feature access is considered one of the principal benefits of SaaS solutions, organizations must understand well in advance when changes are scheduled to be released and whether or not such changes can impact any downstream integration with other systems or customizations used in combination with the SaaS solution.
Subscription Offerings and Alignment with Use Cases
A SaaS solution costs the provider more to deliver than simply providing a license to use their Intellectual Property (IP). As such, SaaS providers typically design their subscription offerings to closely align to defined user profiles or personas. For example, within a single SaaS workload, a user categorized as a "task worker" persona would have a certain type of subscription, while a "financial analyst" would have another and a "developer" yet another. Through this approach, the personas are designed to support roles ranging from entry-level to high-end and many points in between.
Because the margins for services and subscriptions aren't quite as hefty as the margins associated with licensing only IP, the arrangement of SaaS features and the personas they are provisioned to are carefully tweaked to the SaaS provider's advantage.
Any organization that runs SAP solutions understands the challenges involved with ensuring proper alignment of SAP user types with personnel. This same challenge now is part of most SaaS solutions, as organizations must align their internal use cases to how the SaaS provider has provisioned features to their subscription offerings.
The Contract Model
SaaS providers are driven to provision their most robust subscription licenses to maximize their shared resource infrastructure. At the same time, by carefully assigning features to each subscription offering to suggest the appearance of multiple personas, they cleverly build out the lower-end subscription offerings by carving out one or two features that force users to enroll in a higher level subscription.
As with many other user-based models, organizations often find that their use cases aren't always what they anticipated. For example, many organizations deploying SAP have unknowingly over-licensed users with premium subscriptions, only to learn months or years later that those users are rarely, if ever, leveraging all the features assigned to the user subscription type.
When contracting for any SaaS solution that exposes several personas to the same workload, your contract needs to account for the likely possibility that the initial user subscription distribution may not be completely appropriate or accurate. The ability to audit the actual activities users are performing and then making subscription modifications during the contract term is critical.
Another must-have is being able to "step down" subscription types from a higher-level to a lower-level persona. If unused benefit for those higher-level personas has been paid for, a credit-due outcome can be used against future subscription payments.
Most, if not all, SaaS solutions provide mobility options that accommodate access from devices such as smartphones and tablets. All of those extended access options should be part of the primary user subscription and not treated as an "add-on" with its own separate cost.
As mentioned earlier, since SaaS solutions are constantly being refined and updated, your provider should be required to give reasonable notice regarding any changes to the solution that are planned six to 12 months before the changes go live. While SaaS providers may push back on such a demand, smart organizations will insist on contract language that provides reasonable notice and may also wish to have the option to defer receiving any updates if they are concerned about negatively impacting any integration that involves the SaaS solution.
As a final recourse, you should ensure that a pending update to the SaaS solution that may cause material disruption to your operations will trigger a termination for convenience exit option. Moreover, you should secure some level of termination assistance if this same workload needs to be brought back into your data center.
Service Level Agreements in the SaaS world tend to favor the provider. However, if workload is currently licensed from the SaaS provider as an on-premise solution, then securing service credits to be applied to future subscription payments if SaaS uptime drops below a negotiated threshold is completely reasonable
Regarding return on investment, no comprehensive proof exists that spend for a SaaS solution will achieve major savings when compared to a legacy on-premise alternative. That said, the velocity of new feature access and the potential benefits of SaaS solutions could increase yield from the workload running in your data center.