What did I learn from #SAPonHANA announcement?

[former_member182313]

A few years ago, SAP was making two statements:

1. SAPHANA would replace traditional databases and
2. SAP's goal of becoming #2 DB vendor by 2015.

On Jan 13, 2013, instead of delivering that message in a simple, easy-to-understand language, they chose diplomatic route. By doing so, they,in my opinion, demonstrated a tremendous level of confidence on SAPHANA technology.

I heard SAP's message loud and clear: The customers would be better off with their SAP running on HANA.

This message was based on:

STATEMENT 1

Innovations in the SAP Business Suite, such as push down of data centric processing logic from the application server to database tier via stored procedures would be made available to other databases too making them perform better too.  (Source: A promise delivered - SAP Business Suite Is Now Powered by HANA - Vishal Sikka )

Let us see if this is viable. Dr Hasso Plattner also mentioned three things:

1. Pushing the business logic to DB layer is viable today due to the advances in technology.
2. DB manufacturers would be asked to develop/enhance their product to support new SAP code.
3. Where new way of doing things doesn't make sense, despite (b), existing code would be used for backward compatibility.

Let me explain why I've trouble following this:

The diagram below explains how data is processed today.

On the left side, we've application servers (6 servers in the diagram) to process the business logic. The application servers contain several buffers to minimize the number of accesses to the database. The purpose of buffers is explained by Thomas Schneider's SAP Performance Optimization:

Every SAP instance has various buffers, in which data to be accessed by users is stored. When the data is in the buffer, the database does not have to be accessed, because buffers enable direct reads from the main memory of the application server. There are two advantages to this:

1 Accesses to SAP buffers are normally 10 to 100 times faster than accesses to the database.

2 Database load is reduced. This is increasingly important as your system grows in size

Since the database server is expected to handle minimum essential tasks, the size of that server is smaller than the sum of the capacities of all application servers.

Now let us assume SAP's new code is processing the business logic in the DB server. Let us also assume 'all' business logic is pushed to the DB layer. The diagram depicts the load on server 1-6 being pushed to DB server. In this scenario, we don't have application servers but we've a big DB server.

The revised diagram would look like this: This diagram doesn't completely eliminate application servers because Dr Hasso Plattner mentioned that existing code will be used where new code doesn't make sense in traditional databases. Also DB server would definitely be bigger than current DB server. How big would we need? I don't know. No one probably knows at this point.

Bottom Line from Statement 1:

• In order for new code to work using traditional databases, the customers would have to redesign their landscape with "reduced application server capabilities but more DB server capabilities". No one probably knows the sizing algorithm for new code.
• In most cases, SAP wouldn't be using application servers' buffering and asynchronous updates using VB* tables. The purpose of buffers and VB* tables, as I understand it, is to improve the performance and increase the level of concurrency. How new code would address these issues remain to be seen.
• How business logic running on traditional DB server, despite DB enhancements, would improve the performance remains to be seen.
• New code is going to introduce a certain level of uncertainty with or without SAP-HANA. In my opinion, vijay.vijayasankar  offered a sound advice:

If my CIO friends are reading this – this is a good time to make sure you consider Hana in your roadmap discussions – not just for software, but for infrastructure, skills upgrade of your team and so on.

• Which scenario - HANA or non-HANA - would introduce more uncertainty?

STATEMENT 2

SAPHANA will be used for all existing Apps and For All Future Development Projects

This statement further supports my belief that SAP is determined to become #2 DB vendor by 2015 - if not sooner. At this point, I don't even know which one - statement 1 or 2 - is scarier. I mean, when one starts developing code using new technologies, as time goes by, the developers - especially the new ones - would start forgetting the need to support traditional databases.