An ongoing discussion about SAP infrastructure

The hype and the reality of HANA

Can you imagine walking into a new car dealership and before you can say anything about your current vehicle and needs, a salesperson  immediately offers to show you the latest, greatest and most popular new car!  Of course you can since this is what that person gets paid to do.  Now, imagine the above scenario where the salesperson says “how is your current car not meeting your needs?” and following it up with “I don’t want you to buy anything from me unless it brings you substantial value”.  After smelling salts have been administered, you might recover enough to act like a cartoon character trying to check your ears to make sure they are functioning properly and ask the salesperson to repeat what he or she said.

The first scenario is occurring constantly with SAP account execs, systems integrators and consultants playing the above role of new car salesperson.  The second rarely happens, but that is exactly the role that I will play in this blog post.

The hype around HANA could not be much louder and deep than it is currently.  As bad as it might be, the FUD (Fear, Uncertainty and Doubt) is worse.  The hype suggests that HANA can do everything except park your car since that is a future capability (not really, I just made that up.)  At the very worst, this hype suggests a vision for the future that, while not solving world hunger or global warming, might improve the operations and profitability of companies.  The second is more insidious.  It suggests that unless you act like lambs and follow the lead of the individual telling this tale, you will be like a lost sheep, out of support and further out of the mainstream.

I will address the second issue first.  As of today, the beginning of August, SAP has made absolutely no statement indicating they will discontinue support for any platform, OS or DB.  In fact, a review of SAP notes shows support for most OS’s with no end date and even DB2 9.7 has an end of support date that is several years past that of direct standard support from IBM!  So, what gives???  Is SAP saying one thing internally and another externally?  I have been working with SAP for far too long and know their business practices too well to believe that they would act in such a two-faced manner not to mention exposing themselves to another round of expensive and draining lawsuits.  Instead, I place the arrow of shame squarely on those rogue SAP account execs that are perpetuating this story.  The next time that one of them makes this sort of suggestion, turn the tables on them.  Ask them to provide you with a statement, in writing, backed up with official press releases or SAP notes, showing that this is the case.  If they can’t, it is reasonable to conclude that they are simply trying to use the age old FUD tactic to get you to spend more money with them now rather than waiting until/if SAP actually decides to stop supporting a particular type of HW, OS or DB.

And now for the first issue; the hype around HANA.  HANA offers dramatic benefits to some SAP customers.  Some incarnation of HANA may indeed be inevitable for the vast majority.  However, the suggestion that HANA is the end-all be-all flies in the face of many other solutions on the market, many of which are radically less expensive and often have dramatically lower risk.  Here is a very simple example.

Most customers would like to reduce the time and resources required to run batch jobs.  It seems as if there is not a CFO anywhere that does not want to reduce month end/quarter close from multiple days down to a day or less.  CFOs are not the only ones with that desire as certain functions must come to a halt during a close and/or the availability requirements go sky high during this time period requiring higher IT investments.  SAP has suggested that HANA can achieve exactly this, however it is not quite clear whether this will require BW HANA, Suite on HANA or some combination of the two or even another as yet unannounced HANA variant.  I am sure that if you ask a dozen consultants, you will get a dozen different answer to how to achieve these goals with HANA and it is entirely possible that each of them are correct in their own way.  One thing is certain however: it won’t come cheaply.  Not only will a company have to buy HANA HW and SW, but they will have to pay for a migration and a boatload of consulting services.  It will also not come without risk.  BW HANA and Suite on HANA require a full migration.  Those systems become the exclusive repository of business critical data.  HANA is currently in its 58th revision in a little over two years.  HA, DR and backup/recovery tools are still evolving.  No benchmarks for Suite on HANA have been published which means that sizing guidelines are based purely on the size of the DB, not on throughput or even users.  Good luck finding extensive large scale customer references or even medium sized ones in your industry.   To make matters worse, a migration to HANA is a one way path.  There is no published migration methodology to move from HANA back to a conventional DB.  It is entirely possible that Suite on HANA will be much more stable than BW HANA was, that these systems will scream on benchmarks,  that all of those HA, DR, Backup/Recovery and associated tools will mature in short order and that monkeys will fly.  Had the word risk not been invented previously, Suite on HANA would probably be the first definition in the dictionary for it.

