Skip to Content

Does SAP and the Utility Industry have a similar problem?

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 point of all this is that without knowing how the Fairlight worked at the lower levels, I could have spent weeks trying to solve this issue. 

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.

  • 12:00Watch 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.

/
12:00
8 Comments
You must be Logged on to comment or reply to a post.
    • Thanks Tammy – I appreciate the feedback.  The succession planning piece is actually one of the reasons I’m moving back to being an independent Architect/Developer. i.e. I was one of those managers without enough time to help others sufficiently.
  • Hi Matt,
    thanks for the great blog. After doing 20 years of SAP, and programming all the time, I agree that – as a senior – you have always the obligation to teach and mentor your surroundings as much as you can, even if it is not your explicit duty. On the other side, always be open minded and geeky as possible. There is always something to learn. On the current project, we had a young Developer Lead who is brilliant in object oriented design and ABAP OO. We always had a fun competition between old school (me) and new wild stuff. And I learned a lot here. You always need to stay curious on technology and never stop learning and wondering.

    P.S: Great to have the Fairchild legend stuff in the SAP world. I remember the 70ties when we all where drooling with our tape recorders and selfmade studios over the Fairlight but never could afford one. Just seing the new announcement at Winter NAMM this year, the new (reborn) Fairlight is in the range for an SAP freelancer. Just to get old memories up to date with current technology, I am really attempted to order one. It would fit perfectly my now full digital music studio. Just not sure if I get the budget through the family FI departement .

  • Matt,

    This is exactly what it is. With new tools, things may work super easy 80% of the time or take care of 80% of requirements, however it also means you are forever stuck at 80% if you do not try to learn or try to understand what is cooking under the hood(as an IT shop more than as an individual).

  • Matt –

    You’ve made some great points; I’ve been in the HCM space since 1993; I think we have the same issue with skills in functional areas, too. The truth is that it takes a while to master any given area and sometimes I doubt the general willingness of people to put in that time.

  • @Ondrej, @Steve, @Ajay: Thanks for the feedback and confirmation in part that this is a general issue in SAP.

    @Holger – It sounds like you have the perfect attitude and I commend you for that.  In regards to the Fairlight CMI comment: $20k is a little out of my league and would take up most of my very small “studio” space.  That said, I was very jealous of the hardware guys at Fairlight who all had 2nd hand CMI/MFX2’s and knew how to maintain them to keep them working. FYI – My ensoniq TS-12 does an okay job at the CMI III pad that I’m happy with for that classic fat sound – though if you get it and I get to Germany – we need to meet up!

  • Hi Matt,

    Well put – this is definitely something I can relate to as well and you’ve summed it up very nicely! I often encounter people who are all too used to the “magic” and make many assumptions about how things work under the bonnet without understanding basic concepts like I/O buffers or the relationship between a file, directories and inodes… 🙂

    Maybe part of this is due to the continual decline of the traditional “Computer Science” degrees in favor of more abstracted IT education (I am guilty of this!), or maybe it’s because of the continual addition of further abstraction layers in the tools we use every day.

    99% of the time this will be okay and won’t cause trouble. But I agree that a basic understanding of what’s “under the bonnet” is invaluable when encountering the remaining 1%. You don’t have to know all of the usually-hidden stuff – but you *should* know that there is hidden stuff and that it can be googled 🙂

    Just my $0.02 of late-night rambling :-p

    Sascha