This content is part of the Essential Guide: ERP consolidation and integration
Manage Learn to apply best practices and optimize your operations.

Understanding performance tradeoffs in SAP database integration

SAP database integration has always affected application performance, affordability and reliability. An expert lays out the tradeoffs to consider.

Enterprise application design is an exercise in tradeoffs, and much of the tension is between performance, affordability and reliability. While the history of SAP's decisions in this area is interesting, in this article I'll focus only on a recent shift in SAP's strategy on database integration that should inform the way SAP customers and partners think about their own application designs.

Until recently, SAP tried to keep application logic out of the database, avoided using database-specific features and recommended customers and partners do the same. SAP advocates this approach in many places, but makes it especially clear in its SAP Guidelines for Best-Built Applications that Integrate with SAP Business Suite, which states, "Developers' apps should attempt to decouple their software from the underlying database in order to provide maximum flexibility for enterprise customers."

SAP traditionally favored flexibility over performance

This strategy has played out in slightly different ways for different types of applications.

SAP, application server layer, SQL
Figure 1. SAP's traditional design strategy calls for using only SQL to execute logic on the database. This can work well when most logic happens either on the application server or on the database via SQL, but a tension can arise, especially in hybrid apps.

With transactional applications like the SAP Business Suite components, it results in a lot of calculation happening on the application server. Meanwhile, for analytic applications in both the SAP and BusinessObjects BI world, the strategy has been to push down as much mass calculation as possible to the database server by using pure SQL. When calculations cannot be done in SQL, the logic is implemented on the application server. But high-performance and hybrid applications, with their need for both transactional and analytic logic in a single application, have proven problematic under this design strategy.

On other vendors' enterprise application platforms, it has been common to see heavier use of stored procedures, triggers and tight binding of the application to a single type of database. SAP's approach is more flexible, but the drawbacks are the need to rebuild key database functionality such as transactions and query optimizers at the application server level and, sometimes, more round trips, and higher-volume data transfers between the database and the application server.

Strategies for dealing with application design tradeoffs

Broadly, these strategies represent a reaction to tradeoffs between performance and loose coupling of application components. Loose coupling, or the ability to reuse components, is a key driver of both affordability -- reusing components is cheaper than building them new -- and reliability, since proven components tend to be more reliable.

By reusing components across databases, SAP's applications have historically sacrificed squeezing better performance out of specific databases to be more affordable and reliable. Some apps from SAP and many non-NetWeaver apps developed by customers and partners have made a different tradeoff, integrating heavily with database platforms to reap the performance benefits of those databases.

The promise of HANA and SAP's new strategy

Part of the promise of HANA is to change the tradeoffs that guide these application architecture strategies. SAP maintains that HANA isn't just a database, but a platform, and that claim provides insight into SAP's new approach to application design. Notably, SAP Guidelines now include exceptions for the HANA platform, stating: "SAP recommends that the persistency layer should be free of application logic except if SAP HANA is used as the persistence layer."

More on SAP database integration

Learn about trends in SAP middleware

Watch a video on SAP Sybase-HANA integration

Read a book chapter on SAP ERP integration

HANA includes most of the traditional components of a database -- data management and query engines, stored procedures, workload management, etc. -- but it also has components that are more typical of application servers, such as its XS engine and a JavaScript Web and application server built into HANA.

Part of the reason for this new design direction is that it relieves some of the latency and bandwidth bottleneck between the database and the application server, making it less important for developers to decide where the application logic should reside. Instead, you just have HANA handle all the usual database and application server functions. Think of it as a new take on two-tier architectures.

Application logic that is implemented on HANA uses HANA's proprietary application programming interfaces (APIs), which causes some loss in reusability. (Use them on any platform you want -- as long as it's HANA.) But the advantage is that this leaves room for SAP to optimize the interaction between different components of the HANA system. For example, the XS engine already pushes down logic to stored procedures that are pre-compiled, which gives them a performance boost, and might see deeper integration into HANA's data management engine in the future.

For applications like hybrid transactional or analytical apps that have high data-processing and latency requirements, designs that combine database and application logic in a single system could result in easier development. For applications that don't have such requirements, it's worth remembering that HANA can also act as a traditional database, providing the standard SQL APIs and accompanying flexibility enterprises are accustomed to. The question to keep in mind when developing applications is where best to draw the line between performance and flexibility. HANA provides additional options, but the old tradeoffs are still there.

Dig Deeper on SAP UX

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.