So, is there another way to achieve those goals, maybe one that is less expensive, does not require a migration, software licenses or consulting services?  Of course not because that would be as impossible to believe as the above mentioned flying monkeys.   Well, strap on your red shoes and welcome to Oz, because it is not only possible but many customers are already achieving exactly those gains.  How?  By utilizing high performance flash storage subsystems like the IBM FlashSystem.  Where transaction processing typically accesses a relatively small amount of data cached in database buffers, batch, month end and quarter close jobs tend to be very disk intensive.  A well-tuned disk subsystem can deliver access speeds of around 5 milliseconds.  SSDs can drop this to about 1 millisecond.   A FlashSystem can deliver incredible throughput while accessing data in as little as 100 microseconds.   Many customers have seen batch times reduced to a third or less than what they experienced before implementing FlashSystem.  Best of all, there are no efforts around migration, recoding, consulting and no software license costs.  A FlashSystem is “just another disk subsystem” to SAP.  If an IBM SVC (SAN Volume Controller) or V7000 is placed in front of a FlashSystem, data can be transparently replicated from a conventional disk subsystem to FlashSystem without even a system outage.  If the subsystem does not produce the results expected the system can be repurposed or, if tried out via a POC, simply returned at no cost.  To date, few, if any, customers have returned a FlashSystem after completing a POC as they have universally delivered such incredible results that the typical result is an order for more units.

Another super simple, no risk option is to consider using the old 2-tier approach to SAP systems.  In this situation, instead of utilizing separate database and application server systems/partitions, database and app server instances are housed within a single OS system/partition.  Some customers don’t realize how “chatty” app servers are with an amazing number of very small queries and data running back and forth to DB servers.  As fast as Ethernet is, it is as slow as molasses compared to the speed of an inter-process communication within an OS.  As crazy as it may seem, simply by consolidating DB and app servers into a single OS, batch and close activity may speed up dramatically.  And here is the no risk part.  Most customers have QA systems and from an SAP architecture perspective, there is no difference in having app servers within a single OS compared to on separate OSs.  As a result, customers can simply give it a shot and see what happens.  No pain other than a little time to set up and test the environment.  Yes, this is the salesman telling you not to spend any money with him.

This is not the only business case for HANA.  Others involve improving reporting or even doing away with reporting in favor of real-time analytics.  Here is the interesting part.  Before Suite on HANA or even BW HANA became available, SAP had introduced real-time replication into side-car HANA appliances.    With these devices, the source of business critical data is kept on conventional databases.  You remember those archaic old systems that are reliable, secure, scalable and around which you have built a best practices environment not to mention have purchased a DB license and are simply paying maintenance on it.  Perhaps naively, I call this the 95-5 rule, not 80-20.  You may be able to achieve 95% of your business goals with such a side-car without risking a migration or the integrity of your data.   Also, since you will be dealing with a subset of data, the cost of the SW license for such a device will likely be a small fraction of the cost of an entire DB.  Even better, as an appliance, if it fails, you just replace the appliance as the data source has not been changed.  Sounds too good to be true?  Ask your SAP AE and see what sort of response you get.  Or make it a little more interesting and suggest that you may be several years away from being ready go to Suite on HANA but could potentially do a side-car in the short term and observe the way the shark will smell blood in the water.  By the way, since you have to be on current levels of SAP software in order to migrate to Suite on HANA and reportedly 70% of customers in North America are not current, (no idea of the rest of the world) so this may not even be much or a stretch.

And I have not even mentioned DB2 BLU yet but will leave that for a later blog posting.


