An ABAPers carreer path in HANA

(This post was originally written in the Open SAP HANA discussion forum. I have revised it for posting here, since I believe it deserves a broader discussion).

Hi everyone,

I discussed HANA with a fellow ABAPer the other day, and decided to write up the points that ended up crystallizing themselves during our conversation. My friend had not been following the OpenSAP HANA course, but wanted to know the Impact of HANA on the ABAP world. It got me thinking, and this is the result – for whatever it’s worth.

Key points: focus on the SQLscript/stored procedures areas, don’t bother too much (yet) about the UI aspects (UI5/server-side JavaScript).

That got you reading? Good 🙂 Here’s the rest:

Various postings have been written trying to outline the new and exciting carreer opportunities that come with SAP HANA. Most of these have been focusing largely on XS, and the need for skill sets like html/UI5 and JavaScript. A certain confusion seems to prevail as to whether there are incentives for ABAPers to cross over into this new world of UI development, or whether it will lead to a segregation of developers along the MVC principles, as for other environments. SAP seems to push UI5, coupled with XSJS, stating that these are key skill sets for the ABAP community. By doing so, it is also implied that HANA will be chosen as much for its simplified application server (XS) and presentation paradigm (UI5) as for optimizing new and existing ABAP-based applications.

I’ll focus on the ABAP side. My personal opinion is that the average ABAP developer would profit from focusing on SQLscript and the ability to create views (analytical, calculation and so on) in the HANA repository, as well as learning how to create and consume stored procedures. In fact, I believe this (learning how to push business logic down into the HANA DB) will become a key skill set for any ABAP developer worth their $$ in the years to come. Here’s why:

As a future ABAP developer on a HANA system, you have two options:

• Write your standard ABAP report as before, hoping that the inherent added benefits of an in-memory DB will make it run faster
• Or, take advantage of the possibility to push logic down to the DB level, by writing SQLscript procedures and exposing these.

The second option requires that you familiarize yourself with SQLscript, HANA view modelling, and creating/exposing database procedure proxies in HANA. An ABAP developer with the above skill set will be far more efficient than any classical ABAP developer still firmly rooted in the Netweaver ABAP stack, refusing to take the leap. This, of course, also requires that your organization allows for ABAP developers to start hacking SQLscript and building stored procedures, but with the performance benefits this will surely bring, I don’t see why this would not happen.

As for the other exciting opportunities within HANA, such as UI5, Server-side JavaScript, and REST services, I honestly do not believe these to be too practically relevant yet for the vast majority of ABAP developers.

Why? Several factors. To focus on the development community itself, I believe it was John Moy who coined the term “the grey-haired ABAP’er” some time ago – a term still very much alive. I don’t have any statistical evidence for this, but I firmly believe that less than 20% of the ABAP community are proficient in OO-ABAP; less than 5% can be said to have a thorough knowledge of WDA, whereas probably less than 2% can hack FPM. And, these are technologies that have been around for the last 5-10 years. Do we really see these people embarking on a UI5 journey anytime soon?

Secondly, SAP will surely continue to focus on WDA/FPM as the main UI for ABAP-based functionality, and I believe most customers out there will have a hard time seeing the benefits of exposing their new HANA platform via the XS app server to any extent (meaning creating REST services and exposing these using UI5). For some, small-scale applications, this might be done, but the administrative barriers (new role sets, authorization issues, maintenance of two distinctly different lines of access to the underlying data) is not going to sweeten the taste for most larger corporations – again, this is my own, personal, humble opinion.

By all means, obtaining such skill sets will set you apart, and add to your general marketability. However, most ABAP’ers will never make it as UI5 designers, as the inherent skill set for such tasks is different by nature. There’s a reason why the engineers building car engines do not simultaneously design the cars… although a good understanding of the architecture will allow you to bridge the gap between the UI design team and the backend busniess functionality team – which could come in very handy indeed!

What might happen, to some extent, is UI5 taking root as a contender to WDA/FPM, but more on the traditional Netweaver/Gateway stack. When that happens (and it will only happen when or if SAP provides a decent IDE for visual UI5 development – no grey-haired ABAP’er will come around to hack JavaScript anytime soon), we might just see UI5 gaining grounds on WDA/FPM. But what I see as the most probable way forward for the vast majority of the ABAP community – and where real gains can be made by SAP customers – is in the usage of HANA DB procedures consumed in ABAP. This is where I see the ordinary ABAP’er being able to make a real contribution – with a manageable level of effort.

So, to conclude (and I hope I don’t come across as too pessimistic here – I’m just trying to keep my feet on the ground), I believe ABAP developers should focus on the HANA Database Procedure area – at least in the short- to medium timeframe. This means SQLscript and view modelling – in short, learning to map the current “data to code” approach to the HANA-style “code to data” way of doing things. This, in itself, will be an exciting challenge, and could pave the way to further insight into the HANA XS world.