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/

What is still missing on SAP's S/4 HANA Vision

As I'm flying to Amsterdam today, on the plane I saw myself thinking on all the meeting I had during SAPPHIRE a couple of weeks ago in Orlando. And one topic that came across in many of those meetings was: how to make HANA and S/4 become a reality in a cost effective way in my datacenter. So, let me take these two hours of flight to share a bit the raw thoughts that are coming to my mind on this topic.

There are no questions these days that the future of SAP is S/4 and that it runs on HANA.

In the words of a good friend that was already around when SAP migrated from R/2 to R/3, "it's a completely new application stack and solution set".

Also on his words, like it happened with the R/2 to R/3 migration which started in 1992, many working in the SAP world, will take some time to realize and accept that this is the way and there is no way back.

So, for all of those in the ecosystem, the word is: refresh your skills to the new era!

So, applauding the initiative from SAP in reinventing its core Business Software Stack, I still see some aspects missing from the architecture vision, that if not considered will make this transformation fall short on expectations and market potential.

Through this blog post I'll share some of the desires large organizations around the world shared with me, associated with my own interpretation of the situation, in regards to how the reengineering of the SAP Business Suite should look like, as we transition to the new S/4 HANA world.

Let me say upfront, that I agree that what I'll say is not simple to implement. Can say either whether there is someone within SAP thinking about this already as I have NO privileged information. What I can say, is that if SAP really wants to be up to the principle of "Run Simple" these aspects would be major in making it happen.

So, let first have a look at what we know at this date.

We know that SAP is redesigning its applications according the following principles:

   - simplify the data model and reduce the data footprint by eliminating data duplication within the SAP Aplications Landscape.

   - rebuild those applications for Fiori and UI5 for better user experience and productivity;

   - enable guided configuration for simpler startup through configuration wizards and "rapid deployment" easy to consume business scenarios.

All of these will make SAP Applications definitely easier to consume.

To these aspects that SAP announced we can also add other aspect we already know that come from the fact that S/4 is running on top of HANA:

   - pushing calculations down to the database layer, leveraging SAP HANA realtime capabilities to speed up processing;

   - merge OLAP and OLTP on the same platform, enabling real time operational reporting, elimination of data availability lead times and data duplication;

   - enable the processing of structured and unstructured data on the same platform, making it possible to get business insights in real time out of machine, social and other types of unstructured data.

Again, all great here!

So, what am I missing? What are some customers asking about?

I've written a lot about TCO. This is engraved in my reasoning from the days I worked on IT operations and on Management Roles, where I realized in the flesh the weight of OPEX in the agility of organizations, and their resilience to unforeseen events.

And let me reinforce the business agility and ability to react to unforeseen events, as over the last 15 years, with the increased globalization driven by global communications, not only of data, but of people and money as well, we have been going through a series of events, that the majority of the economic players were unable to predict.

Things like the burst of the .com bubble in 2000, the terrorist attacks in the U.S. on 9/11, the SubPrime crisis in 2008 due to real-estate speculation, the European Debt Crisis that we are still struggling to come out of, and that has been having a significant impact on the global economy affecting companies all over the world, and making us see banks considered references for decayed break in the U.S. and Europe.

All of this makes it that - like I read in a McKinsey Quarterly article in 2003 - the only way for companies to survive is either to shape markets or to be very agile in adapting to changing market conditions. Would even say, that in today's economic environment, being able to do both, and reinventing business models is a must to be a player in the future.

As a side note, this is definitely what companies like SAP and EMC are doing by disrupting themselves at their core to get ready for tomorrow.

Not all companies in the world are as prepared for this, and the fact that information technologies, that provide faster and better business visualization to management boards are today slow to react and adapt is a key contributor to that lack of business agility by many organizations.

It is today an absurd that having Information Technologies came to "automate the business processes of organizations", their management and change is still so manual. There is a dramatic need to change in paradigm.

So, one thing that should be included on the reinvention of hardware and software stacks for this new world of uncertainty and rapid change, should be the premise that the systems and architectures should be designed from the start to enable simple and fast change from top to bottom.

This may seem an obvious aspect, and some would argue that this is a lady being done now.

My point of view, and the one of some customers and partners I've had the privilege to discuss this with, is that SAP is still missing some important points.

Why?

