ABAP in the Cloud: Is This a Good Thing?

[jwood_bowdark]

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.

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.

[hofmann]

It's cloud when it runs inside a container 🙂

[ssimsekler]

Hi James

It was great reading your blog. I agree with all the points you mentioned, however, I cannot clearly see your conclusion. Maybe you are a bit too much scared of  #ABAPsNotDead lynch mob.

So, ABAP getting on the Cloud gives us just another alternative among other languages/runtimes. Your view on enterprises will tend to choose ABAP even though it actually may not be the best tool sounds quite pessimistic. I agree it should not be the default programming language; however, I believe this pessimism is too much and unfair.

The benefit you mention about NodeJS is valid for ABAP as well from the other direction when we think ABAP is used specifically for “Side-by-side extensibility” for S/4HANA.

Not only this, but I am sure there will be use cases where ABAP as a programming language will be among the reasonable tools not falling short compared to Node or Java. ABAP as a language is quite well tailored for enterprise applications. I haven’t seen any other language that offers a better way of dealing with data records, compared to “internal tables” of ABAP.

ABAP’s abstraction for database access is a delight and ABAP’s implementation of OOP is quite good. The frameworks at the base of S/4HANA, e.g. BOPF and SADL, look like quite powerful means for enterprise application development.

The missing features of ABAP can eventually be added to the platform and you know there is a large community eagerly waiting for this and you have already mentioned signs of this in your blog, e.g. abapGit.

With the efforts of the community and the support of SAP, ABAP can be a powerful alternative for building enterprise applications.

Because you mentioned NodeJS, there are many who leave NodeJS in favour of Go(lang). One of the arguments when comparing these two is that NodeJS has a larger community and extensive  public libraries. Yet, this may not cover the ugliness (personal opinion) of JavaScript and does not stop the Go community growing. On the other hand, NodeJS evolves to fill in the gaps, e.g. with IBM’s StrongLoop.

Finally, I agree that developers should “broaden their horizons and see what these other environments can do”. I do, too, suggest this to my fellow ABAPers. But that can be said to any developer who locks themselves in one particular language. Therefore, is not really a valid argument especially for an attempt of making a point to imply ABAP will die.

Kind Regards

Serdar

[UweFetzer_se38]

Hi James, good one, as always.

Some additional thoughts: we are not talking about some apps, we are talking about enhancing of (S/4) business logic. As serdar.simsekler  already mentioned, we will get business frameworks like BOPF etc, we will get CDS with build in REST services and so on and so forth.

Try this with Python (nothing against Python, I’m loving it for my IoT projects)

It's all about choices. Whether ABAP is the right one, depends on the project IMHO.

Cheers, Uwe (@se38) #ABAPsNotDead !

[45259]

I bet this offering targets partners, providing them a way to migrate their add-on solutions from on-premise to cloud.

Unfortunatly, that approach is (currently) doomed to failure, due to the lack of interfaces to S/4HANA Cloud.

[ssimsekler]

Hi Stephan

How about these:

SAP API Business Hub, e.g. SAP APIs for S/4HANA Cloud

SAP S/4HANA Cloud SDK

 

Regards

Serdar

[45259]

Hi Serdar,

I know these, but they represent a fraction of the interfaces available on-premise.

However, I assume that most on-premise add-ons benefit from direct access, either by direct data access, or by invocation of functionality not released for external usage. As a partner, you are enabled to create your own interface on-premise, if no interface provided by SAP suits your needs, so to speak. And that is something you cannot port to the cloud (and maybe never can).

Regards, Stephan

[mmcisme1]

I agree with a lot of the comments above.   How much ABAP is really allowed on the cloud and how much will it cost to add your own code?

I also agree with learning new technologies.   Other than just plain being fun, it makes you able to determine which one is the best for the task.    It won't always be the same language.

Now - the pessimistic side of me - you have many shops with programmers who are largely ABAP.   If they don't have enough to do - they are out of there.   So unless people are learning, ABAP will be strong in the future.

A question in general - how many shops still don't use classes?  I'm talking classes they create and not the ALV class.

That tells you how quickly things will change.   On-premise offers clear advantages if you don't want all the extra costs for changes.    I'm keeping an open mind.

Michelle

[karl_kessler]

 

