Back in the mid-1990s, I was responsible for supporting SAP R/3 running on another vendor’s relational database. This is back when R/3 was the only client-server product that SAP offered. R/3 was the product that customers ran their businesses on, and anything they needed to do with that data was done directly in the R/3 system. Performance tuning was sport, and it wasn’t always clear whether we were winning.
I enjoyed it though, because I geeked out over knowing the most obscure tuning parameters that could only be accessed from CLI interfaces and SQL shells. Were they effective? Sure, to some extent. But when I heard Curt Monash use the term “bottleneck whack-a-mole,” I instantly related, because that’s what we were doing – jumping from one problem to the next, and there was really no end in sight.
Needless to say, reporting was slow. Customers complained about this, and rightfully so. To address these issues, SAP, like many other vendors, released a data warehouse called BW. It was designed in its first incarnation to take over the CO-PA and LIS reporting functions from R/3. SAP stated at the time that they would continue to support customers using these R/3 reporting mechanisms, but that new developments would be focused on BW because data warehousing was the future. And everyone else agreed, because they were doing the same things.
BW also ran on third-party relational databases, and it brought about a whole new world of performance challenges. To address these issues, most data warehouse vendors (including SAP) introduced “optimizations” such as summarizing your data so that there was less of it to report on; aggregations, or materialized views, which are pre-populated views of your data; pre-calculated queries, OLAP caching; and the list goes on. Basically, anything you could do to the data and the database to make reports run faster was fair game.
As a customer though, we noticed that we were getting further and further from the source. With each hop along the way – extracting, transforming, loading, summarizing, aggregating, materializing, caching – the latency of the data increased. Not only that, but it was not surprising how many times I saw smart people realize that the summarizations and translations they had implemented inadvertently changed the meaning of the data such that it didn’t reflect what was actually in the source system, and knew that they had to start over again.
And yet still, performance suffered, because BW stored data in a relational database, and relational databases just didn’t do a great job anticipating how users would want to manipulate and view their data. And relational databases were not built for reporting, so if you couldn’t anticipate it, you couldn’t tune for it.
SAP then came out with BWA, which was an in-memory query accelerator. The idea was that, even after all those steps were taken to make queries perform, you could then load your data into memory, which would dramatically speed up your queries. And speed up queries it did, but although BWA was great at increasing performance for some reporting scenarios, id did not address all of the fundamental performance problems inherent in BW running on an RDBMS.
And this pretty much brings us up to where we are today. Many SAP ERP customers run SAP BW for reporting, and many of those are using BWA. Everyone agrees, things could be better, but how?
Other vendors would tell you that the answer to improving performance is (no surprise here) … more layers of caching and acceleration!
I’m sure you’re familiar with the choice of appliances or engineered solutions offered by Other database vendors to address performance issues. Look under the covers, and you’ll find they’re sticking with the models that we’ve had for decades now, but adding incrementally to areas where they can cache. Whether using SSD for data caching, or spreading your load across additional database servers, or storage servers, or opting for yet another in-memory accelerator for analytics, they’re all about the same things SAP customers have been doing for years.
Do they work? Sure, to some degree. There are certainly benefits to these methods. There are almost always positive results to identifying bottlenecks, and coming up with ways of addressing those bottlenecks with point solutions. But that’s really how we wound up here in the first place – incrementally “fixing” issues with band-aids, workarounds or duct tape.
It’s sort of like a rumor mill, isn’t it? As the old adage goes, a story makes it’s way from person to person to person until eventually it doesn’t even resemble it’s original intent. The same thing applies to data management with analytical systems in fact – it’s remarkable how often the end result doesn’t resemble the original data. All of these hops that data must take are points at which the data can be changed, latency added, users frustrated; all because our RDBMS in the beginning didn’t perform well enough.
Well, enough already.
SAP’s vision for providing a solution was to say stop the insanity! Many of the existing solutions on the market have not been “fixes,” they’ve been workarounds, only delaying the problem from returning when business volume increases again. It’s time to fundamentally re-think the solution instead of incrementally adding to the problem. It’s time to use innovative thinking to take advantage of the latest advances in computing technology – processors, memory and networking technologies – and come up with new, compelling solutions to address customer challenges.
And that’s where SAP HANA comes in. HANA was designed from the ground up to run entirely in memory across clusters of affordable servers, and it can very effectively handle analytics directly on your transactional data. That’s right, similar to where we started from, let’s keep your data in your transactional system, but provide a platform that can handle analytical requirements directly on this data and still perform well. In fact, perform much better than our myriad layers do today.
Latency becomes zero because data doesn’t have to move from one database to another, and no time is required for aggregations, summarizations, materializations, etc.
No more making business decisions based on rumors because the data hasn’t needed to be transformed.
And you save money because you don’t need twelve additional layers of hardware and caching just to allow you to understand what your data means.
It seems simple, logical, and sensible, doesn’t it? Shouldn’t it be?
Not only is it that simple, customers are taking advantage of this today. With over 250 HANA customers to date, many of them in production, it is a real solution that provides real benefits for real-time business results. And by Sapphire, you will be able to replace your RDBMS database running under SAP BW with SAP HANA, and begin enjoying the benefits of going back to the Future.