OLTP and OLAP sign a peace treaty to end the Thirty Years War
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. As 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.
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?
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...
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.
Just my 2 cents
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 ...
your points are absolutely valid. Here are 2 references that might help:
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.