Skip to Content
Author's profile photo Irfan Khan

Getting to Know SAP HANA, Part 3: More than a Database

Part 1 reviewed how SAP HANA came to be and laid out the principal differences between HANA and other offerings. Part 2 honed in on HANA’s fundamental differentiator. This time we explore the ways that SAP HANA transcends standard database capabilities, and how it truly delivers on the promise to simplify data management and reduce landscape complexity.

In my last piece, I described how database vendors are attempting to augment their technology stacks with in-memory capabilities. They are adding new components, which are delivered as separate options – resulting in more layers of complexity on top of their existing, already quite complex, environments. The unfortunate truth is that this kind of layering and cobbling-together of disparate pieces of technology is not an innovation.

IT landscapes have always suffered from functional gaps between the core foundations and the application components necessary to deliver a business solution. For example, most of the database vendors with roots in the traditional RDBMS space have felt compelled to promote and sell multiple database offerings. This became necessary in order to reconcile the gaps encountered within the organization: transaction processing, reporting, analytical processing, etc. Moreover, there are often gaps between enterprise databases and the functional logic of the applications that run on them.

In both instances, additional layers are required between the different components to make them work together. These gap-fillers are what create complex data management environments, complex landscapes, and ultimately rigid systems that can’t change in time with the business. In the new paradigm, the data platform possesses capabilities that extend far beyond what databases have ever been able to do before. SAP HANA fills the gaps between critical components within the overall enterprise computing architecture, thus solving one of the most crucial of today’s computing needs.

Moving data between databases that perform different functions is rarely a straightforward exercise. You may need to move data from the OLTP database to an OLAP database, or from an enterprise data warehouse to specialty datamart. A data integration layer, usually a dedicated ETL (extract, transform, load) system, most often fills the gap between the two databases. These systems raise a host of issues:

  • They take time.
  • They consume resources on an on-going basis, both human and machine.
  • They don’t always work.
  • When they don’t work, correcting and reconciling systems can be a nightmare.
  • They move data in batches, creating a time lag between the data in the source and destination databases.
  • They require labor-intensive updates whenever new requirements for reporting or analysis are identified.

SAP HANA’s data virtualization capability eliminates all of these downsides. In a HANA environment, there is no gap between OLTP and OLAP or between a data warehouse and a datamart. Each of these use cases leverages the same, live dataset. All of the data reformatting, cleansing, and moving from place to place, which ETL would typically manage, is done virtually (and instantaneously) in HANA. Where before there were two databases joined by a separate technology layer, now there is one data platform serving any number of different roles.

HANA not only eliminates the latency and complexity associated with traditional architectures, it provides an almost infinitely flexible environment for reporting and analysis. Whenever new reporting or analytical requirements emerge, they can be addressed immediately via the same virtualization capability, with no disruption to the normal reporting or analysis cycle, no new hardware to procure, no new ETL operations to maintain, and no new backups to pay for.

Another performance-draining gap is the one between the database and the application logic that it supports. Up till now, databases have not had the means to address this gap; even those environments that provide cache-based options can’t do it. Typically a layer made up of predictive, business, and search functions fills this gap. As with the ETL layer, this extra data analytics layer (or layers) brings unwanted complexity to the environment while slowing everything down.

SAP HANA eliminates the need for an extraneous layer between the data and the application logic. All of the required business calculations, predictive algorithms, and natural language search functions can take place within HANA. HANA provides a rich set of native data analytic and search capabilities pushing processing down from the application layer to the HANA platform, thus enabling data-intensive operations to occur closest to the data.

Additionally, HANA solves one of the biggest challenges faced by enterprise application developers: joining different data types. In the standard enterprise environment, transactional, multi-dimensional, text, graph, and streaming data have to be joined together via custom application logic because they are stored in different databases. This poses any number of difficulties for the application developer, who is usually not a database expert to begin with. Handling data joins in this manner can be slow and burdensome. HANA, on the other hand, natively handles joining multiple data types simultaneously. The developer environment for this is an elegant graphical editor designed for just this purpose. This capability ensures that within an application environment there will be proper separation of data logic and application logic. It also significantly simplifies coding for the application developer, while eliminating any performance issues that would arise from performing the join via application logic away from the data sources.

The stock answer to that question is that databases can do only so much, given their legacy architectures. The SAP HANA data management platform not only outperforms conventional databases on virtually every measure that you might care to apply, it also picks up where they leave off. HANA doesn’t need help in the form of extraneous layers of functionality. It thus reduces complexity, increases developer efficiency, and lowers maintenance costs. HANA demonstrates how complete and self-sufficient a reimagined data management environment truly can be.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.