BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
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.
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
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.