Great to see the many perspectives of what ABAP can do and what ABAP might not be able to do short-term. We will listen carefully to the needs of our customers and the ABAP developer community. And the ABAP community will even get stronger by the ABAP in SAP CP launch I am quite sure by sharing code, best practices etc. In the past, ABAP was always growing with the demand coming from the outside. Here are some examples from the past: ABAP Objects, BSP, Web Dynpro, XML, now Core Data Services and FIORI. James, if essential capabilities are missing we will add them. Performance (e.g. startup) is always critical and needs to be addressed properly. And again, we do not want to compete with the existing offerings such as Java and Node.js but add a new flavor and combine the best of these worlds. But please give the young child some time to develop.

[rolf_paulsen]

Hi James,

thanks for this extraordinary blog. Each topic and the conclusions are founded distinguishedly.

The essential significance of the “factors” relevant to cloud and agile development – depenency management, automatic delivery chain including system setup – cannot be over-emphasized.

There are concepts deep buried into the ABAP dev platform that will make it extremely hard and expensive to make little progress towards these “missing factors”. These exist in the other languages for years in vivid and productive applications and are continuously improved by legions of developers in communities and companies with vast experience and expertise.

Is building development tools a major business area? Tools that are available for other platforms/languages of-the-rack?

Furhermore, every day and dollar that gets invested into ABAP cloud environment cannot be invested into enhancements of ABAP non-SCP (“on-premise” is somewhat misleading, see Tobias’ comment 🙂 ).

ABAP is definitely not dead and will likely keep on kicking for many years to come.

So true! Even methusalem FORTRAN is not only “not dead” but still modernizing (now OO) and still very important e,g in climate simulation. (A niche, of course, but a very important one for manhood.)

And there is most likely a niche for ABAP on SCP.

BTW I like and agree to your statement about plain REST.

Rolf

[abdul_hakim]

Hi James,

Thanks for sharing your views. After reading various blogs on this topic from different experts i am convinced that SAP made a right choice to bring ABAP into SAP Cloud Platform. As any start up language in new platform will have some drawbacks when compared to other languages which are exclusively developed for that platform it also does not mean that the new language will always lay behind. I am confident ABAP will definitely evolve and prove as one of the best language or atleast at par with other languages in SAP Cloud platform. As Karl mentioned we need to give young baby sometime to develop.

Thanks,

Abdul Hakim

 

[Jelena_Perfiljeva]

After reading the blog I feel more appropriate title would've been "... is this the best thing?" Is ABAP in Cloud "good" - I'd say yes. And before I get lynched by the #DieAlreadyABAP crowd I'd point them to another graham.robinson 's blog - ABAP in SAP Cloud Platform – Why?

IMHO this may have been more of a political than technical decision in the first place. And, as I've noted in the comment to Graham's blog, this does not mean that ABAPers can sit back and relax.

You know I always love to bring some analogies, so here it goes. Last year our air-conditioner broke down at the end of August. Mind you, we live in the US South and it's still very hot here almost till the end of September. Our a/c was an old unit, it has not been very efficient and we knew we'd have to replace it eventually and probably quite soon. But still, my husband didn't have anything better to do, so he checked the unit and found that one part needed to be replaced. He got the part for about $20 (new unit cost about $1500), replaced it and after that our a/c worked for few more weeks before finally kicking the bucket completely.

Of course, we could've just replaced the unit at once (as I said, it was old, so we knew it was coming) but in August the a/c companies still have their hands full with the orders, they can charge premium rates and have low availability. So for $20 we bought ourselves a chance to do some research on different a/c units, get several estimates and then get it replaced at lower off-season cost by a contractor who was not in a rush.

It's a simplification but I'd view ABAP in Cloud as something like that $20 part. The SAP customers still have many ABAPers employed. So from the purely practical standpoint they'd be able to utilize them more with ABAP in Cloud option. Would those ABAPers be wise to learn something else? Probably, depending on what their career goals are (some might be too close to retirement to bother, let's be honest).

