These Aren't the Developers You're Looking for

[jwood_bowdark]

As a development consultant that has worked in the SAP space for a long time, I'm frequently asked by customers (and recruiters) what they should look for when trying to find candidates to fill positions based on cutting edge technologies like SAPUI5/Fiori, SAP HANA, or SAP Cloud Platform (SAP CP). Though I enjoy these kinds of conversations because I'm an IT dork, I frequently find that my honest assessments on these topics tend to fall on deaf ears. I'll freely admit that this could be partly because my ramblings have a tendency to spin folks into a state of technical hypnosis, but I think there's also something about my response that they don't want to hear. What follows is my attempt to make sense of the chaotic world that is the SAP development ecosystem right now.

Changing Times

Even though folks are drawing up t-shirts that loudly proclaim that ABAP's Not Dead, there's no doubt that the SAP development ecosystem is changing. With the advent of SAPUI5, JavaScript has quickly established itself as a first-class citizen in the SAP development space. It's even finding its way onto the server with Node.js support in HANA XS/XSA and SAP CP. Similarly, Java has worked its way back into the conversation for developers building extension apps on SAP CP (and also HANA XSA). And with SAP's firm commitment to Cloud Foundry on SAP CP (and elsewhere), you can rest assured that other programming environments are headed this way very soon (e.g. Python, Ruby, or Go).

But the changes aren't just limited to shiny new programming environments: there's an increasing portion of the overall application suite that's no longer based on ABAP technology (e.g. SuccessFactors & Ariba). Even ABAP-based cloud solutions such as S/4 HANA Cloud or SAP Business ByDesign call for extension development using different environments (notably SAP CP). For customers on older versions of the SAP Business Suite or S/4 HANA on-premise, these developments may feel pretty far away, but things are moving fast and it's getting harder and harder to imagine a world where you just have an S/4 HANA instance on premise and nothing else.

Where Are All These Disruptions Coming From?

Many of the developers I talk to are dismissive about these developments, suggesting that these capabilities are mostly for edge cases and that these new programming environments will eventually be placed in a shallow grave alongside NetWeaver Java. To them, this kind of thing has happened before, but no matter what, ABAP has never relinquished its crown. So why is the current state of affairs any different?

I think there are several important factors (among others) which have converged to get us to a pivotal crossroads:

• The growing momentum of cloud adoption


• The consumerization of IT


• Ever-increasing demands for agility

With so many choices for cloud/SaaS solutions, departments within the enterprise are finding themselves with much more freedom to select the solutions that best fit their needs. If SAP and/or corporate IT can provide that solution great, but if not, they have other options. Suffice it to say that the same old solutions based on legacy technologies such as Classic Dynpro may not be enough to satisfy a customer base with increased demands for usability and mobility.

The end result as I see it is that IT landscapes will become much more fragmented with both SAP and non-SAP solutions spread hither and yon between the on-premise and cloud landscapes. For folks in IT leadership roles, I think this phenomenon presents an interesting dilemma: how do you streamline enhancement development around all these disparate apps? Does it really make sense to pay for lots of costly specialists to build native extension apps/mashups on top of SAP, Salesforce, etc. using a host of proprietary tools/technologies? Or, is it better to consolidate these extensions into a PaaS-like solution such as SAP CP? I don't think the answer is always clear-cut one way or another, but I certainly think it's a worthwhile discussion to determine a long-term strategy for building apps/extensions in an increasingly-fragmented landscape.

For companies like SAP, there's also a competition element in play. As more and more of their competitors offer solutions that can be easily expanded/extended using commodity skillsets (e.g. JavaScript), it's going to become increasingly difficult to sell the next generation of SAP customers on the idea of building on a proprietary platform with a fairly long learning curve and limited and somewhat expensive developer ecosystem.

The Great Learning Challenge

As I see it, the SAP development ecosystem as a whole has been caught between two worlds for some time now: the legacy world of monolithic architectures and huge on-premise installations chock full of ABAP Z-programs and a more modern cloud-based world which emphasizes microservice-based architectures, diversity of tools/services, and a movement towards centralized, cloud-native solutions.This transition figures to take years (perhaps even decades for certain industries), but I think it's more a question of when, not if at this point. And while SAP is likely frustrated that their investments in these areas have been subject to somewhat slow adoption, I think customers are starting to recognize the need for change.