One thing we will never be able to fully eliminate will be the human intervention in IT. it can definitely be reduced by increased automation, but at least for the next 10 to 15 years, there will still be a significant human intervention - at least - in two critical phases of the IT lifecycle: when you set it up, and when you need to change it and evolve it either due to obsolescence of the underlying components, or due to dramatic shifts on companies business requirements (maybe driven from change forces in the market.

And this leads to a series of principles that should be though, as a consequence of understanding the human mind.

I believe it was Jack Welch that said that a company who needs super mans to be managed is condemned to failure (forgive me if I quote the wrong author... hope not).

I would say, that an IT Landscape or architecture that need brilliant brains to design it, implement it, manage it and change/evolve it, is condemned to drag down its company's business agility.

So, how do we solve this equation?

I would add two variables: use standard and modular building blocks accross the board as much as possible.

And this goes down to the infrastructure! Some by reading this will think on what is today called the 3rd platform applications as described by IDC. No, I'm not talking about that implicitly.

What I'm thinking about is: look at what infrastructure components are today the most standard, more broadly used components in the market, and design your applications to leverage those!

This is what I though SAP had in mind when they came up with SAP HANA Scale-out architecture, now enhanced with Multi-tenant database containers and Dynamic Tiering, these last two features announced with SAP HANA SPS09.

Let me start to tie in all of these together.

When I asked to some SAP employees involved in the HANA and S/4 roadmap discussions internally at SAP how were they planning to manage the ERP redesign to HANA, the answers I got disappointed me.

Maybe... And I have to repeat... Maybe, they could not disclose anything more than that at this stage. Don't know. I might even speculated that this isn't even yet in the table of discussion today.

Well, I developed my question as what I was looking for would be any hint that SAP would take this opportunity to go deeper into the data model and application architecture redesign.

Talking about the existing SAP Applications (ERP, CRM, SRM, etc), each of these applications is composed by a number of components. SAP started splitting the development cycle of these components still in the R/3 era when they started to provide support packages in separate for HR and the rest of the R/3, back then integrated in the "APPL" component. Today we have even more: these is the Basis, ABA, BW, etc, etc, etc.

Back then the logic SAP communicated for that change would be to simplify the application evolution, since HR had a lot more fluent updates due to legal requirements than the FI/CO/MM/PP/SD/etc modules. And it evolved to keep breaking each application stack in multiple components that led later to the Business Suite running on top of the WebAS. 

Small curiosity: I was teaching SAP Basis academies for SAP when this happened, observing closely the evolution from R/3 3.1i to 4.6d where JAVA was first introduced.

Maybe I'm asking too much, but my expectation now would be for SAP ago further reduce the size of the monster (ERP is still one of the largest and most critical databases in many customer environments, the larger it is, being more expensive and difficult to manage/evolve).

So, I was "dreaming" of a split of the ERP in its fundamental components, being each component installable as a separate entity, and within a separate database.

For example: if SAP delivers as they are saying, that communication between Database Containers within the same SAP HANA Database Cluster, will be almost as fast as if they were in the same database, then it would make all the sense to split logistics, finance, HR, etc... down to all the industry verticals into a separate database container.

This would make each of this pieces "so small" according to today's standards, that it would then make it very simple for customers to install scale-out clusters, with all these applications split accross the multiple scale-out nodes. Here I'm imagining that one application would be able to call data accross containers, leveraging the massive paralel processing of the scale-out, shared nothing cluster architecture.

But, what I've been told so far is that each of the existing SAP application components will keep existing together as a single database.

And this is not good, because even with the data model simplification, and increasing number of customers will see their database sizes such, that they won't be able to use today's most commonly used infrastructure components. For example: in terms of servers, a 4 socket server that with Intel x86 Ivy-Bridge CPU can host up to 3 TB of RAM.

Do, coming from the infrastructure upwards.

The idea would be to take the assumption that whatever SAP redesigns today must aim to fit in a 4 sockets Intel server. So, for example, the ERP would be split into a number of independent modules (the smallest installable modular unit), that could then be distributed in a Multi-tenant, scale-out SAP HANA Cluster.

This would enable simpler and faste backup times for each of the components in paralel, faster restart times enabling bette Recovery Time Objectives (RTO) t a cheaper price, would enable simpler evolution, for example through the usage of the capabilities of VMware...

And by using the most commonly known infrastructure components in the market, the probability for organizations to have a ton of people inside with that skill set would be higher, making it simple to do a risk assessment when change needs to happen, and evolve faster and cheaper.

Again, thine se are the principles of what is called 3rd platform applications, where you design your application through "micro-services" each of them existing in a container, all loosely coupled and hosted on a cheap, standard, massive paralel scale-out cluster.

SAP, where are you on this journey? If you are working in this direction, I'll bet you would win more in sharing this with the community sooner, as it would build more confidence and gain further support to help you through this transition.

So, I hope that something is already happening, and I'm just not aware yet. As otherwise, SAP is missing here a massive opportunity to lay take its application stack to the next level in terms of future proof architecture.

Tying in the Data Temperature concepts, would then make sense for me as well, while we move to a world of OLAP, OLTP, structured and unstructured all in the same platform (SAP HANA), that all this application modules could be able to also consume and push data to a series of "different storage containers" based on the business value of the information.

So, it would make sense for SAP HANA to be able to access and manipulate unstructured data directly from HDFS storage, which would provide "infinite storage for lower value, higher volume" unstructured data.

Then for those slices to be able to use as well a "warm store" ( here relating to the extended store announced with Dynamic Tiering on SAP HANA SPS09), to park structured data that being important, doesn't need to be accessed by the business so often and so fast.

Would also make sense to have a 3rd store that I would call "frozen" archive, that would be read-only in nature for compliance reasons. And this could just be an export to a file in a file system, as there is a ton of technologies today in the market to take care of this.

Leaving to be stored in memory, realy the most critical data which is needed more and faster by the business.

Then coupling flexible storage, with modular application components, distributed in a cheap server farm (Intel E5 - 4 socket severs today), would realy make the core SAP Business Software be set for the future (beyond the next 15 years), while enabling organizations to have it in cheaper, simpler and faster do change infrastructure architectures.

As a conclusion:

I know that what I'm saying here is not easy, and may take SAP quite some effort to realize.

I also understand that they need to show something valuable fast, to be able to monetize the development investments and reduce the profitability impact of reinventing themselves.

So, I would accept that migrating the ERP to HANA as is might be a good first step.

What I did not like was listening from the people I talked with, that just redesigning the ERP for Fiori and HANA, while keeping the monster ( and maybe even adding some other monsters like BW, CRM, ETC) was the end arrival vision.

If this happens, if we make a paralel to More's law to the volume of data an organization will generate with HANA speed, the problems customers came to feel today due to the gigantic databases they come to build, just give it 5 to 10 years for those problems to be back again.

One final comment to cloud: public cloud will still take some years to be an option in certain parts of the world. Either due to technical, legal, confidentiality, competitive or economic restrictions. Not all the world looks like the U.S., Northern Europe or Japan. There is a lot more world contributing to SAP's revenues. So private cloud environments will still be around for quite some years, and hope SAP remembers that as they design the medium term vision.

Key take aways out of SAPPHIRE Orlando 2015

It's time to say goodbye to Orlando after SAP's SAPPHIRE event, with a week loaded of customer and partner meetings.

The technology related news were few:

   - SAP HANA productive support for scale-out on VMware is now on Controlled Availability

   - New servers based on the Intel Haswell CPU started to appear, promising increased performance per CPU core

But to be fair, and putting my self in the shoes of our customers, it was a very full week, with all the focus on:

   - what business outcomes can SAP HANA enable (S/4, Board room of the future, real time cash management, real time supply chain insight are just few of the many examples through the exhibition)

   - how the Internet of Things can impact business (integration of machine data into business decisions, HANA managing structured and unstructured data under a single pane of glass for better business insights)

But the highlight out of my meeting with customers and partners was an increased awareness and concern with:

   - understanding Data Temperatures in HANA as a way to reduce TCO when integrating massive volumes of unstructured data, and keeping infinitely the structured data generated by the organization

   - realization that implementing SAP HANA as an appliance might have been the only option in the past, and is definitely not the best, and so customers that have already been running HANA for some years, came all over wanting to understand better SAP HANA Tailored Datacenter Integration as a way to reduce TCO and enable the leveraging of existing infrastructures and operational processes for less risk, as well all things about running SAP HANA on VMware as the simplest, cheapest and fastest way to start a SAP HANA project.

So, although the majority of SAP's talking points were targeted at C-level executives, the teams of these executives also came by and they were all about "how to make it happen in the simplest, most cost effective way".

For me personally, this was a massive event! I had an agenda so loaded with customer and partner meetings, and meet so many new faces in the community alongside with an increased interest on the topics I've written the most about, made this week exhausting, but very rewarding.

I' leaving with the strong feeling I've helped many organizations move forward with their SAP HANA adoption plans, by making it simple all things related with SAP HANA Infrastructure Integration.

Topics I would have liked to hear more about and that we're almost non-existent, were:

   - preview on SAP HANA SPS10

   - evolution of the Multi-tenant database containers feature

   - evolution of the Data Tiering feature

   - what is being done to make SAP applications running on top of HANA better for scale-out scenarios

   - more insights in to what is planned in regards to "HADOOP alike" capabilities coming to HANA, for example enabling HANA to natively access and process data available on HDFS stores without need for an HADOOP cluster in the middle.

Well, the plane is coming, and I need to run, but didn't wanted to leave without leaving my first impressions "hot off the press".

It was great meeting you all (customers, partners, SAP friends, SAP Mentors, company colleagues), thanks for all the interesting discussions, or just the fun moments, and looking forward to see you all soon!

   

SAP HANA Storage Whitepaper version 2.6 released

SAP has published quite some time ago their "storage requirements whitepaper" for SAP HANA, which explains at a quite interesting level of detail, how SAP HANA uses storage, and to what extent storage characteristics are relevant for SAP HANA operations.

So far, no news.

What is new, is that with each new version of this "Storage Whitepaper", SAP has been simplifying the SAP HANA Storage requirements (for example on this latest version by reducing the capacity requirements for the /hana/shared/ filesystem), which is a clear reflection of the increased experience on SAP HANA operations, increased stability of the software, and so a clear sign of maturity.

If you haven't read this document yet, I would really suggest you to take some time to go through it in detail.

If you already saw this document at some point in time, be sure to review it and be up to date on the latest.

The SAP HANA Storage Requirements Whitepaper is published at: http://scn.sap.com/docs/DOC-62595

Reference to this and other important documents in regards to SAP HANA infrastructure integration can be found on the right pane of my blog under reference pages: SAP HANA Technical Documentation

The right architecture for SAP S/4 HANA and the Internet of Things?

SAP HANA is changing the long time ERP paradigms for SAP customers.

But SAP HANA itself is evolving very fast, and bringing new functionality and possibilities with every new release. Among the new variables needed to be considered are aspects like:

• the introduction of data temperatures and tiering data to the right “economically viable” repository;
• integration of machine data;
• the mandate for the new HANA warm store to be on a separate server than the HANA system, and using shared storage;
• the new HANA functionality (named HANA "Vora") promising to enable HADOOP for the enterprise;
• the increased value of data and the increased need for availability and data protection in organizations.

Despite the expected data footprint reduction from the migration of SAP ERP to S/4 HANA, the volume of data managed by SAP HANA may only increase, which mandates to think infrastructure in a different perspective.

In this blog post, while explaining where the SAP HANA data footprint reduction will come from, and I’ll talk a bit about the relevance of data storage and virtualization in the new HANA world.

Also separating what is marketing noise from the reality, will take a closer look at what is possible today as well as what is coming, confirming the increased openness SAP HANA is providing today just comparing with what was the reality two years ago.

I'll conclude by making the case on why implementing SAP HANA in a TDI and Virtualized infrastructure are the right choices for companies planning to implement HANA today.

               Setting the scene

Just read an interesting article on a UK online journal, talking about the promise of less storage consumption as an IT driver for HANA adoption.

I would find it strange that a company would implement SAP HANA just because of that, as I think the rationale for HANA adoption should be a business related one.

At least, if today I was working as a customer, that would be my thinking: what does this bring additionally to my business, balanced against the change costs it will imply.

Nevertheless, stepping back a bit from all the marketing stuff that has been around since the S/4 announcement, let’s think on it with more calm.

Where the claim for SAP HANA storage footprint reduction does comes from?

For sure many of you have seen the following image:

For the sake of organizing better my ideas, let me call each of the reduction factors in the image above, Jump1, Jump2 and Jump3.

               Where does the data reduction come from when “just” moving from Oracle to HANA?

Analyzing them, where does Jump1 comes from?

• Looking at a traditional SAP ERP implementation on Oracle, one thing we know is that having all data in memory, the need for a massive amount of Indexes to speed up the access to data goes away.
• If you think about it, more than 50% of the storage footprint of an Oracle database supporting SAP ERP is just for indexes! So, here is 50% reduction in space.
• On the other side, SAP HANA compresses the data in memory, which provides an additional contribution to the storage footprint reduction.
• Also, in the “traditional DB world” some records were loaded in multiple database tables (so data redundancy) to serve different application needs and avoid data access bottlenecks. For example, you had a table with the raw data, another with that same data aggregated by year, and another aggregated by some other variable.
• So, in the new in-memory world of HANA, there is no need for this as well, as SAP is replacing all those tables with views on top of a single data record, and through the elimination of data redundancy, also reducing significantly the data footprint of HANA.

And mainly this is where SAP is expecting the 5x data footprint reduction just out of the Jump1.

And it’s a fair expectation!

Of course, like any generic statements, in reality each case will be a case, and I’ve seen cases where there was only about 50% of data reduction (you can call it 2 x), which summing up the need for free space in the HANA server for calculations and HANA functioning, ended up requiring exactly the same amount of RAM as the disk footprint of the original Oracle Database. This was of course an extreme case of a database with an industry vertical where SAP hasn’t yet done all the table redundancy clean-up, and where the source database was already compressed.

Where does the footprint reduction come from when moving from Suite on HANA to S/4?

Jump2 footprint reduction comes from the well know “magic” of Simple Finance.

The image bellow is for sure also known by many:

The data redundancies I’ve started to describe above, when we talk about basic business objects in the ERP, meant in the example of finance that the data that “could reside” only on 4 tables, was duplicated to about 23 tables.

With the redesign of the SAP’s well know FI/CO modules, now rebranded as sFin, SAP reduced the tables from those 23 to 4. So, this is what is accounting for the additional 2,5x data footprint reduction.

Here I would be careful just for one aspect: we only have today sFin. sLog (Simplified Logistics) has been announced to be launched in the 2^nd half of 2015.

But there is a lot more to SAP applications than just sFin and sLog. So, let’s wait and see what the reality will bring us before start launching the fireworks. And with this I’m not insinuating in anyway that the reduction will be smaller than claimed. In some modules it can actually be more.

Again, if you are moving today to S/4, the only module that will observe this dramatic reduction will be sFin, as none of the others are yet available.

Meaning: manage carefully your expectations. This is a nice statement of direction, but the reality is not there yet.

               What about the split between actual and historical?

Jump3 "will" come from the adoption by SAP Business Suite of the functionality announced with SAP HANA SPS09, called data tiering.

And I put the "will" between "", because dynamic tiering is not ready yet for SAP Business Suite or S/4, and is still today restricted in usage to BW (SAP product management mentione the need for dynamic tiering needing to enable "hybrid tables" before it can be considered for busines suite).

So, What I'll describe here is "imagining the future", as today the reality is just based on the possibility of keeping some data only on disk, and load to memory upon need, sort of working like the old ABAP buffers (least used get's "destaged" to provide space for new objects being loaded in memory).

