The Big Picture
Back in the late 90’s, I used to work for Fairlight (the company who introduced sampling to the music industry that gave us those classic 80’s sounds behind Peter Gabriel, Stevie Wonder, Mike Oldfield, Duran Duran and many others). It was my first job, and I was privileged to work with some great minds that set me up pretty well to tackle anything that work life threw at me (but I digress).
Although it was an office R&D job, on one occasion I was sent to Hollywood from my Sydney home to diagnose a significant Fairlight issue that was happening within a new movie production studio (cool right?). I was given a couple of days to sort this issue out (you can imagine how much cost that is to a studio to do that), and to give you an idea of what I was up against, it seemed to happen in the mornings, but it wasn’t reproducible.
So where am I going with this? After a few hours I was close to being able to reproduce the problem by repeatedly restarting the system (amongst other things), but I could only reproduce it 1 out of 3 times. I was stuck effectively so I gave our most senior engineer a call and described how I could almost reproduce this problem.
Now did you know that in a computer, memory persists in RAM for many seconds when you switch it off and unless you initialise memory when you start a system, memory is actually random and not all 0’s to begin with? Well I didn’t…but the senior engineer did.
As soon as I combined this knowledge, it was only a few hours to write code to initalise the memory at boot and – hey presto – problem fixed and a day to cruise in LA was all mine!
The Aging Workforce
Now I’m not the expert on the aging workforce issue within the energy utility industry, but my interpretation of the issue is that for most of the 1900’s, the utility business was the place to be as an engineer, with huge investments in infrastructure. Then as we headed into the 80’s and beyond, the infrastructure building slowed considerably, newer more exciting careers were opening up for engineers outside of the Power industry (like SAP). Now over the next 20-40 years, the infrastructure created a 100 years ago will need to be refreshed and expanded, but those who knew the Power industry back to front are now retiring leaving a “potential” major skills shortage in the future.
So what has this got to do with SAP?
I started to learn SAP when 4.0B was released and as a developer, being in custom development (and not implementations), it really only took a few years to be on top of the possibilities within that environment plus you even had the ability to keep up with the new technologies being introduced. But from 4.7 onwards; things started to really pick up speed making this tough.
At first we started to see Portals, JAVA, Web Dynpro and other new tools that were still fairly low level; and those caught up in these new technologies were exposed to lots of fun (or pain depending on your view of debugging JAVA dumps, working out how to set-up NWDI, working out what a Business System is vs a Business Service, SLD, garbage collection, etc). The point being that you still needed to understand the underlying technologies and reasoning fairly well at this point).
But as the tools grew more mature and were enhanced to make things easier for developers and basis alike; development and basis became more automated. Best Practice guides and blogs led you down the right path, and things just worked.
Three examples come to mind in terms of recent change in SAP.
1. Web Dynpro for ABAP and the introduction of the code wizard. Suddenly, instead of needing to understand how to navigate the Web Dynpro class structure; you could just use a visual wizard – and hey – code inserted which seems to do the trick. “Don’t know what it’s doing, but it works for me.” Personally, I tend to majorly reorganise and optimse the wizard code; while I can imagine many developers just let it do it’s job for them. Maybe that introduces less bugs, but I’m not going buying into that.
2. I remember when the dual stack was introduced, and a discussion with what I thought was a senior basis person. We needed to start the ABAP stack but leave the JAVA stack down, and it was at this point that I discovered that the basis person didn’t actually know what startsap was capable of.
3. JAVA Stacks offer some great functionality, but unlike ABAP, memory leaks are frequently introduced – sometimes even in the core classes that you didn’t write. As far as I’m concerned, too few JAVA administrators and developers know about how JVM’s actually work and believe that monitoring of physical memory, CPU and disk is sufficient for system health checks.
In short, when everything works fine – these new approaches are great, but when you go outside the box, suddenly you find you have a major skills shortage unless you’ve been on the journey with each new technology/application.
So do we go back to Dialogue and Report Programming and a single ERP stack?
Please don’t get me wrong, I think tools like WD4A and add-on functionality are the future in SAP, but we need to make sure we protect our investments by ensuring developers learn the ropes too. Thorsten Franz wrote a great Model-Driven Development in ABAP about Model-Driven Development (in ABAP but also referencing CE) and this is where the industry is heading in general. He points out the various opinions about modelling verses coding in terms of efficiency, but key to his comment is that you can “break out” with your own coding when required. My concern here are the “developers” who don’t know how to “break out” and are not even exposed to the requirement to “break out”.
So what can we learn and do differently?
Ground rules for this question first. The Enterprise Geeks a while back raised some good points about general development capability. Hence, let’s just assume when talking about a junior staff member that:
- If they’re a developer: they are keen and have already learnt about debuggers, development and test approaches to begin with.
- If they’re a Netweaver Administrator: they know about infrastructure, ITIL processes, UNIX/Windows, etc.
i.e. We’ve hammered home the basics to begin with. You have bigger issues if this is not the case.
Okay, some ideas to what you can do differently:
Dig deeper into your solutions, and make sure you expose junior staff to real low level problems occasionally (even artificially). This applies to nearly all areas of SAP, even functional consultants. eg. Has your JAVA developer ever analysed a heap dump or looked at garbage collection logs to understand normal?
Think about succession planning – don’t just talk about it – don’t just promote your best developer to project lead and expect them to mentor everyone up while delivering status reports or doing performance reviews – actually make sure you continually train up people. People with 10 years experience, need 10 years experience.
Have sandpit systems available for playing – plus give people play time.
Build a network to engage others in the industry around any solution (not just SCN though that’s a good start).
Always question how the “magic” works. eg. When I get my hands on my first In Memory Database ERP system – I’ll want to know (at least) how it works so I can figure out how to both program sensibly with it, understand the possibilities plus understand how to manage it.
Watch out for senior 12:00 Flashers – That’s obviously a little too harsh (and that link takes you to the Urban Dictionary definition if you were wondering), but I have heard of senior developers who stop junior staff from trying new techniques or approaches (as radical as Object Oriented) as they know the old world so well. This is a very bad scenario in my mind as you’ll end up with a solution no one wants to support in the end (eg. Did you notice that good COBOL programmers are getting harder and harder to find now days).
Most importantly – Please understand how much magic is occurring in your solution to understand the risk by reflecting on the solution’s business criticality.