The launch of SAP HANA in 2011 brought about a paradigm shift in the enterprise business. Implemented with in memory technology, SAP HANA offers a more agile business environment and helps accelerate digital transformation of businesses.
Let us find out how SAP HANA, the in memory database (DB) with almost zero response time came about and the advantages of its in memory planning and in memory computing engine.
Consider a situation, where, we have our ERP Central Component (ECC) system on X Database (X is a variable).
ECC was designed to maintain a system of records in Underlined DB. But with the amount of data increasing in the database, ECC performance was getting affected, resulting in longer time period to run reports and generating results.
That is when, SAP started working with Live Cache by partnering with database providers IBM and HP
Live Cache is a memory device plugged on top of SAP ECC system connecting with SRM system, CRM system, APO Live Cache and ECC Distributed Cache. These Live Cache and Distributed Cache are built on RAM, which is a memory device.
Whenever computers and laptops become slower in performance, we add more RAM memory. The more RAM or memory you add the better and faster the interaction with applications. So, these Live Cache are applied on SRM, ECC and CRM systems due to growing system of records.
The objective of an ECC system as a system of records is to process the big data whenever we need reports and able to store ongoing business transactions resulting in more DB size or volume of data.
ECC system should also be able to store the big data, process the big data and make it available to users with its ever-increasing customers and DB size
We now have new data sources like social media data sets, likes and dislikes need to be provided by a retailer, log files, machine data, structured, unstructured, web services, telematic engine diagnostics in automotive sector and so on. Therefore, it is not only our ECC SAP transaction data, but also the other data, which is connected to ECC system through different adapters and various connectors from heterogeneous system that bring in more inbound data.
ECC is required to constantly process not just ECC SAP data but these incoming big data as well. Implementing Live Cache plugged on SAP ECC system turned out to be not enough to accelerate SAP ECC system. To address the performance issue of ECC with multiple Live Cache, SAP introduced a concept called Distributed Cache.
With ever increasing big data there arise a need to increase the speed in terms of real time transactions and to increase system performance issues. In this scenario, even Distributed Cache did not work as it was unable to enhance performance of the system effectively.
SAP began to focus on the core of the system of records where all the records stored in the DB.
In 2008, SAP Started to experiment on various databases (Oracle, Sybase, SQL l db2) and tried to understand how to accelerate DB to accelerate the ECC system.
To accelerate the traditional DB, SAP was required to half the size of the DB platform.
So, SAP started to work on their own DB (max DB), which runs on RDBMS concept and discovered that these traditional DB systems where SAP ECC plugged in work on a spinning disk.
Here we must understand that SAP is not a DB provider but an ERP application provider.
But these ERP solutions were becoming slower over a period of time and considering the future, SAP decided to analyse where the data was being stored and how it could accelerate the DB.
SAP discovered that they are running on a spinning disk which have a fixed rotations per minute. So, a 1TB solid state disk spins about 36k rotations per minute. However, this was still not fast enough for big data.
It is not about how the data is stored but also about reading real time data from ECC multiple queries web services, reports and concurrent users of ERP portal. Hence, SAP started further investigations on traditional DB and discovered that spinning disk was a mechanical restriction.
- Speed of the spinning disk decides the speed of the under lying database
- When the underlying database is not fast enough then the application mounted on it will not be fast enough
The value proposition of the third generation ECC from SAP was that it offered real-time three tier architecture.
- Tier 1 Report
- Tier 2 Application
- Tier 3 Data base
With the Data Base acceleration becoming an issue, SAP was unable to provide the real time 3 Tier architecture, although it was able to accelerate SAP ECC and accelerate reports with some LIVE CACHE.
Here, SAP realised the need to accelerate the database.
But the challenge was that the DB was owned by other providers primarily Oracle. So, SAP decided to connect with the DB provider with the help of Live Cache partners like IBM, HP, Cisco and Dell.
SAP created a new solid-state disk which is built with the dynamic RAM, the same RAM used in the Live Cache. Solid-state disk did not have any spinning disk. Hence,
- It can work with other payroll systems
- Scalable to multiple data sets
- More storage
- No mechanical restrictions on the speed as it is not the spinning disk
With the solid-state disk, SAP wanted to add the SAP software, which was applied on the BW accelerator.
- In memory computing engine library was applied
- In memory DB programs were created
- Other software was added on the solid-state disk in 2009
In 2010, SAP Acquired Sybase Inc. It then shifted its focus on innovating the Sybase DB.
So, all our transactions, postings, master data and transactional KPIs, will all be rendered in real time whether it is read or write. From the system of records to system of engagement, it always provides high performing business transactions in real time. This helps the users to analyse the data while performing the transactions.
SAP HANA is a high-performance analytical appliance with in memory platform.
- Real time analysis
- Real time reporting
- Real time business
- OLAP and OLP together
- SAP Hana enterprise cloud for suite on HANA
- Instant financial Insights
- No aggregates
- Single source of truth
- Simplified data model
- New user experience
- Advanced processing
- Choice of deployment
- Multi tenancy
In the Enterprise eco system we had ECC ERP with different Lines of Business (Retail, Health care etc.,) with system of records and business analytical system with system of engagements.
- The transactional system writes the data to the DB and from the ERP system
- Data will also be loaded to BPC and BA system for the reporting purpose, planning purpose and predictability
- So, the same data is loaded to separate applications and the data needs to be stored in separate database (My-SQL) which is the original design of SAP ECC
Today, with the introduction of SAP HANA, the new DB platform will be shared by ECC for document posting directly done on HANA DB and the same DB will be available for system of engagements (Business Analytics, BW) for planning and reporting. Hence, there is no need for data getting transferred to a separate box stored in separate DB.
For the system of engagement (BA system) for reports planning and consolidations, we have real time data written to the DB and real time data is read from the DB for real time reporting.
Operational reporting is also real time here on ECC ABAP programs. Transactional codes and queries in real time for consolidated reporting and planning is available with business engagement systems.
The rest of the DB are phased out which are spinning disks and we now have an in-memory DB.
All the data sets are posted in ECC and business suite applications will be stored, processed, complied and made available on HANA in real time
The answer is no. The concept of SSD is to process the data when there is no power supply just like your pen drive. This is a special type of RAM and it is a lot faster and cheaper than the existing ones, excluding the cost incurred on Live Cache.
You can optimize ECC without disrupting the business with the new DB.