It's at this point that the question raised as the premise for this blog usually comes up: "what kind of resources do I need to do some of this new stuff?" I think the answer they want to hear is that they can just leverage their existing ABAP staff to take on this work. After all, SAP is SAP and who knows SAP better than my superstar ABAP developer over here?

The problem that I see with this mentality is that there are many ABAP developers who are not well prepared to make this transition. This is not to say that they couldn't ramp up if properly motivated, of course. The important thing to note however is that many of these technologies come with quite a learning curve. For example, consider what it would take for your typical ABAP developer to come up to speed with SAPUI5/Fiori:

• First, this resource would have to learn JavaScript. And, to be clear, we're not talking about the JavaScript that was used in the early 2000s to validate forms, etc. To understand the SAPUI5 SDK, you have to understand a LOT about OO in JavaScript (which is night and day different from say ABAP Objects), asynchronous programming & promises, closures, and much more.


• Once a foundation in JavaScript is built, the developer is then ready to learn how to build web applications in UI5. This takes roughly the same amount of time it took for these developers to learn how to use Web Dynpro ABAP, if not more.


• If the developer wants to be a full-stack developer, then they're also going to have to learn about RESTful services in general and the OData protocol in particular. For some ABAP developers who haven't done much in the way of web development up to now (and Web Dynpro doesn't really count much here), they may also need to spend some time understanding how HTTP works, too.


• The OData learning exercise is complemented by some in-depth study on SAP Gateway technology.

All said and done, we're probably talking about at least a year's worth of learning for typical developers, if not more. Similar learning curves exist for developers looking to get started building cloud-native apps on SAP CP or full-scale analytic apps on native HANA.

Final Thoughts

As a developer that has invested considerable time and energy learning about these technologies and others over the past 5 years, I would tell you that the skills gap is real. There's a whole world of developers out there outside the SAP space who live and breathe this stuff day in and day-out. Fiori/UI5 apps are cool, but there are developers who have been building apps like this using similar frameworks such as AngularJS for years. They know JavaScript inside and out and don't need an OpenSAP class to understand how to jump in and use SAP CP because they've been doing similar things with AWS or Microsoft Azure technology.



When all is said and done, I think the future SAP development ecosystem will (and must) expand beyond the mostly ABAP-based community it is today into a more broad, diverse ecosystem with developers from different backgrounds. This certainly figures to present a challenge for customers/recruiters who think of SAP and ABAP synonymously. However, as we saw above, the requirements for a Fiori/UI5 developer have very little to do with ABAP. If you can find an ABAP developer who as made this transition, great - you should probably jump all over that resource. On the other hand, I would submit that it's not as big of a leap as you might think to consider a strong JavaScript full-stack developer who's been working outside of the SAP landscape using technologies such as AngularJS, React, etc.

As a consulting firm that specializes in these technologies, I can tell you that we struggle with customers who are hesitant to accept consultants who don't have your typical SAP developer resume with 10+ years of ABAP experience. Naturally, these customers want to ensure that they find resources who know what they're doing. However, when you think about it, many of these new-dimension technologies don't map to any traditional SAP/ABAP-based technologies. So, all that experience building SAPscript forms doesn't really translate into building a cloud-native app on SAP CP using Java and UI5, let's say.

I don't want to sound dismissive of ABAP experience, by the way. I think ABAP has and continues to be a great platform for building enterprise solutions but, like any tool, it's better at some things than others. In particular, I think it's fair to say that ABAP isn't well-suited for cloud-native development. If you don't believe me on this, consider that SAP itself has responded very strongly against any inquiries to have an ABAP environment on the SAP CP.

My point is that I think it's time for the SAP development ecosystem to really open its arms and embrace developers from different backgrounds into the fold. With all the digital transformation challenges that lie ahead, I don't see any way that the current ecosystem can expand to satisfy demand. The ecosystem needs fresh blood and ideas to come up with ways to utilize these new technologies to their fullest potential and complement the core foundation that's in place today.

That's my take anyway. I'd very interested to hear yours.

[moyalynne]

Thanks for sharing your perspective and writing this great post, James!

I think it’s time for the SAP development ecosystem to really open its arms and embrace developers from different backgrounds into the fold.

While that is definitely true, and we kind of live it out here in the Wild West where ABAP is probably scarcer than elsewhere in the world, as SAP Cloud Platform product manager, I definitely respect all the work that ABAP coders have put into their enterprise systems. Isn't that also part of the diverse mix of code that's out there?

[jwood_bowdark]

Absolutely! In no way should this article be interpreted as “move on from ABAP” type conversation. It’s more of a “how can the landscape evolve to promote these other environments as first-class citizens as opposed to bit players?” dialog. Some of these other programming environments that I talked about are ideally suited for solving modern IT challenges and that I think the community as a whole needs to start coming to grips with the idea that the ecosystem is going to have to expand into new and uncomfortable areas in order to keep pace with increasing customer demands.

 

[nomssi]

Hello James,

thanks for your well though-out discussion.

 

my guess:

SAP will push the ABAP Programming Model for Fiori to help ABAP developers generate applications based on BOPF, CDS and Fiori in record time without mastery of the new technologies.

At the end, it will be as messy as it now, from generate everything from smart models to implement everything yourself. SAP will provide the tools and let the market decide. Some teams will decide they need specialized know-how (UI5/JavaScript + Design + Graphics + ABAP) and others will be happy with an ABAP specialist who can produce nice read-only/batch-input/interactive apps.

Of course any UI revolution might change everything, so my predictions might not be worth 2 cents.

JNN

 

[ChrisPaine]

Hi, only short as on phone on way to work...

 

Firstly great post, well worth saying and well said.

 

I have a team of developers. I am encouraging all those that cannot JS to learn. But their valuable skill is their ABAP skill. Why? Because it is expensive and still required for full stack development. However, if you abap and can't gateway/odata you are pretty much heading for redundancy.

 

ABAP isn't dead, but full stack abap development where UI and biz logic in ABAP isn't​ going to float your resume to the top of the pile. You can WDA? Great, legacy support...

 

And given I can hire and train full stack java Devs for SAP CP builds, pay them 80% of what I pay an ABAP Dev and they are being paid top of market, and do this for less time and money than training up an ABAP dev. There is a compelling reason to abandon ABAP where possible.

 

ABAP not dead, but it is still too expensive for what it offers.

Cheers,

 

Chris

 

 

[jwood_bowdark]

While I agree that further tooling in these areas is no doubt on the way with S/4, my view of this conversation is that this is much bigger than Fiori apps. To me, the question you have to ask yourself is whether or not you think that ABAP should remain the default, go-to solution for custom apps/extensions in the hybrid/cloud landscapes that customers are moving into these days. In my opinion, these kinds of apps should be developed elsewhere and that means that ABAP is no longer the clear-cut choice that it was in the past for most SAP customers.

Using ABAP to implement surgical enhancements to SAP-delivered products is one thing, but there's an overwhelming amount of custom ABAP solutions out there that are perhaps only tangentially related to the SAP products that they're hosted on. Customers have built all kinds of solutions on AS ABAP systems for years because it was convenient, what they knew at the time, and most of the data they needed was conveniently co-located within the system database. This tight coupling comes with a price though when it comes to upgrades or eventual plans for migrating to cloud solutions. The same is true for customers that have built heavily on top of proprietary solutions included with Salesforce, MS Dynamics, etc.

Ultimately, I think a lot of this goes back to Vishal Sikka's timeless software principles where the focus is on innovating around the core. Whether it's SAP CP or some other cloud-native platform, I think the point is to start moving in the direction of microservice-based architectures that have the flexibility needed to keep pace with the demands of the business. If I move my solutions there, I'm no longer restricted by the limitations of ABAP or any other proprietary tool set.

[Jelena]

Chris, I can't speak for the whole world but I feel in the US the ABAPer salaries have been stagnant at least since the last recession (around 2008). The only well paid ABAP jobs are the senior, architect or team lead level ones. Plain ABAP positions are actually paid less than developers in other languages. I suspect the market has been oversaturated with the candidates who heard ABAP is well paid and now they're stuck because SAP job market is limited (especially in certain geographies).

On the other hand, "all purpose" developers enjoy more abundant and better paid employment opportunities. So this factor may contribute to ABAPers sticking around more and doing jobs that would've been better done by developers with other experience.

[Jelena]

James, thank you for sharing this very interesting and thought-provoking blog! I thought really hard on how to respond to it with anything shorter that another blog. 🙂

In short, I believe more accurate title would be "These are not the only developers you need". IT industry is only decades old and I feel it just very rapidly moves through the same transformations that other industries may have done over the centuries. I believe that long time trend will be toward specialization simply because information is reaching the critical mass when it's becoming too challenging and inefficient for everyone to be a "jack of all trades".

For example, in surgery you'd have an anesthesiologist, a surgeon (and possibly a specialist in specific type of surgery), nurses, etc. In construction, you'd have a general contractor in charge of the project, a carpenter, a plumber, etc. Of course, a rural doctor may even perform a small surgery if there is emergency and an average person can probably build a shed by themselves. But to do anything serious you need more people and you need specialists.

It's probably just the matter of the companies deciding whom to keep in house and which jobs to outsource. While large companies could probably afford to have both ABAP and, say, UI team with different skill sets, smaller companies will probably go for a "general contractor". I.e. someone who knows business and just enough of technology to identify the right resources to help.

In the near future I believe the SAP development ecosystem will consist of the Solution Architects, ABAP specialists who can and know how to work with other developers and non-ABAP developers who can work with ABAP developers. The ABAPers who can do nothing more than read a specification and support legacy systems will eventually find themselves unemployed. Although if this just flashes out the "dear gurus" crowd it might be a good thing.

Overall, it's not at all doom and gloom for all the ABAPers out there. Those who have good analytical and communication skills will likely have some exciting times ahead. Or at least that's what I keep telling myself. 🙂

[TuncayKaraca]

James, thank you for bringing this topic from ABAP developers perspective.  I agree with you that SAP development ecosystem has been changing and ABAP's dominance already been effected. This time is different than Web Dynpro Java vs ABAP Web Dynpro fight and ABAP's victory. If we check what's going in all non-SAP development ecosystem and JavaScript world we easily understand you aren't able to avoid this world and this is what SAP does by bringing SAP Cloud Platform, SAPUI5/Fiori, etc. Of course as long as your core SAP system (S/4 HANA on premise,) lives you will have ABAP for supporting your backend, but frontend choice will be SAPUI5/Fiori; even you are not restricted with SAPUI5/Fiori, you can go to other JavaScript frameworks.

[former_member182048]

Hi James

Love the title and content.

My point is that I think it’s time for the SAP development ecosystem to really open its arms and embrace developers from different backgrounds into the fold

I couldn’t agree more, SAP Ecosystem really needs outsiders communities to join the fold, but i see it more as a way to help improve the culture.

A couple of examples i have heard of lately which hopefully illustrates my point.

MYOB is an Aussie Financial Software company who for years developed Windows based software. To keep up with the market, Intuit, Xero etc. they had to transform to a cloud company, almost overnight.

Instead of firing all their Windows developers, they started to hire Ruby developers to help with the shift to the cloud. Ruby developers are dogmatic about TDD and quality in general, this eventually rubbed of on the Windows developers and together they went from a team that apprehensively released code once a year, to a team that releases code to production many times a week.

Westpac one of the big Aussie Banks has a similar story, competition started closing branches and moving more of their financial services to the cloud, to keep up, they didn’t fire all of their COBOL developers and or tell them to not touch the cool new stuff, sure there would have been considerable attrition, dead wood needs removing, a lot of those COBOL developers now write Micro services in Java and front ends in Javascript.

I see SAP and their customers going through similar transformations, you cant say out with the old in with the new, you will lose all the business knowledge and experience gained over many years, instead i think its a matter of infusing cultures with the behaviours you believe they need to succeed. If there is a learning problem, bring in people eager to share, I have worked on teams where we have bought in Angular developers to teach us CI and agile engineering practices, UX designers, devops, agile coaches likewise.

JSP

[jwood_bowdark]

Yes, that would have been a better title. 🙂 I suppose the title I came up with was a product of frustrations I've had with community members that are overly dismissive of resources that come from non-ABAP backgrounds...

One of the peculiar things I've found in my experience working in SAP is that the community as a whole doesn't seem to value core programming skillsets very much. In other environments I've worked in, there's not as much emphasis placed on a particular programming environment like there is with ABAP. Instead, the focus is more on understanding of OO concepts, design patterns, analytical/problem solving abilities, etc. Here, if a developer has these skills, then they should easily be able to jump into some other technology stack and be productive.

In the SAP world, it often comes down to years in. For example, I saw a job req the other day where the customer was looking to build custom Fiori apps from scratch and there was a hard requirement for 10 years of ABAP experience. While these kinds of requirements are often just boilerplate items added to any SAP job req, I have had many conversations with folks out there who adamantly believe that this is in fact a hard requirement because OData service development in SAP Gateway requires deep ABAP experience. My counter argument to that is that I routinely see highly experienced ABAP developers develop horrible OData services. This is not a knock on them as developers - they're very talented. The problem is that they don't understand RESTful service design principles in general and OData consumption models in particular. As a result, they bring their considerable ABAP experience to bear on solving all the wrong problems. I see similar issues with ABAPers working in SAP HANA and other new-dimension technologies. My point here is that these new technologies are not unique to SAP; there's a host of developers out there who have been doing this stuff for years. The only difference is that instead of SAPUI5 it's AngularJS, and instead of SAP Gateway, it's ServiceStack or whatever. So, while they may not have 10 years in ABAP, they definitely understand how to build SPA apps, etc. using the right techniques. To me, if you have these skills, the ABAP part of this equation is the easy part.

In the end, I agree that the community needs more specialists, but I would also submit that we also desperately need more generalists, too. The IT landscape is becoming increasingly diverse and complex - so much so that generalists are needed to provide the glue that holds projects together. When I'm leading a Fiori or SAP CP project, I don't have time to stop down and teach developers how to use Git for the first time or explain to them what JSON is.This is where I think developers from other disciplines can help bridge the knowledge gaps and diversify the team in new and positive ways.

[jwood_bowdark]

Hi John,

I love the idea of building diverse teams like that. In my experience, it just brings so much energy to the entire process. Several of our new hires have really challenged me to question the way I've done things for years and really helped me embrace new technologies I would have been dismissive of in the past. I look around and see some of the innovative things start-ups are doing with cloud-native development frameworks, CI/CD, etc. and it pains me to see how much most SAP projects still live in the dark ages. Here's to better times ahead.

 

[Jelena]

I'm with you completely on the "years of ABAP" requirements. To be honest, it's not even needed for many ABAP jobs.

Some companies don't even take advantage of their own internal resources. E.g. where I work we have tons of non-SAP programmers that develop firmware for our products and such. I bet we could share a lot with each other but it's never been encouraged. (There might be some political element at play, I suspect.)

[Jelena]

Great examples. My own SAP experience started with "company did not fire all their mainframe developers". 🙂 Exactly as you described - some "dead wood" might have to leave but when such cross-pollination happens it really benefits the whole team.

[former_member182638]

Hi James,

I really enjoyed reading this post.  Thank you for taking the time to write it.

It reminds me of this quote that I saw in a blog last year ...

“Software keeps evolving, and so should we; no-one got into software to watch the world pass them by”

– Gant Laborde

The interesting thing is how fast customers will realize that they need more than ABAP development skills to innovate on their SAP core.  It also means a stronger recognition and respect for software development, which exists in Silicon Valley but not so much in the SAP customer base (indeed I would argue quite the opposite for some customers and integrators).

A trait that I look for in developers is the right attitude, whether they come from an ABAP, Java, JavaScript or whatever background.  Do they actually have an interest in development, in learning new things and approaches.  For me that is the starting point and what differentiates the roles of the future from those of the past.

Cheers

John

PS.  I read your HANA Cloud Platform book from SAP Press in December and I loved it.  Damned SAP just changed the name though!

 

[Ivan-Mirisola]

Hi James,

I loved your take on the subject. Thanks for sharing it.

It reminded me of many discussions around technologies that naturally evolved for the greater good, such as: RISC x CISC; Mac x PC;  Android x iOS and many others (and don't start asking me which of those I use/used). Whenever this discussions came up I always had the firm belief that each had its strong aspects and were targeted to solve problems differently. That's the beauty of it! You must always try to find the right tools for the right job whenever you needed. My point is, you most certainly need the find right people to use the proper tools to solve different problems. This is so true when talking about people trying to solve matrix transposition in HANA tables by using all sorts of techniques that mimic the actual formula used by other solutions such as Octave which will do it in just about 1 line of coding.

Efficiency will be the new trend now (cool tool). Of course one could achieve a lot of the same UI features of a modern UI interface being an ABAP developer with BSP skills. But that would be extremely inefficient and expensive. Thus, companies will tend to naturally steer away from 100% ABAP developers to other kinds of technologies that will support them being innovative and staying in the market. Otherwise, they will be just like those old companies running CLIPPER applications for the rest of their lives.

I totally agree about differences in the current state of affairs. Its no longer a fight between what I know (i.e.:ABAP) and what you know (i.e.:Java, JS, etc.). Cloud Foundry, XSA and other Cloud technologies will not only give freedom of choice to use the right tool to solve each problem, but will bring new horizons to hiring skilled people.

I was totally amazed about Node.RED the other day and how much you can do with it. I couldn't even begin to imagine these things 10 years back. Now one could simply develop something using this technology and push it a platform without caring about which OS and sub-systems it will need. It will simply be a piece of a broader solution using Microservices. In other words, you became efficient by solving the problem with the right tools.

I also agree that ABAP will still remain there simply because it is still part of SAP's core.
However, I foresee that ABAPers will either migrate to CDS development or ramp up to newer technologies (mainly REST/OData). If they choose to not chose they will probably remain as supporters of the core, by developing FM to be used by OData Services. It will likely be what happened to COBOL developers (still out there making their honest money for people that can afford them).

Regards,
Ivan

[Jelena]

Re "recognition and respect" - I find that outside of technology-oriented companies the situation with the whole IT can be summarized in two sentences:

"Everything works OK, so what are we paying you for?"
"Gah, this is broken! What are we even paying you for?!"

I'm with you regarding the right attitude. Unfortunately, in many cases hiring decisions are made rather by looking for the keywords on the resume. Not many decision makers understand that it's not as much about what you've done but rather what you could do.

[lbreddemann]

Thanks for this piece, James, it is, as others already mentioned, a good read about important topics that affect everyone working in the SAP realm of IT.

At first, I was a bit surprised to read that there actually might be the notion held, that the current development tools trends and currents could be waited out and mainly ignored for good. While one can obviously just do that, the important bit is that this one still wants to retain his relative importance to the current employer and the job market at large.

That's where it's getting fuzzy and in this blog and in the comments some concepts are merged together into very discrete meanings.

You explained what you see required to get a good level of knowledge for the "full stack developer".
I don't disagree with the collection of training units - these are probably quite alright. But realistically, many, maybe even the majority of developers are not "mastering" their field. Not all of them are just "ace-ing" it and producing A-level output.
In my experience, there are many that simply plough along with their coding.
There surely are lots of reasons for that (the already mentioned learning investments over the years, the unfamiliarity with new tools and ways of thinking, the delayed gratification of efforts, ...) and each of those requires a separate approach for supporting the future relevance of the developer.

Side comment: interestingly enough, only "hard skills" like new tools and processes made it into this observation. Critical "soft skills" for any "career development" are not even mentioned. I dare to say that this is a huge contributor to the stagnation of developer's relevancy in and outside any organisation.

Another topic is the notion of "the demand".
The IT industry is particularly immature when compared to established disciplines. The entry and retention in it are largely unregulated, strict quality rules are nowhere close to be commonly agreed on which is also true for any tools, techniques or processes employed in it.
In short, it's still the "wild west" version of an industry.
While this doesn't sound too positive (because it really isn't), this situation provides several interesting opportunities:

• the overall demand is growing


• the overall salaries are increasing


• the range of technologies for which there is demand is widening


• the use of IT is more wide-spread and teleworking has become much more commonplace, which means IT work demand is much closer now to any potential IT worker


• education and training in IT topics has become as cheap as 'free' (ok, a caveat here, one has to put in time and effort and usually has to pay for a documentation of these efforts)

So, the overall market is sort of 'stretching' out, but not necessarily moving away from any specific technology in total.
Put another way: the cake is growing and keeps on growing as IT is deemed applicable to more and more things.

It's likely that there will be jobs for "maintainers" for the next, say, 15 years.
That's nearly half a full working life to be doing what one is used to do, without much of change or need of massive "re-education". (I vividly recall some SAP Basis consultants who still make their nice living by installing patchsets, configuring printers, installing SAP GUI to laptops etc. - their credo: "always be one page ahead of the customer in the training manual")

The same companies that Jelena mentioned of being dismissive of the relevance of IT are the ones that are willing to pay even for simpler services.
Not the worst deal, I'd say, if you're up for that kind of working situation - and apparently a lot of people are.

This brings me to another aspect: how is it that there are these people? Aren't they excited about IT, progress, new stuff, the future, technology and flyin' cars?
Probably not - which gives the hipster Bay Area IT culture a big fat turn to the cold shoulder.
The simplistic ideas of everyone being fulfilled and over joyous by working in a creative and challenging environment where one can truly find and expand its own abilities - they are mostly just that: simplistic.

Most folks I know, like their job (or at least don't despise it), but nobody I know takes her/his live's meaning out of it.
To a degree, it's just a job for them, not the centre of the universe.
I'm happy to admit, that this sample is rather limited, but I also think: good on each one of them!
There are more important things in life than the job.

While this is probably clear in itself, the demand for constant education is certainly one that many haven't bargained for. I guess, the fact that this permanent education is not part of the mainstream culture in IT is the reason for a blog post like yours in the first place.

What gives?
As usual, most people proficient in their job and tools will continue to be employable and continue to tag along with the success of other value generating industries.
Will the relative value of what they can provide without further education decrease/increase/stay the same? For the majority probably decrease, while still maintaining an above average salary for relatively easy work. No reason for panic there.
Just that: to keep your financial situation where it is/where you want it, you likely have to increase your income.
And this is really the core of the issue.
If you want to do that, you want to know the stuff that's going to be important and hopefully for some time. But what will this be?
SAP and the whole IT industry have shown us again and again that it has zero problems to come up with a whole new development environment, pushing it for years only to let it die eventually.
Vendors are also just players in this market and try to make a very similar bet. (is it going to be HANA or HADOOP or KAFKA or CSV file analytics or really everything in the cloud or wrist-watch computing? What about Bitcoin? And is SEO really dead? Maybe GPU-coprocessing in the mobile browser will save the day?)

For the folks employed in those organisations that now make the move towards value generation through IT, the story is clearly different. They just have to know the latest stuff, because "knowing the latest stuff" is what they are offering to the market.
But, despite all SAP marketing, I fail to see that this is the majority of all customers. Not that there aren't many, really big customers that are doing exactly that - but remember that SAP has a long tail of smaller customers, too.

My take on this hairy matter is this: there's more stuff to learn than anyone could possibly bring up the time for. So focussing the learning to the "right" stuff is important. "right" means: applicable/marketable and valid for as long as possible.
To me, that can only be a mix of playing around with new tools and revisiting the foundations of our profession.

If I need a new job tomorrow, I'll probably not going to be hired for maintaining an interest in IT papers written 50 years ago, psychology or philosophy and comic books. For that, the current tools know-how is likely more important. But to enable any kind of job flexibility, the other stuff is really important. It is what allows you to get the changed perspective that might be worth the 80 IQ points one day.

Sorry this got so long - it's a mess.

 

[former_member182048]

Hi James

“it pains me to see how much most SAP projects still live in the dark ages”

Yep. I’m reminded of the Drucker quote “Culture eats strategy for breakfast”, seeing lots of companies attempting a top down transformation, not seeing many senior managers walking the talk though and this disconnect means IT lead projects repeat the same mistakes over and again.

A side note, one of the issues i have seen with building a diverse team and or hiring from outside the ecosystem, is it is hard to get good developers to cross the chasm.

For example convincing a good AngularJS/Ember/React developer to learn SAPUI5 is very hard. To an outsider the SAP ecosystem is very proprietary and insular, they have nothing but perception and stats to fall back on, eg 1 role being advertised for SAPUI5 vs 100s for their in demand skill set. As our ecosystem become more cloud focused we are in danger of seeing another Java Webdynpro problem, only CF flavoured. Open technologies, with high barrier to entry because of proprietary packaging and branding.

My observation, we are seeing companies like Apple and Google wanting to get a piece of the Enterprise. I think SAP needs to reciprocate and go to their communities and bridge the chasm and give some compelling reasons for fresh ideas and behaviours can come and help transform our culture, Hana Express is a good start, just feel it needs something more compelling, needs an interoperability story, not a Diageo story </rant>.

JSP

[ChrisPaine]

Hi Jelena,

Whether ABAP dev salaries have stagnated or not (they don't seem to have gone down much here in Australia), to get a good ABAP dev vs a good full stack java Dev, it's still far cheaper for the second. This comes from my own experience in hiring them here in Australia, perhaps it is different elsewhere in the world. The long term emp does have be benefit of domain knowledge which should not be discounted! So as a good employer who cares about their people I would retrain them. And I would be hopeful to get a good developer who knew my business.. Hmm how many employers care more about their people than $$$?

Having seen some rather silly business decisions in my years because the average tenure of a CIO is less than 5 years, I suggest that short term ROI is often more important than longer term solutions.

Today I saw the stack overflow annual survey, I was kinda shocked how much I was paying for ABAP skills compared to what the general market for other skills is.

In the end, however, SAP skills will remain niche market, it will just be a tiny bit easier to pick up UI5 than ABAP was. Knowing how to manipulate the poorly documented APIs will be the skill!

PS, fully agree with your comments back to James below.

Cheers,

Chris

 

[former_member242034]

"Many of the developers I talk to are dismissive about these developments, suggesting that these capabilities are mostly for edge cases and that these new programming environments will eventually be placed in a shallow grave alongside NetWeaver Java. To them, this kind of thing has happened before, but no matter what, ABAP has never relinquished its crown. So why is the current state of affairs any different?

The growing momentum of cloud adoption
The consumerization of IT
Ever-increasing demands for agility

"

It took me a very long time to understand ( 11 years ) that SAP is an ABAP company, and all roads in SAP will lead finally back to ABAP. I have done programming in ABAP, Java, Portal, BPM now SAPUI5 / Fiori and HANA.  Have worked with all kinds of people in SAP.

SAP keeps the core running in ABAP and adopts any shiny new technology at the edge. Nothing wrong with that but then people start to pin their careers and hopes on these shiny new thing thinking of it becoming the core and then comes a rude shock that SAP has moved on to something shinier and all your experience is down the drain, pick yourself up and relearn or unlearn and carry on.

SAPUI5 / FIORI will be be autogenerated in the future directly from WebIDE and CDS views , OData etc, there won’t be any need for specialization. Only if you want to build something crazy fancy, but Javascript programs are not meant to be long term programs for example it is cheaper to throw away a Javascript program then to understand and extend it. You see what is going on in Nodejs NPM space where every noun is a package name.

SAPUI5 is extraordinarily good framework but with an extremely high learning curve. I was there when it was called Phoenix, but still today i struggle to understand the nuances, the tooling has helped, but to expect a even Javascript programmer to pick it up will be a stretch, let alone an ABAP developer.

Non SAP guys are not encumbered with all these details on ABAP Tranports , Solution Manager, QGM , HPQC, Service Now, Remedy ( ahem ).

They would want to work on Chai, WebPack, Jenkins, Gradle, Git, Gerrit, VSStudio or Sublime text. They would never fit in SAP ecosystems, trying to fit them here would be a mistake.

But my hope is new ABAP develoepers ( the one i see at my workplace ) they understand these concepts far more easily, use innovative ways and new ABAP functionality to come up with solutions and work well with SAPUI5 team. I’m betting on these new ABAP guys to carry the mantle in the future.

[Former Member]

Very well-written, thank you! Of course, it would be advantageous for full stack developers, and even for frontend developers to get familiar with SAP products and with ABAP in particular. I am pretty sure this will help to make a greater performance and more elegant and attractive for the clients user interfaces.