BW on HANA Elevator Pitch

[kevin_small]

So you find yourself in the proverbial elevator with a colleague.  Let’s say it is someone sceptical about why your organisation should move to BW on HANA:

Colleague: I just don’t see the point of us migrating our existing BW system to HANA.

You: Why is that?

Colleague: Well, our data loads and reports are acceptably fast already, we’ve designed and tuned them carefully over the years.  We don’t need real-time reports either.  I just don’t see any other benefits.

You: …

Do you know what you might say?  Without a specific business problem opportunity in mind (“our pricing processes takes 5 days to run each month”) how would you give generalised benefits?

Up front we need to make the reasonable assumptions that you can move to a minimum version of BW 7.4 SP8 on HANA SP8 and that you can redesign some areas of your BW system to follow LSA++ design principles where it makes sense to do so.  Given these assumptions you should expect at least four main benefits, many of which are interrelated: S.O.A.P.:

Simplicity

Simpler means cheaper to design and develop:

• BW on HANA has fewer modelling objects.  The Composite Provider, Advanced DSO and Open ODS View replace most other data provider objects.  There can be fewer modelling layers because you can stage less and virtualise more.  You can report directly on lower inbound layers, even when the data just exists as fields.  A further aspect to consider is that in BW today there may be complex designs that exist purely to enable performance – it may be that these can also be simplified.
• HANA comes with a lot of functionality built in, for example Spatial Analytics, Text Analytics (like sentiment analysis), Predictive Analysis and its own XS Engine for native application development.  In fact HANA can be thought of as a platform in its own right.  If you need any of these features it certainly simplifies your architecture to not have to buy or build them.
• Having a single vendor means you should expect long term benefits of deeper integration between application and database.

Open standards

Open standards means connectivity, libraries and skills should be readily available:

• SQL, JavaScript for backend and frontend processing and OData are open standards.  Skills in these areas should be already available, or easily learned.
• HANA offers open connectivity such that data can be exposed to a wide set of SQL-based clients.
• Open standards also means a huge existing ecosystem of tutorials, forums and libraries is available to support development, in particular for JavaScript.

Agility

Agility in software is a much used term, and means different things to different people.  Here I use it be mean quicker development and quicker deployment of both new builds and changes.  This is a big benefit and from a business perspective this could be the most tangible.  That’s why this benefit gets the emphasis box around it in the diagram:

• Simplified BW data flows (fewer layers) means faster development.  More importantly, you can mix BW data flows with HANA models, and HANA models can be adjusted without huge regression test obligations.
• HANA models can be adjusted and deployed without data reloads.  Imagine not having to deal with all the hassles around planning and testing for reloading data?  In addition, if you structure your layers of HANA models to minimise regression impact you should be able to move them live more readily.  Both of these reasons give us faster deployment.
• BW on HANA also offers us new modelling options not available before, the so called hybrid scenarios where BW and HANA functionality can be used together.  For example, you might have a wonderful set of harmonised, high quality master data in BW.  You can expose that to native HANA models, and use these models as agile data marts to quickly report on e.g. non-SAP transaction data merged with that BW master data.

Performance

Lastly there is the benefit that things generally go faster in HANA. In our example, your colleague is not so interested in this (for the reasons they gave) but there can still be benefits here:

• With just a technical upgrade you can expect to see faster loads, activations and perhaps queries all “for free” (look through some of the customer stories).  Crucially, there is also the opportunity for further performance improvement – perhaps code push down during loading (see the ABAP for HANA course), something not available before HANA.
• If you already use BIA/BWA then query performance may not change greatly.  This depends on what BW/BWA version you’re moving from, as for example push down of exception aggregation calculations could make a big difference to certain queries.
• There is the opportunity for reporting to be closer to real time.

So there we have it. SOAP doesn’t just stand for the boring old Simple Object Access Protocol. To explore the benefits of BW on HANA further a good place to start is the BW on HANA OpenSAP course.

Your colleague may make a mental note not to be left alone in an elevator with you again :wink: , but hopefully they’ve got a broader idea of the potential benefits of a migration.