A new perspective

[kavindra_joshi]

Some days back I was in a workshop for Knowledge Transfer to support colleagues. After a few rounds of KT over the phone , we had to do some face to face KTs. It was a very eventful workshop and add some very good perspectives as consultant.I would like to share few of them

a) The questions covered areas beyond and boundary of our area of work. For e.g.we use to work in quotations but the questions came when the followup document is created from opportunity what is the processing logic and what happens when the quotation is accepted by customer.

Normally we concentrate on our area of work and tend to don't concentrate our energies on the boundaries and beyond it. This was a very good wake up call for us and definitely when we take up newer development tasks we would definitely be able to think in this direction as well. We have to think in terms of business process rather than the area of work.

b) One of the greatest concern came from performance related issues. I have to say performance is a much abused word. We have CRM / ERP landscape hence we have to make use of RFC calls many times. People tend to believe that RFC calls are always expensive but this is a misnomer. If we create a relation in CRM and use it to fetch data then also it is a RFC call but with a much heavier stack. Remember that when you call a method , a context switch happens and key variables are put in a register which would be used to start the program from the same context where it called a new method. With a heavy stack , this call is more expensive then a RFC call. The real test of performance can only come when measure the time taken by a method (under question) with the proposed solution. With this amount of explanation we were able to provide answers to some of the questions.

Also as a side note , SAP frameworks have inbuilt performance optimization built. If you have a 10 documents and you try to change a particular field in that document , then if the old value and new value are different then only the modify operations go through. Otherwise the change is discarded.

All this discussion actually help us think in the way a software should be optimized. Not just following the guidelines but trying to follow the guidelines in letter but in spirit.

c) There was a lot of discussion around the business process and the interpretation of change requests. Since we as developers think from a different point of view and the support colleagues had a different view point. We did not agree on many points and had to consult the stakeholders on this. Surprisingly few points on which we thought that stakeholders agreed that it  works this way though it could have been different. People are trained to use software in a particular way and people continued to use it that way.

d) Some of the components which were existing in some form and the concept was reused. For the support team it was one to one correspondence between the features but as we were unaware of the earlier components we never felt that they were reused. Most of the problems were because they thought that system should behave as it was in the earlier component which was latin and greek for us.

Funny as it may seem but it was such a wonderful experience and deep dive into technology , business process and understanding how business users use the tool. In the end I would say it has a layers of new perspective to how we write the solution.