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.

EMC Acquires Virtustream, the leader in cloud for mission critical apps like SAP HANA

EMC has signed a definitive agreement to acquire Virtustream!

This will dramaticaly improve the value of the EMC Federation in the SAP space, and will further simplify the deployment of SAP Workloads, including SAP HANA, for all those organizations looking for an Hybrid Cloud environment, that has the flexibility to adapt to each company's specific constraints in terms of Risk, Compliance, Technical and Financial conditions.

This is a BiiiG topic for SAP customers around the world and for service providers as well, and for that, let me spend some time to share my own personal perspective on why this matters to you.

The news came out yesterday, and you can read more about it, or subscribe to listen to the recording of the press conference at: http://www.emc.com/about/news/press/2015/20150526-01.htm

Virtustream, being already quite known in the U.S. and in particular in the SAP World for providing Cloud Infrastructure as a Service, for enterprise, mission critical, high workload applications, isn't yet a familiar name in many other parts of the world.

To better understand Virtustream's current capabilities, have a look at the following charts from some of the Market Analysts:

Forrester classified Virtustream as the clear leader in "Hosted Private Cloud Solutions", and Gartner recognizes Virtustream's leadership as a niche player. Now with the EMC Federation on its back, Virtustream's (and the EMC Federation) position in Gartner's analysis, will only improve.

The relevance of the names already in Virtustream customer list also confirm their strength: http://www.virtustream.com/customers/list

So, let me share some words to explain my own personal perspective on what is the value for SAP Customers, from having Virtustream joining the EMC Federation as an independent company.

          What kind of applications (workload profiles) Virtustream specializes on ?

First of all, it's important to understand what kind of SAP Workloads Virtustream has been hosting.

So, let's imagine that you have two applications in your datacenter: one to support your "order to cash" process, including billing and accounts receivable, and another to do career planning and performance appraisal for your employees.

Both applications are important, but the impact of instability or even unavailability of these two applications on the ability for your company to keep operating, are significantly different.

If you loose your career planning and employee performance management system for a couple of days, your company will not stop to operate and generate revenues (and some employees may even be happy about it), while if you loose your "order to cash" system, money stops coming in and your company will go into serious trouble.

