Economics of SAP HANA Adoption in the Cloud – one real customer example

It’s with a great honor that I write today, sharing another of my customer experiences on SAP HANA adoption.

And it’s with a great honor as I’ve just been named a “SAP HANA Distinguished Engineer” (you can read the nomination announcement at: http://www.hdespot.com/2016/06/24/antonio-freitas-sap-hana-distinguished-engineer-hacker-and-troublemaker/).

Feel truly humbled that the HDE community (http://www.hdespot.com) valued my contributions toward building and sharing knowledge on SAP HANA.

On the words of my friend Tomas Krojzl (http://www.hdespot.com/author/tomas_krojzlcz-ibm-com/), one of the greater expectations upon a SAP HANA Distinguished Engineer is to openly share knowledge on this area to help the product and the industry grow and advance.

So, to honor that principle, coming today with a very short note on a concrete customer example, that I was privileged to guide over the last 8 months from proposal to delivery.

Today my focus will be on the “economics of SAP HANA adoption in the Cloud”.

Without identifying the company these values relate to, I’ll provide relative values on this company’s costs when operating their SAP Systems on-prem with a legacy Risk/AnyDB config, in the Cloud with Windows/AnyDB, and finally in the cloud with Linux/HANA.

Setting the scene

I know that one of the biggest concerns of most companies evaluating adopting SAP HANA, is the economic impact in terms of infrastructure and managed services.

I’ve been writing about “SAP HANA openness” for 3 years now, and the key implication of the increased openness of SAP HANA has been allowing lower entry costs and lower operating costs of this infrastructure.

Although in the past most of my focus was on on-prem deployments of SAP HANA (look for example the following whitepapers I’ve contributed to: http://www.emc.com/collateral/emc-perspective/h14459-making-sap-hana-mainstream-datacenter-part1.pdf and http://www.emc.com/collateral/white-papers/making-sap-hana-mainstream-datacenter-part-2.pdf), today I have to agree with a lot of the reasoning I’ve seen from John Appleby (http://www.hdespot.com/author/john-applebybluefinsolutions-com/)  where he said that any customer today considering starting an SAP application implementation, if he did not chose to do it on HANA and on the CLOUD, he was not providing a good service to his company.

I struggled with that a bit at the beginning, as I had an idea of cloud built at the image of the first cloud providers, where there were a lot of concerns in regards to security and compliance (especially when thinking on non-US companies putting data in US datacenters), but also around service assurance (Application level SLAs for Performance and Availability), which led in many cases to see their operational costs go up due to the increased complexity of managing the cloud provider’s flaws.

You all know that I’m passionate about what I do, and that I struggle to do a job or work for a company I don’t believe in.

Well, having come to Virtustream I’ve found a company that merges the best of Cloud (agility, cost savings, flexibility) with the best of IT Outsourcing (security and control, managed services, application level SLAs).

So, over the last 9 months I’ve been, on one side “learning Virtustream”, and on the other presenting Virtustream to customers and then guiding them to migrate their systems to the Virtustream Enterprise Cloud.

It is necessary some months on the job for you to start to see results of your own work, and it with great gratitude that I’m seeing the first customers I’ve consulted with, going into production on the Virtustream cloud.

And this provides me a unique opportunity to do a “before and after” analysis, and that is what I’m coming to share here now.

I hope to get the specific customer I’m writing here about to become a public reference soon, but until that happens, here is a bit of their story and also some insights on the numbers behind the story.

               Looking for “The Right Cloud”

First of all I have to say that this is a very innovative company, as their operating model (being this company operating in a very traditional manufacturing area), already included a consumption based billing to their end customers.

So, for them, paying only for what you actually consume, was already embedded on their DNA.

15 years ago they were running their SAP systems on-prem, and being a very agile company with a very light IT department supporting their operations all the countries they operate (way over 50), it was clear for them that the internal IT needed to focus on activities that truly added relevant value to the business.

Then this led them to sign an infrastructure outsourcing contract with one of the big manufacturers, running all their SAP Systems on a Risk/AnyDB platform.

After 10 years with this provider, they felt that they kept lagging on the business expectations, in terms of response time, cost of change, and ability to experiment and innovate.

On their words “every single new request was painful to get”. It “took weeks to be able to schedule a meeting as the provider always come with large team to each meeting” and the simple factor of reconciling agendas was a nightmare. Then the costs associated with small changes plus the lead time necessary for any change to happen, sometimes just killed the business case, as the business units would have lost the window of opportunity.

So, coming to the end of this 10 years outsourcing contract, they decided to go back to the market, and hearing all these new things about cloud, asked for cloud offers from all the known players in the market.

Their conclusion was disappointing. The model all providers were presenting, resembled a lot the experience they already had with that IT Outsourcing over the last 10 years. Have to mention here that this being an European organization, hosting their most critical production systems in a US datacenter was out of the question, and that the requirements on security and compliance were very strict.

So, instead of confirming with the “least bad” option among the responses they got to their RFP, they hired the consulting services of one of the market analyst firms, which looking at their magic quadrants immediately pointed them out to a player they haven’t invited to the tender.

That player was Virtustream, and I was assigned to support that opportunity.

               Defining the right cloud: First impressions

Having this customer today already in production on the Virtustream cloud, gives me a chance to go back and ask them: when did you made up your mind that Virtustream was the right option? What made you decide?

And this customer has been kind enough to be open and transparent about this, as in his own words “we have not contracted a supplier, we have brought in a strategic business partner to our business”, and so open and transparent communication is a fundamental baseline for the collaboration their company expects from Virtustream.

First of all, would like to share the goals they have documented on the RFP they sent to all the respondents:

• Improvements in the agility and flexibility of the organization in a changing market
• Improved quality of service and reliability of business processes
• Improved relationship between business and IT
• Scalability of operations
• Significant cost savings through true consumption based billing
• Have a fully managed service and have internal IT as service managers, not IT engineering and operations

And their first impressions were like this:

• We wanted agility
• We wanted solutions out of the box
• We wanted solutions specifically designed to our problems
• We wanted fast turnaround times
• We wanted a knowledgeable business partner that was able to advise us on the best way for our company
• We wanted a simple consumption model
• We wanted to pay just for what we actually use, and not for what has been allocated to us
• We don’t want to over-size, but rather to right-size and grow as we go
• We wanted to have control and visibility on where our data resides
• We wanted s strategic innovative partner with capacity to support our own innovative ideas

And this is what they felt none of the providers that had responded could offer, and that they saw all through their interaction with Virtustream.

A key aspect here was that instead of responding to the RFP they had written, which of course was a reflection of the IT outsourcing they had been on for the last 10 years, Virtustream challenged most of those requirements, and instead proposed them a different approach:

• Some of the key benefits of cloud is agility and cost saving
• The only way to get these is to have “brutal standardization” both at the infrastructure level and in the processes
• So, let’s look at what we have to offer out of the pocket in our standard catalog, and then evaluate the real business requirements for the applications to be hosted on the cloud
• Whenever is acceptable for the business the standard SLAs offered by the standard offerings of the provider, let’s adjust the requirements on the RFP, so that instead we can just “pick from the menu” and build an order specific for you
• If there are some very unique business requirements that our standard offer and SLAs cannot cover, we’ll build a custom solution to you

Here I have to say that having the CIO in the discussion, and being a very senior person with a very deep understanding of the business, advised by a team of direct reports also very knowledgeable and pragmatic, and enabled to make the decision to adapt all requirements to the standards offered.

One of the biggest barriers I see for many customers to have a positive adoption of cloud for their enterprise mission critical SAP Systems like SAP ERP, is that they design RFPs that do not ask for what they truly need! I understand this, as one cannot ask for something they do not know. So, the reality is that most RFPs I have seen to host production mission critical systems on the cloud, either ask for a cloud model based on the first generation of cloud providers (read my blog on this at: http://sapinfrastructureintegration.blogspot.com/2016/05/sap-hana-adoption-in-cloud-made-simple.html) that are not suitable for this purpose, or have been written for an IT outsourcing model which has proven to under-deliver over many years.

So I have to say that this customer was truly innovative, by being available to open a blank sheet of paper, learn how Virtustream operates and delivers services, and then rebuild their requirements from a different starting point. This was a key success factor for the levels of satisfaction this customer is observing now.

The outcome was the presentation of a financial offer 1 week after the first meeting, signing a contract in 3 months after the first meeting, and having all systems migrated to the cloud less than  3 months after contract signature (migration included multiple system landscapes, being one of them a SAP ERP 6, and the other a SAP BW, core to the company's business).

And all of this with a very smooth migration process, and better performance, visibility and control on the cloud than they ever had with their IT outsourcer.

So, the first impressions on the engagement, and the way the whole process was handled, showed this very innovative customer that this company was the right choice for them.

Joking a bit, they said that “mentally” they decided to buy 1 week after the first meeting, and the rest of the time was just to confirm and validate that decision as what we were delivering was completely different from anything else they had seen so far, so they needed to learn more about us to be confident of their purchasing decision.

Also they mention that one of their bigger concerns was the fear of losing control, or not being able to get proper support and attention as the “the provider was all on the cloud”, including managed services, and so through this process only happened a hand full of face to face meetings.

He recognized that having not only the systems “on the cloud”, but also the “managed services on the cloud”, enabled them to get access to the best professionals in the world regardless of where they are located, and that the responsiveness and “presence” of the team throughout the complex migration project (this was the first OS/DB migration this customer had gone through) was better than anything they have experienced with their outsourcers over the last 10 years.

We had the pleasure of being invited by the CEO to a discussion, where he explained the importance of these systems for their operations, and that without them they would be completely stopped. This conversation was critical to build trust and a common understanding of the goals, as this was a strategic decision for that company, that could not be taken lightly.

               What about the economics?

So far it is all very nice, but what about the economics?

One of the key decision factors for this customer was also to get “significant cost savings” on IT infrastructure and managed services.

And here is where the story becomes interesting.

This customer had the strategic goal of implementing S/4, as they do understand the benefits of HANA in things like real-time treasury management, as they need to manage the cash balances across countries, and having to move money between countries with bad market conditions, can dramatically erode the company’s profitability.

Also they buy commodities as raw materials for their production processes, also a situation where operating in real time can make the difference between profit and losses.

Then the question was: how much will it cost me to migrate to HANA, consume an infrastructure for HANA, and operate HANA?

There was a whole lot of unknown, and a high risk perception, as their outsourcer had tried to upgrade them to EHP7 a number of times to get them ready for HANA, and it was a slow and painful process. It took them more than 6 months just to get a stable development system.

So here are the numbers:

1. Just by migrating from on-prem Risk/AnyDB to the cloud with Windows/AnyDB, this company saved about 40% in their monthly bill!!! This includes all infrastructure services (compute, network, storage, security, service desk) and managed services (OS, DB and SAP Basis management, including ITSM process handling and overall service management).
2. This project was executed in 2 phases: phase 1 was just migration from Risk/AnyDB to Windows/AnyDB; phase 2 was upgrade with DMO from Windows/AnyDB to LINUX/HANA.
3. The 1st phase of the migration project will have a payback time of less than 6 months (meaning, 6 months of savings on the monthly charges paid the migration project);
4. The project for the technical upgrade with DMO to migrate to HANA was also funded by 6 months of savings!
5. The total monthly costs of running on the cloud with Linux/HANA were 17% higher than running with Windows/AnyDB. Which means that still with some increased costs against running on the cloud on LINUX/HANA vs Windows/AnyDB, it was still a lot lower than the costs of the IT Outsourcing contract they had for the last 10 years (we are talking more than 20% savings every month).
6. This customer evaluates that the business benefits of adopting HANA for their business, will complete overshadow the costs of the infrastructure and managed services, by multiple dozens multipliers.

Have to say that some of these numbers are “projected savings”, as with the Virtustream patented microVM consumption model, we expect the real numbers to look even better.

When talking about the difference in cost between running those systems on the cloud with Windows/AnyDB versus LINUX/HANA, we wanted also to understand where the difference came from, and so here is a bit more detail:

• Compute: costs more 116% on HANA vs AnyDB, and represents 29% of the total monthly HANA costs;
• It is a fact that SAP Business Suit applications on HANA consumes more CPU and Memory than on AnyDB. This is a factor of much of the application code and data structures not having been yet optimized for HANA. So, the benefits we see in terms of data footprint reduction when implementing Simple Finance, isn't yet available for many of the other business areas (to understand more about this, read: http://sapinfrastructureintegration.blogspot.com.es/2015/04/will-sap-s4-hana-really-require-less.html).
• Note that this simulation does not account for the impact that Virtustream’s patented microVM based consumption model will have, which we expect to make these numbers look better, as the customer can for example shutdown non-productive systems through the night or weekends when they are not used, and they will not pay this item for those period. These optimizations have not been factored in. 
• Again here, the fact that we have more OS images due to the separation of the HANA DB and APP Servers on different OS instances also has some influence.
• OS Licensing: costs more 1305% on LINUX vs Windows, an represents 2% of the total monthly HANA costs;
• This is due to 1 factors: 1) the fact that Linux support costs a lot more than Windows subscription licensing, and 2) the fact that when running on HANA we have more OS images as we do not run any systems as “central servers” (DB+ASCS+PAS on the same server). The good thing here is that the weight of this cost on the overall costs is very low.
• Backup: costs less 70% on LINUX/HANA vs Windows/AnyDB, and represents 2% of the total monthly HANA costs;
• I believe here factors like HANA not having indexes, and the compression play a big part. We’ll need more time in production to be able to take more supported conclusions.
• Storage: costs more 3% on LINUX/HANA vs Windows/AnyDB, and represents 9% of the total monthly HANA costs;
• We believe the storage costs could be lower, but as customers get concerned with SAP’s recommendations for x-time multipliers on Memory to disk (to know more about this, read http://scn.sap.com/docs/DOC-62595), they end-up over-provisioning capacity they will never use. I expect that as I get more customers “from proposal to production”, with more experience to provide stronger advice to customers to start with less storage, as in the cloud, they can grow as they go.
• Managed Services (OS, DB, SAP Basis): costs more 3% on LINUX/HANA vs Windows/AnyDB, and represents 37% of the total monthly HANA costs.
• The difference is relatively small and is due to the fact that the customer when running Windows/AnyDB had some central servers, so less OS images to manage, and we are implementing all systems separating the SAP HANA DB into a different server from the ABAP Application Servers.

NOTE: these values are specific to this customer scenario, and are dependent on the mix of systems in the landscape, the size of those systems, etc. So these numbers intend only to show – on this specific example – where the higher cost of operating HANA actually came from. Also, on these vales are included all software and services necessary to operate a full infrastructure service, and not only the respective hardware components. On your specific reality these numbers may be different depending on your source system, target system, landscape size, data volume size, etc.

               Conclusions and looking into the future

So, even if there were no business benefits from running their business on HANA, the savings of migrating to HANA on the cloud would have paid the migration project in less than a year.

When factoring in the business benefits of HANA, there is simply no argument against.

And to this you have to add the strategic and operational benefits brought by the adoption of the
Virtustream cloud:

• Better performance
• Better responsiveness of the services team
• Lower cost to experiment, by being able to spin up a sandbox system to test new functionalities for a couple of days and then shut it down, only paying for the resources actually consumed on that period
• Better cost predictability and transparency

It is indeed a great pleasure to have seen this project develop, watch this customer unleash creativity, and getting their IT team already focused on the next step, and how else can they help their business be more efficient, more innovative and more competitive.

And the next step on this customer’s roadmap, after a small stabilization period for the systems we've just migrated, is to start evaluating IoT scenarios, as they see a lot of potential in streaming data from their manufacturing machines and cross analyze it in real time against their orders data, inventory data, commodity costs, etc.

So, I’m already thinking on how to enable them to start experimenting with HANA Vora, and build a lab environment to enable them to bring that innovation to their business faster… Stay tuned for news on this soon!

So, this is it. The conclusion is simple: running SAP HANA in the Cloud is a lot cheaper that running SAP applications on Risk/AnyDB. Running your SAP applications on HANA in the Virtustream cloud will also provide you a way better service than the one outsourcers have been providing. So, why wait? Get started on your SAP HANA adoption plans!

Would love to hear your own experiences, your challenges in building a business case for SAP HANA adoption, and know how the numbers worked on your specific scenario.

Looking forward to your feedback!

SAP HANA in the Cloud? "No way" or "what cloud"?

Being "Cloud" one of today’s buzz words, that is also shaking-up the SAP world alongside HANA, I’ve come across many customer with a strong “antagonism” to any topic with “cloud” on the title.

I see as a root cause to this antagonism, the huge confusion created by all the players that want to be in this market, whom call “cloud” to everything that moves in their portfolio in their struggle to be relevant.

So, when talking with CIOs, Enterprise Architects and other IT leaders, I see still lots of misunderstanding in relation to “all things Cloud for SAP”.

In this blog, I’ll make a brief definition of my understanding of “Cloud”, to then use this definition to do a high level discussion on “what is the right cloud model for each company and business scenario”.

Note that you’ll see that my discussion is generic from a pure cloud perspective, and not very “HANA” specific. The point here is that, all I’ll be discussing in this blog post, can be part of a datacenter wide strategy discussion on which SAP HANA today definitely fit in as well.

SAP HANA is becoming increasingly normal, and so you should consider it as an integral part to your cloud strategy.

I know there are certain limitations in regards to “very huge” HANA systems. But when talking with customers with 70 and more productive systems with full landscapes of more than 300 SIDs, and many multi-terabyte databases, the ones that require special attention are usually less than 10%. So, you can set a rule for the other 90+ %, and then deal with the exceptions.

Let me tell you as well, that I’ve seen companies looking at those huge SAP HANA systems first and using them to define the standard, and it has led to massive costs that could have been avoided. But talking on the benefits of standardization of IT would be another conversation I’ll leave to another occasion!

           What is "Cloud"? 

So, let’s get to it and start putting some names on the “things”.

In fact, Cloud is a buzz word subject to many miss understandings today, and due to that may not be “the first option” many organizations around the world would think of.

Although the “Cloud” buzz word is relatively new, the concept has been around for many years, and it’s all about industrialization of IT.

Looking beyond the noise and the smoke, indeed Cloud not being new, it is indeed real today.

I remember presenting at conferences for another company many years ago about “industrialization of IT” where I knew that what I had was a reference architecture, and that everything would have to be custom built through massive consulting projects. This is no longer the case today.

And industrialization of IT is real because today we have the technologies that indeed enable to manage IT as a Service at its multiple levels.

Hardware has evolved to be able to be managed and configured by software, and most components in the IT stack provide scripting interfaces that enables “automation tools” to manage them.

This discussion has been becoming increasingly confusing for customers because each provider organization abuses the “cloud” word to positon themselves as relevant despite their disparate maturity, standardization, automation, geographic coverage and competitive positioning.

Among the miss understandings of “cloud” there are 2 I consider fundamental to overcome:

• That once a workload is virtualized, it is already in some sort of cloud;
• And the idea that cloud is only “public cloud”. 

           Just Virtualizing Systems is not Cloud !!!

Let me then start setting some foundations by making a reference to the U.S. National Institute for Standards and Technology (N.I.S.T.). This organization came up with a definition of cloud, to which all players in the market can refer to, so enabling cloud customers to have a framework through which evaluate their candidate providers in terms of completeness of offerings.

This standard has been widely accepted by the key players in the “cloud business”, and can be found at: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

If you read through the N.I.S.T. definition of cloud computing, it clearly identifies what are the essential characteristics needed to be in place, so that you can call something “cloud”:

• On-demand self-service;
• Broad network access;
• Resource pooling;
• Rapid elasticity;
• Measured service.

You can read more about them both on the N.I.S.T. documentation and on other documents available in the internet.

From these characteristics you can evaluate that they imply a more comprehensive scenario than just virtualizing applications. Virtualization can indeed be a key enabler of cloud as it enables for example “rapid elasticity” and “resource pooling”, but to be in face of a cloud, you’ll also need a significant level of automation.

Indeed, automation is a key component to any real cloud. If you look at it, Information Technologies came with the promise of automating the business processes of organizations, but the management of the IT systems has been quite manual. In fact, for most organizations around the world (end customers and service providers alike), the cost of labor is one of the biggest items in IT operating expenses.

So, "Cloud" is all about bringing to IT what IT brought to business processes many years ago: minimize the human intervention in regular IT operations. The benefits from this reduction of human intervention has been realized for many years in the manufacturing industries, having demonstrated to reduce defects, improve response times, reduce operating costs and simplifying change.

These levels of automation are implicit in characteristics like “on-demand self-service”, where it is assumed that there will be no manual work behind a “self-service portal”, as it would be fully orchestrated and automated through workflows.

For me a “cloud” that is hosted at a service provider, but that behind the “portal” has a lot of manual work, and because of that has expensive costs and low response times, is not a cloud. Although many service providers around the world advertise cloud offerings for SAP HANA that indeed in the background operate in this way. They will always fall short on the expectations created by the “true cloud players”.

Another key characteristic of cloud is to have a “measured service”, as this is a key characteristic to enable your organization to run IT as a Service, and become an IT services broker to your business organizations.

This would for example enable to, when a business user comes to you asking for a system to start a new project, to check your “private cloud” and “public cloud” costs, security, service levels and response times, and give an the best option to the business user based on the business scenario he will be implementing. Here is where I believe IT really becomes a partner to business organizations in driving innovation and further organizational agility.

I believe we can agree at this stage that “virtualization” and “cloud” are not synonyms. Virtualization is definitely a key ingredient to build efficient clouds, but is not “cloud” just by itself.

           Cloud is not only “Public” Cloud – look for Private and Hybrid as well.

The clarification for the second myth we’ve referred above comes from the N.I.S.T. definition of Cloud Computing as well.

In that document there are also described the “Cloud Service and Delivery Models”.

In terms of service models, N.I.S.T. defines the following:

• Software as a Service
• Platform as a Service
• Infrastructure as a Service

And in terms of delivery models, the following are defined:

• Private cloud;
• Community Cloud;
• Public Cloud;
• Hybrid Cloud.

Again, not being my goal to dive deep on the NIST definition (as you can read all about it online), the point here is that private IT organizations can work in a “cloud operating model”, delivering a Private Cloud to their business organizations with similar characteristics to public cloud offerings.

To do this, what private organizations need is access to the infrastructure components, tools and know how on the processes used by leading public cloud providers. And this is available today!

I’m pleased to have gotten to know some IT organizations that “got their act together” and stepped it up to be competitive in terms of agility and quality of service with public cloud providers! In the end it’s all about the people.

But there is another choice coming strong to market, that might bring together the best of two worlds: what if the “public cloud provider” offered his services to manage a private cloud hosted on your premises (under your full span of control) in the same way it manages his public cloud?

This is what I call the “managed private cloud”.

The point here: cloud is not only public cloud. It’s all about a service model around automation of IT.

I believe then, that we can agree that accepting this definition, “cloud” must indeed be part of every IT organization’s strategy discussions.

           Should I go IaaS, PaaS or SaaS? Soo many “aaS” is so confusing...

Now, looking at the NIST defined service models, what is the right one for each of your business processes / application stacks / organizations?

Let me share what I’ve learned on this topic from working in IT operations myself, and participating in many interesting discussions with the leaders of those IT organizations.

Many organizations look to differentiate themselves through the usage of information. This makes it that an increasing number of organizations see “code development” capabilities increasingly as a core competence as it provides them the capability to manage and analyze information. In the information age, being able to rapidly turn information into actionable insights to the business is a key competitive differentiator.

On the same side, there are also organizations that struggle to get the skills they need at this level, and see themselves many times hostages of “under-performing” IT teams. This has led in many cases to top management decisions to embark on “comprehensive outsourcing deals”, which we’ve seen as very popular through the late 90’s and early 2000’s, as they expected the outsourcer to solve the problems they haven’t been able to solve themselves.

History has shown that most of these comprehensive outsourcing deals apart from the short term financial impact of turning CAPEX into OPEX and providing a cash injection, have come short on most operational, innovation and strategic expectations.

So, externalization of IT functions, being through Outsourcing or Cloud, has been a tool in the hands of CEOs, CFOs, CIOs and in general C-level executives as a way to solve many different problems (strategic, financial, etc), including IT skills and processes problems.

I have worked both on architecting solutions for these “old large outsourcing contracts” as well on the delivery of those contracts, and I have a ton of stories to tell on my learnings from it.

But the point is that these problems haven’t gone away, and still exist in many organizations.

So choosing between SaaS, PaaS and IaaS may also align to where the problem lies in the customer’s IT organization.

I would say that a decision to adopt IaaS, PaaS or SaaS should be based fundamentally on the business scenario to be supported. But I have to acknowledge that on the board room, this is not the only discussion argument.

This is why I say that SaaS may be a way to solve your problems when functional and development teams do not deliver. By going SaaS you externalize all of that to the provider. Of course this should be balanced with an analysis of the application, as going to a SaaS model would be a good fit if the application has mainly standard requirements across the company’s industry.

As for PaaS, apart from providing pervasive access to a development platform, it might be looked as well as a way to cover poor capabilities of DB and OS admin teams, as that would be in the responsibility of the provider.

Remember, these are just examples of discussions I’ve observed, and I believe it is important to put the SaaS/PaaS/IaaS options in perspective.

Associate this previous aspect with the fact that in many parts of the world there are severe technical and regulatory limitations to a public cloud model, and the scenario of implementing a IaaS private or hybrid cloud model is in fact the most accepted one for business critical applications. I see this today, and foresee it will stay like this for the coming years.

           What is the right cloud delivery model for my Business Critical applications?

So what kind of a cloud will you’ll be putting each of your workloads on?

Will everything be public?

It depends on the specifics of each customer / country and use-case, and the following metrics should provide you a good guidance on how to decide: Economics; Trust; Functional.

For example:

• Where is more economic to run this workload? On the public cloud or on my private cloud?
• As internal IT usually does not have a profitability goal, the end cost for the company may be lower running it on-premise. But on the other side, in many occasions private IT organizations do not have either the scale or the most efficient operating model, making it then more costly in the long run. Not all companies are alike, so the result of this evaluation is absolutely unique to each customer scenario.
• What confidentiality and compliance requirements are applicable to this business process/application? It is subject to data sovereignty regulations, or other risk related regulations like "Sarbanes/Oxley" or "Basel"?
• Not all countries have the same regulation, and each organization manages business in a different and unique way. There may be scenarios that either industry, country or corporate regulations impose certain restrictions on "data placement". Also the risk profile of each company defines their approach to risk, and their evaluation on probability, impact and acceptable risk containment/management practices.
• Does the public could provider provide functionality that maps to the unique needs of the organization?
• There are business processes in organizations that are quite standard in the industry, leading to look at application adoption as a way to have access to standard and updated industry best practices. There are as well situations where the business processes and functional requirements are very unique or custom to the organization, being even a unique source of competitive differentiation, situation in which most likely a standardized public cloud offering may not be a good fit.

Again, this is just an example of a reflection, and if you look at this, you can realize that most likely you'll find workloads suitable to public cloud offerings, and other that will be subject to more restrictive conditions.

Apart from this, we have to remember as well that not all the world has today cheap and stable high bandwidth connectivity, and that the increased news on data privacy violations and questionable access by public entities to private data, makes it that many organizations see themselves in the cross-roads of making careful decisions of what should be placed under the organization’s direct span of control (the private cloud), and what is acceptable to be put in a fully public environment.

Let me share one example provided by one customer I met some weeks ago on his reasoning of what we could place on one side or on the other.

This customer gave as an example 2 particular systems:

• one to support employee performance evaluation, career planning and skills development;
• and another system for “order to cash processes” like invoicing and accounts receivable.

If they lose access to the employee evaluation system, the company will not stop operating. Also, the kind of data included in such a system does not contain critical data in terms of the company secrets, which makes that having a reliable public cloud offering it might be the right solution for such a system.

On the other way, for the invoicing and accounts receivable system, if access to such a system might be lost, the business operations would be paralyzed and cash inflows might be negatively impacted. 

Also if in such information there is business critical data, like the markets an organization is operating, its revenues by market, its customers, its planned promotions and new product launches, etc… This is definitely the kind of system that it will be most difficult for an organization to accept being operated outside its span of control, or without access to its own auditing services.

If we remember as well, that apart from the US, Western Europe and certain specific countries in Asia, the majority of the world still has both technical and legal constraints around public cloud, I believe on-premise (or a hosted / managed private environments) will still be the mainstream option for the core business systems of organizations for quite some years to come.

So, we will have cases where a pure public cloud offering where you have no control over the software stack or the data placement location will be an acceptable choice, and also cases on the other extreme where you'll need to keep full control of the software stack and data location. But between these two extremes, there are a multitude of possibilities, like leveraging a local provider providing you an hybrid model like: having the data placed in the local provider within the country's borders, in association with a global provider providing the cloud services on top of that infrastructure, either in a dedicated or in a shared environment.

The point: today there are multiple options, so embrace the discussion and find out what are the best options for your organization from a financial, strategic, innovation and operational perspectives.

           IaaS is the Cloud Service Model that Provides you the most flexibility

Assuming that through your “cloud workload filter” you define what services are acceptable to run on a public cloud and which are not, you’ll end up with the conclusion that you’ll be operating a Hybrid Cloud Model, with certain services running under your span of control (either hosted by your own IT or managed in a hosted managed private environment at a Service Provider).

How do you ensure you do not end up locked-in to a certain vendor, and that you don’t lose the flexibility an hybrid cloud model should be providing you in the first place?

The response would be: adopt a cloud service model that enables you to have control over the “mobility” of your workloads between public clouds, or between public and private clouds.

Today, only Infrastructure as a Service (IaaS) offers this.

Let’s look at it for an instant:

• SaaS: the application logic will be property of the service provider, and if your organization wants to move that process back to its span of control, it will imply a major migration project as it will be needed to configure a new application to support that functionality alongside a migration of the data from the public provider to your controlled environment. This will definitely be time and resource consuming, representing a disruptive change. So we can say, that once you make a choice to adopt a SaaS offering in a Public Cloud, there will be a number of barriers to exit, that must be evaluated beforehand and included in your contract “exit clauses”.
• PaaS: the provider owns up to the run-time platform where you deploy your code. Means that most likely, your data will also be hosted on the provider infrastructure. Here moving these processes from public to private cloud becomes simpler, whenever the platform you’ve chosen to run your code on can be easily deployed on-premise as well. But also in this case, moving functionality from public to private will be a disruptive event which will imply certain costs and application downtime.

Both in SaaS and PaaS, when talking about hybrid cloud scenarios, we are thinking about the possibility of business processes or applications interact and expand between private and public cloud. But in neither of these cases we can talk about “dynamic workload mobility”. At least with the current (that I know of, and foreseen for the medium term) public cloud offerings and technologies, there is NO dynamic / real-time workload mobility.

But this is a reality today in the IaaS model.

When considering Infrastructure as a Service, apart from having complete isolation at the data level with today’s Virtualization Technologies like the ones provided by VMware, the whole stack needed to run your business processes is packed in a container that is the Virtual Machine, that you can absolutely control form a confidentiality point of view and move around between compatible clouds.

But the key benefit here is that if you choose public cloud providers who operate on VMware, having VMware as well as an enabling technology for your private cloud in a IaaS model, you can today use technologies like “long distance vMotion” (check out the announcements on this topic from VMworld US 2015) to dynamically and without disruption move applications from the private to the public cloud and back, avoiding being locked-in to a specific vendor.

There are also storage provider technologies that facilitate the movement and copy of virtual machines between clouds that are in use by many service providers around the world and that can be used in combination with “long distance vMotion”. But to my current knowledge, the scenarios I know are in production still imply a minimal application downtime to do this workload mobility, as “long distance vMotion” is a brand new feature that will still take some time to become widely implemented and integrated with key hardware infrastructure components.

So, from a risk perspective, IaaS is the only model that truly enables you to operate in a hybrid cloud that doesn’t get you "technically" locked-in to one public cloud vendor.

          IaaS is the only true hybrid cloud model without vendor lock-in

Cloud isn’t then just Public Cloud.

Cloud is about industrialization of IT, being its architecture enablers: virtualization,  automation and orchestration software, and most important, people and processes.

Today it is possible to acquire a pre-configured infrastructure, with all the software already deployed on it to provide an out of the box self-service portal, charge back tools, automated deployment workflows, and all those other tools that truly enable a private cloud according to the characteristics of cloud described above as per the N.I.S.T. definition of cloud computing.

Considering the profile of your organization, and the different types of business processes you’ll be supporting, cloud must definitely be a part of your IT strategy conversations.

In many cases, implementing a private cloud and adopting a cloud operating model on your own IT organization may show to be the right solution to your most critical and customized business applications. But in many cases I’m finding out that with the increased security certifications obtained by cloud companies like Virtustream, the option for a hosted / managed private cloud receives a lot of very strong positive feedback.

Having hosted managed private cloud offerings, brings most of the benefits of a public cloud but under your organization’s span of control.

Being Cloud a key topic in your architecture discussions today, adopting a TDI and Virtualized infrastructure for your on-premise SAP HANA deployment will also enable you to be prepared for the adoption of a Hybrid Cloud IaaS scenario, where you’ll be able to have full control of the mobility of your workloads between your private and multiple cloud providers operating under this model.

This scenario will for example enable:

• Higher utilization of private assets: provisioning only for average workload, being able to leverage public cloud for peaks;
• Simplification of operations: by having the same base architectures on-premise and on your cloud provider you can for example setup your disaster recovery to the cloud in a fully automated way;
• Reduction of the risk of change: having a new project you can just deploy a system either on-premise or on the cloud, whatever is more convenient, being able at a later stage to move that system in either direction depending on your “workload filter” and whether the applications will more or less critical and confidential.
• Drive business innovation: one of the key aspects to business innovation is to be able to experiment at a low cost. This scenario provides you full flexibility, so that you don’t have to say no to your business ever. In this scenario you can truly operate as a business broker taking the best of your private infrastructure as well as the public providers you are working with.

           Conclusion

Hope that at this point you agree with me that “Cloud” must be in every organization’s strategy and architecture discussion.

Which one is the right one for you? There is definitely not a “one size fits all” answer.

The good thing is that there are choices that can map to your specific organization, industry, location, and business scenario.

I hope this discussion helps you get started with your own ideas on cloud.

From my side, it is my true belief that an Hybrid IaaS model will be the leading option for mission critical SAP application, being based on SAP HANA or AnyDB.

If you want to get started in engaging with candidate providers to work with you on building your cloud strategy and architecture, being close to me, let me advise the following:

• EMC Federation Enterprise Hybrid Cloud for SAP: this solution makes available a fully enabled cloud infrastructure factory build and fully integrated, delivered pre-configured on your datacenter, leveraging the best technologies from the EMC Federation (EMC, VCE, VMware, Virtustream), so that you can start operating a private cloud without having to build all functionalities on your own from scratch;
• Visit https://community.emc.com/docs/DOC-30532 for more information.
• Virtustream Hosted and Managed Cloud offerings for SAP: Virtustream is a recognized leader in cloud for SAP and SAP HANA and has been recently acquired by the EMC Federation, being as well one of the only 3 SAP Premium HANA Cloud Partners.
• As Virtustream keeps operating as an independent company please visit http://www.virtustream.com/ for more information.