If you look for the presentations released by SAP at the time of SAP HANA SPS09 announcement, you can find one presentation specific on this topic.

In that presentation you’ll find the following slides:

So, the idea if that on S/4 HANA, the ILM (Information Lifecycle Management) functionality will be redesigned to take advantage of this feature (somewhere in the future...), where the idea is that the HANA system will be able to automatically determine the relevance of a specific data record and either place it in memory, or in the “Warm Store”. Remember, I just said this is the “future idea”. So we are not there yet.

If you look at this slide, the warm store is another service of the HANA database, where the primary image will be on disk.

What does this mean? This will be a columnar compressed database, but optimized to run on disk.

If SAP implements this well, and according to the expectations, one of the things that made SAP databases grow so much to a size almost unmanageable, was the difficulty to define data governance policies that then led to data archiving practices.

Meaning: many SAP customers never did any archiving, not because it was technically challenging, but because no one on the organization has put their neck on the guillotine in defining what data could be removed from the database.

So, here we are no longer talking about data footprint reduction but rather about placing the data on the most “economically sensible” medium, according to that data’s value.

For example, if you want to make real time business decisions, maybe this year’s data is fundamental to be accessed very fast, but do you need the data from 10 years ago to be available at the same speed, and so at the same cost? Maybe not.

Here SAP is finally introducing the concept of data temperatures, and data tiering. Concepts, that companies like EMC have developed and successfully implemented many years ago. The difference here is that SAP is trying to implement this logic on the DB code.

