SAP’s three ‘ages’ of HANA

    By: Mr. Adrian Bridgwater on Jan 14, 2013

    SAP was on home turf in Frankfurt this week to discuss recent augmentations to the HANA in-memory computing platform, suite, programming platform and ecosystem.

    While the news announcement itself warrants separate analysis, the fact that HANA can (arguably) now be justifiably referred to as all of the above entities is (in itself) an interesting position.

    Exactly how much has HANA grown over the years?

    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 ingredients

    Regardless, 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.


    Released: January 14, 2013, 1:41 am | Updated: March 22, 2014, 2:25 pm
    Keywords: Opinion News | HANA




    Copyright © 2014 ISUG-TECH. All Rights Reserved
    All material, files, logos and trademarks within this site are copyright their respective organizations

    Terms of Service - Privacy Policy - Contact the Help Desk