SAP HANA resolves the long conflict between transactional and analytical data, ending a long war over database doctrine.

Two different views of an essential truth caused the most bloody war in Europe since the Fall of Rome. AThirty Years War.jpgs Catholic fought Protestant across the continent a generation grew up knowing only war, starvation and chaos. The Treaty of Westphalia (1648) ended the conflict and brought in the idea of the sovereignty of the nation-state which redefined national relations.

I was reminded of the end of this war with a comment that Bernd Leukert (SAP Board member for Products & Innovation) made today at SAP Select in Barcelona. He spoke about the fact that transaction data (OLTP) and analytical data (OLAP) no longer had to be stored separately, but that in new in-memory databases the generation-long pain of duplication had been eliminated.

In order to understand how this peace broke out to end the thirty years of IT conflict, we need to understand the doctrine that birthed it.

Transaction data needs systems which provide fast access, and with special capabilities such as transactional integrity and roll-back. IBM, Oracle and others built sophisticated technologies to support transactions such as accountants who needed to post a sales order.

Analytical queries are fundamental to business cognition. To solve a customer service issue you might initiate a query such as “how many times have we shipped a 15mm gasket within a week of a new pump order” which required sequential reads of huge tables. However, it rapidly became clear that allowing reporting systems to co-exist would slow the transactions down so much that a customer would hang up before the order could be booked.

The schism between transactions and analytics had started.

Just as when Luther nailed his theses to the door of Worms Cathedral to kick off the Protestant Reformation, IT managers developed their own doctrine to launch the age of Data Warehouses. Sometimes these were just extra redundant tables (called aggregates) sometimes whole new architectures with specialised programming languages and endless synchronisations, updates, lags, Excel sheets, star schemas and the like. The War had started.

Casualties of the Age of Aggregates were

  • Time and Money spent by IT departments in buying, building and supporting data warehouses
  • Complexity in software which led to architectures that became inflexible to changing  business needs
  • Incorrect business decisions based on out of date or incorrect data

Sometimes the conflict was characterised as the difference between a “system of record” and a “system of engagement”. The executives never heard the doctrinal debate, they just knew that a board meeting, despite six weeks of preparation would have data that was either wrong, missing or old. It all sounded as arcane as those 17th arguments about the nature of transubstantiation, which the peasant never cared about but saw the secondary effect: an army raiding his farm.

Now peace is here

Work done by Prof Hasso Plattner led to the launch of SAP Hana, which was re-engineered to provide lightning fast transactions and analytics at the same time, with no duplication at all. Information Architecture is radically simplified as there is one source of truth, updated once, in one place.

The Treaty of Westphalia at the end of the Thirty Years War led to Europe’s golden age: the Enlightenment and the Industrial Revolution. Maybe the elimination of the conflict between transactions and analytics in our Information systems will lead to another Golden Age.

To see what SAP Hana can do for your business, take a look here.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Michele Prisco

    Thank you for the brilliant insight. In your honest opinion, does it make sense for an mature SAP customer, to keep a parallel BW installation running, when all reports can be retrieved from the S/4 HANA? And would you suggest to a company starting from a green field, to implement a BW?

    (0) 
    1. Erich Schneider

      Michele,

      to find answers to your questions, you might want to look into this blog:7 Reasons Why S/4HANA Does Not Replace SAP BW

      IMHO the question would be, why would you still need a data warehouse, not product-specifically why BW…

      In general

      • S/4HANA will provide all operational reporting if you have a single S/4HANA instance
      • In case you have 10 years of transaction and sensor data and that volume would be 1PB of data, would you require the same SLA for all of the 1 PB, or only for a subset of the data?
      • Assumption:
        Today you have 5 years of history in your SAP ERP system
        S/4HANA has a different data model than your SAP ERP on a traditional RDBMS (more details here):
        The remaining x years of SAP ERP are archived in a BW system
        All the data from M&A activities from x + 5 years are available in the same BW system
        Would someone recommend to load x years of SAP and non-SAP data from a BW system into a live production S/4HANA system which has a new data model which requires data transformation – though it is technically feasible? Probably not. My recommendation would be to archive another 3 years in order to keep the data set to be migrated small because you have the data in BW already anyway. This allows you to focus on innovations, like how can sensor and social media data enhance your operational reporting in S/4HANA in real-time to enable real-time business decisions.
      • In case of a greenfield approach, with SAP HANA MDC = Multiple Database Container(s) – you would run both applications, S/4HANA and BWoH, on the exact same database: Different applications, different purpose, same database – 1 single set of data – 1 query.

      Just my 2 cents

      erich

      (0) 
      1. Laszlo Torok

        Eric,

        I am much worried – together with my fellow BW colleagues with 16+ years of experience – that soon we need to change and start over with a new module. If BW was to be integrated into S/4 then definitely the level of complexity of the data warehouse layer would go down, not needing that much experience as the current model. Or BusinessObjects will take it’s place entirely.

        Still there is hope, as the increasing diversity of datasources still fuels BW, as long as SAP is not exclusively dominant within a company.

        Your points are good, but SAP sales is so strong, that they can sell any idea to the most of their clients – maybe the selling point of S/4 can be to cut costs by eliminating data warehouses.

        It would be so nice to see at least an unofficial statement from SAP about the vision of BW …

        Laszlo

        (0) 
        1. Thomas Zurek

          Hi Lazlo,

          your points are absolutely valid. Here are 2 references that might help:

          • My blog on “S/4HANA and Data Warehousing” which fundamentally explains that
            1. S/4HANA is not a data warehouse (DW) – you rightfully point to “the increasing diversity of datasources”, a problem that is not tackled by S/4HANA as it is not in its scope
            2. OLAP <> DW: you can do OLAP within both, an OLTP and a DW system; historically, mostly for performance reasons, OLAP was bound to a DW but that tie has been broken with the advent of newer technology (like HANA)
          • See Hasso Plattner’s comments around his recent blog. For example the one starting with “one more point why a separate bw/dw makes sense …”

          DW have a future, even though their (technical) setup and role will change in the light of technology changes and the advent of big data. But that’s only natural. BW will stay their too – see its role within the HANA DW.

          I hope this helps.

          Thomas

          (0) 

Leave a Reply