We’ll need to wait and see how successful they will be in implementing this, because if the data tiering doesn’t come to be dynamic, lots of benefits will be lost due to the same reasons lots of customers never archived: lack of governance, lack of technical knowledge, or not wanting to deal with that additional level of complexity.

Nevertheless, data storage has never been more important. What changes here is the profile of that storage as new variables will increase of importance in the new HANA reality.

               The VMware effect on SAP HANA Data Volumes

So, lets now put all of this in perspective.

Do you remember what happened to the number of servers that existed in organizations when VMware made deploying them so easy? They went sky rocket!

Translating to HANA, if SAP makes – not only data tiering – but as well data acquisition simple, integrating structured and non-structured data, capturing machine data, making HANA a “business information hub” for the organization, two of the “Big Data V’s” will hit hard these systems like nothing we’ve see so far: the Volume and the Variety.

The performance and lifecycle effects on storage capacity

Adding two final variables to this discussion before diving into my conclusions of this phenomena:

• A system that on Oracle needed 32 CPU cores to run its database, on HANA may run on 120 CPU cores;
• Imagine loading machine data into a 120 CPU (or even 240 cores and more). How many log writes will such a system generate;
• HANA has to comply with ACID principles of Atomicity, Consistency, Isolation and Durability, so whatever happens in the HANA world will have to be persisted on a “persistent medium”.
•  Maybe its more sexy to call it persistency, but this is storage! It may be a different type of storage, more oriented to speed than to capacity, but this is what storage companies are moving for, as their offerings will be more needed than ever!
• What about High Availability? Disaster Recovery? Data protection or Backup and Recovery (whatever you like to call it)? And application change management?
• All these activities have demanded additional storage capacity over the years. Having customers demanding as much as 16 times the productive database capacity to support the requirements here (DR site, Test systems, etc);
• One thing I haven’t seen thoroughly discussed yet is how SAP Applications Lifecycle Management will evolve in the new S/4 reality, as this will be determinant to define the true impact of HANA on the storage footprint.