If an option exists it does not mean that every single SAP customer should or would use it. As you said correctly, it might not always be the best. But I can see how this could be either an interim solution or even a long-term solution (our $20 part could've fixed the issue and a/c might have worked still, who knows) in the cases when it's just "good enough".

That's just my POV based on the limited knowledge I gathered so far, so I reserve a right to change it. 🙂

Thank you!

 

[former_member209088]

There is an old saying, a "Jack of All Trades, is a Master of None".

I agree that all tools are not created equal, and the right tool should be used for the task.  An easy one is JavaScript for the front-end.  Doubt you will get much argument there.

However, creating an SAP Sales Order by writing database inserts and updates using node/ruby/php, versus a simple Function Call to BAPI_SALESORDER_CREATEFROMDATA is simply unwise.  It is simply less expensive to wrap this function as a Service (ABAP supports XML and JSON).  SAP themselves have painfully learned this with ODATA evolution.

There are a few concepts you left out.  They may be old, but they still apply:  High Cohesion, Low Coupling and Encapsulation.  Not sure why anyone thought it was a good idea for everyone to learn SAP' data model using ODATA, when API's are much better.

Note: I have built Fiori apps with SAPUI5 WebIDE, Fiori Apps with OpenUI5 (using Neptune), ODATA with SEGW, and ODATA with CDS views.   Neptune's Remote calling of ABAP classes is easily the cleanest approach.  BOPF will ultimately morph to this, but a shame it was not obvious at the start.

Tim

 

[abdul_hakim]

I don't think adding ABAP into SAP Cloud is a $20 thing example may be the $20 thing already there got broke so we got new one now 🙂 . On serious note ABAP developers cannot sit back and relax thinking that now that ABAP in SCP they don't have to upscale. They need to upscale to make ABAP in SCP a great success!!

[cyclingfisch_]

Hi James,

a really good post, as usual.

I don't want to add more pros and cons about ABAP or other languages. But as we all agree, ABAP will remain in ERP systems and in the SAP ecosystem for quite some time. So for me it makes sense to show the ABAP community that ABAP is not outdated and that SAP still invests in making the platform and language better and renews it. And there are plenty of new things which I like in ABAP! If SAP would stop the ABAP investments, there would be less ABAP developers and I assume not the best ones would stay in the ABAP world. This might be critical for many business critical systems.

Also there are already two offerings from SAP in the cloud which run on ABAP: Business by Design and S/4 HANA Cloud. So bringing ABAP to SCP can help to get the ABAP platform more "cloud ready".

With ABAP on SCP and the SCP Trial offering ABAP will become more easily available for e.g. students who are interested in ABAP and other SAP technologies. Getting a bigger SAP & ABAP developer community has only advantages for all of us, imo.

In my opinion, with all the PaaS offerings out there, the way we develop will change even faster. Talking about microservices and using all the services the PaaS platforms offer, all developers (this applies to all languages, not only ABAP) have to shift their mindset. For many ABAPers out there, using APIs and REST/OData services is still not the way they develop. But if they start to use ABAP on SCP, they will be forced to, I'm sure. So this will help to get more skilled developers in the ABAP community. At least I hope so! And maybe they even try another language...

And last but not least: ABAP on SCP is also a change to clean up the ABAP language, because there are no legacy applications which rely on the downward compatibility.

I'm looking forward to ABAP on SCP! But this will not hinder me to have a look on other programming languages and their concepts!

Cheers,

Martin

 

 

[jwood_bowdark]

Hi Serdar,

I'm sorry if this came across as too pessimistic or unfair, that was not my intent...

Regarding your comments about ABAP's suitability for side-by-side extensions though, I would submit that the pattern(s) used to develop enterprise app extensions in the past are not necessarily the go-to options for building cloud-based extension apps today. If you think about extension apps based on the model shown below, there's nothing pushing me to use a relational database. I can't get my hands on the database backing the S/4 system, and if I have custom persistence requirements in the extension app itself, SAP CP gives me many alternative persistence service options including a NoSQL database like MongoDB. For apps like this, I think the utility of powerful ABAP features such as internal tables is greatly diminished by the impedance mismatch in play whenever you're handling so much JSON-encoded data. And, although I just used Node as an example of a modern alternative above, I would offer that a Node+Mongo-based solution offers many of the same kind of benefits that the ABAP+Relational Database pairing offered in the past.



In the cloud, I think it's going to be harder for ABAP to play to its strengths. Instead, it's going to be called upon to consume RESTful services, handle lots of JSON, interface with cloud services, etc. You can definitely use ABAP to accomplish all these tasks, but it's going to rough sledding for a while as the community tries to catch up to these other more mature environments which have robust marketplaces for reusable modules. I personally do a fair amount of development with Node & Python, and I can tell you that there's basically a module there to handle any requirement imaginable. The same thing applies with Java+Spring(Boot).

I am a big fan of the new ABAP-based programming concept which employs the use of CDS, BOPF, etc. However, as ABAP matures on SAP CP, I'd like to see the BOPF spun off as a more general-purpose service offering on SAP CP which enables developers to model business objects in a language-agnostic kind of way. Salesforce and Dynamics 365 have options like this where developers can define business objects using graphical tools and consume the objects from any language offering using REST APIs.

In the end, I suppose my main point here is that I'd like to see SAP treat ABAP on SAP CP as just another programming environment and not carry with it a lot of the heavyweight resources used in modern NetWeaver systems (e.g. Gateway, etc.). I'm sure SAP is working very hard on this, and trust they know what they're doing. Still, as the owner of a consulting firm, my bottom line often comes down to what I can sell and, from my experience, the competition in the cloud space is very steep. Here, the decision is not always as simple as which programming environment is the best. Another increasingly important factor is operating cost. Enterprise-grade apps built on lightweight frameworks such as Spring Boot, Node+Express, Ruby on Rails, etc. can be run in Linux containers quite cheaply these days. They're quite scalable and also portable across environments. So, if ABAP is going to compete in this space, it's going to have to be efficient here, too.

If nothing else, it will be interesting to see where this goes.

[jwood_bowdark]

Hi Uwe,

Please see my response to Serdar above. I'd personally like to see frameworks like the BOPF spun off into general-purpose services that can be consumed in a language-agnostic way. That way, I could model by business objects centrally and then create my app using a microservice-based architecture that might leverage multiple programming environments for different things: Node+Expess for API routing, Python for ML-based requirements, and perhaps ABAP for additional business logic.

You're definitely right though - it is all about choice.

 

[jwood_bowdark]

Hi Michelle,

You raise some important points. Sadly, I still find that OOP in general and ABAP Objects in particular are not widely valued among SAP shops. I've never quite been able to put my finger on the why in this. Perhaps the added pressure ABAPers have in learning SAP modules/business logic plays a role here? That is one thing I find fairly unique to the life of an ABAP developer: you're expected to know an awful lot about many different things. Perhaps there's just no more time in the day for many of these developers...

 

[jwood_bowdark]

Hi Karl,

Well said. I have no doubt there are many brilliant minds at work on this and trust that you all will steer this ship as best you can.

 

[jwood_bowdark]

Hi Tim,

Regarding your BAPI/sales order example, I can't say that I agree. If I go with say Ruby instead of ABAP, it's not a situation where I'm hacking in database records and bypassing APIs. With S/4 Public Cloud (and other SAP apps in the cloud), all external accesses funnel through REST API calls regardless. Just because I run ABAP on SAP CP doesn't mean I get a special license to directly call BAPIs, etc. So, I see these other languages as being on equal footing with ABAP, and arguably ahead because these programming environments have more mature/efficient libraries for consuming RESTful APIs.

Also, on the topic of OData, one thing I would point out is that these services can and should be consumed by more than just Fiori applications. Some other examples here include:

• I can consume the APIs to create customer/supplier portals, develop mobility solutions, or create cross-system extension apps which blend data from SAP and say Salesforce, etc.


• I can also use the APIs to create new mash-ups. For example, I might want to utilize some of the powerful ML libraries of Python to create an app which examines transactional data patterns. Defining a REST/OData service provides me with a language-agnostic API I can use to accomplish these kinds of things.


• Reporting/Analytics solutions such as BoC, Microsoft Power BI, etc. can all consume OData natively to quickly create reports and dashboards. Heck, even Excel integrates with OData these days.

Tools like Neptune are great for building a purely ABAP-centric solution, but I think there's definitely value in spending the time to create proper APIs. As fast as business is moving these days, it's more important than ever to have reusable software assets in place to pivot in a hurry.

[jwood_bowdark]

Hi Rolf,

Yes. It occurs to me that the cloud-native approach is somewhat at odds with the whole 4GL language concept. I'm personally very curious to see where SAP goes with that part of this. If ABAP is used in much the same way as say Java, will developers love it as much? My guess is no...

 

[Florian]

As already stated on twitter. This is a logical step to make S/4(cloud) THE solution.

Of course it doesn't replace other options there, but this option will be one which also let customers and partners easily take also advantages of the cloud to their systems and hopefully do also help to get an additional view to cloud-services.

Personally I see it as an entry to the next level. I know a lot of customers which even do not think that cloud could be an option.

~florian

[ssimsekler]

Hi James

The reason I gave S/4HANA side-by-side extensibility use case was mainly because you emphasized the benefit of NodeJS making the development in Javascript end-to-end. Although, S/4HANA extensibility use case would not make it end-to-end, resources who can maintain S/4HANA backend can develop in ABAP on the cloud for extensibility which means a similar skills reuse case.

I am aware of the extensive public library and community support around NodeJS/Python but this, for example, does not stop Go to flourish. There are thousands who have a great deal of experience in ABAP and it might be easier to streamline the language to fit in the new world rather than confining it to an even smaller area and asking most of the experienced developers somehow forget about it. I can develop applications in Javascript, but I would prefer developing in ABAP and I would like it to be around as an alternative.

I agree on your point saying “I’d like to see SAP treat ABAP on SAP CP as just another programming environment” and ABAP does not really have to carry all of the heavy lifting it does on the Netweaver. But as a language, it can be an alternative. It’s not there yet, it needs a lot of effort; but it does not have to be a still-birth or doomed-to-die.

And yes, it will be interesting to see where this goes.

Kind Regards

Serdar

[ChrisPaine]

Hear hear! Whilst I'm sure that many feel ABAP has a place, this is is a hell of an expensive move for SAP to develop a whole new brand of air conditioner.

more thoughts here:> https://www.wombling.com/cloud/on-abap-in-the-cloud/

Nicely said Jelena.

Cheers,

Chris

[ChrisPaine]

<rant>

You'll know that SCP is industry standard term for Secure Copy yeah?

SAPCP is the acronym that refers the the SAP Cloud Platform.

</rant>

If you're part of the #ABAPsNotDead lynch mob, and thought what James was writing irritated you please get extra annoyed and read my thoughts:

https://www.wombling.com/cloud/on-abap-in-the-cloud/

And have a wonderful Friday 🙂

Cheers,
Chris

 

 

[ssimsekler]

Hi Chris

You wanted this!

…because the skill in ABAP isn’t in the language, it’s in understanding the existing library of standard code and frameworks that you can use to get things done.

I guess ABAP is the variable here and the solution set is quite extensive. Any good programmer can pick up elements of almost any language and learn its syntax easily. The experience lies in how much they know about the existing libraries and frameworks. Ooops! I said almost the same thing you said but in a more generic way. Because it’s valid for almost any language.

If we start building cloud extensions in ABAP we are locking down the list of people who could support them.

That “list of people” is neither fixed nor needs a secret ritual to have your name added. There are more training and self-learning material and accessing to trial/development editions of SAP products is easier than ever.

ABAP ain’t cheap, and neither are ABAPers.

Awww, thank you! ABAPers aren’t cheap; not because they are born like that. Like you mentioned in your blog, they come with the extra knowledge of how SAP products work. Changing the language here will not make it much cheaper on its own.

I don’t think ABAP and it’s whole lifecycle management is really well designed to build cloud apps.

I agree and that’s one of the many things SAP and the ABAP community is/should be working on. I like this kind of arguments. Otherwise, I try to give romantic answers and I am not really a romantic.

But if you can’t see anything out there other than ABAP, my goodness you are short sighted.

After developing in ABAP for years, if one is so reserved about it becoming one of the language alternatives on the Cloud, then one is unfaithful (to ABAP :-)) and long sighted. No offence We just want it to be there as an alternative not as the de facto/de jure standard. Let’s find the middle ground and have ABAP in the cloud without being the default language of SAPCP? (Did the trick work? :-))

