We now see for real the effect of the maturation process the platform has undergone at the same time as stability, licence terms and functionality have improved and a number of our clients have either already migrated or are under way with migrating their SAP data warehouse to SAP HANA. At Innologic, we have continuously certified our consultants in SAP HANA. Most recently, in 2015, 11 Innologic consultants took part in a SAP BW on HANA training at SAP Denmark, with subsequent expert level certification.
The primary trend we see at Innologic is for customers to choose to run a setup with SAP BW as a primary data warehouse and a “side-car” setup that gives them specific opportunities for establishing non-strategic reporting that bypasses the data warehouse. In its own way, this setup reminds of something we have seen many times before, e.g. on the Oracle or DB2 platform: that customers in certain cases establish data models or dedicated reporting that bypasses the data warehouse – sometimes as a strategic decision, but more often driven by coincidences or as a “protest” against heavy development processes. At Innologic, we recommend that you first take a look at your company’s operating model in order to determine what kind of architecture and agility you should go for. More about this is available in a previous blog entry here.
In this connection, keep in mind that even if the ETL tool and the database are now SAP’s their own as opposed to before, the considerations are the same: establishment of data models and functionality at a “database level” without long-term in-depth architectonic deliberations, in the final analysis, may come to cost a lot of money when the solution (and possibly the SAP BusinessObjects reporting in the overlying layer) is re-implemented in the data warehouse for the purpose of ensuring support for changes to business requirements in connection with, e.g. data integration, authorisations or more advanced functionality such as time-dependent hierarchies. It is not necessarily more “acceptable” to establish a quick and dirty solution now just because the login screen says SAP…
As I said in the beginning of this article, the HANA platform is in full steam ahead. New functionality that helps customers improve their performance and keep costs down is developed all the time. There is rapid development in the area of near-line storage and on the BW platform, which now allows customers, for example, to easily administer if certain historic datamarts, should, for example, only take up space on the disk insofar as memory is concerned. This is an amazing development that provides certain possibilities for keeping track of operations. We also expect continuous performance improvements on the load side. As a rule, HANA promises a 30% reduction in load performance, naturally depending, to a high extent, on the load scenario’s utilisation of database vs. calculation needs. Customers here should make sure to carry out an ABAP optimisation to eliminate inexpedient code in transformations known to be incapable of being done in HANA. Unfortunately, in way too many cases, we observe inexpedient solutions where an optimisation can result in gains by a factor of 100 or 1000.
The complexity of the platform in its current design demands, to a high extent, that SAP’s customers focus on in-depth training in SAP HANA since our experience is that it has become significantly more complex and that the “best practice” for, e.g. modelling still needs certain definitive touches – both at SAP and at the customer’s. If you do not watch your step, you are staring at a potential risk of re-implementations and lost investments. For example, in certain cases, now we have up to 11 different modelling scenarios of HANA where we had 1 for the same purpose before. On the customer side, we want to strongly recommend that you get thoroughly acquainted with the options and possibly implement trainings of selected employees in the same way as we continuously do.