One thing I know for sure: the value of information for organizations will only grow faster.

So, I do not see organizations assuming data loss anymore, and even less in this new HANA world.

Having all data accessible at “nanosecond” grade speeds, and increasing the dependency of business processes on real time data, will imply increasingly demanding architectures in terms of disaster avoidance and business continuity.

Conclusion

In conclusion, yes, HANA may drive some data footprint reduction.

And it must, to be viable! As 1 TB of RAM does not cost the same as 1 TB of disk.

Determining the right value of data, and putting it on the right “economically suitable” medium, is fundamental for the SAP HANA ROI equation.

So, I see the “HANA data volume reduction” more on the perspective of HANA’s viability itself (someone wrote some weeks ago that the price list of 12 TB of RAM is over 1 million USD!!! So, a lot more than the same capacity on disk).

But thinking on the increased easiness of loading and manipulating data in HANA, associated to the expected volume and variety coming for example from SAP HANA integration with machine data, I’m not sure that in a 10 years period the volume of stored data will actually be less than it is today with SAP ERP on Oracle.

If I may make a guess, I think it will not only increase, but it will increase at an accelerated pace!

What I take from all this discussion is that probably the “infrastructure things” customers will buy in this new “in-Memory” world will be different from the ones they were used to buy up until today, but maybe the budget will stay the same.

Providers will need to adapt to this new reality to stay relevant and in business.

But considering SAP’s own statements that the HW costs are only the tip of the iceberg of the total IT costs, there are so much saving to be realized on other areas, that I wouldn’t go all obsessed with the infrastructure part of it, as what I see is that “the early adopter’s induced obsession” with CAPEX reduction, now that some of them have reached 2 or 3 years of operations experience, have revealed a significant increase on all the costs hidden bellow the water (as per the slide above).

The money spend on Operations and Change Management is massive in many organizations, and can easily - over a period of 5 years - be 4 or 5 times the investment cost of the infrastructure.

Let me suggest you all to have a look at a presentation from SAP focused exactly on this: the new HANA economics.

As you can see, SAP is also evolving their understanding, and aspects like SAP HANA Tailored Datacenter and Virtualization are just a natural evolution step on SAP HANA maturity, so options you should consider from the start.

If you agree with SAP’s analysis there, a couple of things stand out that confirm what has been my reasoning for quite some time now:

• When implementing HANA chose a Tailored Datacenter Implementation as it will drive out costs;
• When possible use commodity hardware (for example the new validated Intel E5 based servers – available for configs up to 1,5 TB);
• Virtualize your systems whenever possible (vSphere 6 coming in a couple of months to support HANA Scale-out virtualized, and scale-up systems up to 4 TB).

And be prepared for the unexpected, as not only your business may change to unexpected directions and making massive “monolithic and inflexible” investments will not help your business become more agile.

With all the footprint reduction described here, as it will imply the implementation of data temperatures, and tiering data out of RAM to more affordable mediums, implementing HANA in a VM, with the Warm Store on another VM, and the HADOOP store on another, all using shared storage, will be the right way to go.

Looking to the picture above, I believe it is clear that "an appliance" cannot respond to the architecture needs of this new SAP HANA reality.

And, don’t take my word for it, as it is stated crystal clear in the SAP documents I’ve been mentioning through this blog post!

So, I would expect to see:

• a raise on HDFS capable storage in conjunction with HANA to store the less valuable “machine data” managed by a fully virtualized HADOOP cluster;
• a rise in the demand for cost effective, flash optimized storage to support the warm store, as the majority of volume for the structured thata will be there in the future;
• and a speed optimized “multi-channel” storage to support HANA massive log generation, and speedy restart time needs for application availability requirements;
• SAP HANA Tailored Datacenter Integration become the preferred deployment model for SAP HANA;
• Virtualization usage to see increased adoption.

I hope this discussion will help you out to put in perspective both your architecture and data placement strategies for this new HANA world.

S/4: HANA no longer a matter of if, but rather how and when - strongercase for TDI and VMware

Over the last 6 months I've observed a significant evolution in my conversations with customers in regards to HANA adoption.

More agree that the HANA discussion is no longer a matter of "if they will adopt HANA" but rather a matter of how and when. And SAP's statement of direction with the announcement of S/4 HANA is definitely contributing to this change of discussion.

And when talking about the how and when, one interesting factor is the weight the experiences of the early adopters already start to have on the considerations of the new adopters.

There were 3 particular customer engagements that really got me on to write this blog, as they represented 3 very different stages of HANA adoption. And all these 3 experiences highlighted 3 things I've been writing about for more than a year now: the impact of start-up cost, operations cost and change cost. As usual my focus is on the infrastructure impact of HANA in customer datacenters.

In summary my findings were:

1   - with a customer now planning the introduction of HANA in their datacenter portfolio, one of their biggest concerns was the risk and cost introduced by having to change their standards in datacenter architecture and operational processes. In this case I've found that the ignorance and insecurity of the consultants on the project on topics like SAP HANA Tailored Datacenter Integration, infrastructure architecture, datacenter operations, virtualization and other infrastructure related disciplines, still makes these people communicate (still today!) that HANA can only be installed as an appliance, ignoring the impacts and risk this represents to many customers. Keeping up with aggressive SLAs is all about building a smooth operation. Smooth operations is all about people and processes, and forcing the introduction of an appliance in this scenario makes the risk and cost of change go sky high. This customer was so relieved from listening me guiding him through what is SAP HANA Tailored Datacenter Integration, and the current support status of HANA on VMware;

