Last week, I had the pleasure of attending Björn Goerke's executive keynote at SAP TechEd 2017, Las Vegas. While there were many interesting take-aways from this talk, perhaps the most notable bullet point for developers like myself was the announcement of SAP's plans to eventually provide an ABAP development environment within the SAP Cloud Platform (SCP). Though this development was met with thunderous applause throughout the SAP community, I find myself rather skeptical about the benefits of adding ABAP into the cloud development mix. What follows is my attempt to explain my concerns.
Before the #ABAPsNotDead lynch mob comes knocking at my door, I want to issue an important disclaimer: I think ABAP is a fine language for developing on-premise enterprise applications. I've developed with ABAP extensively for going on 17 years now and have written several books on the topic, so please know that any conclusions I may draw here were not formed haphazardly. Suffice it to say that I'm not an ABAP hater just trying to throw shade on old-school technology.
Ever since SAP released the SAP Cloud Platform (back in the Neo/HANA Cloud Platform days), I've had many discussions with developer peers that dismiss the SCP as just another attempt by SAP to push Java on the developer community. Sort of like a NetWeaver Java 2.0 if you will. However, while Java has been sort of the de facto flagship language of the SCP to this point, the open approach SAP took with SCP is so radically different from NetWeaver Java there's hardly any comparison between the two platforms. This is not just about ABAP vs. Java (or any other language for that matter).
As a Platform-as-a-Service (PaaS), SCP offers so much more than programming environments like Java. The whole point of a PaaS offering like SCP is to provide developers with a modern and flexible environment that can be used to rapidly develop new applications, extension apps, and so forth. Included in this environment are a series of backing services which span lower-level functions such as persistence and connectivity, platform-level services for rolling out mobility and IoT solutions, and even business-level services such as SAP Hybris-as-a-Service (YaaS) which provide reusable application building blocks such as "tax-as-a-service".
As you experiment with the platform, one of the things you'll notice is that these services are language-agnostic. Indeed, when you browse through the SCP help documentation, you'll find lots of examples for consuming these services from Java, Node.js, Python, and so on. This separation of concerns has become even more pronounced with the release of the (relatively) new Cloud Foundry environment which has ushered in a true "bring-your-own-language" (BYOL) approach to app development on the SCP.
As a developer, I've been very excited about the BYOL language approach afforded by Cloud Foundry, but not just because I want to tinker around more with Python or other language types (although that's definitely true). The primary advantage that I see with the BYOL approach is that it gives developers a much more modern tool set to deal with one of the biggest challenges I see in enterprise development space right now: gravitic anomalies.
If you look at the figure below, you can get a sense for what I mean when I talk about "gravitic anomalies". While SAP S/4 (or SAP ECC/SoH) on-premise systems remains a crucial part of the digital core for most companies, lots and lots of new cloud-based systems are popping up all over the enterprise software landscape. Whether we're talking about SAP applications like SAP SuccessFactors, Ariba, or Hybris or 3rd-party applications such as Workday and Salesforce, the point is that the constellations in the IT landscape are shifting and this presents many challenges for application developers.
Hybrid landscapes like the one shown above present much more than just integration challenges. When you add SaaS solutions into the mix, there's a limit to what kind of functionality we can "push out" to the application endpoints. For example, if a company decides to implement SAP SuccessFactors, there are certain things they can customize, but much of the system is locked down as standard. Customers are not permitted to modify/enhance the delivered Java code, for example. This phenomenon similarly applies to an ABAP-based cloud solution like SAP S/4 HANA Public Cloud. Here, if you have requirements that extends beyond the basic in-app extension points, your only alternative is to build external enhancement solutions on top of (RESTful) APIs provided by the SaaS solutions.
As more and more of these systems enter the mix, the question becomes where do we go to build app extensions? In the old days of pure on-premise landscapes, the gravity of a large SAP ERP instance would cause many shops to build app extensions in ABAP because it was just easier that way. After all, the SAP system owned most of the data, there was usually plenty of application resources to go around on the SAP application server cluster, and companies had an army of ABAPers to throw at the problem. Some middleware might be required to navigate through low-level technical issues, but for the most part, ABAP would win by default - regardless of whether or not it right tool for the job.
Nowadays, I think most enterprise architects agree that it makes sense to start moving these kinds of development efforts away from endpoint systems and over to a centralized and standalone PaaS. Whether this is SAP Cloud Platform, Microsoft Azure, Google Cloud Platform, or Amazon Web Services doesn't really matter. Nor does it necessarily matter if the PaaS is in the public cloud or in a private cloud (e.g. Azure Stack). In the end, the goal is to find an environment where you can efficiently innovate around the edges of your ever-evolving IT landscape and insulate yourself from inevitable changes. Personally, I think that prudent companies will also look to open standards and technologies to implement these innovations on top of their preferred PaaS provider. Besides protecting you from vendor lock-in, this approach also opens you up to a much wider ecosystem of developers, libraries, and frameworks.
As a software engineer, I look at ABAP as one of many possible tools to use to solve a problem. If it's the best tool for the job, that's great. But if not, I don't see why you'd want to force it. For example, when building extension apps in the cloud world, it's important to be able to process REST API calls, parse JSON & XML, and expose APIs to frontend JavaScript-based frameworks like SAPUI5 (which drives SAP Fiori). Though it's technically possible to accomplish these kinds of tasks in ABAP, I would submit from experience that it's much easier (and elegant) to use a more modern programming environment like Node or Python for these kinds of tasks. After all, they grew up doing this kind of stuff, so they're just natively better at it.
In 2012, one of the early cloud pioneers Heroku (the PaaS subsidiary of Salesforce) published a set of best practices/principles for developing cloud-based apps called The Twelve-Factor App. While I won't go into detail on all 12 of these factors, there are several factors in particular that I think make ABAP a rather poor choice for cloud-native app development:
In the end, my goal in writing this is not to bag on SAP for giving customers something they want. Instead, I look at this as kind of a continuation of Graham Robinson's Call to Arms for ABAPers back in 2012. Before dismissing these other technologies in favor of the devil you know, I would implore developers to take a much closer look at what these newer cloud technologies have to offer. When you dig into the core of the technologies that are driving the cloud-native development movement (e.g. Cloud Foundry, Docker, and Kubernetes), I think you'll find a treasure trove of goodies that will forever change the way you think about application development. I know it did for me.
In the ABAP world, developers often think of development in terms of RICEFW objects: reports, interfaces, conversions, enhancements, forms, and workflow. As you start to play with newer technologies in the SAP world, I would encourage you to think about whether or not ABAP is really the best tool for the job at hand. For example, if you're going to build a brand new Fiori-based app to implement some enhancement, do you really need ABAP in the mix? Since the frontend will be built on the JavaScript-based SAPUI5 SDK, there are some real benefits to building the server-side REST APIs using Node and going JavaScript end-to-end. There are plenty of alternatives to choose from for other RICEFW object types as well.
ABAP is definitely not dead and will likely keep on kicking for many years to come. However, with the pace that technology is evolving, I think it's in your best interest to start trying to wean yourself off of ABAP sooner rather than later. If nothing else, at least try to broaden your horizons and see what these other environments can do. And as you're contemplating all this, consider also that this phenomenon is not unique to SAP/ABAP - other mainstays of the enterprise space such as Java and .NET are being disrupted as well. So buckle up because there's no turning back at this point. It's either evolve or die.
I look forward to a lively debate on this topic.
Disclaimer
Before the #ABAPsNotDead lynch mob comes knocking at my door, I want to issue an important disclaimer: I think ABAP is a fine language for developing on-premise enterprise applications. I've developed with ABAP extensively for going on 17 years now and have written several books on the topic, so please know that any conclusions I may draw here were not formed haphazardly. Suffice it to say that I'm not an ABAP hater just trying to throw shade on old-school technology.
What's So Different About the Cloud Anyway?
Ever since SAP released the SAP Cloud Platform (back in the Neo/HANA Cloud Platform days), I've had many discussions with developer peers that dismiss the SCP as just another attempt by SAP to push Java on the developer community. Sort of like a NetWeaver Java 2.0 if you will. However, while Java has been sort of the de facto flagship language of the SCP to this point, the open approach SAP took with SCP is so radically different from NetWeaver Java there's hardly any comparison between the two platforms. This is not just about ABAP vs. Java (or any other language for that matter).
As a Platform-as-a-Service (PaaS), SCP offers so much more than programming environments like Java. The whole point of a PaaS offering like SCP is to provide developers with a modern and flexible environment that can be used to rapidly develop new applications, extension apps, and so forth. Included in this environment are a series of backing services which span lower-level functions such as persistence and connectivity, platform-level services for rolling out mobility and IoT solutions, and even business-level services such as SAP Hybris-as-a-Service (YaaS) which provide reusable application building blocks such as "tax-as-a-service".
As you experiment with the platform, one of the things you'll notice is that these services are language-agnostic. Indeed, when you browse through the SCP help documentation, you'll find lots of examples for consuming these services from Java, Node.js, Python, and so on. This separation of concerns has become even more pronounced with the release of the (relatively) new Cloud Foundry environment which has ushered in a true "bring-your-own-language" (BYOL) approach to app development on the SCP.
As a developer, I've been very excited about the BYOL language approach afforded by Cloud Foundry, but not just because I want to tinker around more with Python or other language types (although that's definitely true). The primary advantage that I see with the BYOL approach is that it gives developers a much more modern tool set to deal with one of the biggest challenges I see in enterprise development space right now: gravitic anomalies.
If you look at the figure below, you can get a sense for what I mean when I talk about "gravitic anomalies". While SAP S/4 (or SAP ECC/SoH) on-premise systems remains a crucial part of the digital core for most companies, lots and lots of new cloud-based systems are popping up all over the enterprise software landscape. Whether we're talking about SAP applications like SAP SuccessFactors, Ariba, or Hybris or 3rd-party applications such as Workday and Salesforce, the point is that the constellations in the IT landscape are shifting and this presents many challenges for application developers.
Hybrid landscapes like the one shown above present much more than just integration challenges. When you add SaaS solutions into the mix, there's a limit to what kind of functionality we can "push out" to the application endpoints. For example, if a company decides to implement SAP SuccessFactors, there are certain things they can customize, but much of the system is locked down as standard. Customers are not permitted to modify/enhance the delivered Java code, for example. This phenomenon similarly applies to an ABAP-based cloud solution like SAP S/4 HANA Public Cloud. Here, if you have requirements that extends beyond the basic in-app extension points, your only alternative is to build external enhancement solutions on top of (RESTful) APIs provided by the SaaS solutions.
As more and more of these systems enter the mix, the question becomes where do we go to build app extensions? In the old days of pure on-premise landscapes, the gravity of a large SAP ERP instance would cause many shops to build app extensions in ABAP because it was just easier that way. After all, the SAP system owned most of the data, there was usually plenty of application resources to go around on the SAP application server cluster, and companies had an army of ABAPers to throw at the problem. Some middleware might be required to navigate through low-level technical issues, but for the most part, ABAP would win by default - regardless of whether or not it right tool for the job.
Nowadays, I think most enterprise architects agree that it makes sense to start moving these kinds of development efforts away from endpoint systems and over to a centralized and standalone PaaS. Whether this is SAP Cloud Platform, Microsoft Azure, Google Cloud Platform, or Amazon Web Services doesn't really matter. Nor does it necessarily matter if the PaaS is in the public cloud or in a private cloud (e.g. Azure Stack). In the end, the goal is to find an environment where you can efficiently innovate around the edges of your ever-evolving IT landscape and insulate yourself from inevitable changes. Personally, I think that prudent companies will also look to open standards and technologies to implement these innovations on top of their preferred PaaS provider. Besides protecting you from vendor lock-in, this approach also opens you up to a much wider ecosystem of developers, libraries, and frameworks.
As a software engineer, I look at ABAP as one of many possible tools to use to solve a problem. If it's the best tool for the job, that's great. But if not, I don't see why you'd want to force it. For example, when building extension apps in the cloud world, it's important to be able to process REST API calls, parse JSON & XML, and expose APIs to frontend JavaScript-based frameworks like SAPUI5 (which drives SAP Fiori). Though it's technically possible to accomplish these kinds of tasks in ABAP, I would submit from experience that it's much easier (and elegant) to use a more modern programming environment like Node or Python for these kinds of tasks. After all, they grew up doing this kind of stuff, so they're just natively better at it.
The Missing Factors of ABAP
In 2012, one of the early cloud pioneers Heroku (the PaaS subsidiary of Salesforce) published a set of best practices/principles for developing cloud-based apps called The Twelve-Factor App. While I won't go into detail on all 12 of these factors, there are several factors in particular that I think make ABAP a rather poor choice for cloud-native app development:
- Dependencies
- This factor is all about explicitly declaring and isolating dependencies. As of today, this is not something that ABAP does very well at all.
- It's also worth noting that the new ABAP-based environment on the SCP will be fairly limited in terms of available modules/libraries to leverage from. While SAP will provide APIs for consuming cloud platform services, etc., many of the functions/classes you may routinely leverage in an on-premise SAP system will not be available in the stripped-down environment. Perhaps in time SAP and the community will build up some reusable libraries, but there's a long way to go to catch up with Node, Python, or Ruby in this area.
- Disposability
- In order to take advantage of cloud-based infrastructures and support horizontal scaling, it should be possible to spin up/dispose of a container in an instant. Perhaps in time the new ABAP environment will get there, but I believe I heard that the new environment may take as long as 8 minutes to start. That's not really an ideal environment for building lightweight microservices.
- Dev/Prod Parity
- This principle is about eliminating gotchas that creep in whenever there are differences between environments. ABAPers are accustomed to dealing with these problems all the itme: missing transports, configuration, and so forth.
- One way that organizations are dealing with this challenge is by automating the environment creation process end-to-end. Here, code is checked into a centralized source code repository such as Git, assembled into a package using automated builds, and deployed as a self-contained app container (e.g. Docker containers or Cloud Foundry droplets). In this way, there's no room for environmental discrepancies to creep in because the build process is exactly the same in each environment. While the community is off to a great start with the open source abapGit project (some great info on this can be found here), we're nowhere near the maturity level of these other programming environments.
Conclusion: It's All About Choice
In the end, my goal in writing this is not to bag on SAP for giving customers something they want. Instead, I look at this as kind of a continuation of Graham Robinson's Call to Arms for ABAPers back in 2012. Before dismissing these other technologies in favor of the devil you know, I would implore developers to take a much closer look at what these newer cloud technologies have to offer. When you dig into the core of the technologies that are driving the cloud-native development movement (e.g. Cloud Foundry, Docker, and Kubernetes), I think you'll find a treasure trove of goodies that will forever change the way you think about application development. I know it did for me.
In the ABAP world, developers often think of development in terms of RICEFW objects: reports, interfaces, conversions, enhancements, forms, and workflow. As you start to play with newer technologies in the SAP world, I would encourage you to think about whether or not ABAP is really the best tool for the job at hand. For example, if you're going to build a brand new Fiori-based app to implement some enhancement, do you really need ABAP in the mix? Since the frontend will be built on the JavaScript-based SAPUI5 SDK, there are some real benefits to building the server-side REST APIs using Node and going JavaScript end-to-end. There are plenty of alternatives to choose from for other RICEFW object types as well.
ABAP is definitely not dead and will likely keep on kicking for many years to come. However, with the pace that technology is evolving, I think it's in your best interest to start trying to wean yourself off of ABAP sooner rather than later. If nothing else, at least try to broaden your horizons and see what these other environments can do. And as you're contemplating all this, consider also that this phenomenon is not unique to SAP/ABAP - other mainstays of the enterprise space such as Java and .NET are being disrupted as well. So buckle up because there's no turning back at this point. It's either evolve or die.
I look forward to a lively debate on this topic.
- SAP Managed Tags:
35 Comments