Having multiple skills is important, and it’s also important to know when to use them.

I agree! Why cannot ABAP get a place in that list of skills? But wwwhy? SAP supports it, the community wants to give it a try.

Enlighten yourselves people, there is a whole world full of cool s**** out there, go and have a look.

Exactly! And again, why cannot ABAP be there?

… any PaaS you build on should be language agnostic

Has SAP announced ABAP will be the default or the only language on SAPCP?

CIO to SAP: how do I transition to S/4HANA public cloud with all the people I currently have, who only know ABAP and I can’t make redundant?

They cannot be made redundant (well, at least majority of them) not only because they know the ABAP language, but also because they know how SAP products run and have more variety of knowledge around how businesses processes can be implemented.

Just to normalize my point: I have no reservations against any language in SAPCP and I think BYOL is great. As you said, a proper PaaS should not radically favour one language.

And finally, sorry if any of the above sounds offending in any form, that is definitely not my intention.

Kind Regards

Serdar

[abdul_hakim]

hi Chris, Thanks for the link. I have gone through it. We can keep debating on this topic but we all have some sort of fixed mindset to operate in a certain way which is very much good for the developer community. I honestly feel that ABAP developers cannot take it for granted. What i see is another option to build extensions in the cloud and in my opinion which is a great  move to include millions of  ABAP developers into SAP's cloud journey.

