The other day I stumbled across this quote in a blog by Gant Laborde, which whilst generic in context is easily applicable to the world of SAP …
“Software keeps evolving, and so should we; no-one got into software to watch the world pass them by” – Gant Laborde
With this quote, and as this year marks my 20th in the SAP ecosystem, I reflected on a contentious blog that I wrote over 5 years ago on the SAP community network titled ‘Can we reinvent the grey haired ABAPer?’.
For SAP developers, it has been a tumultuous journey. In the glory days of the 1990s SAP development was somewhat restricted to a limited set of development practices – primarily screens, function modules, reports, enhancements in the form of user exits. I remember the early 2000s when SAP’s technology head at the time Shai Agassi proclaimed that ‘Java is the language for the user interface’ as SAP sought to redevelop new user interfaces using the NetWeaver Java platform. I saw the fear in some developer’s faces at having to pivot their skillset to an entirely new language set and object oriented development. Indeed only a small proportion made the leap. Some developers were left behind. Of course years later SAP circled back to standardize on WebDynpro for ABAP and Floorplan Manager for the user interface. It introduced other concepts such as Personal Object Worklists, CHIPs, and so on. More developers were left behind. These days with SAP embracing Fiori and HANA technologies, SAP developers are expected to stretch their skillsets to optimising code for HANA’s columnar storage, exposing OData services using NetWeaver Gateway, and via SAPUI5 developing in Javascript (no, not Java) for the user interface along with having a good understanding of HTML5 and related concepts. And most recently SAP expects developers to pursue extensions to SAP solutions in the cloud via SAP HANA Cloud Platform (HCP). More developers will be left behind. Add to this the critical skills of understanding specific industries and business processes (which comes with experience), the expectations of a modern day SAP developer have never been more demanding.
Those of us in the know understand the depth of knowledge expected from a fully rounded SAP developer these days (and I’m sure many of you can add many more technologies, acronyms and so forth that I’ve not mentioned here). But it does telegraph one important thing … that the concept of a generic SAP developer is a myth. In reality, each developer is unique, and has evolved to a certain level along a multi-dimensional continuum of skillsets and technologies.
Looking at the above diagram, we could argue about what technologies should be listed and when they were introduced. But the point is this … the skills challenge is getting increasingly more difficult as SAP continues to evolve with new technologies without deprecating the older ones (think SAPScript etc). Even looking at SAP’s S/4HANA release, it seems that many older technologies are still running alongside newer approaches. Which means an SAP developer is expected to stretch their capability across a widening breadth of technologies and approaches. Or projects are expected to double up on resources to achieve this coverage of skills.
Now more than ever, it’s important to curate the right individuals for your development team. Don’t treat them as generic commodities. Think of your development team as the engine room via which you can build innovative solutions (eg. mobile apps) on your SAP digital core. Finding the right ones can help to propel you forward and keep your systems relevant.
It’s why myself and those I work with see good developers as enablers and respected consultants, not commoditized order takers. That ethos is enshrined in our manifesto. But when I say ‘developers’, I do mean the ‘right developers’. Those that seek to evolve. To move beyond your SAP GUI. The ones that don’t wish to ‘watch the world pass them by’. This blog is dedicated to them.
Comentários