Saturday, September 19, 2009

SAP ECC6.0 : My thoughts to other developers...

Of my 6 years as a developer, I'd met a lot of good, inspired and even bad programmers. Everyone of them has a different way of doing their programming. Some are so organized right down to one line of data declaration it is neat and clean. These types of programmers gives good programs and will have less errors and ensure good enhancements in the future. Now, there are those who care less about coding management and gives you less desirable result. These programmers gives you lots of errors after roll out plus nightmarish future enhancements. It's not that they are not experience but resultant of the attitude they carried in their development.

There may be many factors as why one programmer does not pay any attention to coding management and I can give you some examples. First, it is just programming and as long as it works and get the results. This is a grossly injustifiable attitude in programming, the person just want the program to work only. This behavior will always result a messy piece of coding. Future maintenance will be very terrible to maintain. A messy code usually make enhancement difficult when original flow is thwarted from working normally. Second, seasoned programmers who had to make a change to learn new programming language. This behavior is a result of their mindset which was so fixed to their old programming language's behavior that they could not find a way to accept the new programming language's behavior. This kind of scenario is similarly to a management changing their company's direction and many of their staffs finds it difficult to adapt to new challenges. So, it is the same when a programmer changes to new programming language.

If you just program a program for the sake of "I-am-force" to use a new programming language I am very sure you will find that programming new languages dull and eventually you will dread coming to work and see that language every day. I was a C programmer when I started working. Then I'd change to working with Visual Basic until I saw it became Visual Basic .NET. Finally, I settled with ABAP for SAP. With all these languages I come to understand that each of them requires different understanding to be able to use it. I am not saying ABAP is a good programming language or C is difficult language to use but each of them has it own unique feature that require your time to understand them. In my years of doing ABAP, I see many ABAPers, especially the new ones, complained why it doesn't work like web programming languages or like Visual Basic. I can only say one thing, they are trying, with some degree of difficulty, to accept the language's behavior and its way of usage.

It is normal and one definitely need a lot of patience and practice. It's like a programmer who has been so use to programming Visual Basic suddenly change to C++ and he needs to grasp the language so he could start programming for his assignment. At this level, one need to find time to understand and learn to accept the new language's behavior. I have a colleague who thinks that all languages are just getting data, processing data and displaying data and one should not focus on just one programming languages. That is good in my opinion as one need to diversify in order to survive otherwise when one language is consider obsolete you will have less opportunity to work in projects. Yet, this colleague of mine will less likely to accept the difference of behavior in each language he uses. One language can do such function with one routine but that does not mean the other language can also perform back similar routine. Most of the time, it requires a different approach. ABAP is a good example, it does not work like any other web languages. It is a proprietary language cater for business reporting and customization of SAP. That point itself it is always overlook by many new ABAPers when they start to compare with other languages.

On one hand I totally disagree with my colleague's atttitude towards all programming languages too because he has taken to a level to think that all programming languages are just getting data, process data and displaying data. I believe my days will be just as dark as the charcoal you get from the coal field. Why? This explanation gives me an impression my job is bored and dull and there's no excitement in doing programming and customization. However, if you regard your programming language as a tool to solve unique problems then I can give you one beneficial possibilities that your working life as a programmer will not be as dull as it is like any mundane routine. I like programmers has the fire or passion in their work. In every work, you need to have understanding and a degree of passion in it. Otherwise, there will be no more creativity to solve problems.

"Programming is an art or skill that requires passion, understanding and patience so it can be a masterpiece" - William Wilstroth

william wilstroth... programming is an art

Friday, September 11, 2009

SAP ECC6.0 : Roll Out

Editor : Just in case, you are wondering what happened to my old technical blog. Here's the link isskythelimit-technical. I had it revised and migrated to this new blog. All my old entries still remains in the old blog. Thanks!

It had been almost half a year since I participated in ECC6.0 roll out at the end of 2008 for EU, the Americas, and Asia Pacific. I was in a team responsible for Asia Pacific region and Germany being the leading team started the roll out at December 2008 with a blast. Things were getting excited and my team had faced a number of challenges but had it solved before the go-live. It was a challenging but wonderful journey. Some of the things I'd learned from the roll out, I list it down as below:

1. Unicode translation need to be taken care of because ECC6 is unicode enabled system. It means all custom reports had to be flagged for UC. It's not all that easy because you need to identified all programs that is not UC enabled prior to 4.6c.

2. Codings in existing customized program, forms, function modules, batches, Idocs and other customized include programs had to be check out for obsolete coding and to be replaced with newer ones especially strings and certain standard function modules.

3. A lot of testing were carried out by our functionals to ensure that all processes and customizations are working fine accordingly as in the old system after stages of migration as in ECC6.0.

4. There was a UC team specifically to handle unicode and language translation on various countries like EU, China and Japan. It was a gruesome task especially tables are language dependent. SUMG is a good TCODE to maintain your translation objects.

5. Migration of development system, quality system and production system are taken stage by stage to ensure, I should say, a smooth upgrade that does not impact the business process or users.

6. Then come after the roll out, the warranty of supporting all users so any unfound errors left in the upgrade process can be iron out. So this is another last wave of support. There after, its back to normal support and development routine.

Six month upgrade project that I had gone through with the team. A good deal of fine functionals and a four person development to support only Asia Pacific region.

Some reference for everyone who is undergoing ECC6 Unicode Enabled Upgrades:
2.TCODE : UCCHECK - Unicode Check program

Welcome to my new technical blog!

williamwilstroth... ecc6.0 roll out...