I would take Karl's comment "Let us give young baby sometime to develop". Personally I am pretty confident ABAP will evolve in Cloud in the coming years as a defacto extension option for S/4 HANA Cloud..In the meantime i would continue with NodeJS for my extensions in S/4HANA Cloud.

 

Thank you

Hakim

[rolf_paulsen]

Jelena, I like the idea behind your analogy. For me the most important analo itgy is that you and your husband took the obtained opportunity for knowledge built-up, market analysis and a well founded future proof decision.

If you felt comfortable with your $20 part and postponed your invest into leaving past technology, it would have become an expensive waste of time.

IMHO this may have been more of a political than technical decision in the first place.

What are the technical reasons so far?

There is many “ABAP may/will catch-up here or there, give it some time”, there are islands like abapGit already moving – impressive that this is possible, but still a fragment, for how many years now is git the de-facto standard for software versioning? – BUT there is no “ABAP and the ABAP way excel in cloud development because of this or that”.

Catching-up first and foremost would require that the follower moves faster. There is neither reason nor evidence that this will happen.

[Jelena_Perfiljeva]

I don't know what the technical reasons are at this point (and I agree with another comment saying we should give it more time). That's why to me this seemed more of a political decision at this point.

The "question" in Chris Paine's blog (link somewhere here in the comments) is very accurate IMHO. From the management standpoint, they already have available ABAP resources. And now they are not only good for SAPScript and dynpro but also for "the Cloud", yay. At least that would be the management's perception and we all know who makes the purchasing decisions here.

