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.
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:
- 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).
- 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.
- 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);
- The project for the technical upgrade with DMO to migrate to HANA was also funded by 6 months of savings!
- 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).
- 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:
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!
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!