Insights

View full profileHerman Ohlhoff

Enterprise DW Lead & Head of Consulting (SA)
Bluefin Solutions

How in-memory technology can change SAP BI Projects

SAP’s latest in-memory development HANA (High Performance Analytical Appliance) promises to deliver some pretty exciting performance capabilities for SAP applications in the near future.  During the recent TechEd conferences much attention was focussed on how this in-memory technology will change the way businesses can analyse, simulate and update their information. 

Unsurprisingly, these demonstrations and use-cases were hugely popular and very impressive.  However, as a consultant mostly involved in the implementation of BI solutions I started contemplating how this technology could change my day-to-day life i.e. how it will change how we approach BI projects.

New meaning to the term “Agile”, goodbye waterfall

In-memory technology not only gives us the ability to retrieve mass amounts of data in the blink of an eye, but also the ability to update this data very quickly.  This means that the “cost” of correcting mistakes or improving the design after initial go-live drops significantly.  For example, adding a characteristic or key figure to a cube with a billion rows is not a trivial exercise.  In order to populate these fields for historical records the entire cube needs to be reloaded, which usually means downtime and weekend working for the IT team.
However, with in-memory technology this exercise becomes much more manageable and could be completed in minutes/hours rather than hours/days. So how does this change our approach to the implementation?

 
This lowering “cost” of changes will naturally lead to a more iterative and agile approach to BI implementations.  The ability to react to and absorb changes with less impact on the live system will mean there is less focus on getting a ‘perfect’ design before implementation.  This will mean getting solutions implemented quicker and then iteratively improving them over the course of time.

I think it is easy to underestimate the power and value of giving the users the luxury of being able to change their minds more easily.  Often decision paralysis sets in because people are afraid of ‘getting it wrong’ and no progress is made.  If ‘mistakes’ can be more easily recovered from people will take more risks and the overall value of the process is likely to increase.

Greater user engagement, better buy-in, higher usage

In addition to the overall development cycles being reduced by adopting agile approaches, I also anticipate that project team behaviour will change.  The ability to apply fundamental changes to large datasets in short times means that the turnaround times between gathering requirements and playing back a modified solution will also shrink.
This is particularly useful when making use of Poc’s during the requirements gathering process. By shortening the time it takes to reload data, more time is available to play back the solution and gather feedback from users.

This means you can either refine your solution much more within the same space of time or deliver your solution much quicker.  It also means there is much more time available to engage the end users, which will result in greater buy-in from the user community. 

The ultimate outcome should be not only reports that perform tremendously well, but also reports that are much closer aligned to the current business requirements, which in turn will ensure increased usage of the reports and improved ROI on your BI investment.

Iterate, Iterate, Iterate

By now it should be clear that I believe in-memory technology will indirectly result a much bigger uptake of agile iterative approaches to BI projects.  Traditionally the adoption of agile approaches is often disruptive to existing landscapes where quarterly or monthly ‘landing slots’ are used to implement new functionality.  The landing slot concept makes a lot of sense when an implementation typically takes an entire weekend to complete (e.g. 6-8 hours for backup, 4-12 hours to import transports, 12 -24 hours for transition loads).  The requirement to have staff available over the weekend to support this process also means that it is not feasible to do this to regularly.

However, with in-memory systems the traditional landing slot time will come down dramatically and could be completed in a couple of hours.  Such a quick implementation time would mean that these drops could easily be done weekly. So an agile and iterative implementation methodology can be adopted without risking significant disruption to operations.

Disclaimer

It’s not clear exactly what the SAP BW / HANA combination will look like technically.  We know it’s on its way and that HANA is effectively the next step in the evolution of SAP BW Accelerator.   However there are still some unanswered questions. Will the entire SAP BW application be run in memory or will only the contents of certain database objects be kept in memory (similar to the current BW Accelerator approach)?

For the purpose of this blog, I have assumed that the entire SAP BW application will reside in memory and that the incredible performance will apply to all SAP BW processes. 
While this may not be the case in the first version, believe this will be the ultimate destination.

Summary

If you are considering adopting the in-memory technology offerings from SAP I would recommend that you also consider investigation and adopting agile implementation methodologies such as scrum, as I firmly believe the one will lead to the other.