[rolf_paulsen]

If those who make decisions about training of their ABAP resources decide to postpone e.g. Java courses because of “yay”, ABAP on SAP CP may be a misservice to these resources.

[kmoore007]

Hey James,

I also was at SAP TechEd in Vegas this year.  What I heard somewhere during the event was that SAP only has about 1,000 customers live on S/4 HANA, but they have something like 43,000 SAP installations.  Sounds like this is going to be a gradual evolution to me.  No ABAP'er is dying anytime soon due to the evolution of cloud technologies.

:-)

Kenneth

[Former Member]

Hi James , Interesting read , thanks for sharing your view . Oracle cloud reference architecture is in this link .

http://www.oracle.com/technetwork/architect/archday-rws-2013-krishnaswamy-1966514.pdf

I felt that Oracle has better positioned themselves in this cloud space compared to SAP .

I also feel that existing SAP Customers will be moving to S4HANA and ABAP as a language would be alive here .

Not sure about S4HANA Cloud traction in market as we dont have any numbers here .

Agreed with your point that other skills apart from ABAP are more relevant in this cloud era.

 

Best regards,

pradeep.

[hendrik_lock]

Resources we invest on supporting ABAP on SAP Cloud Platform will compete with resources used to invest in supporting a Java infrastructure on CF. I’d rather see one approach done right and fast. Which obviously is crucial for adoption. A stripped down environment may be a nice move for better perception, but without a rich set of standard libraries it will not convince many developers.

[Former Member]

+1 Agree

 

It's like telling Apple please kill Swift and pick Java. Why would SAP kill its ecosystem. ABAP is a very competent language and offers stuffs better than Java that gets things done and as Karl Kessler wrote every one must wait to see how it develops.

I am sure ABAP on SCP will be great success because it's a non disruptive shift but a tectonic one.

It's really fair on part of SAP to bring ABAP on cloud and a great fair opportunity and treatment to the community. Why would they not bring it on cloud when it can be brought and I really don't understand the whole open source and Java story. We want a proven capable language ABAP is proven and capable. What is there about open source we write enterprise apps why would there be stuffs for free.

 

[Former Member]

Thanks Serdar. ABAP rocks and SAP has been fair to it's developer community.

 

[TomD]

Excellent article James. I think your analysis of the future for SAP development and the role ABAP has in it is pretty much spot-on. We're already seeing some of the changes in the way we approach these type of platform-based projects with dozens of components or moving parts. I'm not sure if you intentionally drew a parallel with the "data gravity" concept but your idea on gravitic anomolies is very interesting.

I share your doubt on the value of brining ABAP to the cloud. As mentioned elsewhere here the main reason I would want to see this ABAP dev stack brought into the cloud is to unify the transport processes and move away from the horror that is SAP's native version control. A single repository with a fit-for-purpose ALM flow running in SCP would be a dream come true. But I'm not sure how much of a priority this kind of unification would be for SAP.