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!

The future for SAP HANA Productive on VMware is now! #LowerTCO

I'm watching live the SAPPHIRE keynote speech from Bernd Leukert, and on one side, VMware's CEO Pat Gelsinger comes live through satellite, and at the same time, one tweet led me to an SAP Press Release...

Wow!!!!

Awesome news!

Let me list them all:

1. SAP HANA on VMware, in a single productive VM per physical host is now Generally Available;
2. SAP HANA on VMware with multiple productive VMs per physical host is now released as Controlled Availability;
3. VMware plans to release early in 2015 a new version of vShpere supporting up to 4 TB of RAM in a single VM, which will enable productive HANA systems to leverage that! Just a few months away.
4. VMware is also closely working with SAP to support SAP HANA scale-out in production across multiple VMs.

So, I have to say, to all those system integrators and customers who were waiting for this... if you haven't started yet, the time to start with SAP HANA on your organization is now!!!

Keep a close eye on the following SAP notes:

•  https://service.sap.com/sap/support/notes/1788665 SAP HANA Support for VMware vShpere Environments
•  https://service.sap.com/sap/support/notes/1995460 SAP HANA on VMware vShpere in Production (controlled availability)
•  https://service.sap.com/sap/support/notes/2024433 Multiple SAP HANA VMs on VMware vShpere in Production

Check out all the great add-ons EMC can bring to the table either through the SAP HANA Tailored Datacenter Integration program, or by leveraging the most advanced converged infrastructures from VCE. Read more about this on my blog post here: http://sapinfrastructureintegration.blogspot.com/2014/06/negative-roi-when-considering-sap-hana.html