2   - with a customer that has just finished a successful PoC and is planning the start of the implementation project of HANA, having the customer more knowledge (through their research and search for real experiences from other customers) than their implementation consultants on what can be done today in terms of HANA virtualization, they saw the start of the project blocked because the consultants in the project said that if he decided to virtualize HANA they would be out of support from SAP! You are afraid of what you don't know. Unfortunately I had to be the one to clarify that the negative impact of virtualization of HANA was only of performance and not at all of functionality. This customer was adopting HANA for functionality purposes, and having processes going from 53 minutes on Oracle to 16 seconds on HANA, the discussion of if "on physical it could be 15 seconds" was just irrelevant compared with the cost avoidance that virtualizing their 700 GB HANA instance represented. How much were worth 1 or 2 seconds in these scenario? Non of the consultants working with this customer had the capacity of putting things into perspective. Ignorance is really a killer of faster HANA adoption;

3   - with a customer that has been in production for about 2 years, that we tried to have him adopting a TDI scenario last year, we got to meet him again because he found out that the cost of operations to sustain their SLAs, and the cost of change derived from their business growth and evolution, was just too much as a consequence of having implemented the appliance with internal storage only. It took almost 2 years for them to agree with me, and that the OPEX of operating that scenario over 5 years would far exceed the CAPEX saving of buying that appliance. More, in their case, 1 year was enough for their increase in OPEX to exceed their saving in CAPEX. Being glad to hear them say "you were right", even if it was almost 2 years later, I have to say it could have been avoided. I don't feel better with my ego, just sorry they had to go through such pain. Again here, ignorance and fear of the unknown was a key road blocker to adopt HANA more extensively in their datacenter. Implementing HANA, and operating HANA against aggressive SLAs are two very different things, and more education on what operations implies might do some good to many of the people talking to customers to adopt HANA. I'm so glad for the time I worked on operations. Priceless learning!

So, let me - once more - based on these real customer experiences explain the rationale of implementing TDI infrastructure for SAP HANA, and why virtualization makes sense for many scenarios.

Stay tuned as I'll bring to my blog the arguments learned from these 3 customer engagements, so that other customers starting now this journey, can learn from them, and also force the hand of the consultants their are working with, fighting back the ignorance that keeps delaying HANA adoption, or making it way more expensive than it could be.

Do not let the ignorance on what is possible today, complicate your journey towards HANA adoption!

Mind Blowing Possibilities with XtremIO for SAP Application LifecycleManagement

Some weeks ago, meeting with the SAP Functional and Development teams of one of our global partners, I had one “Eureka” moment.

It all started with a discussion about what do SAP Functional and Development teams complain more when interacting with infrastructure teams. And the team immediately started to list those things.

They said: “it’s always the same things, on every customer, on every project, being on implementation phases or on maintenance phases”.

And this took me to one unexpected journey of discovery how one technology can really transform the way organizations have always thought of SAP Application Lifecycle Management activities, and remove the “accepted limitations” they were thought to live with.

I’m not much into talking about specific Infrastructure Technologies, but this one blew my mind, and I’m sure many SAP Customers, that will need to keep operating their Netweaver Systems ABAP still for many years to come (because moving to HANA will still take time), will realy appreciate this perspective.

It's all about making simpler all the process involved in getting new code to production, and helping organizations get faster to market. In the SAP world, this process of moving code from development down to production is called Application Lifecycle Management, and through this post I'll be sharing my reflections together with SAP Functional consultants from System Integrators and customer organizations on how EMC XtremIO is unique in transforming this process.

So, where it all started? On one of those meetings where you think that you might got there by mistake…

I was planning to go and meet the SAP Basis team, and I found in the room the guys from SAP functional consulting and SAP application maintenance.

               The Business Challenges

Stepping back a bit, and to provide a bit of context, there is always a tension between what Functional Consulting teams want, and what infrastructure teams deliver. And Functional Consultants keep seeing their plans delayed or complicated because infrastructure teams say: what you want is not possible.

Why infrastructure teams say it’s not possible? Because they either don’t have available infrastructure resources for what they are being asked, or don’t have the budget, or don’t have the time to do it in the requested frequency or time window.

So, Functional teams keep asking, and infrastructure teams keep saying no. No good working relationship will come out of this, right?

What kind of challenges do SAP Functional Consultants face that makes them put so much pressure on infrastructure teams?

• The business users always want information faster, and including the most recent data;
• New business initiatives always come to application teams with aggressive deadlines;
• So, being opening a new store, launching a new product, opening a new online channel, updating pricing rules, or whatever configuration is asked, the business always wants is faster in production than development teams can do it.

This is normal in today’s economy where competitiveness is ever increasing, with global markets, real time connected, and where being the first to market may make or kill a business initiative.

It’s here that concepts like “Agile Development” and “DevOps” are being looked at.

And SAP Functional consultants are the ones dealing with the business owners on a daily basis, having to respond with quality and in time to the ever changing business needs. They are the first face of IT to the business users, and they suffer a lot whenever they have to say no, take more time than acceptable, or miss a deadline.

So, it is important to understand the pain these people suffer with their “internal customers” (the business users), to be able to really do something in IT that is meaningful to the business.

               The IT Challenges

Being today working for an IT Infrastructure company, I wasn’t there just for the fun of chatting about life, so the conversation continues in my intent to find opportunities to help them help their customers.

So, further ahead in the conversation I asked: and does infrastructure impact your ability to meet those requirements in any way? Remember that for SAP Application Teams, infrastructure is the SAP Systems Administration Teams (also known as the Basis Team).

And that’s where the conversation got interesting infrastructure wise!

They mentioned things they would like infrastructure teams (meaning the Basis Teams) to provide them, which they almost never get. And started by saying “it’s always the same 5 or 6 things”:

