How do you get your experts with negative stance for new things to HANA
We have over 50 ABAP developer (senior experts). Primarily we develop in the old core module (SD, MM, FI, CO, HR, PP, CS, IH, PS) on ERP systems / business suite.
We have three groups of developer:
Group 1: They can’t await to work on new architectures – they’re open for all and have fun to work as a pioneer and dig in the deep of the system
Group 2: For this developer it’s all the same – for this people it’s not a problem to go to a other architectures
Group 3: They have no interest
– to work in new architectures
– to spend time to learn new things
– they are very closed for new things
– they have for all topics bad statements
I am part of the group 1. In my opinion in the IT it’s normal to spend much time at new topics in free time to keep up to date. New topics / innovative things make the developer job very exciting. For me it’s regular process – and that’s my own passion 🙂 .
Since two month we have our own HANA system in our data centre as play field 🙂 (business suite on SAP HANA). I’ve some colleagues who made the HANA certification – and we made the first steps in our system. For group 1 and group 2 everything is okay and they’ve fun 😉 .
We have problems with the group 3. They find every hair in the soup – they spend very much time to search arguments against HANA. That’s our “negative group” 🙁 . We copied our SAP System to a new system and made a technical migration. Now they compare the SAP System, which is based on an oracle datebase, with the new SAP System which is based on a HANA System. They go through the standard ERP process (offer / order / purchase order / goods movements / delivery / MM invoice / SD invoice / material master data / customer master data / vendor master data / conditions / financial bookings / etc.). They main argument is, that they can’t see a grow up of the performance / the added value of the invest / etc. Our other problem is that the group of this people have experience over 20 years in ABAP developing – and their opinion have a high weight. The other arguments: IBM and oracle are working on similar architectures – and we can hold on on the open sqlsyntax / on the present coding.
Have you similar problems to get the acceptance of group 3?
Have you tips / tricks for us?
Have you ideas for catching the group 3?
What standard components are really optimized for HANA?
In which standard components can we see a really performance grow up?
There are standard use cases to see the differences?
Which data volume do we need in the data model to see the differences?
What can we do to take the group 3 with us?
Hi,
I think for one thing it is a quite normal human behaviour to try to keep things as they are. Being conservative is not always bad, in fact, it is the normal phase after the storming (=new technologies) phase.
In the end these guys keep the system running which they are fighting now. And they will improve it step by step.
So, you need to get them in your boat.
In the end it is about the valid application scenarios, because it is clear that an investment in HANA doesn't make much sense if neither the performance nor the functionality stays the same or improves only a little bit.
Try to find the scenarios and use cases where you really see a business or technical benefit.
If this is convincing, it might be the right time to show that many principles in HANA are not so new. They were combined, though, so that the sum of many features may create something extra-ordinary.
For example:
column based databases before (see Sybase),
in-memory database (see liveCache in APO),
database procedures
etc.
One major benefit is that reporting can be done on the transactional data itself without artificial aggregates in the system. So, not only performance should improve but also availability of current analytic data without time delay.
But developers also may understand that transactions involving INSERTS of new data are not necessarily quicker (maybe even slower). So, it is also about the right training of people.
If the concepts of HANA are understood, nobody can honestly argue about performance of a transaction for creating business data. On the other hand the benefits of reporting on the data directly may be even more obvious.
Just my 2 cents in the discussion...
Hi Thomas,
that are really many points. Let me take a single one, the performance. A transaction is not just fast because the database is HANA. If there are many select single or only few data lines, there is no or even a negative effect. That is the reason, that SELECT SINGLE and also selects transfering too many columns are to be handled (and removed if needed) in a migration project to HANA.
If I remember it correctly many SAP standard coding is not yet adapted to HANA, but I cannot tell you in details which ais and which not.
I build test data to check our HANA system. The result was, that it needs at least 1 million lines to see a difference. But then the effective is dramatic. Selects are performant without the need to care for index. Using HANA it is easier to work with bigger quantities of data.
In most cases it is not needed to use HANA native SQL. In many cases it suffices to use appropiate Open SQL Statementes.
With kind regards
Rainer
Hello together,
thank you for your answers - it's very interesting to hear the experience from other experts.
Best regards
Thomas