Considering migrating BW to HANA? Why not?

Whilst the rest of the world seems to be taken by storm by the possibilities of HANA-powered BW systems, the adoption rate in Australia has been fairly modest. Why is that so?

The talk of the town is: “Why would I invest time and money just to make my BW reports run faster? My users are OK with the current performance. Why bother?”

Administration

First, there are hidden costs in making the current BW queries run as fast as they run now. Creating aggregates, pre-calculating queries, caching, etc. are all mechanisms that we all use to keep the performance of the existing analysis acceptable – and we lock our users into certain navigation states just to make sure that they get the response they need within acceptable time.

Getting in the way of progress

Not only there is an incredible overhead in making this all happen (disk, IT resources, you name it), we are also not giving our users the flexibility they  need – and they may well not be getting the benefit they need from the solution, because they cannot analyse data the way they really need to. They are simply not given the chance because this could result in unrunnable queries, that would just take ages to produce a result, or that could even crash the database. 

Projects

Another (not so hidden) cost: it is not uncommon for Analytics projects to include a major performance tuning component – it is no use delivering a solution that does not run fast enough for the users. This is a project cost that comes directly from the fact that our current databases are not capable of dealing with the required data volume fast enough.

We spend a lot of time analysing data loads, extractors, creating secondary indexes, analysing query performance, creating aggregates, including them in process chains, etc.

Furthermore, our BW team has been involved in several projects that have the sole purpose of making something run faster. Not long ago, I was involved in a major overhaul of HR data load to make sure that load ran within the nightly window (yes, the previous process could only be ran once a week) just to, at the end, hear a user say: “the reports are OK, but they only give me yesterday’s truth – I really need real-time information to make valid decisions”.

 
The Business Case

It is not hard to imagine how better performance translates to tangible benefits:

Reducing Cost of Administration

With HANA there is no aggregates, no indexing – so there is no need to maintain them. Administration is much simpler and the technical team can spend more time delivering new solutions, instead of maintaining the status quo.

This results in reduced Total Cost of Ownership.

Reducing Project Costs

The performance tuning component of the project reduces significantly. There is no need to spend time building aggregates. Many of the design options that we use today to improve performance become redundant.

The model becomes simpler too: it is possible to report straight out of DSOs, InfoCubes become smaller and simpler – and a lot of the work to reduce query runtime becomes unnecessary.

In my experience, Analytics projects on BW on HANA have been completed 10-20% faster, and used 10-20% less resources overall.

Software Licensing Costs

As absurd as this may sound, I have heard (and seen) more than once that, when the organisation puts pen to paper and compares the cost of their current Database License (and maintenance), BWA license (which is 100% redeemable on the purchase of HANA) and hardware with the cost of running a HANA database on a certified appliance, they have found that their overall bill will be reduced.

Why is that? HANA licensing is per database size (a set amount per 64GB units of productive system), whilst other databases are per seat. Furthermore, the size of a HANA database is normally 1/5 of the existing database. Moreover, hardware is getting cheaper by the day.

It pays to do the numbers – you will be surprised.

New Possibilities

We no longer have to find out the typical navigation state of queries and optimise the system for them. The user is free to navigate, interrogate, and truly slice and dice data, in ways that were not practical before. This creates new possibilities – not only users are able to gain more and better insights from the information they already have, but they are also able to get a larger number of different results from their existing projects.

You get more bang for your buck. Less projects are required to achieve the same results – this reduces the organisation’s overall cost of IT.

 
Self Service

In many organisations, IT managers have been reluctant to let users create their own analysis, as this could cause the servers to slow down or even crash – this fear is well funded. With HANA’s performance and ability to deal with large amounts of data, this fear no longer exists – and the user can explore data using BusinessObjects  tools such as: Explorer, Lumira (Visual Intelligence), Analysis, or even BEx.

This too reduces the overall cost of IT, as users require lessproject work to get the results they need.

Recycle abandoned solutions

Every organisation has Analytics solutions that are no longer used (or rarely used) because their performance became too poor. I know, I have seen and fixed many of them. Sometimes there is no fix: they have to admit defeat and simply stop using such solutions.

A faster database will breathe new life into these solutions and deliver the benefits that were intended when these solutions were first created.

Pervasive Solutions

Faster data load processes means data load can run more frequently, Virtual Providers become feasible and real-time data can be incorporated into Analytics solutions (obviously, the performance of the extraction still depends on the performance of the source system).

A new type of Analytical solution is now possible: solutions that enable the user to combine historical and real-time data. 

A Word on Migration

Migrating BW to HANA is a relatively small and highly non-disruptive project. It is essentially a system copy with some preparation either side to make sure the system shuts and starts in a stable manner (and unnecessary objects are removed) – provided the BW system is already at the required patch level.

There is a lot of literature about the subject, there is an RDS (Rapid Deployment Solution) path, and there are several options to reduce risk, resulting in a low-risk exercise.

Training requirements are minimum too (of course, HANA administration needs to be learned).

Concluding

Whilst the visible effect of migrating BW to HANA is a faster system, there is a lot more to it.

The impact of a faster system will be felt in: reduced administration costs, reduced project costs, reduced licensing costs and a plethora of new possibilities.

End users may not be clamouring for it yet, but they don’t know what they are missing.