SAP HANA - from Analytics Appliance to Vendor Consolidation

[Former Member]

Last week we headed to SAP TechEd 2011 in Las Vegas - the first of 4 TechEd conferences around the world. I thought it might be nice to reflect for a few minutes on one of the big topics that we expect to see out there - and what it means for the wider IT audience.

As we know, SAP HANA 1.0 SP02 as it stands today is just an analytics appliance on crack. I've been vocal about some of the issues that customers are facing during implementations but none of that will matter once SAP start to solve the issues faster than they are being found.

What is truly fascinating is what SAP are planning for HANA, and how aggressive the roadmap is. Because let's be clear, they are planning to build out software which will change the whole face of the IT industry, and if they succeed, I will probably have to suggest that SAP deserved to use the moniker "game changer" and kitties weren't harmed afterall.

SAP HANA as a database

The first thing that SAP plan is to turn SAP HANA into a kick-*** multi-functional database. Right now in HANA 1.0 SP02 there are far too many limitations for this to be true but they are working on it. So far they have built out:

- Columnar storage for good data warehouse performance
- Row storage for good transactional read performance
- Delta mechanisms to offset the poor write performance of columnar storage
- Calculation and execution engines to optimise data warehouse performance
- Persistent storage and writes so the appliance can be powered down

But there's a lot of work to go to make it into a proper database. For instance:

- Disk storage for archives
- ANSI compliance for SQL
- Ability to run as a database for SAP Business Suite
- Planning engine
- Backup, disaster recovery and good administration tools

But let's be clear - if SAP clear all this stuff up, and make it work, they have the potential for a formidable product which outperforms anything out there in terms of cost-to-performance. And that's just from a generic database perspective - so Teradata, IBM and Oracle had better watch out.

SAP HANA as an Application Platform

Because SAP HANA is a 2-tier architecture (app platform and client) rather than a 3-tier architecture like SAP R/3 (database, application server and client), there are benefits that it can bring to bear that haven't been relevant since the traditional mainframe. In the last 20 years, the biggest problem by far that large-scale computing has faced is the ability to move stuff between layers.

None of that I/O performance matters with HANA because everything happens inside the memory of one system - not along lengths of glass or copper tubes. This provides a lot of exciting opportunities because you can build the database, application and everything into a single unit, which will perform better than anything else out there.

What's more SAP HANA as a platform could run multiple Apps, ERPs, Data Warehouses and anything else - all in one big cloud - virtual private cloud, or perhaps - in time - public cloud.

SAP HANA as a Vendor Consolidation Platform

If you look at this logically - what SAP HANA does is to collapse layers. It collapses the application layer with the database layer, which means you don't need to buy your database software from one vendor and your application software from another - you can buy it all from SAP. This is a great simplification of the procurement process and means SAP can make more profit and deliver more innovation for the same license fee. But let's take this further.

At the hardware level there's also consolidation - you buy an appliance which is fixed in its nature. There are currently 5 hardware vendors you can buy HANA appliances from: Cisco, Dell, HP, IBM, Fujitsu. Dell are the kings of commodity hardware and they are currently a disorganised mess around SAP HANA so far. If Dell get their act in gear - and I'm planning on kicking them until they do - this stuff will commoditise fast. It will drive profit margins down to normal commodity and this will ease the barrier to entry.

But this isn't the point: if you want to consolidate with SAP HANA then the only logical outcome is that SAP also provide the hardware - I have written before about why SAP must acquire a hardware vendor. This way it becomes a one-stop-shop to procure hardware, database and application.

And take it a step further, what does it mean for the traditional Systems Implementor (SI)? I predict two models: first, the SI will be the orchestrator, combining SAP, Hardware and Services into the HANA pot pie. The second will be SAP providing a one-stop-shop for everything including - perhaps - a cloud based model - inevitably subcontracting services to SIs. Customers just don't want the confusion of any other model in this increasingly SaaS-dominated world.

Conclusions

Let's be clear - SAP HANA isn't many of the things I've described yet - it's just in its infancy. But if you are going to SAP TechEd 2011 either in Las Vegas, Bangalore, Beijing or Madrid and you are in the technology business, then you need to seriously consider what it means to you. And I highly recommend you learn about SAP HANA early and get into the groove.

The underpinnings for SAP HANA are already in place - the in-memory database is already there and this won't change. So anything you learn today about HANA will be useful to you in the future, and will get you a early-adopter's advantage.