There has been a lot of talk among SAP executives about of late about how "game changing" SAP HANA is to the enterprise
software industry. While there are many solid cases where hundreds, or even thousands, of percentage increase in performance can be achieved, just how game changing it is remains to be seen.
Ever since SAP began holding such sway in the ERP space, companies have looked for a way to get their data into a meaningful format to make decisions. This is why organizations chose to record every transaction in a database.
But herein lies the current dilemma: how to get that data out and transform it into a format that can be consumed to answer complex questions. Anyone with experience as an end user in an enterprise corporation likely has spent time dumping SAP ERP data into Microsoft Excel and formatting it into tables, charts and graphs.
In an era of business analytics applications (such as the SAP BusinessObjects platform) it still amazes me how many knowledge workers go through the process of manually cleansing data in Excel. Recently, a business user told me it took three full days to extract the right data and format it for a monthly management report. Imagine if that user had those three days back to work on more strategic efforts. We shouldn't be dealing with issues like this in 2012 and beyond.
This problem is why the data warehouse was born almost 30 years ago. The problem that has since arisen has to do with the speed at which data warehouses are built and maintained. After many years of building these massive data warehouses, we have encountered many new issues that directly affect how the business views their data. These issues center on speed of development, speed of realization to business, and flexibility. Reporting performance has always been a problem, but it was largely enhanced by aggregates or SAP Business Warehouse Accelerator (BWA).
In fact, in the three years I supported users of SAP BWA while working for SAP, the most common reaction from the business was "We can't live without BWA." Now that the business has seen such speed in reporting, the main complaint has now been "Why does it take forever to build my reports?" It's unacceptable today to think that analytics cannot be delivered in a usable format via the Web, or a mobile device, and implemented very quickly.
Speed of development -- In a traditional Layered Scalable Architecture approach to SAP data warehousing, you can typically build up to seven layers of data. This means you copy the same data seven times before it is actually in a format that the end user wants to see. Theoretically, these seven layers can now be reduced to simply two or three with HANA. Many people familiar with SAP BW find this hard to grasp. It now seems entirely possible that HANA will massively change how we create models in our data warehouse. While this is quite disruptive to the BW developer ecosystem, SAP has proposed that customers in the interim implement HANA as the BW database. This can be very beneficial to preserving one key feature of buying SAP software -- there's an ecosystem of partners that support it.
Speed of realization -- The subsequent effect of a faster development cycle is that systems can be deployed to the end users much faster than previously was the case. This is important because it allows for a much more nimble approach. In my experience, Agile methodology works very well in business analytics because many end users have no idea what the system capabilities are and what they really want to see. Typically in BI projects where we load millions (and possibly billions) of records, there is serious downtime for the developers as they wait for data to load. If issues arise in these data loads, it is very easy to see how the development cycle balloons out of control. Inevitably this spells frustration for the business user and loss of confidence in the system. Development agility also supports SAP's statement concerning opening up innovation for customers. We're seeing this today with the likes of Google and Facebook, and SAP has the vision to do the same.
Flexibility -- The process of creating data models in SAP HANA can be reused much more frequently. This means that creating additional reporting scenarios on your existing extracted data is much easier for new developments.
While this is all good, it is built largely on three large assumptions:
- That we have very good SQL developers
- That we have infinite scalability of certified HANA memory
- That system integrators adopt a more agile approach
As these areas mature, I can guarantee more and more companies will adopt HANA into their landscapes. It may not be game changing to business users today because they probably expected life in business analytics to work like this the whole time.
ABOUT THE AUTHOR
Michael Bestvina is the head of mobility at Xoomworks in London. His organization helps business leaders adopt mobile applications. He also focuses on disruptive technologies in enterprise software and their effect on businesses. You can find him on Twitter: @techdisruptive.