1. Batch Performance in Production is never good enough from the end user perspective;
2. Be able to have large datasets in non-production systems for better unit testing is always a challenge as there is no space on those systems;
3. Being able to have a freshly updated Test system with a full copy of production data for more comprehensive testing, as many times the cost and time to refresh test systems is so much, that they are only update every 3 or 6 months and they would like to have it every week;
4. Being able to deploy Sandbox systems fast to explore new functionalities, as some times they get questions from the business, and not being sure if that is available on a new version or a new component they haven’t installed yet. So being able to spin up Sandbox systems fast and cheap would be great;
5. Being able to take a “photo” of the test system before a “potentially destructive test”, and then be able to roll back that test system fast and as many times as needed to that picture until the problem is solved, as indeed many times problem solving, due to time pressure is done through trial and error;
6. Being able to do load and report testing on non-production systems with similar runtimes as production systems, as sometimes processes that in production take 1 hour, in non-production take 10 hours, implying longer test cycles.

This is very interesting as it’s not often that you are able to map the business value of a component very low in the infrastructure stack, and these things can really make a difference in a company’s competitiveness.

Here you could say: but this is all just a matter of buying some new or upgrade/expand the existing infrastructure.

               The balancing act of Cost and Benefit

Then, why don’t companies just buy new technology components or expand existing one’s capacity? Why have SAP Application Teams learned to live with these limitations?

Sometimes "we techies” forget that organizations don’t buy technologies just because they are the fastest, better or coolest! Organizations buy IT to serve business purposes, so there need to be a business rationale in every investment decision.

And things are as they are – not as good as the business users would like – because there is an associated cost. Here companies try to find a balance between the total cost of ownership (the purchase cost of a technology plus the cost of operating it), and the expected business impact / benefit of having it or not.

In the end, you invest in production to have a reasonable platform the business can live with, and you minimize as much as possible the investment in non-production systems as the perceived value is minimal. At least until the pain I described starts to hit hard the business.

               The value of XtremIO for SAP Application Lifecycle management

And this brings me to my breakthrough. My “eureka” moment. And I say this, because all of this impact was not completely obvious to me until I had those discussions.

XtremIO can really address the Business Challenges I’ve described above, and overcome the IT limitations they imply in a very cost effective way.

I wouldn’t be able to explain in detail here the architecture of XtremIO and each of its functionalities, and there are better people to do that than me.

So, let me instead focus on what XtremIO functionalities mean to each of the 6 challenges I mentioned above.

I’ll go into the details here, so this will be a bit long, but hopefully will help both SAP Applications Teams, SAP Basis Teams and Infrastructure teams understand what this means for each of them:

