via Content in SCN
Being an advocate of SAP HANA makes me somewhat idiosyncratic. I tend to see the advantages of implementing SAP HANA for BW systems, but I am not involved in the "other side" of the BW administrators. Recently I discussed the implementation of SAP HANA for my favorite BW landscape. Speaking with the responsible BW administrators was somewhat of an eye-opener for me. Even if such issues like hardware selection/sizing and overall project funding are clarified, then there remain four obstacles or let's better say challenges:
1. Encryption
I was asked whether the current version of SAP HANA supports data encryption. I had to say no, and this clearly violated the corporate policy. So no HANA implementation is possible right away. Life can be hard. There is this ideal landscape - THE landscape why SAP developed HANA in the first place, and it cannot be implemented due to the security policy! I was flabbergasted. I just hoped that SAP would provide encryption in a future release to alleviate this problem. Luckily the "what's new" of HANA 1.0 SPS05 was right on the spot. This obstacle was fixed really fast, thanks SAP!
2. Resources
BW data loading can be really complicated. There are some old and obsolete BW instances which cannot easily be dumped due to some complex data loading configurations. Unfortunately, such old instances bind resources, and this can hinder the implementation of new technologies like SAP HANA. It doesn't really matter if you have some old reference systems which cannot be shut down due to legal reasons, but using obsolete BW releases (on obsolete HW/OS/DB) for reporting is getting more and more critical. Of course this is well known among the BW administrators, but not being able to support such an obsolescence process in any way goes against my grain as being a support engineer.
3. Capacity Planning
BW systems can be very demanding and tend to be very important for a company, therefore better use good hardware. The hardware should neither be under nor over utilized. Either way you'll get complaints. So you need a good capacity planning process. BW systems are "work in progress" with different projects running concurrently and new subprojects going live all the time. If you have finally found a working solution so that the CPU-, memory- and IO-demands can be met in an economic way, you can be pretty sure a game changer like SAP HANA will void that process. I would not call that a real obstacle because the SAP HANA scale-out solution together with the "pay-per-use" software license should reduce the pressure from capacity planning and move it to performance + resource consumption reporting. However, if I say capacity planning is no problem, that could be only marketing speak as long as there is no verification in real life.
4. Data Issues
OK, so now for the straight talk. There was one issue which I really didn't anticipate and could cause some subsequent problems: I was told that implementing HANA would enable the end users to see all the data, because certain queries wouldn't time-out any more. So end users could complain that in certain areas only mockup data is loaded, not the real data. This of course means some more follow-up work on the data loading side to provide the real data. You better plan such tasks as part of the migration project if you don't want to enter reactive mode. HANA will raise the data quality because it will really make it possible to check all the data. Have you ever wondered what to do with the people who are currently struggling with performance troubleshooting? This is the answer what they will be doing after the migration to HANA.
Conclusion
My expressed thoughts are of course my very own opinion. Nevertheless I expect HANA to reveal some more strange intricacies which are not related to software bugs or architecture issues.
No comments:
Post a Comment