- HANA 2 was introduced by SAP with extreme marketing fanfare.
- What was presented by SAP is not the real reason for the HANA reboot.
HANA 2 was released with great fanfare by SAP, but as time has passed a number of concerning issues have come out regarding HANA 2, its lack of backward compatibility and its issues with lock-in from SAP.
In this article, we will explore these issues.
How SAP Surrogates Explained HANA 2
The following are excerpts from AgilityWorks, an SAP consulting company.
“On the one hand SAP didn’t disappoint, as during his keynote Bernd Leukert made the grand announcement of SAP HANA 2. At the same time, details and information on what this actually is and what it brings were initially thin on the ground, with SAP proclaiming a further massive advancement of database technology and a milestone in the industry, whilst others I spoke to during the week suggested that SAP HANA 2 is actually just the next SPS of HANA to come out of SAP’s normal release cycle.”
We will see later on that this is entirely incorrect. Also, this was not a milestone in the industry.
“Scratching a bit below the surface suggests that the truth is somewhere between those two extremes. HANA has now moved way past its early stages of maturity with many established customers, so SAP are looking to push it forward further and indeed potentially faster than before, whilst still also supporting the large installed base from a stable maintenance perspective. SAP have clearly been considering how best to balance innovation with stability and SAP HANA 2 appears to be their answer.”
There is no reason to accept instability from SAP when better performance with better stability is already available from other DB vendors.
“The very simple answer is innovation. With HANA 2, SAP aren’t releasing ground-breaking technology but instead changing how they release updates to the HANA platform. Yes, HANA 2 will include some new capabilities (enhancements in the areas of system management, data-tiering, predictive capabilities and bring your own language to name a few) but these are essentially HANA SPS 13 capabilities.”
Will this bring HANA 2 up to par with competitive offerings? No.
“What is really changing is SAP enabling customers to choose how they manage their update cycles. Currently, SAP releases a new SPS pack for HANA every 6 months and expect customers to be within 2 SPS levels as part of the terms of their maintenance contract. For some organisations this rate of change is just too much but something they have to manage to retain support, meaning those organisations often have to live with the constant change – this constant change of their core landscape can often kill innovation.”
Innovation as SAP’ Name for Development
Research at Brightwork into HANA indicates that SAP and their surrogates use the term “innovation” to simply mean development. HANA is behind its competitors and is developing more rapidly to catch up. But the correct word for this is not innovation. Here is the definition of innovation.
“Innovation can be defined simply as a “new idea, device or method”. However, innovation is often also viewed as the application of better solutions that meet new requirements, unarticulated needs, or existing market needs.” – Wikipedia
What does SAP have with HANA that other DB vendors did not already have? If SAP has nothing new, but is merely catching up with DB2 and Oracle 12c how is that innovation? Is SAP merely reversing engineering other databases and calling it innovation?
It appears to be the case.
“Whilst SAP will continue to make new SPS packs available on a regular basis for HANA 2, they are also extending the maintenance period for HANA until May 2019. This enables customers who don’t want/need, or simply cannot stomach the rate of change of 2 SPS packs per year, to stick with their current HANA platform for longer, without worrying about keeping up with SPS releases.”
Why is this being sugar coated? Applications and databases are supposed to be upgradable from one version to the next.
Why was HANA 1 a dead end? Was it released too early by SAP?
HANA 1 Released Too Early?
It appears to be the case.
“Essentially, SAP are offering two routes to HANA, hoping that stable customers will welcome the reprieve from a support perspective with HANA, whilst innovators will welcome the ability to take advantage of new features as they are released via HANA 2. It is worth noting that SAP are still recommending customers move their stable HANA platforms to SPS 12 prior to “slowing” the update cycle.”
Again, it is dubious to call anything in HANA 2 an innovation.
“This approach benefits SAP as it continues to ensure customers are on a relatively recent SPS level, which aids SAP’s support functions, whilst at the same time allowing them to deliver innovation and advancement to their database platform. I see many customers taking advantage of this dual model to achieve a bi-modal landscape for their database platforms. They can use HANA to support the stable core and roll out up to date HANA 2 instances as and when needed as the agile layer.”
This is an amazingly positive spin on what is considerable complexity. SAP promised that HANA would simplify the data layer.
Simplifying the Data Layer?
“I do wonder though whether customers will simply look to HANA Cloud Platform to act as the agile layer, taking advantage of an up to date and low impact route to HANA there. Either way, this added flexibility will be a massive advantage for many customers keen to explore more advanced and innovate capabilities without the worry of impacting their BAU landscape. The easing of maintenance efforts in the BAU landscape should also free up resources to be invested into innovative initiatives.”
Very few companies use the HCP. The HCP was introduced as a way to HANA wash various SAP offerings, as is covered in the article Is the HANA Cloud Platform Designed for HANA Washing?
“If you are on a pretty recent release of HANA (i.e. SPS 10 or above) it should be a simple upgrade to get to HANA 2. If you are on an older release SAP recommend migrating to SPS 12 first, then completing the upgrade to HANA 2. Key here is that SAP state it is an upgrade to HANA 2, and not a full on migration, so it should be comparatively straight forward to take advantage of HANA 2.” – Gareth Ryan
But it is not an upgrade. HANA 2 is not compatible with HANA 1, so therefore upgrade is not the correct term. And why is this author convinced there is anything
ASUG on HANA 2
For the false context, it is always good to see what ASUG publishes. ASUG is there to justify whatever SAP does, and the article SAP Positions New HANA Platform Release HANA 2 for Fast Track Innovation
“The aim with the new platform release is clearly to tie HANA more closely into SAP’s overall message of digital transformation. Think of HANA 2 as an underlining from the vendor that its platform can act as the basis for organizations to transform their businesses into fully digital enterprises. Leukert also talks about where HANA 2 fits in one approach to digital transformation, the concept of ‘bimodal IT,’ a term analyst firm Gartner has coined. As an aside, it’s worth mentioning, other research organizations are not so convinced of the benefits of this approach.” – ASUG
Digital Transformation is a meaningless term as is covered in the Brightwork article The Problem With Using the Term Digital Transformation on IT Projects.
Nothing in this paragraph regarding digital transformation makes any sense.
Bimodal IT also is a meaningless term.
“In bimodal IT, an organization operates IT in two separate modes running at different speeds. So, the first mode can be thought of as ‘business-as-usual’ or the ongoing optimization of traditional business processes, while the second mode functions as a rapid, more experimental testing ground for potential new functionality and offerings.
SAP’s idea is that HANA 2 mostly fills that second mode, while an earlier version of the platform fills the first need. “Bimodal IT is exactly what customers are requesting,” Ken Tsai, VP and head of cloud platform & data management, product marketing at SAP, says in a recent phone interview with ASUGNews. “They do want to experiment.”
This adoption of the term Bimodal is how SAP and ASUG are covered up for the instability of HANA 2.
“One important change for ASUG members to note who are already running HANA is a widening of the maintenance window. For the most recent HANA SPS releases, so HANA SPS10, SPS11 and SPS12, SAP will provide maintenance revisions from six months up to three years, Tsai says. For HANA SPS12, for example, SAP will provide maintenance until May 2019.”
ASUG has such a great way of pitching anything negative as a positive. So earlier versions of HANA will be obsolete as of 2019. And according to ASUG, this is magnanimous on the part of SAP.
Way to look out for customers ASUG.
“This extension of the HANA maintenance window was heavily requested by customers. ‘As customers are running mission-critical apps, they don’t want to be forced to upgrade the foundational database every six months,” Tsai says.”
SAP on SAP HANA 2 in the Article 9 Questions Answered
Why are you implementing a product change to SAP HANA 2 rather than releasing SPS 13 for SAP HANA?
“SAP HANA 2, with its extensive range of functionalities, represents a new technological milestone. SAP HANA 2 is even better equipped than SAP HANA to help companies prepare for the digital transformation. The new release management strategy also gives customers more flexibility, as there are now two possible options: The first is the “Innovation Track” with SAP HANA 2, which offers six-monthly updates; the second is the “Maintenance Track”, which guarantees maintenance and security patches until May 2019 for all those customers currently using SAP HANA SPS 12.”
Here we go with the digital transformation. Again, SAP is presenting HANA 2 as a positive.
“For customers with Support Pack Stack 10 and higher, the transition to SAP HANA 2 is straightforward. Customers with older versions of SAP HANA need to perform an intermediary step via SAP HANA SPS 12.”
Here it comes. SAP HANA SPS 9 or lower is a reimplementation.
The Real Story with HANA 2
The problem with HANA was that the standard support answer was to upgrade to the latest version.
But this is not workable for a live production system. For this reason, SAP decided to take a more stable release and freeze it.
And only add new things in HANA 2.
But now for a customer who is going to start implementing, which version should they go for?
And something left out is how stable is HANA 2? Again, it will have to be lower than HANA 1.
HANA 2 was introduced as a new product, but that was just a cover story. If SAP had gone to customers and told them that the copy of HANA they purchase would dead end in 2019, how many companies would have invested. Once again, SAP changes the rules, hides the immaturity of its product, and then has a campaign of misinformation to turn into something positive.
The following is from SAP’s blog where a realistic explanation of HANA 2.
“When I saw HANA 2.0 being released I assumed since it comes from SAP, it will be downwardly compatible and that everything which runs on HANA 1.0 will run on HANA 2.0 .
We’re all familiar with installing SAP systems and when downloading the Installation Binaries choosing the NW version and then the Database (eg Oracle, DB2, SQL Server) and then receiving the Installation Binaries based upon the Software Version & Database combination.
So, it seems the same is true for HANA itself, the HANA 1.0 product and HANA 2.0 product must be so different that NW needs to be written to support either, eg when downloading NW we would choose which Database we intend to run NW on, either HANA 1.0 or HANA 2.0 .
This kind of now explains why HANA 1.0 SPS12 has such a long lifecycle, and will be supported until May 2019, this must be the grace period to enable Customers who have NW 7.4 on HANA 1.0 to
- a) Upgrade NW to a version which supports HANA 2.0 and then
- b) Upgrade HANA to HANA 2.0 –
I had also assumed when I started seeing that HANA 2.0 blogs and marketing information, that HANA 2.0 upon RTC would be supporting NW versions, but it’s curious that HANA 2.0 is out there but currently there’s not even a NW 7.5 which supports HANA 2.0.” – Andy Silvey
The Necessity of Fact Checking
We ask a question that anyone working in enterprise software should ask.
Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?
If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.
In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our Other HANA Problems Content
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model