From data-mart to database to data analytics, SAP HANA's three ages of man

SAP held a co-located press conference in Frankfurt, New York and Silicon Valley this month to announce recent amplifications to the HANA in-memory computing platform, suite, programming platform and ecosystem.

SAP Business Suite powered by SAP HANA is a new option for SAP Business Suite customers.

The means that the company is now claiming to be the “only provider” of a family of business applications that can capture and analyse transactional data in real time on a single in-memory platform.

IDC’s Henry Morris has suggested that by combining both transaction processing and analytics on this “single platform”, SAP HANA now supports a “blended” system of record… and of decisions too.

“The integration of transaction management with real-time decision management eliminates the delays and inefficiencies inherent in parallel operational and business intelligence systems. This enables employees to make better tactical, operational and strategic decisions based on relevant, granular, up-to-the-moment data,” said Morris.

Quoted on Computer Weekly, Adrian Simpson, chief innovation officer at SAP UK and Ireland has said that it is important to realise that this news “offers an opportunity” for CIOs to simplify their applications landscape, putting transactional and analytical processes on a single platform.

While the news announcement itself made good eating in its own right, the fact that HANA can (arguably) now be referred to as all of the above entities (i.e. in-memory computing platform, suite, programming platform and ecosystem) is (in itself) a curious proposition.

So how has HANA changed over its three ages?

SAP for its part does not provide an easily referenced ‘potted history of HANA’.

Technology companies don’t like doing this i.e. they don’t like looking back, as they prefer to “sell” heavy on current features and capabilities as they typically exist on the future roadmap.

HANA recipe list: ingredients as follows…

If we try and look back over the years we can see that HANA grew out of an amalgamation of three distinct individual software products i.e. TREX, P*Time and MaxDB.

TREX (Text Retrieval and Extraction) technology essentially started life as a search engine somewhere back in the mid nineties (1996 in fact). A TREX pattern is capable of specifying a pattern for the structure and content of an XML document and the technology itself eventually migrated into the SAP NetWeaver service-oriented application and integration platform.

Along the way, HANA has also assimilated P*Time – a row based data store with an in-memory OnLine Transaction Processing (OLTP) pedigree. The MaxDB relational database (developed by Software AG) has also played a part, as now has Sybase ASE and Sybase IQ.

The three ‘ages’ of HANA

So we come to the three ‘ages’ of HANA as we can now regard them.

Age #1: HANA essentially came from the analytics side and was marketed as a “data mart” and a solution store.

Age #3: Then as we moved through OnLine Analytical Processing (OLAP), HANA became positioned as a database for BW i.e. Business Warehousing.

Age #3: HANA’s third blossoming phase has seen the technology ultimately running as a transactional system. SAP suggests that if you had asked a techie developer/DBA three years if you could run a column store as a transactional system, the answer would have been no.

Why was this so?

The reason, explains SAP senior VP of HANA’s technology engineering practice (TIP) Franz Faerber, is because a traditional column store wouldn’t be able to perform speedy transactional processes. Single operations to update every element of the column store would be too expensive (in terms of memory processing cost), but this challenge is now overcome with in-memory speed efficiencies.

Now (in the third age) we see HANA has an OLAP and OLTP analytical and transactional system working together.

SAP reminds us that “other” database management systems on the market are typically either good at transactional workloads, or analytical workloads, but not both.

According to SAP, “When transactional DBMS products are used for analytical workloads, they require you to separate your workloads into different databases (OLAP and OLTP). You have to extract data from your transactional system (ERP), transform that data for reporting, and load it into a reporting database (BW). The reporting database still requires significant effort in creating and maintaining tuning structures such as aggregates and indexes to provide even moderate performance.”

SAP further explains, “Due to its hybrid structure for processing transactional workloads and analytical workloads fully in-memory, SAP HANA combines the best of both worlds. You don’t need to take the time to load data from your transactional database into your reporting database, or even build traditional tuning structures to enable that reporting. As transactions are happening, you can report against them live.”

The firm says that by consolidating two landscapes (OLAP and OLTP) into a single database, SAP HANA provides lower TCO with much faster speeds.

Will there be a fourth age of HANA? Possibly so, but the mechanics of this engineering are in place for some years to come.