This is why, most companies can easily buy into the idea of running the "career planning and performance management" system in a public cloud environment (where they have NO span of control on the architecture stability and resilience), and hesitate a lot (not to say that won't even consider) to run their "order to cash" system in the cloud.

So, let's agree at this stage to call the "order to cash" system, a mission critical workload, in the sense that without it, companies loose their ability to keep operating and fulfill their goals, or even if those systems see their performance and stability decay, it will imply an important negative impact on business.

It's all a matter of risk evaluation. For organizations to consider running mission critical applications in a cloud environment, they will need to ensure a set of conditions: availability guarantee, performance guarantee, and ability to audit (and for the service provider to demonstrate) capability to operate such an environment in a stable and predictable way.

The majority of public cloud offerings do not offer such guarantees.

Well, Virtustream having been born by the hands of people coming from the SAP ecosystem, that had experience setting up and managing these mission critical systems, do fully understand the implications of hosting and operating such environments, and have build their offerings to address specifically the needs of the Global 1000 (the 1000 largest organizations in the world) in regards to cloud offerings for their most critical business systems.

Also Virtustream, understanding well the reality of these large global organizations, also understands that for some systems, those organizations - not wanting to engineer and manage them - may want to keep a significant span of control on them. Meaning, having them be operated in a "hosted, managed, private cloud environment". So, it's having the systems under their span of control (or even under their own property), but hosted and managed in a cloud model in the same way public clouds are managed, to reap all the benefits in terms of business agility, operational risk and costs that a cloud model can offer.

These companies may want as well to dynamically choose what systems run on their own private cloud, and which run on a public cloud, dynamically moving (and controlling the movement in real time) of these systems between their private cloud and the public cloud.

          What are the business benefits of the Virtustream model ?

Such a model enables them to manage risk in the sense that they decide which systems are 100% under their span of control, and which ones are not, by being able to dynamically move systems across boarders between their private cloud and the public cloud.

It enables them to manage cost, by ensuring the same efficient management model that exists in the cloud for a better utilization of their assets, while being able to leverage the public cloud for peaks in demand, avoiding the need to over provision capacity for projects, and keeping their "private systems" provisioned just for average workload needs, and so maximum utilization.

Here Virtustream is really unique as they charge by utilization, and not by allocated capacity like most cloud companies do, making them way more cost effective for that reason, and boosting the benefits for organizations from operating in a Hybrid Cloud Environment. This is a part of the Virtustream secret sauce, where they have come up for example with the concept of microVM.

It enables customers to be more agile, as Virtustream has embedded in their Cloud offering and orchestration software, way more than just provisioning of virtual servers. Coming from their SAP background, Virtustream founders have build in as well automation mechanisms for things like systems cloning and refresh (fundamental and usually labor intensive for most SAP customers), making it simpler for IT organizations to keep up with the demands from their business units.

And again, with the beauty of all of this, in having the private and public cloud resources managed through the same tool set, and both able to bring in the same benefits > complete transparency.

Don't want here to explain what is Virtustream, as you can have it explained in 5 minutes in the words of its founder and CEO "Rodney Rogers" at http://www.virtustream.com/blog/2015/05/24/virtustream-technology-overview/

          How Virtustream joining the EMC Federation, benefits SAP Customers in general ?

So, why is this so important for SAP Customers: Virtustream joining the EMC Federation as an independent company.

First of all, Virtustream has been working very closely with SAP (having SAP been one of the early investors in Virtustream) to drive cloud adoption for SAP applications, and SAP HANA in particular. There is a lot more to the collaboration between Virtustream and SAP, which you can read about at the Virtustream site and blog.

On the other side, Virtustream having started as a "Venture Capital Funded Company", would need at a certain point in time to expand their financing capabilities in order to scale and be able to keep up with the significant demand increase.

Also, to expand its reach it would need further access to the supporting technologies of their business model, and access to markets by means of a broader sales force generating demand for them.

Being today the collaboration between Virtustream and the SAP Community inside EMC already very close, being SAP one of the top strategic partners for the EMC federation of companies (EMC Information Information Infrastructure, VMware, Pivotal, VCE, RSA) and running Virtustream most of their operations on top of technologies from the EMC Federation (VCE VBlock, VMware, etc), all of this aligned to the partnering model the EMC Federation of companies fosters, I truly believe that Vistrustream was a perfect match for EMC.

So, joining the EMC Federation as an independent company will provide Virtustream the robustness of belonging to this amazing groups of companies, enabling it to accelerate their growth, expand their reach, and extend their coverage way further from their current market reach and portfolio. By being an independent company within the Federation, it will enable Virtustream "not to get dispersed or diluted" like it happens on many acquisitions in the IT world, and so keep focused on its unique business strategy. That is why it is referred on the announcement that Virtustream is now "EMC Strong".

As I meet with CIOs and their direct reports all over the world (just landing now coming from a CIO Summit in Prague), they all agree with my own experience that, what works for SAP Applications, will work for almost everything else as well. So I would say, that coming from an SAP background, it shouldn't be hard for Virtustream to expand their reach into other application areas.

With Virtustream, EMC completes its vision for an end-to-end cloud offering, from the "Federation Enterprise Hybrid Cloud" which aims to cover the private on-premise needs of customers, with Virtustream covering the on-premise and off-premise managed private clouds, and vCloud Air providing a completely public cloud environment (customer has no span of control on infrastructure architecture/operations), having these three working seamlessly.

In summary, for end customers: this acquisition of Virtustream by EMC, will enable you to implement an Hybrid Cloud model today, with out of the box, ready to use architectures for your private cloud, leveraging all the best practices from operating a public cloud, being able to leverage Virtustream's expertize also to manage your environment up to the SAP Basis layer, including if needed performing the projects to migrate your workloads to the cloud, all with the assurance of a robust global corporation recognized for its strength in the "mission critical world" like EMC.

          How about companies with technical and legal limitations to use U.S. based clouds?

There are 2 additional key aspects to which I'm very aware, as I do also work a lot with customers in Latin America, Eastern Europe, Middle East and Africa, that are very important in regards to customer decisions about any "cloud plans": technical and legal limitations for cloud in these regions.

One of the key limitations of the "U.S. born and based" public cloud offerings, is that they were born to be "public cloud only" and most of the times hosted only on a very limited number of datacenters, mainly in the U.S.

Well, for a U.S. based company, or a company operating mainly in the U.S., this only represents advantages. Even for most truly global companies, this does not represent a problem.

But there is a lot more world than the U.S., and the geo-political environment in other parts of the world, associated with technical limitations like the access to cheap, stable and reliable broadband communications, makes it impossible for certain organizations to consider the possibility to host any of their business critical systems outside the borders of their countries. More, in many countries in the world, there are "data sovereignty regulations" that forbid local companies from placing their data from outside the physical borders of the countries.

There are also the cases of Global Corporations, that having operations in certain countries, are also obliged (either due to legal or technical reasons) to host their systems closer to their operations.

The consequence here is, even if the existing public could offerings based out of the U.S. were reliable enough to host "in-production" business critical applications like SAP (which most are not), due to the technical and "data sovereignty" constraints, those offerings would not be an acceptable (or even possible) alternative for many companies in the world.

One possibility would be Virtustream "managed cloud services", enabling the systems to be in the location of the customer, but being fully managed with all the cloud best practices up to the SAP Basis layer.


          EMC, Virtustream and Service Providers

But there is another perspective here, where both EMC and Virtustream share one common understanding, that they will not be able to reach to the whole world, and maybe it isn't at all a good idea to try and do it all themselves. In most cases there are already local service providers who are building their own local public cloud offerings to attend to the needs of those companies limited either by technical or regulatory limitations in regards to hosting their business critical data outside the country.

Virtustream, apart from providing their own "Infrastructure as a Service" public cloud offering in the U.S.  and Western Europe, and their "managed cloud services", also licenses their software to power Service Providers all over the world.

EMC also has a strong program to equip service providers around the world with "cloud enabled infrastructures".

So, here both companies come together to provide a comprehensive "hardware and software" solution, ready out of the box, either to power service providers or large enterprises looking to build their own private clouds.

Check here the EMC Cloud Service Provider Directory

Having Virtusteam's own IaaS offerings in a Public Cloud model, as well as their managed services targeted at those customers wanting to have a managed private cloud, together with a vast and strong network of service providers all around the world operating on the same architecture, along side with customers having their own private clouds running on this architecture as well, will truly enable IT organizations and their CIOs to become "IT service brokers" for their businesses, procuring the right IT services, being from their private cloud, a local cloud provider or a global cloud provider, according to their financial, technical and regulatory context policy (needed span of control) applicable to each application environment, knowing that they have partners in the public side ready to host and operate their most critical business applications.

          Conclusions

So, I believe these are truly amazing news for the SAP ecosystem (SAP themselves, customers, system integrators and service providers), as the acceleration of the expansion of this model all over the world, will further simplify things like migrating to SAP HANA, and reducing the operating costs of running SAP Applications (including SAP HANA) while improving the performance and agility of existing business systems.

For example, with Virtustream operating as an independent company within the EMC Federation, a Global Company will now be able to have a truly global cloud strategy, that fits its legal, technical, financial and risk model, for their most critical applications (SAP and non-SAP, as what works for SAP will most likely work for everything else), managed through the same model, using public, private, managed or hosted-managed as appropriate without getting locked-in, truly making justice to the principle of "think global, act local" within a Global Hybrid Cloud.

I would invite you also to have a look at the blog Virtustream's CEO, Rodney Rogers published at the time of this announcement with his own personal perspective.

Adding to this fact that I already have some very good friends at Virtustream, it will be truly a pleasure to bring the Virtustream value to my conversations with IT leaders all over the world.

Know more about Virtustream at: http://www.virtustream.com/

How Infrastructure can help reducing the cost of operations of SAP HANASystems

It has happened more than once seeing persons involved in SAP HANA opportunties, that without realizing, built unfair doubts and concerns in their customer’s minds regarding whether adopting SAP HANA is really the best option for a specific business challenge, and whether it is mature enough to support mission critical applications.

The result was a miss perception of the achievable values in terms of both CAPEX and specially OPEX when implementing and running a SAP HANA landscape.

This has led in some cases for SAP HANA adoption projects to be halted, postponed or even canceled.

Among the different situations I’ve observed, one aspect has been repeating itself: relates with the Data Center integration of SAP HANA, and its operations practices.

I would argue that it has happened for 2 reasons:

1.      those persons talking with the customer have no clue what it is like to manage and operate a datacenter supporting aggressive Service Level Agreements in support to Business Critical applications, neither the costs involved in that, neither of all the options currently available to SAP HANA;

2.      customers managing business critical applications in support of aggressive SLAs know that changing people and processes is always more costly than implementing a new technology, and so they always look beyond the high level characteristics of that new technology, down to its implications on operations cost and risk down the road. And if they find no trustworthy options may decide for a postponement or "additional research" before making a commitment.

In the last couple of days, EMC announced the availability of certain functionalities for use with SAP HANA, that I believe will revolutionize the way many customers have been facing SAP HANA deployment options until today, and that will simplify the Datacenter operations of SAP HANA systems, contributing to lower operations cost, less risk, and better lifecycle management options.

This announcement further confirms the high level of maturity that SAP HANA software has reached since its announcement in 2010, and enhances the choice available to customers looking into HANA as a platform for their mission critical applications.

I’m not sure whether most people involved with SAP HANA opportunities around the world are fully aware on how this announcement could help overcome the concerns many SAP customers have been expressing, as well as how much it could impact the costs associated with change, risk and operations management of SAP HANA systems in a mission critical datacenter environment.

So, through this blog post I’ll share what I’ve learned from the customers I’ve been meeting in regards to their decision process, and will explain why this EMC announcement is so ground breaking, trying also to explain the relevance of the technical solutions announced in terms of their impact on datacenter operations, tying into the potential impacts in achieving overall lower OPEX out of running SAP HANA system landscapes..

I will also further explain why I believe the SAP HANA appliance model will become obsolete, by exposing the case of Converged Infrastructures as a factory built infrastructure stack that can be shared both among HANA and non-HANA workloads, contributing also to drive down HANA projects CAPEX.

2015-05-01 Update: SAP has come to agree with all my arguments here, and the evidence of that can be found on the "New HANA Economics" presentation, that I would strongly suggest you to go through. Having this presentation been build to support the arguments that running SAP applications on HANA is more cost effective that running them on Oracle, the same reasoning also supports all I'm arguing on this blog post.

Setting the scene

As more customers adopt SAP HANA systems, its use scenarios also expand.

While many customers realize the potential benefits of integrating this technology into their applications portfolio, many still struggle either to achieve a positive ROI business case for its adoption, or get concerned with the limited datacenter integration options available, which most of them know will be a key factor driving up IT Operations, Risk and Change management costs.

In this perspective, some even say that the variety of options in terms of datacenter integration of an application, are a good sign of its maturity. This leads to the consideration that SAP HANA still lacks the maturity as a product to reach the prime time of Business Critical applications in many of customer’s datacenters.

I heard a wise CIO once saying, that for his mission critical applications we wanted “the almost latest technology” as testing new things with its core business, is a risk that has cost the job to many.

Having persons involved in SAP HANA project opportunities pushing for the “pitch” they were taught and presenting unreal and very limited options in regards to datacenter operations, without fully understanding the variables customers consider when running Proofs of Concept, may sometime do more harm than good in helping customers make their decisions.

Figure 1: SAP HANA Tailored Datacenter Integration for Enterprise Storage enables sharing the same storage infrastructure for SAP HANA and non-SAP HANA applications.

I’ve once written that I believe the SAP HANA Tailored Datacenter Integration program would make the appliance model obsolete, not only by driving further choice and openness to customers, but also by making easier for SAP partners to bring their A game to the table.

Recent announcements further confirm this, by further expanding SAP HANA's Datacenter integration options, and through that,  providing more choice to customers, further showcasing its current high maturity levels.

EMC has just announced the release for productive use of the replication (synchronous, asynchronous, concurrent and cascade), cloning, snapshot and consistent split technologies embedded in their VMAX arrays, for usage in production with SAP HANA Systems both in physical as well as virtualized configurations.

These technologies will enable major cost savings and “de-risking” of SAP HANA implementations, and SAP resources involved in “ HANA DataCenter related” discussions should at least be aware of these things.

So, let me try and shed some light over a different perspective in regards to the "why" customers may value these new possibilities, in order to help you expand your understanding of the currently available possibilities to integrate SAP HANA into existing datacenter practices.

            Why customers consider implementing SAP HANA

Today, with globalization, companies need to be faster and more precise than ever in their business decisions.

This is taking many organizations to decide for the adoption of SAP HANA, the new In-memory Database from SAP, as a way to accelerate the way the company is operating.

With the increased adoption of SAP HANA by customers globally, the variety of use cases also expands, leading to increased situations where SAP HANA will become the primary persistency of Business Critical Applications.

Business Critical applications, due to its relevance to company’s business, usually imply more demanding technical requirements, which lead to increased overall costs associated with its implementation and operation.

Those technical requirements are usually related with aspects like:

·         Availability;

·         Recoverability;

·         Data Protection;

·         Performance.

Nevertheless, companies don’t buy technology just because it is the fastest, or the best in any particular characteristic in the world.

Figure 2: Example of balancing factors in customer’s decision process related with new technologies adoption.

The best managed organizations (and the ones more subject to fierce competition) make decisions on a balance between the expected Business Benefits and the Costs associated with those technologies, evaluating carefully what is the reasonable Return on Investment to be achieved.

And what I’ve observed is that many organizations evaluating SAP HANA adoption projects, considering only some of the limited options available in the past, has made it impossible for many of them to solve this equation, in a way that they reach a comfortable positive ROI result.

            Questions that delay SAP HANA adoption

This happens as most organizations undertake a decision process that involves asking (and getting facts supported answers) to a number of questions other than just simply finding whether SAP HANA is the fastest thing they have ever seen. Examples are:

·         What Technical Requirement must be meet to support the intended Business use of SAP HANA?

·         What will be the investment needed to implement SAP HANA?

·         What will be the operational implications in terms of cost and risk of meeting the Technical Requirements based on the various Implementation Options?

Figure 3: examples of aspects evaluated by organizations in the process of deciding for SAP HANA adoption

After evaluating all these needs, customers must reach a positive ROI scenario to move forward with their purchasing decisions.

Usually, setting up Proof of Concepts have the goal to confirm that HANA has the capability to speed up the Business Processes to the expected levels, but also the goal to gather knowledge that enables responding in an “evidence sustained way” to questions like the ones on the figure above.

I’ve heard from our customers that in many cases where negative ROI is reached and the purchasing decision is halted, the key factors contributing to drive up the cost are associated with risk, change and operations management.

In fact, in most customer scenarios the cost of operating a certain business application on a 5 year period is far greater than the investment required to implement that application, and we see this same feedback from customers when discussing SAP HANA adoption projects.

When evaluating more than just the CAPEX part of a SAP HANA Adoption project, unfortunately I’ve found quite some customers where the calculated Total Cost of Ownership (TCO) of a SAP HANA solution (the OPEX part of the equation) simply led to a negative ROI business case, having as a consequence the mandate to find other alternatives that are able to provide that positive ROI business case, or simply halting, canceling or postponing the SAP HANA related projects under evaluation.

This is quite unfortunate as today's reality provide far greater options and openness that it was possible 1 year ago, and many times that information is not made available to customers.

            Customer experiences in Driving Down cost of operations

A key factor driving down costs associated with risk, change and operations management is to have known and consistent practices & technology solutions across the technology stacks used to support those business applications.

Figure 4: Key factors driving cost associated with SAP HANA risk, change and operations management

In fact, is today an accepted principle that standardizing the technology and processes across the datacenter, represents a huge cost saving factor.

Why? For many reasons! But let me highlight some.

Having standard technologies across the datacenter:

·         drives less cost on spares;

·         enables pooling of similar resources driving higher utilization levels, and through that lower costs;

·         simplifies automation, as the automation tools and procedures can be used across more similar components;

·         enables economies of scale;

·         drives less dispersion of skillsets and through that more expertise, which has as consequence the ability to manage risk better, as well as dedicate more resources to service improvement and innovation;

·         Enables higher automation levels, which release IT personnel to further engage in supporting strategic business initiatives.

In summary, reducing the IT Datacenter Portfolio dispersion drives simpler change processes, lower risk of operations and overall less cost for the whole Datacenter operations.

To make me look smarter, let me put this in an equation:

ROI = Business Benefits – TCO

TCO = CAPEX + OPEX

Considering that OPEX for a solutions on a 5 years period can easily be 4 times the CAPEX for that same solution, from these very simple formulas, you can easily understand that any reduction in OPEX will have a significant impact in the expected ROI of the project.

            Further explaining the case for cross Datacenter standardization

The fact that operation costs account for the largest chunk of costs in the Total Cost of Ownership of a Business Application, gets further relevance if we remember that all organizations have multiple applications to fulfill their business needs, which is a contradicting force to the standardization case I’ve just made.

Application choice is in fact driven by its capacity to provide the business functionality required, which often makes companies disperse their application portfolio across multiple vendors.

So, as application functionality drives dispersion, and in consequence drives cost up, companies look more and more to reap their needed IT budget savings out of the infrastructure stack.

Remembering again that no single customer has only SAP applications in their datacenter, makes further the case to ensure that the datacenter and infrastructure integration practices are the most common possible across all applications.

This principle is one of the key driving forces behind today’s large consensus behind the movement to “Cloud Computing”, being in its Public, Private or Hybrid flavors.

Figure 5: the key steps towards implementing a Cloud Enabled Infrastructure

(NOTE: I know that Virtualization also plays a key part in all this reasoning, but I’m leaving it out on purpose, as the sole benefits of virtualization are so huge, that I thought it would deserve a blog post just for itself.)

In the past having all the standard datacenter architectures and processes shared between HANA and non-HANA workloads was not possible. But has HANA matures, new options have become available, making this a possible option today.

            Diving into the relevance of EMC’s announcements

EMC has been known for years by its mission critical capabilities embedded in the Symmetrix VMAX arrays. In fact, according to some analysts, EMC accounts for the largest installed base of SAP systems running on top of their arrays.

This means that most of SAP’s customers will already have EMC functionality to protect and manage their existing mission critical SAP systems.

So, being able to manage the same datacenter technologies and procedures, will represent for many of these customers a very low startup cost to add “just another application” on top of their existing setup.

In fact, in many customers, the combination of the multiple technologies of the array provide “out of the box” High Availability, Disaster Recovery, Data Protection, LifeCycle Management and Automation capabilities to all applications that sit on top of it.

For many customers, not being able to leverage these capabilities, and being forced by the past SAP HANA deployment option that limited HANA to be available through a dedicated appliance, meant to build a new silo in the datacenter, with a complete new set of Datacenter Components, its unique set of processes and management tools, represented such a startup cost and risk, that just killed the business case for SAP HANA adoption.

For all these customers, the good news are that the SAP HANA Tailored Datacenter Integration (TDI)program has been Generally Available since November 6th, 2013 providing more options in terms of SAP HANA deployment options, and removing the restriction of having HANA only available through a dedicated hardware appliance.

As part of the SAP HANA TDI program, EMC’s has tested and proven the EMC VMAX technology for usage with SAP HANA, and has released for productive use the following functionalities of the VMAX arrays:

·         EMC SRDF S/A/STAR

·         EMC TimeFinder Clones / Snapshots

·         EMC Enginuity Consistency Assist

This enables organizations to leverage those technologies for all their Business Critical applications (including SAP HANA) in a standard and consistent way, and through their use, to drive up SLA’s while driving down operations costs and risks, which will contribute to the reaching of better ROI in SAP HANA adoption business cases.

Figure 6: Key benefits for SAP HANA customers from the adoption of the EMC VMAX storage for their HANA solutions

EMC has a set of built in capabilities in the EMC Symmetrix VMAX storage system, that enables organizations to setup an architecture for SAP HANA, that provides “near-zero data loss” and “near-zero data unavailability”.

With SAP announcing the support to run SAP HANA in Production virtualized with VMware, the benefits of running a virtual datacenter can now also be leveraged by SAP HANA.

The characteristics of the EMC VMAX presented above, represent a solid foundation not only to support SAP HANA setups in a shared physical infrastructure, but also for the setup of a virtual Datacenter, one that through the combination of the EMC VMAX and VMware vSphere capabilities, provide out of the box a set of availability, flexibility and lifecycle management features that can be leveraged between SAP HANA and other SAP or 3^rd party applications at a lower cost than silo based architectures like the old SAP HANA appliance model represented (but let’s leave the virtualization part for another blog post).

            Explaining the value of all these EMC News for SAP HANA

For those of you not familiar with the EMC technology naming, let me take some paragraphs now to map the relevance of those technologies to SAP HANA operations challenges.

Figure 7: Mapping of EMC VMAX Functionalities to SAP HANA Data Center Integration needs, driving up the SAP HANA Platform Resilience and Manageability

The functionalities of the EMC VMAX enable the expansion of SAP HANA datacenter readiness, by :

·         Simplifying High Availability:

o   The EMC VMAX has building characteristics that provide up to 6 9s availability, like the replacement of most parts without downtime;

o   The usage of the SAP HANA Storage Connector for Fiber Channel (aka SAP Block API), enables transparent and non-disruptive HANA node failover in case of a single server component failure;

·         Consistent practices for DR for SAP HANA and all other applications:

o   SRDF/S enables synchronous replication across storage volumes, ensuring an RPO of the last committed transaction, as even the log files are replicated (enabling as well a point in time recovery on the secondary site, if needed);

o   SRDF/A enables asynchronous replication of the SAP HANA Data and Log volumes over large distances, enabling SAP HANA to have the SAP DR practice as all your other applications;

o   SRDF/Star enables multiple scenarios of cascading and concurrent replication to comply with the most demanding data protection requirements combining simultaneous synchronous and asynchronous modes to multiple different destinations.

·         Improved Backup Capabilities

o   Through EMC TimeFinder it’s possible to build consistent disk based clones of SAP HANA Systems;

o   Through the integration with SAP HANA Snapshot functionality enable to do point in time recoveries of SAP HANA using the HANA Studio, using as a starting point a storage snapshot (available as of SAP HANA 1.0 SPS 07);

o   Deliver restartable copies of SAP HANA through HANA’s snapshot capabilities (available as of SAP HANA 1.0 SPS 06);

o   Backup productive systems through a snapshot taken at a remote replicated site through the integration of EMC’s TimeFinder with EMC’s SRDF and SAP HANA Snapshot based backup functionality;

·         Simplified Quality Assurance System Refresh

o   Use storage snapshots to build a restartable image of SAP HANA systems without need to stop production, and be able to convert those snapshots to full clones if needed;

o   Be able to perform the operation referred on the previous point either on the productive site, or on one of the sites to which the system is replicating using EMC’s SRDF;

o   Automate the storage clone and the mounting of the new cloned volumes through the usage of EMC’s Replication Manager software;

·         Simplified test scenarios in virtualized environments

o   Through EMC’s VMAX integration with VMware vShpere’s VAAI, take storage based snapshots or clones either locally or remotely, through the use of a combination of EMC’s TimeFinder Clone/Snap with EMC’s SRDF, to enable consultants to build very fast a copy of production for error regression debugging;

·         Simplified test scenarios in physical environments

o   Take clones of productive systems and easily build clones of clones, or convert snapshot to clones either locally to the production datacenter or remotely on a replicated site for regression testing of errors in production, through the integration of SAP HANA’s Snapshot functionalities with EMC’s TimeFinder, EMC’s SRDF, using EMC’s Replication Manager to automate the pre and post-split steps to very quickly the new test HANA system;

·         Secure DR Testing

o   Through the integration of EMC’s SRDF and EMC’s TimeFinder technology, you can build a full clone of your production environment, and mount it on servers for DR testing, without interrupting replication of your productive environment, and through that enabling DR testing without risking production protection;

·         Cross application consistent backup

o   In the cases where multiple applications are interdependent, and the loss of data in one fatally affects the others (which is the case for example of the use of SAP HANA as a sidecar to a SAP ERP System with the usage of SAP SLT for trigger based replication, where a loss of data in the ERP implies the full reset of STL and full reload of HANA leading to multiple hours of recovery), the integration of EMC’s TimeFinder Clones or Snaps with the Eginuity Consistensy Assist enables to federate the disk volumes of multiple systems for backup purposes, and to recover them to the exact same point in time consistently, avoiding the need for the HANA System reload;

·         Cross application consistent Quality Assurance landscape refresh

o   Using the same technologies referred in the previous point, enable the consistent build or refresh of a quality assurance environment, ensuring that a federated environment is refreshed at the exact same point in time (usefull for example in the case of a refresh a a Q&A environment composed by connected ERP, SRM and BW systems, eliminating the need for functional teams to align the systems data after the technical refresh, and trough that speeding and simplifying test plans).

A brief look just at replication as one example

To further illustrate the benefits above, let me look at the example of setting up a disaster recovery architecture and associated procedures.

I have to say that when I started my career I was a huge fan of database software replication as a way to build disaster recovery configurations.

It was so cool! I had to script a lot of stuff, and you just needed a dumb on the other side.

So, back then, I couldn’t understand why anyone in their perfect mind would choose to do hardware based replication using the storage systems replication capabilities.

I came to understand it the “very hard way” some years later, as I came to manage the operations team of a customer (had all the system administrators and operators reporting to me with application availability SLAs with HUGE penalties for any downtime that exceeded 1 hour).

Having an "explosion" reported on the primary datacenter, I had to activate the disaster plan, and get the team working on the Disaster Recovery Systems activation.

Through that very long Saturday night that I spent “awake” managing firefighters, policemen, the customer and my team, I got a very extensive understanding of Murphy’s Law:

·         As DR activation involved scripting, I came to find out that although all our governance procedures, there were changes made in the production system, that weren’t applied in the same way on the DR site, which represented an impediment to get some critical systems up and running;

·         I also came to understand that sometimes when activating a DR plan you don’t have your best resources available;

·         It may also happen that your most skilled resources do not react well under the pressure of a real disaster situation;

·         As the DR was based on database level replication mechanisms, there were some critical files at the filesystem level needed to get some business critical processes running that weren’t there…

Well, I have to say that this event changed my understanding of Disaster Recovery planning, and made me appreciate hardware based, comprehensive, automated and complete replication solutions.

Figure 8: analysis of what is, and is not, included on the SAP HANA System replication.

So, allow me to also apply this learning to SAP HANA.

Last week I was at a customer event, and not surprisingly, the majority of customers had very experienced people from operations there to meet me, which had been involved in operations for many years.

So, for these guys, this is so obvious, that you don’t even need to explain it. One of those cases was a manufacturing company that had a failure on their production system and was out of business for almost 2 days.

The customer mentioned that this event had as consequence:

·         Full stop of production as they managed all production planning and supply chain trough SAP;

·         Loss of Revenue for not having their product on the shelves of supermarkets;

·         Major costs of restarts of the production plant as a stop implies that product will be such on the pipes and raw material having a short live period had to be through into the garbage.

This customer commented that all the ones involved in the architecture and management of the IT components responsible for this failure are no longer with the company.

Sometimes I may look like an alien on the eyes of colleagues that having SAP HANA application knowledge, never were in front of datacenter operations for critical systems. These experiences leave you learnings that last for a lifetime, and these learnings are the ones that make it for solutions that were not the most obvious choice in certain eyes, to actually be adopted by many of your customers.

For this customer, being able to leverage the EMC technologies they have purchased after that failure is a key decision factor in the adoption of SAP HANA, and these news were very well received, having contributed to kick start preparations to start migrating existing applications from Oracle to SAP HANA.

It’s all about the TCO!!!

Still, at this stage, some might argue that having the SAP HANA System Replication make all these functionalities of storage arrays irrelevant in the HANA space.

Well, if it wasn’t clear yet, it's all about the TCO!!!

Licensing costs or even the total CAPEX of the solution only represents one part!

Change, Risk and Operations management may be more difficult to calculate at the starting point of a project, but an experienced customer will never leave them out of their TCO calculations.

And that is why it is so important to make customers aware of what possibilities are out there.

So, other than doing just a simple CAPEX costs analysis, I’ve tried to make an exercise that exposes other variables that may be relevant to a lot of other customers.

Figure 9: Example of a possible alternative analysis of SAP HANA DR Options.

Through the table above, I do not have the presumption of being right on all my classifications.

The point is to showcase that there are other variables that are relevant for many customers which imply consequences on the TCO equation, and so should be considered whenever they are relevant for a specific customer SAP HANA implementation scenario. For example:

·         Being able to replicate all the data inside a system, and not only the data inside the database, may provide increased reliability in DR activation;

·         The possibility to use the same replication technology for all applications in the datacenter, may simplify DR activation and get the business processes running faster, as most business processes do not work with only 1 application online;

·         The possibility to ensure a consistent backup and restore across different applications, may be key to minimize the impact of logical errors (I have more than one customer scenario where this is a must to ensure consistent recovery of ERP, SLT and HANA when in a sidecar scenario, and avoid the need for a full HANA reload in case of any failure);

·         For many customers having a Recovery Time Objective of a couple of minutes is an easy trade off against having all the other aspects I’m referring on the previous bullets;

·         Some customers will not consider a technology for business critical applications that does not enable the testing of the Disaster Recovery plan without losing protection during that test;

·         For some customers not having the need to have active standby servers, may represent a significant cost avoidance not only in terms of CAPEX, but also in terms of OPEX as there are less OS images to manage, patch, etc.

These are just few examples among all I've gathered on the multiple customer meeting I've had over the last 12 months. But I believe they are enough to illustrate that there isn't a single version of what is the "true" in terms of SAP HANA Datacenter integration.

Again, presenting these options to customers will for sure remove the objections some of the teams may bring up either during Proof of Concept Projects, or in the whole purchasing decision process.

What about the reason some customers love appliances?

Up until now I’ve been talking all about TCO reduction as a key factor driving up SAP HANA adoption.

My main focus has been the OPEX part of the equation, but there are also customers concerned with the CAPEX part of it.

This is where having shared infrastructures for HANA and non-HANA applications come into play.

Again, virtualization of SAP HANA systems with hypervisors like VMware is also very relevant to this discussion.

But one factor that intrigued me from the start was some discussions I’ve observed where some argued against my blog post foreseeing the end of the appliance model for SAP HANA, that there are a lot of customers that do want to buy an appliance.

Before closing this blog post, I wanted to touch briefly this point.

Has anyone of you taken the time to ask questions to your customers and try understanding why those customers liked the appliance model?

Well, I took the opportunity of the many customers meeting and events I’ve attended over the last year to ask the question, and the response I got surprised me completely.

I got answers like:

·         I’m not an IT engineering company, don’t want to build systems on my own;

·         Engineering and integrating IT infrastructures on my own takes so much time and resources, that I want to get it already built;

·         It has happened to me buying components with factory defects that took me weeks and even data loss before I could find out the exact cause of that failure;

·         With all the SLAs the different teams have in my IT organization, from getting a system into my datacenter up to the moment I’ll be able to logon to the operating system and install an application, will take me no less than 3 months;

·         I want a single neck to choke in terms of infrastructure support problems;

·         I want a single provider to be responsible for the patching and integration of all the infrastructure components…

Well, the point is that none of the answers were SAP HANA specific!

So, I asked again:

·         What if you could have all that, but in an infrastructure that could be shared with all your other applications in the datacenter, and so avoiding building another silo?

Most customers answered without hesitation: that would be perfect!

But then argued that such a scenario was not possible, as all vendors are moving to single stack, siloed solutions, and so “between the fire and the pan”, they would rather go for those appliances.

I realized then that most of those customers were not familiar with the concept of converged infrastructures.

I would compare “Converged Infrastructures” with what has been the work of auto manufacturers over the last years:

·         They produce an end product ready to be used: a car;

·         They do not manufacture every single component of it;

·         But they provide warranty and integrated support to the full solution: the car as a whole;

·         They engineer the system, specify it, and procure the production to partners;

·         They are then responsible for the physical assembly as well as the logical configuration of the product (for example setting the default language for the electronic systems – GPS, car audio, etc)…

Figure 10: an example of a comparison of the value of a Converged Infrastructure for SAP HANA, against some of the currently available appliance offerings in the market.

Again, I do not have the pretension of having covered all the key variables in my analysis above. My goal here is to show that depending on the usage scenario of SAP HANA, and on the specific customer situation, there may be other variables that matter.

IT is evolving, and in the same way are evolving IT Infrastructure providers.

It’s my perspective that the maturity state IT has reached as enabled IT infrastructure providers to evolve from single component delivery, where customers were responsible to assemble and support the full solution, to a scenario where a provider provides already a “ready to drive” solutions, and one that can be driven by multiple persons (run multiple applications), as opposed for one that can only have a single unique designated driver (single application silo).

Converged Infrastructures provide to SAP HANA customers the best of the SAP HANA appliance model in a shared “factory built” infrastructure.

When making this comparison I’m referring to VCE’s VBlock Systems, which incorporate from factory all those EMC technologies I’ve been referring through this blog post, and so enlarging the Datacenter Integration options of SAP HANA, while driving down risk and complexity associated both with the SAP HANA Implementation Projects (the CAPEX part), as well as SAP HANA operations (the OPEX part).

                Conclusion

I believe all of these are great news to come out on the week is happening the SAPPHIRE 2014 in Orlando, as these announcements are an evidence of the maturity levels SAP HANA has reached, which prove it as a technology ready to reach the prime time of mission critical applications in our customer datacenters.

I hope that people advising customers on SAP HANA Datacenter Integration and its impact on operations learn about these new possibilities, in order to present the realistic view of today's SAP HANA openness and Datacenter Readiness in it full scale..

Fortunately there are many around the world that have understood the importance of being up to date on the datacenter integration options of SAP HANA (not only from SAP but from partners as well), and I’ve been very privileged to be some SAP employees in customer events and discussions where this topics were openly approached and discussed, having those discussions contributed decisively to help those account teams bring to successful closure SAP HANA deals that were “on the hoven” for quite some time without progress.

Also, all these news are another evidence of the major focus the EMC Corporation is putting in further enhancing the SAP HANA datacenter readiness, and through that also drive its increased adoption.

What I’ve touched here represents only a small part of all the things EMC has been working on, and there are a couple of things I know for sure:

·         The best news from EMC are yet to come (DSSD acquisition coming to market, and others…);

·         Competition will only increase on the SAP HANA space, having competitors running fast to catch up on this announcements, which will further increase the Datacenter Integration and Openness of SAP HANA, contributing for an accelerated pace of HANA adoption over the coming years.

If you were brave enough to read through all this very long email post, do not hesitate to get in touch with me for comments or questions!

All perspectives will be highly appreciated.

For reference, check out the following links:

·         My blog post on why SAP HANA TDI will make the appliance model obsolete

·         Myrecommended reading list for SAP HANA Technologist and Architects

·         EMC’s SAP HANA TDI landing page

·         EMC’s whitepaper detailing the technical configurations of the technologies referred in this blog post for SAP HANA

·         VCE’s page on VBlock Systems for SAP