My recently turned 9 year-old, Lucas (you may remember him from his days as a YouTube star) just showed me a new series he's been watching on NetFlix called "Speed Kills". This "naturally" got me thinking an awful lot about HANA.
Speed of Analysis
When most people think about HANA, they think about the speed of output. This is definitely compelling (thorsten.franz did a bang up job discussing the value of that in the first section of this blog post), and it is clearly the most fun part of both analytics and nature shows.
For speed within an analytic, HANA helps because the query takes no time at all in most circumstances. This means your only real performance hit is the round-trip to the database and the time it takes to update the visualization. Certain business intelligence tools have round-trips that naturally take longer than others, but by taking seconds out of that query run time, they will still all respond better.
We should also keep in mind that this level of speed allows for analysis that couldn't be done previously. Dynamic filtering and grouping is a nightmare in a traditional database with any sort of heft because pre-aggregations can't be done easily or effectively. And there is also the fact that if your data source is HANA your BusinessObjects Explorer suddenly has far fewer limits in terms of dataset size and calculation complexity.
Speed of Development
The other thing that HANA allows, and is often less touted, is the speed of development of analytics. In traditional data warehousing you stage your data from a far away location into similar tables in a target location, then transform that data into another slightly different and often more normalized format, then apply business rules to that version, then build multiple layers of aggregated data for faster consumption by end user-facing tools. Sounds simple, right?
In HANA, however, almost all of that replication and aggregation is unnecessary. You don't copy and physcially aggregate data anymore - you simply apply your business rules to the transactionally-shaped data in a view of that data, then build more views on that data or only access the columns you need from that view for different use cases. Not only does that mean that the first time you go from your transactional system to your analytic is faster, it also means that every time you change your mind about what you want it can be updated faster.
The speed of HANA literally allows your end user to sit with your data modeler, change their mind, and see what the end report/dashboard/visualization looks like based on that change while they are sitting there. In the old world, changing the threshold or inclusion rules for a measure meant updating code in one or more places and then running hours worth of jobs to push the data into the end state. In the new world, you change the code in one view and simply hit refresh. That's poweful.
This speed to development is especially important in today's business environment, where opportunities need to be jumped upon quickly. Oftentimes if it takes you 6 weeks to produce a report for a business leader, they no longer even remember why they wanted it.
Speed of Conclusion
If you are considering HANA for your analytics strategy, don't forget to consider all of the types of speeds it enables. Getting data to users minutes faster is great, but getting it to them weeks faster is even better.
- SAP Managed Tags:
