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.
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.
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:
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.
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:
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.
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.
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.
- SAP Managed Tags:
21 Comments
