A New Approach to Application Design

A traditional data model built on legacy technology is often complex and includes many workaround solutions to overcome performance problems. This adds complexity to the application code which runs on the data model because code has to be developed to maintain these workaround solutions. Up to 70% of application code is built specifically to support performance of an application and adds no value to the core business functionality.

A complex data model and complex application code means that integration with other applications, and enhancements, are difficult. These complex applications are simply not agile enough to keep pace with a modern fast-moving business environment.

Watch this video to learn about simplified data models and applications.

In SAP HANA Cloud we have a simplified data model and this means simplified application code that runs on top. With a simpler data model it is now much easier and quicker to enhance the applications and integrate new features.

A good example of a simplified data model can be found when you compare SAP ECC with SAP S/4HANA. SAP ECC was developed many years ago using disk-based technology and limited computing power. Many workarounds were needed to maintain performance.

When SAP developed SAP S/4HANA they dramatically reduced the number of database tables that support the business applications. They did this by removing redundancy (overlap) across tables and also combining tables that were previously fragmented. This resulted in fewer, but often much larger tables. SAP HANA Cloud supports very large tables due to its superior in-memory database technology, using parallel processing, compared to the traditional, outdated disk-based database technology. With far fewer tables and no need for aggregations, the SAP S/4HANA code was simplified to make it easier to extend.

In the past, the role of the database was to take care of all data-related instructions that were sent from the application. These instructions could be any of the following:

• Create data

• Read data

• Update data

• Delete data

These requests were usually simple and required little or no actual processing or calculating of the data. For example, in the case of a read request, the database would hand over the raw data to the application layer which would then take care of the calculations performed on it. The actions in the database were only to fetch large chunks of data, or write large chunks of data back once the application had finished working on the data.

Once the database had handed over the data to the application layer, the application would then process the data. These processing tasks could include the following:

• Aggregate and dis-aggregate data

• Filter, sort and rank data

• Combine data sources with intersection, unions and joins

• Calculate new values from data

• Generate forecasts

• Convert data (for example, currency, unit of measure)

• Cleanse data

• Re-structure data

Moving data between the database and application layers is inefficient and affects performance of the application.

Ideally, an application should send all data processing requests, whether simple or complex, to the database for processing right where the data resides. SAP HANA Cloud database does exactly that. SAP HANA Cloud database receives the processing request from the application layer, but instead of sending the data to the application layer, SAP HANA Cloud processes the data in memory and sends back only the results to the application. This massively reduced the data traffic and therefore the performance of the application.

Moving the data processing tasks from the application layer to the database layer is often referred to as push-down.

Applying a push-down approach means that application developers need to re-think the way they code. In the past, all coding relating to data calculations was done in the application layer. For example, an ABAP developer would fetch all records from the database into internal tables of the ABAP server and would then write code to loop through the records in the internal table. But now with SAP HANA Cloud database, large parts of the coding can be developed directly in the database. The language used by developers in the SAP HANA Cloud database is an enhanced version of industry-standard SQL called SQLScript. SQLScript provides developers with a language to develop sophisticated views and to write stored procedures and functions that can be called from their application code, including the passing of parameters.

Let's see how SAP HANA Cloud brings transactional and analytical requirements into one platform.

Here is an example: An employee vacation booking system analyzes the forecast of peak workloads based on real-time customer orders and blocks out the days that can be taken as vacation when all staff are needed on the shop floor. In the past, two separate applications would need to have been built on separate platforms: One for analysis and another to execute the transaction. This new approach has revolutionized the way applications are built and the line between analysis and transaction application has become blurred.

A key objective of the SAP HANA Cloud database is to remove all data redundancy. This means that only one copy of data should exist and this data should be accessible by all applications in real-time.

There are a number of features of SAP HANA Cloud that make it possible for one data set to be shared by all applications including:

• Hybrid data models - SAP HANA Cloud handles both transactional and analytical processing by supporting different data models such as relational (for transactional apps) and dimensional (for analytical apps)
• In-memory column store database - provides exceptional performance even for applications that have demanding data processing needs
• Data Connectivity - SAP HANA Cloud can connect to any data source, anywhere, cloud or on-premise.
• Huge Storage - Some applications requires access to a lot of data, perhaps related to history. SAP HANA Cloud supports access to data lakes that can hold infinite amounts of data.