Infrastructure Architecture for SAP HANA and S/4: one customer example

By suggestion of some friends, I've broken the My previous blog post on SAP HANA TDI KPIs in two parts, to give the proper highlight to the architecture considerations I included in the second part of the original version of this post. This is part 2.


          Part 2: One customer example to illustrate

A concrete example: I talked with a customer that was evaluating the migration all his SAP landscape to HANA (not decided yet, just calculating the implications). He had about 45 productive Netweaver based systems, in a total (if I remember well) of about 180 SIDs. Within these, there are 3 productive systems where there are massive data loads, and so write performance is critical. But for all the others, there aren't that many data loads, and the most critical aspect is read performance.

His biggest challenge was to achieve a positive ROI, and the initial architecture proposals we got from some players, fully based on appliances with HANA System Replication for all productive systems, would simply not fit the business case. So he wanted to find ways to build a more economic architecture, while ensuring appropriate service levels to his business.

My suggestion was to define as a standard, a virtualized architecture on top of a stretched cluster replicated across 2 datacenters at a "metro distance". For you more knowledgeable in infrastructure, the replication between the sites was already being done using EMC VPLEX Metro.
This architecture would most likely serve for 177 of his 180 systems.

This architecture drove major cost savings, and depending on how much saving the customer wanted to draw out of this scenario as well as the distance between the 2 replicated datacenters, it might happen that some of the SAP HANA VMs might not fulfill all the TDI KPIs. And that is no big deal, as this kind of compromise is already happening today in the Netweaver world, and is good enough for organizations, better when put in perspective with the major savings achieved.

Then as the other 3 were an exception, we came to a discussion in regards to what would be the acceptable balance between performance and data resiliency.

If you want zero Recovery Point Objective (RPO), meaning no data loss, there is no other way that to implement some sort of synchronous replication. Being the replication done at the storage level or through HANA System Replication, you'll always suffer the impact of the network latency.

If you cannot compromise performance because the load on this system will be massive, no way you'll be able to replicate synchronously to a datacenter at a "metro distance" as the network latency will always add up degrading SAP HANA write performance.

Then, you need to evaluate your specific business scenario, and define which is the best compromise.


          2 Step SLA as a compromise solution for the "performance and availability" paradigm

Through the discussion I suggested him then to define a "2 level SLA":

• One SLA for single component failure within a datacenter;
• And another SLA for a full site loss.

When you build resiliency into your architecture, what you're doing is putting in place a contingency for a business risk.

All risks are a factor of probability and impact.

So, the probability of a single component in the datacenter infrastructure failing is very high, but if you design properly the systems, the impact can be minimal.

Also, the probability of loosing a full datacenter is very low, although the impact would be massive.

So, maybe the RTO and RPO you would be willing to accept in these two scenarios would be different, as if you lose a full site, maybe this is a major disaster, and it might even imply that your customers would be out of business as well, so you need to evaluate how much are you willing to spend to put a contingency in place, or whether is acceptable to reduce your SLAs and complement them with an insurance policy for unexpected losses.

In the end, all this discussion goes back to ensuring that you fulfill business needs, while at the same time you ensure that the TCO of your solution doesn't become bigger than the business benefits of it.

This then opened the following possibility as a more costly one, but one that would balanced the extreme availability and performance requirements of these systems. Doing this for the few systems that "really required such extreme characteristics" enabled a major cost saving on all the other systems included in the above defined standard (the virtual Datacenter).

To protect from a single component failure, it could be implemented SAP HANA synchronous replication with "in-memory pre-load" option, ensuring zero RPO and near zero RTO (less that 1 minute for sure). This would be done across 2 servers in the same datacenter, to ensure minimal performance impact.

For full datacenter loss, then one of the systems would be replicating asynchronously at the storage level to the secondary datacenter. The calculated RPO would be less than 1 minute and the calculated RTO would be less than 15 minutes, ensuring an acceptable SLA, with minimal performance impact, and also reducing the TCO by allowing the utilization of the system on the replicated datacenter to be used for "pre-production testing" in normal operations.


          Conclusion

Not all business systems are alike, and not all have the same business requirements. Being them running on SAP HANA or not!!!

This implies that the technical requirements will not be the same to all these systems either.

By defining a standard for the majority of the SAP HANA and Netweaver systems based on Virtualization and Mirrored Datacenters with VPLEX, this organization would achieve a very flexible architecture, easily manageable, with a very high utilization of assets, and so with a very high service level at a very affordable cost.

Even if some of the systems would not fulfill all the TDI KPIs, it is not a big deal, as all this KPI discussion is one of "performance" and not of functionality, or even support as stated in SAP's documents referenced in this blog.

Then exceptions were evaluated for what they are: EXCEPTIONS!

And specific solutions were design according to the business requirements.

So, again, SAP HANA is becoming a normal application in the datacenter! Make sure to keep up to date on the current rules and conditions to ensure the most suitable architecture to your organization, not only from a performance perspective, but also from a data resiliency, availability, CAPEX and most of all OPEX, as its OPEX you'll be living with for the rest of your solution life.

Being this just one example, I hope this helps others going through the same discussion.

SAP HANA TDI KPI: mandatory or indicative? And what about the network implications on Synchronous replication?

By suggestion of some friends, I've broken this blog post in two to give the proper highlight to the architecture considerations I included in the second part of the original version of this post. That seccond part is now published at: http://sapinfrastructureintegration.blogspot.com/2015/10/exceptions-are-exceptions-one-example.html


          Part 1: The current facts