August 5, 2013 - Posted by | Uncategorized | , , , , , , , , , , , , ,


  1. There are some interesting points in this blog, but based on the below it does not seem that many people view IBM pSeries as a platform that is growing.

    Intel commodity servers seem to meet most customer requirements.

    Comment by former pseries admin | August 20, 2013 | Reply

    • Growth or lack thereof does not necessarily imply relevance or what platform is best at addressing business needs. Let us consider revenue numbers. According to the just published IDC 2Q13 revenue estimates, IBM Power Systems showed a revenue of $4,992M over the last 4 quarters. That is more than HP x86 servers at $2,814 or Dell x86 servers at $2,176M. Those are very good numbers for x86, but still, Power is almost twice the revenue of the nearest competitor. Intel commodity servers can certainly be valuable in many customer situations, but to say that it meets most requirements is not backed up by facts. Some customers require secure systems. According to Solitaire Interglobal Ltd, a very well regarded data analysis company that uses a vast array of customer submitted data to derive the results they share, customers using Power Systems showed almost no SAP system breaches compared to between 5 and 30 (depending on size of customer and which x86 vendor) over a 3 year time period. Some customers require SAP systems to be available at all times. Solitaire also determined that customers using Power Systems delivered up to 4 times less SAP Application Downtime than those using HP or Dell. I could go on, showing lower TCA, lower TCO, better executive, end user and IT satisfaction, lower risk, etc., but I think it is clear that meeting low customer requirements are easily achieved by x86 systems, but meeting the demands of customers that are betting their businesses on SAP is best accomplished using IBM Power Systems. Please take a look at the recently updated Solitaire analysis at for more details.

      Comment by Alfred Freudenberger | August 29, 2013 | Reply

  2. Interesting discussion …I am that SAP salesperson that suggests to my clients to try HANA, understand the architecture moving forward and establish the value proposition before buying anything. There are more sales people like me than represented in the first paragraph – Believe it!

    Additionally, I have personally seen the technology piloted/proven at a client with a large (70,000 user+) SAP implementation. The results were astonishing.
    – actionable analytics that were never possible previously (they had tried other approapches such as the ones suggested above)
    – daily batch processing time from many hours to just a few minutes for large & complex data models
    – data modelers/analyst productivity was off the charts – no disruption in most cases – no additional BI tools needed to be introduced
    – revealed a new and safe method to deliver real self-service and lightweight analytics to the masses (data visualization/exploration/collaboration etc)
    – many many other use cases were identified by the client such as MDM/data cleansing, customer segmentation, complex scenario analysis(predictive), distributed planning and forecasting, customer engagement …etc..

    I have to agree that sidecars are a safe place to start with all the benefits of a path to an integrated transactional and analytics data tier (aka full Suite on Hana) in the future…good suggestion.

    I would suggest to readers seeking more on HANA, the real level of risk, the business problems it solves (and coincidentally the benefits of the INTEL based hardware platform) that it is worthwhile to explore customer testimonials on the topic before digesting the facts and risk assessment made in this article. Furthermore, I would take a look at IBM’s X Series hardware family. The IBM X Series HA and DR implementations are worthy of consideration when evaluating an overall total cost of ownership.

    or )

    Comment by sapcarsalesman | September 29, 2013 | Reply

  3. To sapcarsalesman,

    Faster analytics can be achieved with other columnar technologies, such as DB2 with BLU acceleration to name one. SAP could also use stored procedures to massively speed up batch processing times on databases other than HANA. It doesn’t because SAP needs the competitive advantage of doing this only for HANA database. For high volume OLTP workloads HANA has a performance problem, it has an architectural disadvantage being primarily designed for analytics.

    People who have worked with HANA in the field also tell me it remains immature and has many problems, despite SAP boasts.

    HANA Skeptic

    Comment by HANA Skeptic | March 8, 2014 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: