These Aren’t the Developers You’re Looking for
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.
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.
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:
- 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.
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.