- SAP Managed Tags:
There is a discussion that is taking place in every company, not just in the IT department but at the Board level too: should we embark on the Cloud route? And if so, what benefits can the company expect?
I can assure you that I am also having these discussions regularly, not only with our customers, but also our partners, and even analysts. Especially when it relates to established software that have been running in a company for quite some time so are most likely historically OnPremise.
If there is a consensus on the fact that Cloud solutions bring new potential, the question of the Total Cost of Ownership (TCO) is always on the table. Different deployment models will have their benefits and their trade-offs that need to be taken into account before making an investment decision.
In this blog, I’d like to summarize some of the benefits of each deployment model: OnPremise, Cloud and in-between with Hybrid, with a lens on specifics relating to Governance, Risk, and Compliance.
A Simple Definition
I am pretty sure that everyone has a good understanding of the 3 models so I won’t go into much detail and will just add below a simple recap:
OnPremise | Cloud | Hybrid |
| Traditional licensing model with customer control of deployment and maintenance | Subscription licensing model with deployment in Cloud environment maintained by the vendor | Combination of OnPremise and Cloud capabilities to meet specific, modular needs |
Economics is Key
Search for economic optimization is crucial and this holds true for any organization, regardless of their business model or industry. Even for not-for-profit!
As a result, the way they invest it is also key.
 |  |  |
| In the OnPremise world, licensing is usually perpetual so once acquired, only ongoing maintenance is required. Considered as a long-term investment it is generally categorized as a capital expenditure, which means that the licenses can be depreciated over the total life of the software. In addition to the licenses themselves, the cost of the infrastructure also needs to be factored in. | In Cloud, licenses are usually on a subscription model. This means that the fees are generally considered operating expenses so recorded on the company's income statement as expenses in the period when they were incurred. A smaller up front price tag, but the total length of the usage needs to be taken into account to be able to compare with OnPremise options. | Simply put, hybrid is not a licensing model by itself, it can either be a full subscription model or a mix of perpetual license for the software and subscription for the hosting infrastructure. |
Cloud costs are of course more predictable but for long term projects, the Total Cost of Ownership might end up higher. Nevertheless, Cloud offerings include continuous functional enhancements delivered directly in the live solution providing a gain compared to upgrading OnPremise implementations. As a matter of fact, the functional aspect is a key component of the next section.
Time to Market for Productive Usage
We usually use the term “time to market” when referring to the length of time necessary from the conception to the release phase of a product on the market. The same concept applies for the time between the selection of a software to its productive roll-out to users.
| | |
When selecting an OnPremise software, the technical infrastructure needs to be taken into account: do you already have the servers, databases and expertise to maintain both these hardware and software prerequisites? If yes, then you are good to go to the next step. If not, then there is a delay and cost that needs to be integrated. But not all is negative for OnPremise: they often enable a higher degree of customization of the software. If the solution provides a competitive advantage to the company thanks to its personalization for specific requirements, then the fact that it takes more time to be “live” can be counter balanced by the fact that it will be a long term solution for the company to retain or gain advantages against its competitors. | Here, the company doesn’t need to concern itself with technical infrastructure: it’s already provided, and users just need a Web browser to access the service. Instead of customization, most Cloud solution providers offer configuration options with ready to use best practices. In essence, personalization options are available in predefined capabilities. This enables a very rapid setup of the software and therefore a quicker Go-Live but doesn’t allow deep adaptability to the company’s specific requirements. Access governance tools would now typically fall under this category: the identity and access management process is well defined, best practices established so it is a perfect candidate for a Cloud solution. | Hybrid is often considered a good compromise for companies requiring customization of some solutions, but that are perfectly fine with adopting best practices for others. Working together, these models can satisfy both requirements. Many companies that started their GRC software journey over 15 years ago with OnPremise (sometimes even fat clients) audit or control modules and added more capabilities over time now decide to leverage a hybrid path to transition to the Cloud: progressively moving to new modules and removing legacy ones enables a controlled shift. |
As per AWS, “70% of cloud adoption programmes stall or fail due to nontechnical challenges” so business requirements must prevail over technical and pricing concerns and must be the driving force behind the decision. If the users’ requirements are not met, then there is a certainty that the solution won’t be used so an alternative will have to be identified and licensed or the process will have to revert back to the legacy system that had been deemed no longer adequate. Even for small investments, a negative ROI is never a good thing so user adoption can’t be an afterthought!
Roles and Responsibilities
| | |
The company, via its IT department, owns the process with limited to no reliance on vendors. From my experience though, if IT has a good grasp on identity and access governance tools and prioritizes them, I feel the same is not true of risk, audit and control solutions. As a result, IT might not rank these solutions with the same level of criticality – and hence dedicated support, as other business applications. | A Cloud model doesn’t require much involvement from IT and ongoing maintenance is reduced, if any. More rapidly scalable, this model is great for internal control tools for instance where the user population can quickly grow when the tool is rolled out to new territories or businesses. This model introduces a heavier reliance on 3rd parties though, including the software provider and possibly the hosting company. | Here, let’s be honest, it’s really not the best option for the company in terms of workload. Yes, it reduces part of the effort for these solutions that will be in Cloud, but the OnPremise ones will still require the attention of IT. In addition to IT, it also creates a dependency on 3rd parties for the hosted modules. |
Once again, let me summarize the roles and responsibilities of the parties with a graph:
External Considerations
There is finally a last consideration that needs to be taken into account, especially when we talk about Governance, Risk, and Compliance topics. Are you even able to choose a deployment model?
There might be data residency and data sovereignty requirements or national security standards but also privacy concerns that your company will have to comply with, particularly for regulated industries and public sector.
As a result, location of servers storing sensitive data, but also data movement – including when travelling to backup systems, might be dictated by external considerations and reduce the options that can be explored.
In OnPremise environments, but also in Customer Data Centres (Single-tenant Cloud setup managed by a provider on behalf of a customer and where no other customer shares the hardware and service), organizations retain complete control over their systems and the data and are fully in control of what happens to it, this might therefore address regulatory constraints.
What about you, are there other considerations that you would suggest taking into account? I look forward to reading your thoughts and comments either on this blog or on Twitter @TFrenehard