I've been receiving a lot this question: when I have SAP HANA either with storage or HANA System Replication in a synchronous mode, depending on the network latency, it will not meet the TDI KPIs. Will SAP accept this? What would be the performance impact at an application level?

The question came as this customer wanted all the performance he could get, but also the maximum data resiliency technology could provide today.

In a nutshell, there are certain situations that the "Laws of Physics" do not allow you to have all you want, and you need to chose: either the maximum performance, or the maximum data resiliency.

So, going through this reasoning I first collected the currently available information from SAP in this regards, just to reach the conclusion that "YES it is acceptable to fail KPIs" as SAP says "its the customer's decision to define whether the performance penalty is acceptable to his specific business scenario". Then, I entered a discussion with him on finding the right balance between technical and business requirements for his architecture blueprint.

Where did I get the information that it is acceptable to fail KPIs?

Let me share here what I wrote some weeks ago to a customer with a question in regards to what latency is accepted when doing storage replication, as a competitor was telling him that if he had storage replication and did not fulfill all the TDI KPIs, he could not run any production workload on that infrastructure, which is FALSE!

Then, I'll also share the reasoning that followed after getting this question cleared up, by providing a concrete customer example I hope helps you build your own reasoning in case you're going through a similar discussion in your organization as well.

          Network latency impact on SAP HANA performance when replicating synchronously

Indeed the network latency will be a critical factor on SAP HANA performance. But it is both for storage replication in the same way it is in the case the customer decides to implement SAP HANA System Replication in synchronous mode.

My advice here is to carefully evaluate what is the latency between the two sites being synchronously replicated. Ideal is in fact for latency to be below 1ms. More than that can really start to impact write performance, so if the customer application will have massive data loads, the data load time can become longer because of this. There will be tough, absolutely no impact on the read performance as it is done in the memory of the server. So depending on your application specific workload profile, you may feel a lot this increased latency or nothing at all.

In the end, all the details are on SAP’s Whitepapers.
There are two in particular relevant to this matter: The SAP HANA Network Requirements whitepaper: http://scn.sap.com/docs/DOC-63221
In page 28 it says:

• There is no straightforward recommendation regarding the bandwidth and the latency a system replication network must provide. A rough estimation of the required performance is given in the How-to Guide Network Required for SAP HANA System Replication, which is referred to from the SAP Note 1999880 - FAQ: SAP HANA system replication
• Latency: The redo log shipping time for 4 KB log buffers must be less than a millisecond or in a low single-digit millisecond range – depending on the application requirements (relevant for synchronous replication only).

This applies to storage replication as well. So, let’s say that if you cannot stay below 1ms, that 2 or 3 ms may be acceptable. But it will depend on your specific business scenario.
Transactional scenarios (like SAP ERP on HANA) are more sensitive to latency. Analytical scenarios are more sensitive to throughput.

Looking at the note mentioned above it sends you in a sequence of documents being the final one: Network Recommendations for SAP HANA System Replication at http://scn.sap.com/docs/DOC-56044
Here, the same as above is mentioned:

• All changes to data are captured in the redo log. The SAP HANA database asynchronously persists the redo log with I/O orders of 4 KB to 1 MB size into log segment files in the log volume (i. e. on disk). A transaction writing a commit into the redo log waits until the buffer containing the commit has been written to the log volume. This wait time for 4 KB log buffers should be less than a millisecond or in a low single-digit millisecond range.

          Even without replication, it is your choice whether is acceptable to fail KPIs

Let me add as a final note the transcript of the response to question 7 on page 7 of the SAP HANA TDI FAQ published at SCN: SAP HANA TDI - FAQ | SCN

There is written:

Q: Which cases where one or more KPIs are not fulfilled does SAP consider as uncritical or acceptable?

• This is always up to the customer to decide if falling below the KPIs is acceptable for his/her daily operation of the SAP HANA system. The customer must decide whether the performance of his/her SAP HANA system is sufficient for his/her needs.
• The following questions and examples might help for making that decision:
  • Is the given SAP HANA system a non-productive system?
    • The KPIs apply for production systems only. In general, for non-productive systems weaker performance is acceptable
  • Which SAP HANA scenarios are run on the given system?
    • OLAP scenarios only (e.g. SAP BW-on-HANA):
      • The performance of queries is usually not affected if all required tables have been loaded into memory
      • Latency times of the log volume and throughput rates for writing the data volume are mainly relevant when loading data from source systems
      • Throughput rates for reading from the data or the log volume affect the overall system restart time (e.g. after applying an SAP HANA revision update)
    • OLTP scenarios only (e.g. SAP Business-Suite-on-HANA):
      • Latency times of the log volume affect the duration of every transaction that changes one or more tables in the database
      • Throughput rates for reading from the data or the log volume affect the overall system restart time (e.g. after applying an SAP HANA revision update)
    • See the Storage Requirements whitepaper for details: SAP HANA TDI - Storage Requirements | SCN

So, as you can see, SAP HANA is really becoming a normal application in the datacenter, and more choice is given to customers every single day. Today, even without replication, it is each customer's choice whether failing certain KPIs is acceptable.

And this is relevant for example when you think on very small SAP HANA systems that are not very critical, that you see more and more as customers make SAP HANA mainstream and migrate every single system to HANA. There may be a couple of systems that are very big and very critical, but there are a ton of others where you could compromise a bit of performance to have a better TCO.

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!

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