Hasso Plattner is not just a co-founder of SAP; he's also one of the founding fathers of ERP, the lynchpin for enterprise processes. At SAP, he's led the company through the evolution of its breakthrough ERP systems -- from R/1 to SAP ERP Central Component and beyond.
It was Plattner who spurred the development of SAP HANA, an in-memory database that can store and process transactional and analytical data in the same platform to help deliver results in real time. SAP HANA's release in 2010 was followed five years later with the introduction of SAP S/4HANA, a next-generation ERP system designed for the SAP HANA database.
At SAP Sapphire Now 2019, we sat down with Plattner to discuss the current and future state of SAP and the SAP HANA database. In part one of this two-part series, Plattner details the nature of the SAP HANA database, what distinguishes it in an enterprise landscape where data is growing exponentially and why SAP HANA is positioned more as a generic database now.
Editor's note: This interview was edited for length and clarity.
What is the current state of the SAP HANA database?
Hasso Plattner: The big picture, the strategy is that after we basically converted all SAP-acquired and original applications from any database to HANA, we now have time to go back to five years ago, where HANA is a generic database. Most of that is done. There's still some work to be done in Ariba and Concur, but Concur is a different type of application, and it runs on Microsoft SQL Server.
Why does the SAP HANA database need to evolve to meet the explosion of data requirements?
Plattner: Ten years ago, I concentrated on database development for ERP systems, which are the most highly evolved systems in enterprise computing. The data is very precisely defined. Everybody knows what we actually have to do, what the flavors are and the functionality, but data is not that big. Just to give you a flavor, SAP on HANA is under 2 TB -- this is close to a $30 billion company.
Most of our S/4HANA in the cloud companies are under 5 GB of enterprise data compressed -- uncompressed it's more. Nestle is about 6 TB to 8TB per system, and they have three systems. The largest installation with data is Etrade.
So, ERP data is relatively small while the world has exploded in data. That means, since the current version of HANA can only store data in dynamic RAM (DRAM), HANA becomes too expensive for other applications. So, we announced the next version of HANA, called SAP HANA Cloud Services, which will only be in the cloud.
Why is permanent memory needed for the SAP HANA database?
Plattner: We dropped 60 functions, which we don't believe will be needed anymore in the future, and go for a multi-tier HANA DRAM. Then, permanent memory collapses the cost significantly and improves the system. Permanent memory will hold all of the data we need for restart, so we will have a restart in seconds, rather than a restart in minutes, which is very important for high-availability implementations.
We will have then the next data layer on disk. Years ago, I said we don't do disk anymore. But now, we will do disk, because there's no need to keep data, which is older than two years in financials, in DRAM. You almost never need to access it, and if you do, it's a sequential access, which on disk is pretty fast. Then, we put what we took from Sybase IQ underneath HANA as a separate engine, but a compatible system, which will be the HANA data lake.
How does the SAP HANA database integrate with other databases?
Plattner: Underneath we have SAP Data Hub, which we integrated with HANA and can now access Hadoop, Oracle, ASE, IBM -- anyone. With one SQL statement, from top down, you can go through all these layers, but you have to organize these layers. It's a question of data tiering and partitioning, and that has to be customer-specific. After two years, it goes on a near-line storage disk. And after five years, it goes into the lake and sits there.
Why is keeping data in one location so important?
Plattner: The philosophy is that we do not transfer data anymore -- no extract and load. We want somebody to access the data in the original location -- [for] data security, [there is] no data transfer. The communication time to get the SQL to the other system is no issue, and to get the result set back is OK. If the result set is big, there is some transfer time, but it's a much better model to put everything on the same system. So, we now have total flexibility for our next development and for customer development.
How have the recent SAP restructuring and layoffs affected the SAP HANA development group?
Plattner: We reduced the product management level, so HANA people left SAP. When a group gets bigger and bigger -- HANA has over several thousand people -- all of a sudden, there's a product management layer growing. We never really find out what they're doing; they talk to customers, they talk to development, they talk to sales -- and I just used the word talk three times now. Less talk, more code. The HANA development team is growing, and we have a very dynamic new manager for HANA, analytics and data warehouse.
Executive Editor David Essex contributed to this report.