BACK

To HANA or not to HANA

“To be or  not to be…” That may be a question.
However, for many of our customers the question is rather “To HANA or not to HANA?”… or even “How to get to HANA?”
One of their biggest questions nowadays is whether it is worthwhile to adopt SAP HANA. Basically, there is only one answer: yes. It is. Full stop. Simple as that. The reasoning behind that is simple – a complete SAP stack will be best in performance, implementation, and operation.
However, there is one caveat, and that is when. And also how. OK, that may just make it two caveats.
First: when… well, when it makes sense. Today may be too early – first check other, more urgent topics. If the system is running, then it is not too urgent, and you can take the time to evaluate the real benefit and the urgency.

As to the HOW… When moving their BW environments to SAP HANA, customers have the choice between different options and paths for how to achieve the transition.

 

These start way before the HANA transition even kicks off: the first question to answer is whether to run HANA on premise or in the cloud. In the course of 2014, SAP’s HANA Enterprise Cloud is gaining more traction and is attracting more and more customers. With HANA in the cloud, the way of migrating is similar when it comes to technology, but more complex in terms of organising and keeping track of roles and responsibilities with more parties involved.

 

For the transition itself, there are several ways of doing the transition. To make it more confusing, some of these can be combined.
  1. OS/DB migration: with a classical OS/DB migration approach, the HANA transition is treated like any change of database system. With this approach, all BW data from the existing BW environment is made available on the HANA BW system.
  2. DMO: this is a technology build into the SAP upgrade manager (SUM) which allows for a release upgrade with a database transition. Also with this approach, all data is brought to the HANA BW system.
  3. Greenfield or near-greenfield: with this approach, a new system is set up, BW content is either activated and created or transported into the HANA BW system. However, this still means starting with a new system which is empty for a start, and then loading it from the ERP source system(s) or from the old BW system.
  4. full migration or selective migration of data: this is the way to go using our DataVardian “Road to HANA” service which is the result of a co-innovation service together with SAP. This approach takes a different path for the transition which is a bit faster than most other approaches when it comes to delivering quick wins.
One aspect to consider is side by side operation during a transition period. Since HANA based BW systems obviously require new hardware the existing BW environment is still available. As a consequence, many customers fall for the temptation and decide for a parallel operation of the legacy BW system and the new HANA BW system for a transition period. Some of our customers were planning with a transition period of up to two years. From my perspective, lengthy parallel operation with a gradual switch-over of application by application to HANA binds too many resources to be truly temptating. This was of the motivation drivers when engineering our Road to HANA approach. It is a co-innovation service based on our long standing experience with SLO services for BW together with SAp.
In this Road to HANA approach by SAP and DataVard, a two-step approach is chosen:
  1. in a first step, we create a HANA landscape for BW development and production based on the “Lean System Copy” approach. In this approach, we build an empty system… empty in terms of data because the new system will have the complete active business content, users, data model, customizing and custom developments as the current production system. This removes the need of messy mass transports and “reinventing the wheel”.
  2. Then, in a second step, data is brought into this system using SLO data migration tools for SAP BW based on DataVard ReLine – either all data, or selectively. We have successfully used this approach to avoid long side by side operation of legacy and HANA systems and set up HANA systems with data.
 

Leave a Reply

Your email address will not be published. Required fields are marked *