1. Batch Performance:
1. Most companies still have the majority of their systems on rotating disks. And no matter how good they are, they are never as fast as the business would like.
2. XtremIO by being an all-flash array, it will automatically speed up the system performance.
3. The numbers we are seeing show 2 to 3 times performance improvement in batch processing (so a 1 hour job going to 30 or 20 minutes), and this without any application migration, performance tuning or other change from the operating system upwards of any kind.
4. Meaning, getting this kick costs little to nothing.
5. Two important notes: the more a batch job depends on physical database reads, the better the improvement. So any type of processing on SAP Systems with very low “DB Time” (DB Time is well known to SAP Basis teams, is measured in transaction ST03 for SAP Systems based on Netweaver ABAP, and represents the part of the total run time of a process that was dependent on database response), will see little improvement.
6. The other note to “little to no cost”. Here I’m thinking about the cost that represents things like OS/DB migrations and ABAP code changes due to upgrades, which is often way bigger than the cost of an infrastructure component. So, not having to do anything at the application level is a huge cost saving. Of course there is always the cost of the system, and the downtime of implementing it, as doing infrastructure projects always implies at least a little downtime.But here the costs are in line with other investments on rotating disks, an the downtime will be minimal.
2. Large Datasets on Development and Quality Assurance systems:
1. SAP Basis consultants have learned to make copies of data in many ways:
1. Remote Client Copy;
2. Export/import;
3. Using SAP Test Data Migration Server (TDMS);
4. And through database specific tools.
2. In many customers refresh of data wasn’t done at all, or not often enough because of one of the following:
1. There was simply no space on the non-production system to hold the production database;
2. On development systems, overwriting the database might make the customer to lose the version history of developments which is a problem in terms of compliance for many organizations;
3. Due to one of the 2 above points, they used copy methods that had very long run times, or had an impact on production, and so needed to be planned carefully as might imply either unavailability of production, or severe limitation on production usage during the copy.
3. XtremIO Deduplication feature makes that a copy of a disk volume, occupies no space on the storage. So, if you write the same block at the storage level 3 times, you only occupy the space of 1, not 3.
1. This means that the space limitation ceases to exist. You can copy things as large as you want, as many times as you want, and you will only occupy the space of the source.
2. On development systems, there are procedures from SAP to export those things (version history of ABAP objects, etc) and I’m planning to do a bit more research on that, and maybe write a blog post on it. Nevertheless, for environments where this is not a constrain (or new implementations), now customers can also build a new development system from a copy of production.
3. The only caveat here is if the customer has strict confidentiality requirements, and uses SAP TDMS or equivalent solutions to scramble the data. In this case XtremIO will only help by speeding up the reads on the source system and the writes on the target – so speeding up the overall copy procedure, but would not provide the deduplication benefit. The systems would still occupy the full space.
3. Regularly updated test systems with full copies of production:
1. The pain here comes from 3 things:
1. Most of the times production is one 1 Tier1 storage array, and non-production systems are on another Tier2 storage array. So, copying multi-terabyte databases from one array to the other is heavy lifting.
2. Many times, the Tier2 storage system doesn’t have enough capacity to hold the production database. It’s very rare to find a customer with databases larger than 10 TeraBytes that have the same space on their Development, Quality Assurance and Pre-production systems.
3. Copying an SAP Database from production to a non-production environment is not only about copying the storage volumes, as there are a number of tasks that need to be done at the database and ABAP level to repurpose the system and have it ready for testing.
2. And XtremIO addresses these 3 things:
1. XtremIO’s architecture when you make a copy of a disk volume, due to its deduplication feature, it only creates pointers, does not copy the data. So, being on the same array, you don’t have neither movement of data neither read/write of data to copy it. It’s just like taking a photo of the data: takes seconds! I’ve tested in the lab and seen it at work. Amazing! Also, if you study the architecture of XtremIO this will become obvious to you.
2. The system deduplication mechanism also makes that, when you create a copy of an existing database at the storage level, as it is an exact copy, will be fully deduplicated, so not consuming any space at the storage level. Yes, this is true, and no, it doesn’t imply an impact on performance of the production database. Of course as you start to change the data on the copy, the changes will start to occupy space on the storage, but my experience as a customer shown that the volume of changes in a non-production system is always very low. So, maybe, just with a max of 10% of the total size of the database, you can have a full copy of production! Lab testing showed that creating 3 additional copies from 2 source databases (one with 340 GB and the other with 126 GB), ocupied only additional 7GB after all the ABAP post processing was completed (BDLS included - SAP Basis teams know what I'm talking about). So instead of going from 466 GB to 1272 GB, we went to 473 GB. How cool is that?
3. And last but not least, is now under development the integration of XtremIO with SAP Landscape Virtualization Management software. For those who don’t know about it, is an SAP software that orchestrates all the steps involved in an “homogeneous system copy” process, including the ABAP post processing. So, it will enable to realy have a copy if the system with the click of a button. And in minutes (or few hours depending on how many tasks have to be performed in the ABAP post processing).
4. Easiness to deploy sandbox and training systems:
1. In many customers, applications teams cannot just get a system to play around. And one reason is because building a new system consumes resources.
2. Now imagine that:
1. With XtremIO deduplication, new copies of existing systems consume little to no space on the storage;
2. If you are running virtualized, you can deploy this system overcommitting RAM and CPU (so with little or no resource contumption) as it is intended or a single user or few users just to learn or “play around”.
3. And if you add automation with LVM, even the effort of building the system goes away.
3. So, wouldn’t this change the way development and application teams have worked until today? 
1. True that in many cases doing a client copy, and building a new client was a way to solve some of these things, but didn’t provide the opportunity really to go around and change also repository objects. 
2. This way, there would be no restrictions, since SAP LVM also has a “system destroy” option to then delete the system once it is no longer needed. And this would take me into “cloud discussions” and things like self-service portals… but will focus at this stage only on the enabling technologies, from an affordability point of view.
5. Being able to rollback a system fast and as many times as needed:
1. This has implications way further than just test systems, as it can be applied to backups of production systems, build of parallel landscapes for projects like SAP system version upgrades, and also backup of non-production systems.
2. Again, the magic here comes from XtremIO deduplication and snapshot functionality, which works in a unique way in the market.
3. Since doing these operations consumes little to no capacity, and have no performance impact, it opens endless possibilities, as you can create as many copies as you want (of course within the limits of the XtremIO specifications) for whatever purposes you want. So, you would have production grade backup through storage snapshots for all production and non-production systems at “no-cost”. And no cost I mean that these copies do not occupy space or impact performance, which is a major constrain on traditional systems.
4. Also the fact that the system has a very intuitive and simple graphical user interface, makes it easier, faster and less risky to perform these operations. No risk of the storage admin run the wrong command and impact production.
6. Being able to do testing in non-production with production alike performance:
1. Repeating myself here, the magic comes from the snapshot technology that XtremIO uses, it’s deduplication feature implementation, and the fact that it is all flash.
2. This allows the copies of the productive disks to perform as well as the originals. So, testing will be much faster as well.

Conclusion: having infrastructure teams say YES, and drive innovation

So, I truly think XtremIO is a “game changing” technology, and is disruptive in the way it allows to challenge long time limitations and constraints on SAP Application Lifecycle Management tasks.

It took me these interactions with SAP applications stakeholders to get this “Eureka”. 

I’ve been digging on XtremIO for professional reasons since June last year, but I was struggling to see the uniqueness, and especially for the SAP world. Ok, it is fast and has lots of cool features, but looking at it from the SAP Applications Perspective, so what? What is different or unique compared with other technologies in the market?

In the end this is all about having Infrastructure teams being able to say YES to more of the requests they get from the functional teams, enabling the functional teams to serve better the business users, and so driving better time to market, and in the end, better business agility.

And having already shared this with other persons in customer and partner organizations, validated my reasoning. XtremIO is really unique in the market from this perspective.

One Applications Director at an organization I spoke with told me that this would enable him to shorten dramatically SLA’s with the business in regards to response time of requests for change, while reducing the costs of “unit testing” and “end user training” dramatically.So, he would fund an infrastructure project to get the SAP Systems on it, as the benefits were tremendous for them.

There is a lot more I could say on XtremIO, but my goal here was not to make a technology review, but rather – leveraging my knowledge on XtremIO architecture, together with my knowledge and experience on SAP Systems Operations and Applications Lifecycle Management – to show how a technology can indeed transform for the better an organization in terms of iits business agility.

A final though: another customer saw this as an outstanding opportunity to take out cost of his current operations costs (both at application maintenance level and on infrastructure operations), to release budget to invest on new initiatives, like funding the adoption of SAP HANA.

Closing by saying: it will still take some years for customers to migrate all their systems to HANA, and being able to improve them at these many levels, with no application changes is of tremendous value for many organizations.

If you want to know more about EMC Engineering testing with XtremIO, just read the latest whitepaper I've worked with EMC X-BU Engineering on the topic, that you can find at: http://www.emc.com/collateral/white-papers/h13859-xtremio-sap-wp.pdf
 

Glad to be back to blogging after some crazy months overloaded! Hope to come back soon, again on my favorite topic: HANA!