Skip to Content

Mastering SAP Technologies 2015 Melbourne

Mastering SAP Technologies 2015 Melbourne

Day 1 – Sunday 24thMay


Figure 1 – Conference Dustbins

This year the Mastering SAP Technologies conference in Melbourne was co-located with both the Mastering HR conference and the Mastering Finance conference. This meant there were 700 people there, which is an enormous amount for Australia, though of course we cannot hold a torch to the SAPPHIRE event in the USA where there are 40,000 delegates or whatever the exact number is.

1PM – SAP Inside Track

This is a free event so a lot of people who were not going to the conference rocked up including a big bunch of university students brought by SAP Mentor Tony DT.

How this works is a bit like speed dating – you have to jump from table to table with people you have not sat with before and all say who you are and what your business challenges are for five minutes, then run to the next table. During this bit you can get to talk in a small group about such challenges and everyone gets a say.

Thereafter all the challenges are written on a blackboard and the most common ones chosen for one hour or twenty minute sessions. In those sessions the group splits into enormous groups where one person totally dominates the conversation and a few others interject the odd comment while most people sit around listening.

As might be imagined popular subjects of interest were user interfaces and S/4 HANA. The major point I heard I am going to go into detail about and this all revolves around one of the students asking the question “should I learn ABAP?”.

ABAP – Dead Again!

You may recall that in 2001 ShaiAgassi was more or less in charge of SAP and wanted to kill off the ABAP language and replace it with Java. I believed this at the time and as I had only been programming for a few years was not even that attached to ABAP. However as history tells us nothing ever came of that initiative.

As far as I can tell – and I may have totally misinterpreted this (I hope I have) here is the latest position from SAP.

·        They want all us customer companies to move onto S/4 HANA in the Cloud

I hope that bit is not too contentious, not too much of a shock. Here comes the problem – as noted there and then it seems that as much as 50% of the screens that end users currently see are in fact custom screens written in ABAP. That sounds right to me, at my company it’s more like 100%.

So, in the cloud you cannot change the code. Nobody is going to put up with standard SAP – as we have seen – even standard SAP with lovely new UI5 screens. Everyone is always going to want to put their own stuff in, as they have always done with user exits and custom reports and bespoke applications for things specific to their company and so on.

How does SAP intend to square this circle? As I understand it from the talk at the Inside Track, the idea is that S/4 HANA will have API’s which custom applications can hook into, thus achieving the same sort of thing we have today.

How do you build such custom application,such custom code? In the HANA Cloud Platform (HCP).

OK, what language do you program things in using the HCP? The answer is – any language you want, so long as it is not ABAP.

That doesn’t sound good does it? I just wrote a book about the future of ABAP, SAP has put an enormous amount of innovation into the ABAP language in recent years, and now it is dead again? That can’t be right, surely?

It sounded to me like SAP itself as an organisation was still going to use ABAP itself, S/4 HANA would still be in ABAP, new SAP delivered innovations would still be written in ABAP, but we customer types cannot change the core of S/4 HANA and cannot add new applications in ABAP.

In other words SAP can still use ABAP to develop but the customers cannot because it is too good for the likes of us. Instead we have the minor task of re-writing everything we have written during the last 20 years in JavaScript or some such. No problem really, should only take us ten minutes.

When I phrase it like this do you think many organisations will jump at this idea like it is the best thing since sliced bread?

Possibly not, so I must have got this wrong. It is the only possible explanation. I must have been hearing things; SAP cannot possibly be suggesting such an approach. The funny thing was at that point I had not even started drinking. Even stranger when I asked other people throughout the conference they seemed to have heard the same message as well.

6:30PM – Jumpstart / Demo Jam

The Demo Jam is a contest where people have a limited time to demonstrate something new and exciting they have created using SAP technology, usually mixed with other technology.

This year it was all about bicycle power which ties in nicely with SAP’s current focus on sports and applications to monitor sports performance.

7:30PM Network Drinks

Figure 2.jpg

Figure 2 – Conference Food

Then it was networking time. The idea here is to talk to as many people as you can and make connections. The drinking is an aside and by no means the main focus.

Figure 3.png

Figure 3 – Networking

Day 2 – Monday 25thMay

Figure 4.png

Figure 4 – Conference Dustbin

SAP User Interface Strategy

This was a presentation from SAP and no huge surprises here. The idea is that UI5 is the go-to technology; everything else is a sort of bridging technology. Screen Personas is a sort of stop-gap measure, and NWBC is a way to see all the disparate UI technologies at once e.g. SAP GUI, Web Dynpro and UI5.

No-one at SAP is ever going to say that Web Dynpro or the SAP Portal is dead, especially the latter as people may maintenance fees for that. However reading between the lines I get the feeling that both are in the “Dodo / Dinosaur” basket.

Figure 5.jpg

Figure 5 – Lunch on Day 2

Netweaver Business Client – John Moy

Now it was time for two fantastic presenters, one after the other, again both talking about UI technology which was a big focus for this conference.

John Moy was talking about his experience implementing NWBC in real life. Some people at my organisation are mad keen to try this, and John made it look very impressive indeed. The killer is that really you have to be on a higher level than EHP5 to get the most of this, and that is what my company is on. We upgraded in December 2011 and that does not seem like too long ago to me but we are already miles behind and really cannot go through the effort of a major upgrade (which is what putting in an Enhancement pack is) again so soon.

By getting the most out of this technology I mean things like having side panels (so called CHIPS) appearing by standard SAP GUI transactions without having to modify such transactions.

In addition, Julie Plummer posted a blog on SCN the other day about the future of UI in SAP and (as always) the next version of NWBC coming out in 2016 looks like the important one, as it will have the Fiori Launchpad as the “start” menu.

UI5 – Graham Robinson

There is very little I can say here I have not said before – Graham’s presentations are very “hands on” with lots of live feeds from his system as opposed to static PowerPoint slides.

He noted all the “good parts” of UI5 like it’s usage of the MVC pattern and how it responded to running on different devices automatically.

The “worst part” was the he shock of SAP development organisations being dragged kicking and screaming into the modern world full of horrible things like agile development with rapid releases and having to deal with quirky new things like deploying software onto mobile devices.

Networking Time Once More

Figure 6.png

Figure 6 Networking

Day 3 – Tuesday 26thMay

Figure 7.png

Figure 7 – Conference Robotic Dustbin

UI5 at Australia Post

Australia Post keep losing things posted to me and it seems to take forever to post anything from one side of Sydney to the other, but that’s just my experience and I don’t think I can actually blame the IT department for that.

Anyway the IT department is clearly ahead of the curve ball when it comes to adopting new technology and this presentation was all about how they had adopted UI5 to replace some applications and as a basis for creating new ones.

They covered the technical basics, which are all over the SCN so I won’t re-iterate them here but the important things is how easy they found it to make the change once they had conquered the fear of doing something totally new. They certainly do not regret it.

They also stressed how fast new developments were on this platform.

Figure 8.jpg

Figure 8 – Conference Lunch Day 2

Latest Development Techniques #1

Alisdair Templeton gave a presentation which was a “grab bag” of things developers should be thinking about when writing programs.

This was really good, he had nowhere near enough time to cover everything he wanted but managed to pack a load of stuff in. I like it when people challenge such basic assumptions and one was “the fallacy of re-use”. All the IT articles keep on and on about re-use being the be-all and end-all of development but AT questioned whether this did not cause more problems than it solved by introducing dependencies all over the place,

Latest Development Techniques #2

Ben Patterson then gave a talk on the Business Objects Processing Framework (BOPF). I have experimented a lot with this recently, as it was part of my book, and I am glad this is getting some attention at conferences, as I believe this framework has a lot of potential.

Latest Development Techniques #3

John Patterson (no relation to Ben) then gave a talk about using “Grunt” to automate various development tasks whilst developing UI5 applications. This was also accompanied by a big screencamof the tool in action to make this a bit more real.

Why this is useful is a very difficult concept to grasp from an ABAP developer as lot of things needed in other programming languages are done “behind the scenes” in the ABAP environment. This is all lovely until you want to put applications on smart phones and things and then people really get outside of their comfort zone.

John Patterson may not be Stevie Winwood, but we did used to work together back in the year 2000 and this was the first time I have talked to him since.

Screen Personas

The saddest thing about the conference was the fact that Steve Rumsby from the University of Warwick could not make it over to talk about his experiences with Screen Personas. I was looking forward to talking and listening to him, my understanding is that he has made Screen Personas sing and dance and do a lot of things it is not supposed to be capable of.

Still, a chap from SAP gave this talk instead though hearing SAP say something about one of their products is never going to be as good as hearing a “customer” doing a “warts and all” story.

The main take-away is that really you need to wait till Screen Personas 3.0 is in general availability. I had heard it was often in the “too hard” basket to get Screen Personas 2.0 to combine multiple tabs and screens into one (a common requirement, one that the premium version of GUixt could do 16 years ago). In addition version 2.0 runs on “Silverlight’ which is a dying technology.

Elephant Whispering

The best presentation of the conference was the last one; Greg Taylor gave a talk about change management and a brilliant one at that.

Every so often he would distract the audience by showing them a funny video and by the time the video was over (only about two minutes) he was back on stage in a different costume, talking in a totally different accent. Or it could have been a succession of people who looked just like him.


Then after a bit more networking it was time to go home.

figure 9.png

Figure 9 – Networking

However sad that the end of one conference makes one they are just like buses – if you wait a while another one comes along. In the case of Australia the next one is the Australian SAP User Group (SAUG) conference in August. I am talking at that one about the latest developments in ABAP.

I wanted to talk about that very subject at this conference but as I mentioned earlier in this blog it appears ABAP is on its way out once again as a programmer language for us customer types.

Naturally if someone from SAP wants to tell me I have got totally the wrong end of the stick then I am all ears – in fact it will help me sleep better at night.

Cheersy Cheers


You must be Logged on to comment or reply to a post.
  • I'll be the first one Paul (even though I am not from SAP) - you have got totally the wrong end of the stick. πŸ˜€

    ABAP lives - it is a fundamental part of S/4HANA.

    However, if you choose the cloud edition of S/4HANA you will have considerably less opportunity to modify standard code to what you are used to.

    If you choose the on-premise edition of S/4HANA you get to play pretty much as you always have.

    Thanks for blogging about your experiences at Mastering SAP Technologies 2015.


    Graham Robbo

    • Thanks, Paul, for your blog post and thanks, Graham, for your corrective comment.

      Nobody intends to kill ABAP. As Graham writes, S/4HANA in the Cloud will have restricted options to where extend/customize the system with ABAP code. More strict than what customers have been able to do in the past in an on-premise world where even modification of SAP original code was possible (but of course highly discouraged. Nevertheles...) In order to be able to maintain Cloud qualities, the extensions points in an S/4HANA for Cloud solution will be better governed from the start.

      Besides the "in-app" extension mechanisms (e.g. field extensions, custom code/reports, certified add-ons, ...), there's of course topic of loosely coupled extensions running outside of the S/4HANA core system. Those things have existed in past times as well all over the place -- just think of all the extensions apps that your IT organization has built over the past years around your core ERP system on various tech stacks. Those extension apps have been built via APIs (of some sorts) into the core system. Those kind of apps you will be able to build in a convenient and well integrated fashion on top of HCP.

      So there's a place for extensions both in ABAP and in non-ABAP worlds... Both ecosystems are huge and relevant.

      So, ABAP lives. And will continue to do so. For a few decades. Or so. πŸ™‚



      SAP P&I Technology

    • Actually I came pretty much to the same conclusion as Paul. Cloud means "no ABAP" + SAP wants everyone in the Cloud = SAP wants "no ABAP". So when SAP says "no, ABAP is still alive" it actually makes the paranoid types like me even more suspicious. Clearly SAP is just making sure us ABAPers don't escape from the asylum too quickly and leave their customers stranded. Can't believe you fell for it, Graham. πŸ™‚

      • Private and public cloud are different.

        The public cloud is the one where you can't use ABAP only HCP. Private cloud is a hosted solution and you can use ABAP. So moving to the private cloud allows for ABAP

        • After SAPPHIRE 2015, SAP has decided to remove this distinction between Private and Public Cloud. They just call it Enterprise Cloud.

          So basically there are just two options for S/4 : Cloud and OnPremise.

          At least this my understanding.

      • Cloud means "no ABAP" + SAP wants everyone in the Cloud = SAP wants "no ABAP".

        Precisely, that's why everyone that is listening ends up with the same conclusion as Paul. I know what Graham is saying, but at the end of the day you get the feeling SAP wanted a cloud only S4/HANA, and will push towards that goal.

    • Absolutely right Graham, and to add: We have in-app and side-by-side extensibility (the later via hcp)

      Looking forward to see some of you at SAUG in August...

    • Hello Graham,

      I would be really very grateful if you could help me understand the role for us ABAP guys in the world of s4/HANA in custom development side. So we can continue with custom innovations right.

      So as an ABAP developer we will write the core logic and everything but all inside cool ABAP CDS stuffs that will interact with HANA and then in the middle there will be the SAP Net Weaver Gateway i..e.

      HANA DB <-> ABAP CDS <-> ABAP based OData Service generation<-> SAP Fiori.

      So, this is not only SAP technically rewriting the entire applications for suite grounds up but we as developers or consultants too need to re imagine the design solutions we develop in future. We need to master CDS and OData if we only stick to ABAP side of things and everything will be just consumed by Fiori Apps developed by UI5 developers or ABAPers with Fiori expertise. I try to understand what mentors like you post but given my limited experience and knowledge it becomes very hard for a person like me to make a concise summary. So, I would be glad if you could confirm my understanding is right.

      Another question is we have some customers who don't buy the Fiori story and they over the years have added horrible custom transaction screens that will even make Fiori look horrible and I don't know if can even be made to Fiori. These customers don't want Fiori and they want the custom screens to be carried over as we migrate them to HANA DB.

      So what about such custom transactions when they migrate to s4/HANA as per their road map by 2017. Will there be support for such applications, AFAIK they need SAP GUI , how long will SAP GUI be supported? How will they access such applications with s4/HANA launchpad etc which is a different world.

      Thanks in advance πŸ™‚



      • Hi Prasenjit,

        thanks for you comments - but you are responding to a post that is almost 12 months old so don't expect too much response here.

        You have some interesting questions that have been asked by many others so I would encourage you to look for these threads in the forums and other related blogs, and if you still have outstanding queries by all means post a new question in the forums.

        I would encourage you, if you haven't already done so, to watch the replay of the Bjoern Goerke keynote at SAP TechEd Barcelona last year at I think it will help you understand SAP's strategy.

        And finally, I would say to you that ABAP & SAPGUI are not going away anytime soon.


        Graham Robbo

        • Hi Graham,

          Thanks for replying, yes indeed it's quite an old post πŸ™‚ I will watch the keynote as you suggested and hopefully I won't have to post the question again.

          I am quite sure ABAP is here to stay with the ABAP 7.5 being the core for s4/HANA πŸ™‚



        • Hi Graham,

          Just watched the replay and it was awesome, never expected the executive keynote could be full of substance and yet entertaining. And i guess I got a validation that my summarization was quite correct. He created ABAP CDS to consume data on HANA DB, exposed CDS via OData, and then put a state of the art UI on top of it with Fiori Smart Templates.

          Wow, watching the live demo I just felt so excited.

          Although my questions about the terrible customer  screens and the allergic reaction to Fiori is still not answered but I don't mind as GUI is going to be alive for some time, and finally it's their business and they have to take the call πŸ™‚

          But I know what the future holds; so much of stupid concerns and questions in mind just got answered in one awesome keynote. Are there more such presentations by Bjoern Goerke, if yes where can i find them?

          Thanks again.



  • Sorry to make you sad. I was very sad not to be there, but family issues kept me at home.

    I'm hoping to be talking about the singing and dancing at TechEd, ideally both Vegas and Barcelona, so if you are at one of those events maybe that'll make you less sad? And I'll happily chat about Personas over a free beer or two.

    As for ABAP, you are right that there are new extension mechanisms in the brave new world of HANA and S/4, mechanisms than don't use ABAP. It might be a good idea to start getting to grips with JavaScript for when you need to use HCP. But as Graham said, that's an issue primarily for the cloud edition of S/4. The on-prem edition of S/4 works just as ERP does now - you can write as much ABAP as you like. And the on-prem edition isn't going anywhere any time soon.

    Oh, and you'll need to know JavaScript for writing Personas scripts, which makes it even more important πŸ˜‰

    ABAP isn't dead. It just has some friends now.


    • Hello Mr.Steve,

      I will be at SAP TECHED in Las Vegas, so talking to you over the free beer about personas would indeed be a desirable thing.

      I have no problem with JavaScript. I have programmed in many languages in my life, BASIC and PASCAL to start off with back when I was 14-18. I am in fact quite fascinated with the concept of a functional language as opposed to an imperative one like ABAP. As Graham Robbo has said, failure to even acknowledge the fact one needs to learn such new languages is professional suicide.

      If one does learn them - which is not even that difficult - you can become a "full stack of pancakes programmer" as the industry phrase has it, that is you can code the model, view and controller even if they are all in different languages e.g. ABAP, XML and JavaScript as one possible UI5 combination.

      Anyway, hope to talk to you in person next month. I think I even visited the University of Warwick once, a long time ago, for a student university radio conference.

      Cheersy Cheers


      • This will be my first time at TechEd Vegas, so I've no idea how easy it is to arrange to meet people, but I will be at most of the Personas sessions so get yourself to some of those and I'm sure we'll bump into each other.


        • TechEd is smaller than SAPPHIRE but still one could easily go hiding for days there. Not sure what the mobile app for the event will look like, but you might want to exchange the contact info if you'd like to meet someone.

          Also, Paul - sorry to break the news but there will probably be only one networking event with free beer (not a lot of talking possible at the concert). But I'm sure there will be many ABAPers willing to buy you a drink. πŸ™‚ Wish I could bring your book there to sign but darn thing is just too heavy!

  • Thanks everyone for getting back to me so soon.

    I have no problem with other languages, back in 2001 when I thought Java was coming I read the book "Thinking in Java" and that has come in handy all over the place e.g. in the Java mappings in PI supplied by Ariba which I sometimes needed to understand and correct/improve.

    I also like the academic concept of JavaScript being a "functional language" as opposed to ABAP being "imperative". That sort of new (to me) thing fascinates me even as I struggle to find the difference between "side effect free" in a functional language and a method in ABAP which only refers to local variables and the parameters in it's signature.

    I am looking forward to writing UI5 applications with the controller in JavaScript, I have only played around thus far for my book (with a lot of help from Graham). My company is looking to ditch the SAP Portal in favour of having ESS/MSS in UI5 in the same way US company Pacific Drilling were talking about at SAPPHIRE NOW a few weeks ago.

    You know how language can be a barrier when different people use the same term and understand different things by it.

    I have been really puzzled in recent times by the meaning people put to the word "customisation". Back in 1997 there were two ways to change the behaviour of your SAP system. Firstly you could go into the IMG and make some customising settings.

    This is the same in Ariba you go into the "settings" section and change some settings based on the specific needs of your company. In neither case did this involve changing the actual core code of the system.

    This is what I always understood by "customising".

    Custom Code on the other hand was either a user exit written in ABAP code, or a Z report or Z application again written in ABAP living in the repository of the SAP system alongside the standard SAP code by in the customer namespace. This did not impinge on the core code though the user exits influenced the core code.

    This is what I always understand by "custom code".

    Then we have the so called "repairs" which were going into the core code and changing it, at the start via the modification assistant, and in latter years using the enhancement framework. This does change the core SAP code.

    This is what I have always understand by "modification".

    Now in virtually every recent presentation / talk / media article the term "customisation" seems to be used to refer to all three of the above. This seems to be especially true when people are talking about S/4 HANA.

    I always understood that the on-premise version of S/4 HANA was just like the current ERP 6.0, but with a HANA database and some of the core SAP ABAP code changed e.g. more standard logic rewritten in stored procedures and the like.

    When I ask about the cloud version of S/4 HANA and ask about how custom code works with it I get answers like "it is easy to add a Z field". I don't want just to add Z fields - I want the fifty or so full grown custom ABAP applications we developed over the last fifteen years which sit in front of all the standard SAP transactions, hiding them from the end users.

    We are not the only company to do that - not by a long shot.

    Such applications don't rely on modifying the standard SAP code. They have their own front end logic and then orchestrate one or more standard transactions using BAPIS or BDCS when BAPIS are not available (which they are still not for some really standard transactions (or functions or said transactions), even after 15 years).

    So if a company relies on things like that i.e. tons of existing custom ABAP applications that are absolutely vital to the business, then would it be fair to say that S/4 HANA in the cloud is not an option?

    Is the HCP designed to build such things using JavaScript (or whatever) for new companies just starting out in the SAP world?

    It didn't half seem to me when I was sitting in the Inside Track that when the student asked "Should I learn ABAP?" the answer from Graham was "Yes - ABAP Rocks" and the answer from the SAP guy was "No".

    @Steve - I really hope that I will be presenting in TECHED in Las Vegas. SAP approached me and asked me to submit an abstract which I did so that is a good sign.

    • Paul, thanks for your clarifying comment.

      I fully agree with your observation that the indifferent usage of the term "customization" for the three very different things "customizing", "custom code" and "modification" is totally confusing -- and the fact people use it that way drives me nuts (at times -- trying to maintain my stature ; )

      Indeed, for writing those custom applications you mentioned above, HCP may be a good place. Whether you use JavaScript or Java or some of the other languages we may support in the future (all disclaimers apply!) is then up to you and/or the specific use-case.

      If a developer asks in the context of SAP whether they should learn ABAP, I think the only right answer is "YES". Why wouldn't you? Knowledge is power. ; ) Do you need ABAP in all circumstances? No, of course not. See discussion above. But in many cases it's just straight forward to do certain things within the ABAP stack if you want to do something in the context of an ABAP solution.


      P.S.: BTW, I think the question is not about ABAP as a language per se, but the environment (tools, software logistics, etc.) that the ABAP stack brings with it. Acknowledging the risk that this comment may spawn the next bulk of comments ; )

      • Aha! So you're saying it's not ABAP that's dead, it's BASIS that's dead! (There goes my career....) (and so on with more spawned bulk comments...)

        Ok, obviously that's far too much of a blanket statement, and I don't actually see my job in Basis evaporating in a puff of smoke (and mirrors) quite yet. Yes, in Cloud Edition, I may not be in much demand for new installations when a customer can flip a switch and "spin up" a new NetWeaver instance, and upgrades will probably be at the whim of the service provider (i.e., SAP) rather than the customer, and performance tuning is likely to be in the sphere of the service provider as well, and all that DBA-like stuff in my job description, and... hmm, ok, maybe this isn't going well for me.

        Except that as Graham, and Bjoern, and Mark, and Steve, etc, have all said, it's likely that quite a few current ERP 6.0x customers will end up in S/4 on-premises, not cloud, for the reason that migrating (removing) all of that customization they've done over the past 20 years is far too much of a chore to handle in just the next 5 (10?) years, among other things, and in the world of S/4HANA on-premises, I do see a lot of continuing Basis work of some rather traditional varieties. And ABAP work, too, as has been pointed out by others. In fact, I'd say the future here looks quite interesting, with opportunities to get beyond the drudgery of installs and upgrades and transports and the odd tuning opportunity and provide some real value.

        As system architects. As migration experts. As landscape optimizers.

        Ok, my real point is, this Australian Mastering conference looks, from the photos, like it was a lot more fun than SAPPHIRE. The networking opportunities...

  • Hi Paul

    Thanks for the blog and it sounds like I will need to get out to this event in the future.

    We were together in South Harrow in 1997 when I would configure and you would code and live was easy.

    I think what you have proved is the S/4HANA message is a bit cloudy. Having a cloud based solution without an IMG or ABAP called S/4HANA and an on-prem version with ABAP and IMG with the same name creates confusion.

    Robbo has clarified most of the points - however I would say I assume the majority of SAP's current customer base will use the on-prem version of S/4HANA (ie upgrade their current environment)

    My message to SAP would be is to re-brand one of the solutions with a different name so people know which option they are talking about.

  • Robbo / Björn

    SAP ERP core system was customized heavily by all the customers. Customizations in the form of User exits/Customer exits/Enhancement points and even the modifications(the worst but done with no other options in most of the cases).

    If these existing customers want to get into cloud edition of S/4 HANA then according

    to SAP they need to rewrite all the stuff in Java or JavaScript etc in HCP. This

    one i call it as innovation with disruption.This is a complete re implementation which 90% of the existing customers wont prefer to do(This is my opinion).

    So ultimately they may get into On premise edition of S/4 HANA. But as per SAPs

    development guildeline for extensions on S/4 HANA, I believe extensions means(exits and new applications) HCP is the preferred development environment. So it is again a non ABAP development approach.

    In a nut shell even though SAP says ABAP is strategic but in reality based on what SAP is doing today does not seem to give that confidence. Because one side they are saying ABAP is strategic and on the other side they don't want customers to use ABAP for development in S/4 HANA (Cloud or on premise).

    SAP should clarify black and white what should be the right development approach and if ABAP is really strategic then when and how it should be used in the context of S/4 HANA.



    • HI Abdul

      to confirm a few things. ABAP can be used within the on-prem version of s4h, there is no pressure to use HCP here within the suite.

      There is no need or pressure to re-implement from a current business suite solution, it is just a two step upgrade, database and then sfin activation to get s4h

      In terms of the cloud solution and heavily be spokes solutions, it is worth noting the reason why be spiking took place many years ago was the functionality was not in SAP at the time. With industry solutions and enhancements some bespoke can be replaced with standard SAP within s4h.

      the cloud solution will help clients simplify if they wish to, however if a clients wants all their bespoke they don't want to simplify.

      • Hi Mark, Thanks for the clarification. Let us say after evaluating the current standard Solution available in SAP S/4 is still not meeting the business requirement and we need the ABAP extensions we have done in the past, in this situation the customers who want to move into cloud need to do a re implementation right? do  you think it is  a right guideline from SAP? i don't think so.



      • Mark Chalfen wrote:

        In terms of the cloud solution and heavily be spokes solutions, it is worth noting the reason why be spiking took place many years ago was the functionality was not in SAP at the time. With industry solutions and enhancements some bespoke can be replaced with standard SAP within s4h.

        the cloud solution will help clients simplify if they wish to, however if a clients wants all their bespoke they don't want to simplify.

        I have to disagree. Customer usually want to simplify and most of the times that's why they have custom developments. A simplified version of an SAP transaction/process/whatever might not be as simple as the one developed by the customer. The assumption that the customers either take what SAP offers or it means they don't want to simplify is basically false.



        • I think Mark might have meant "they don't have to simplify" but either way I have to say that SAP solutions cannot be simpler than a bespoke solution for a very obvious reason.

          An SAP solution has to cater for multiple industries and multiple countries, while a customer bespoke solution will cater for just their organisation and often just one country.

          So whilst SAP can - allegedly - make solutions simpler than they were before it is quite unlikely that a standard SAP transaction can ever be as simple as custom one. Unless the custom transaction is a badly written horror story of course.

          • Unfortunately, I rather suspect a large percentage of custom-written solutions are just that, badly written horror stories. You know, the kind where all the teenagers die but one.

  • Hi Paul,

    in terms of the latest position where S/4HANA should go, i think SAP will be more than happy to do the migration on-premise (and not necessarily in the cloud) as this is the latest offer for sFIN2.0:

    SAP Simple Finance, On-Premise Edition – SAP Help Portal Page

    - helpdotsapdotcom/sfin200?current=sfin

    let me know if you heard something more official or recent than that.



    P.S. and there's a plenty of ABAP in there as far as i can see.

  • Hi,

    since there's a number of statements regarding whether ABAP is strategic to SAP or not and whether SAP wants all customers to move to the Cloud where there is no ABAP, let me try to clarify.

    1. SAP does not want all customers to be in the Cloud. It's the market that's tilting towards Cloud over on-premise in more and more application areas. It's customers who want to be there with parts of their solutions. Not all customers. And not with all their solutions. But significantly many. That's why SAP offers choice to customers to the possible extent.

    2. S/4HANA comes as an on-premise version (S/4HANA for On-Premise) and a cloud version (S/4HANA for Cloud).

    3. The on-premise solution is broader in functional scope and offers like Business Suite in the past all the flexibility in terms of customization, custom code, etc.. The on-premise verison can of course be operated in SAP HANA Enterprise Cloud as managed cloud version like any other SAP on-premise product. Extensions to the former Business Suite done in ABAP can be migrated to the S/4HANA for On-Premise with tool support (restrictions and the usual disclaimer apply). There will also be services available to support customers in the migration. SAP's goal is clearly to make the move as smooth as possible (we call this non-disruptive at times).

    4. The cloud version of S/4HANA has a smaller scope than the on-premise version and due to the fact that it is a public cloud offering certain restrictions apply in how much the product can be extended by customers with custom code. Nevertheless, like with the On-Premise version, there are extension points to the system "in-app", i.e. it's possible to do field extensions (code free), add custom exits at predefined points, have certified partner add-ons that live up to Cloud requirements, etc.. So there is a place where "in-app" extensions can happen -- but they are more strictly governed than in the on-premise case -- as in the end SAP as service provider is responsible for the update/upgrade cycles of the system and has a vested interest in keeping the system highly upgradeable. This is the reasons why there are restrictions put in place.

    5. SAP's goal is of course to make the migration of existing extensions built on the Business Suite as much "migratable" as possible to the on-premise and cloud versions of S/4HANA. What can be migrated will differ based on the target version of S/4Hana (s. #3&4 above).

    6. By making S/4HANA available in the Cloud, SAP is effectively making ABAP even more important for its own and its customers future (in effect prolonging it's lifetime even further)  and is heavily investing into the ABAP stack (I have the opportunity to work right in the middle of the ABAP development teams here in Walldorf and I can tell you that everybody is busy like crazy doing a fantastic job ; )

    7. SAP expects hybrid scenarios to be around for the coming years (if not decades). So there's no need to worry about the relevance of ABAP or BASIS skills at all. The contrary is the case. Will a few things change? Of course. So it's up to everyone to move with the developments and adapt to the changing environment. SAP's goal is to simplify everything around SAP solutions -- so don't expect us to not try to get rid of things that required expert skills in the past ; ) 

    8. Finally, it is safe to assume that ONLY knowing ABAP will not be sufficient in the future. But you don't need SAP to know that... And I think it wasn't enough in the past either ; )

    9. Like in the past years as well already, there were many extensions to SAP software happning in non-ABAP tech stacks. This will continue to be the case. SAP is offering a powerful cloud platform (Platform-As-A-Service) called "HANA Cloud Platform" (HCP) to more easily build, deploy and run such "out-of-app" extensions in a well-integrated fashion with SAP solutions than any competitor platform or tech stack offers. That platform does not only address classical SAP on-prem solutions like Business Suite, it also supports SAP's SaaS Cloud solutions like SuccessFactors, Ariba, Concur, FieldGlass, Hybris etc. and of course S/4HANA in its deployment models. Just think of building mobile Fiori apps providing a new UX to an existing SAP app... Of course, this model of "extensions" will require to connect remotely via APIs to the respective SAP solutions.

    There's clearly a place for each type of "extension" or "custom code" in the overall picture if one doesn't go "black and white" pov.

    So I keep repeating what I said before: ABAP lives! Prospering nicely and becoming even more powerful than it ever was before as we enhance it for Cloud, native HANA, Fiori, etc.etc.. And this will not only benefit the Cloud version of S/4HANA, but also the on-premise version.


    • Thanks, Bjoern. This is pretty much what we heard at SAPPHIRE, but I think you've delineated the major points and differentiators more clearly and succinctly than is often the case elsewhere.

      • Hmm, did we go to the same SAPPHIRE? The messages I kept hearing were along the lines that if the SAP customers don't drop everything and switch to "The Cloud" (preferably right now) the hell will break lose. πŸ™‚

        Unfortunately it appears that SAP Marketing speaks louder than more reasonable
        "technical" voices and the messages they convey don't always correspond to reality. I hope someone will come to understand that this just confuses the customers and breeds all kinds of conspiracy theories. Ideally we should not need Bjorn to decipher what SAP is really saying (although it is nice of him to clarify).

    • Björn

      Thanks for the clear cut explanation. To be honest i didn't receive such a clear answer from any other SAP folks on the same topic. Much appreciated.

      Also need clarification on other question related to the same topic. I believe some of the offerings that you have mentioned for instance Hybris, Concur are complete Java based solutions but the extensions for such solution is possible through HCP using Java. In the same way why SAP cannot provide ABAP as an alternate development language in HCP to built extensions for S/4 HANA. What is the real challenge? Are there any future plans to onboard ABAP to HCP?



      • Abdul,

        valid question. We get that one once in while, but it's not that this is the most urgent request we keep receiving.

        From a purely technical perspective, one could of course imagine to put an ABAP stack "into" Hana Cloud Platform (HCP) -- it's all just turing-complete software ; ). But it wouldn't comply with the cloud operations and lifecycle principles and requirements that HCP as a PaaS requires.

        Again, we would have to distinguish ABAP language and ABAP stack. If there were a PaaS-suitable ABAP runtime available one might consider putting it into HCP, but reality is that ABAP as a language cannot be considered independent of the whole ABAP stack it runs in. This stack was completely built around certain paradigms of how a system gets operated and software development including software lifecycle management is done. This whole model simply doesn't smoothly fit into the concepts and operations principles of HCP today (and even less likely into where we're driving things towards  from a future perspective with CloudFoundry). So you have to decide to take the whole ABAP stack "as is" and put it into "the Cloud" which basically means operating it on your own on some Infrastructure-As-A-Service offering (like what you can do with SAP's Cloud Appliance Library approach on e.g. AWS) or going for some Managed Cloud offering like SAP's HANA Enterprise Cloud where someone else is operating the ABAP stack for you including the underlying infrastructure.

        So if you want to have an SAP operated ABAP stack in the SAP Cloud, you may go for HANA Enterprise Cloud (HEC !).

        We're currently working on providing direct IaaS access within HCP (Platform-as-a-Service) to run alternative stacks to what we offer as-a-Service in HCP itself. This may be a way to get an ABAP stack "into" HCP as well. But all disclaimers apply (this is not a product announcement. Don't make your buying decisions based on this. ; )

        What you always need to have in the back of your mind: even if you would take an ABAP based stack in HCP to "extend" the S/4HANA application, it would be a remote extension -- "side-by-side" -- and you have to rely on remote API calls to have the two apps to talk to each other. You wouldn't run "on top" of the same HANA instance and you couldn't directly access all of the underlying data model. If you have an "in-app" S/4HANA extension though, your extension is part of the ABAP stack and application (hence "in-app") and runs "in-process" on top of the same HANA instance. There's a place for each type of "extension".

        Hope that clarified further.


        • Hi Björn,

          If NW ABAP stack needs an IaaS like environment, is this what SAP does for S/4 HANA ? SAP is creating (manually or automatically) a separate environment (individual NW ABAP Stack) for every customer of S/4 HANA. Is this a fair statement ?

          Then there is no PUBLIC cloud version of S/4. It is always separate/individual environment  (so called PRIVATE cloud or HEC) for S/4.

          In that case why don't SAP allow all of them to customize their own system equally ? why should HCP be used ?

          This is important because everything goes back to the way it was before just like the on premise world.

          Can you please share your thoughts ?


          • Hi Pramod,

            S/4HANA for Cloud separates customers through provisioning highly standardized, fully automated and isolated systems. Still I wouldn't consider this "private cloud" -- it still is a public cloud Software-as-a-Service model (e.g. public internet access via standard protocols and clients (Browser with Fiori UIs) only) where SAP (and not the customer like with Private Cloud applications) operates the solution. 

            Since SAP is responsible for the SLA provided for the Software-As-A-Service, SAP controls what extension code goes into a customer's system and what doesn't. Hence the restrictions in terms of adaptability with only limited and controlled means (pure config based customization, code only at certain extension points, etc. see my comments above). Only this way, SAP can guarantee that systems remain "upgradeable"/"updateable" in a smooth and automated fashion and all systems can be treated equally.

            HEC is different. HEC is not public cloud accessible but links into the customer's corporate network as a virtual private cloud. And HEC in particular allows for customer specific system configurations and customer specific code extensions. In HEC, SAP operates infrastructure and basis systems. The application management is done by the customer itself, a customer's preferred partner or SAP, who is offering according Application Management Services optionally.  

            Hope that clarifies.


  • @Bjeorn - you talk about "in-app" extensions for the S/4 HANA in the public cloud. Are those extensions created using the HCP using JavaScript or whatever. Just need to be 100% certain that there is no ABAP involved here.

    In addition it was mentioned at Inside Track that HCP supported many different languages (apart from ABAP). Does this mean Microsoft Developers could build something there in C sharp (or whatever it is they use)?

    @Mark - I remember our lovely project in 1997. We spent ten million pounds putting SAP into our UK organisation, and then six months later the ownership of the company changed and they spent ten million pounds taking SAP out again. Then in 2007 the ownership of the company changed again, and back I went to the UK in 2009 as part of the ten million pound project to put SAP back in again, In every case these were just "stay in business" projects where success was measured as "can the system work as well as it worked before?".

    I am happy to say in Australia we have got a lot of added value out of SAP over the years!

    In regard to new versions of SAP having functionality that was previously custom, the problem is that if something was missing - say dispute management - and a company built it's own bespoke ABAP application to fill this gap, then that bespoke application would fulfil that particular companies needs 100%.

    When the SAP version comes along it has to satisfy the entire world, so it is only going to do 90% (at best) of what the bespoke version could do, so the company would have to add user exits and what not to add the missing bits.

    So the business case would be "let us retire our custom version, and then spend some months learning about and then configuring the new standard SAP solution, and then write some user exits, and then we will have - if we are lucky - something that worked as well as if we had just done nothing and kept with our Z version".

    There are obvious benefits to going with standard solutions e.g. SAP does the bug fixes and upgrades the functionality.

    For some time I have been looking for a case study at a presentation on the internet of an SAP customer that has in fact retired a custom solution and gone back to standard because of a new added thing by SAP that filled the gap. And I don't mean just a small gap filled by a user exit but a whole application.....

    Cheersy Cheers


    • Paul,

      the "in-app" extensions in S/4HANA for Cloud are done through customization/configuration (e.g. field extensibility) or ABAP code (functional extension points). "Side-by-side" extensions can be done on HCP in Java, JavaScript, HTML5/CSS, etc.

      .NET is not supported today. I consider this an excellent candidate for the IaaS-"breakout" scenario I have mentioned above (we call it "root VM" internally). Whether we add .NET as an SAP supported runtime environment, remains to be decided.



  • I did suspect that "SAP want everyone on the cloud" is more of marketing slightly moist dream than a vision of any actualisable future. 

    I'm always up for learning new things, so the demise of ABAP wouldn't bother me much.

    Of the "new" stuff my order of interest from least until most is:



    The pirates' language - R

    That should cover me for the next few years.

  • I will keep this short (for once? haha)....EXCELLENT write up! Almost felt like I was there with you....being a cynic-by-your-side and everything! haha Thanks for putting this up!

  • BOPF?!  Bahahahahaaa!  Or should I just cry.  Twice as much programming so you can cram your business processes into their framework.  To give credit, yes, there are a few benefits like letting the framework handle database updates.  But that key processing logic is ridiculous and cryptic just for a simple database read!  I would say DOA, but I've been wrong before, like about ABAP Objects/Classes taking off.  Missed that prediction bad!

  • What SAP needs is a good API, the UI is secondary. If you have a good API then yes we can build extensions on HCP and I will gladly do it in Java or Javascript.

    Unfortunetely I spent some hours during the weekend trying to find a BAPI (not an unreleased FM) to change the name of a customer. I failed. Even if it exist, SAP's biggest problem, and the reason customers build so many upgrade breaking Zs, is the very poor quality of its API. I was hoping to hear we would have a new API as a result of the S4/HANA "rewrite" but Hasso didn't give me that good news.

    I ended up doing a batch input which obviously may break in a future upgrade, but I didn't really have a choice.

    • There will be APIs. As part of "Fiori" new UI the whole system gets REST/OData interfaces all over the place. The remaining task to solve: Which ones do we make public and keep them stable (or version them) and which ones remain internal (as they are very UI specific). Current good candidates for read access are APIs derived from CDS (Core Data Services) and for write access derived from Draft Objects (a mechanism in Fiori programming model to overcome stateless backend programming, save intermediate data entries for error checking and consistency and submit transactionally at the end).


      • So we will have a new documented REST API for all business objects like customer, vendor, purchase order, sales order, etc? Please take into consideration that people have a lot of complaints about the SAPUI5 documentation and I have to agree that compared to iOS or Android APIs they are very lacking.

        I can't stress enough how this lack of APIs (derived from the coupling of UI and business logic in classical SAP) is one of the reasons for so much "hard" development that breaks upgrades.

        The whole "simplify" approach is impossible if you don't have access to public documented APIs and need to keep hammering away at the core.

        • Joao,

          I couldn't agree more: APIs are the key. Without them, the whole story doesn't fly as intended.

          Regarding the complaints about the SAPUI5 documentation -- which I assume is an independent topic to the S/4HANA API discussion here: could you share more of your thoughts about this with me? Would be interested to understand what we need to do about the documentation.

          Thanks a lot for your support,


          • In the case of Javascript the main problem is that the language is untyped so you need to specify in the JSDoc the real properties of an "Object". Right now, saying a method takes in a variable of type "Object" in Javascript is basically saying nothing.

            You need to specify what properties that "Object" can have, that are handled by the internal logic but many times this is absent which forces you to read the code, or look for code snippets. SAP Explored has a lot of code snippets which make the most used components manageable, but if you look at something like Sap.Viz the API is cryptic.

            And I think of the BAPI documentation of ABAP which is even worse. Several BAPIs have no documentation whatsoever.

            What I'm saying is that SAP's track record doing code documentation is not awesome, and it will be very important going forward.

          • Thanks Joao, for clarification.

            I'll get your feedback to the SAPUI5/OpenUI5 folks in my team for commenting/fixing if needed.

            In regards of the BAPI documentation, that's a different story... Let me see what I can do about it (not my own construction site)...



          • Thanks, but as far as the BAPI documentation, I look to the future for the new API. I don't think we should expect SAP to fix that, I'm just really hoping SAP gets this next one right. Don't take it the wrong way, SAPUI5 is a good upgrade from BAPIs and SAP has embraced a standard way of documenting APIs. It's just a first effort that could be improved.

            If this REST API is good, I think many developers will embrace HCP. Right now my biggest problem with HCP is that I can't visualize integration with SAP using the current APIs.

          • Pooh, happy to hear you'll give in on fixing the BAPI documentation ; ) Let's do a better job on the new APIs front...

            Regarding SAPUI5/OpenUI5, the team has worked on improving tutorials. This will be rolled out very soon. Furthermore, for the upcoming dev wave (we make highlevel plans along 3 months "waves") the team has put significant time for each individual UI5 developer into the backlogs for improving and fixing issues in the existing API documentation of UI5. We'll make sure to have the most burning pain points addressed.


  • I've been coding ABAP since 1992 or there abouts, and I think I've heard from SAP marketing of ABAP's immediate demise about once every 2 years or so on average since then. So I wouldn't set too much stock on this latest news of its demise, not until someone invents AI that can understand the most cryptic functional specifications that you can imagine, and manages to turn that into a working application, from what I've seen we probably have another 20 years or so before that becomes even close to reality.

  • In addition to what Björn already said, one should point out that the last two years brought the most break-changing changes to the ABAP language in years. Look at all what has been done to bring modern functional paradigms to the language and what is done to support the latest and greatest SQL features via Open SQL or CDS for all databases (and especially HANA). Let alone that we now have, with ABAP in Eclipse, a modern test driven enabled and platform independent IDE at hand.

    With this efforts, the ABAP language raised to place 19 in the Tiobe index of most commonly used programming languages (I remember it was way beyond 30 a few years ago). A few weeks ago it was even more popular than Ruby when I remember correctly!

    • I had never heard of that "top of the pops" type chart for programming languages.
      - I had always wondered how popular ABAP was in the grand scheme of things.

      It came as no surprise that Java was at the top of the tree. I was wondering about ABAP, I thought it might be popular because of the large number of big companies using SAP, but I suppose the number of big companies are swamped by small companies.

      Anyway, well done to ABAP for getting to number 19. Now all it has to do is beat COBOL which is coming in at number 18.

      Wally from the Dilbert cartoon knows how to program in COBOL, though Dilbert himself does not. I am willing to bet neither of them know ABAP.

      COBOL Programmer.gif

      COBOL Programmer.gif
    • Kilian Kilger wrote:

      to support the latest and greatest SQL features via Open SQL or CDS for all databases (and especially HANA).

      Don't mean to beat the dead horse, but it'd appear SAP might be doing this not out of love for ABAP but rather out of love for HANA or just sheer necessity. Just like people do feed prisoners who are on the death row. Just sayin'...

      @Paul - actually I just stopped getting emails from recruiters regarding COBOL positions just a few years ago. The darn thing will outlive us all, as it looks. πŸ™‚

      • I wouldn't rule out that from time to time some smaller things happen at SAP that you could only explain with the fact that someone had a particular urge to do something "out of love" for a certain product or component, but for major investments we normally don't make decisions purely "out of love for something" ; ) Neither would this be appropriate from a business perspective, nor would it -- in this particular case -- do ABAP justice (not that ABAP would even need such kind of favours ; ).

        To build on your "horse" picture: ABAP is a work horse if it comes to running powerful business applications. That's why SAP keeps investing heavily into it. By putting HANA underneath ABAP and bringing up to date features of SQL into the stack via Open SQL and Core Data Services (CDS), we not only improve the support for developing apps on standard databases, but we make the best capabilities of our in-memory platform HANA available in an easy to consume fashion for our, our partners' or our customers' application developers -- all in ABAP. And of course this is a major goal of SAP. It would be stupid not to do it.

        If -- as this blog post from Paul suggests above -- there may have been a time where SAP was not 100% clear about the future of ABAP, I think latest by now with HANA and S/4HANA there should be no doubt left that ABAP is and will remain strategic for SAP for decades to come.

        • Long live the King ABAP. Well when the top boss of SAP replies in clear manner what else can one be doubting.

          Thanks Bjoern, but as a person depending on SAP for livelihood there might be many who would agree that we need more clear responses from SAP like the one you gave. Simply drawing a beautiful picture some times lefts a lot unanswered and that makes things scary for customers and us. We really don't know what to say and when we go back to our seniors we get a deck of new slides imported from SAP. At the layer of business that gets the things made and we who deliver really don't find a common point between what the top layers says and envisions.



  • Hi Paul,

    I won't feel like ABAP being killed but I would rather say that " Re-birth of ABAP".

    We have the latest version of ABAP 7.4 with really cool features and I am sure that this change could make a Traditional ABAP Developer journey more smoothful.

    Coding is now not just remembering syntax , it's a way to instill your ideas into the compiler to make it think and behave like how you would exactly like .

    Its not How to Do it, It's about What you can do with it.

    We have SAP S/4 HANA in place, Though SAP Screen Personas and SAP Fiori completely make use of JavaScript and UI5 technologies ,the underneath core applications are still exclusively built on ABAP which would would completely utilize the power of In-Memory database. SAP Netweaver Gateway is another cool feature which would expose SAP Services to outside world through Web. This is again can't be possible without ABAP. Odata is again implemented in SEGW making use of ABAP only.

    What to say about SAP Webdynpro and FPM , these are extensively used still by many customers and these applications are built using ABAP OO concept. Take the example Adobe Forms .This would again require ABAP as well. And Last but the Least , Workflows to better the business processes are still required which run on ABAP.

    The Enhancement which is just another cool feature of SAP can't be done using ABAP

    Still many customers like the way of Enhancing few standard applications to adapt to their organization process. BRF Plus , the way to manage Business Rules is in turn built using Web Dynpro ABAP framework.

    I won't see ABAP just as an Programming language,more that that it's a all-in-one platform for all SAP Core applications which are irreplaceable.

    Whatever advancement/improvement SAP Comes up with , the later always compliment ABAP but not to kill it. ABAP Stays Forever"

    Warm Regards,


  • Good blog about the future of ABAPer.

    I think some guys do not afraid.

    May be you can come to China to be an ABAPer.

    There are lots of companies with R/3/ ECC4.

  • I don't want to confuse people so I changed the title of the blog. I possibly made the original title an emotive statement to get a response from someone in SAP and luckily that worked.

    I wanted a response from SAP because at that Inside Track I honestly did come away with the feeling that ABAP was under attack once again. That is how I interpreted the discussion anyway.

    It seemed to me that the chappy from SAP was saying how wonderful it was to move your ERP system into the cloud and he honestly felt that would be a big business benefit to a lot of SAP customers.

    Then it was mentioned that should you do this then the HANA Cloud Platform was the mechanism by which you should "build stuff" i.e. the custom applications that the vast majority of SAP customers build on top of the standard ERP system.

    When asked what language the HCP used the answer was that you "brought your own language" similar to bringing your own device to work. The only language not supported was ABAP.

    After anyone has worked closely with computers for a while they become a bit like one themselves, and I am no exception. What computers need 100% is precision and no ambiguity whatsoever. They cannot operate otherwise (leaving aside AI and Quantum programming and the other science fiction things becoming reality all around me).

    So I wanted to know exactly where I stood. My guess was that you can stick with the on-premise S/4 HANA and life goes on as before in respect to custom programming.

    What I was interested in is as follows - is writing custom programs in ABAP and migrating to S/4 HANA in the cloud mutually exclusive? My guess was yes but I was getting all sorts of vague hints otherwise.

    My question was "can I do custom programming in ABAP with the S/4 HANA in the Cloud". I think the answer is no, but the answer I got on the day was "not as much as you are used to" which could mean anything. It's like saying I have a present for you and it is not a banana. That does not really give any clues as to what the present is.

    The answer went on "you can still add Z fields to tables without modifying the core S/4 HANA Cloud system". OK, but how do I populate those Z fields which I have just created? I normally do some sort of programming to fill in the values using user exits.

    So what I want is a one word answer YES or NO as to whether any custom ABAP programming at all is possible to influence the behaviour of the S/4 HANA ERP system in the Cloud. Not "it depends" or "somewhat".

    If the answer is NO fair enough, if YES then a pointer to a detailed explanation of HOW would be in order.

    The guy who lives next door to me works for SAP and he tells me that one of SAP's "lighthouse" customers (what I call poster child's) is Nestle who agree to be guinea pigs to new SAP technology. In this case they have committed to moving all their SAP ERP systems (they have a lot I think) into S/4 HANA in the cloud.

    I would love to hear from someone at Nestle as to what this means for their existing custom programs. A company that size must have some custom programs, surely?

    Some people say that when you upgrade to a much higher release you can bin a lot of your custom development and return to standard. I would question this for the following reasons.

    Firstly your organisation may be so unique in one or more areas that the SAP standard has not yet (and maybe never will) plug the gap that your custom application fills.

    But let us say that new standard functionality does arrive that replaces a Z application you have written. I have two cases studies here, from my own experience.

    In 4.5 when you had a shipment costs document you had to settle you had to manually create the purchase order to pay the driver. We have 7000 deliveries a day so manual creation of all those POS was not an option. So I wrote a program that ran in batch each night and created missing purchase orders, just before the settlement batch job ran.

    When we upgraded to 4.7 I discovered that the standard system now automatically created missing purchase orders. That is a textbook example of an opportunity to return to standard ... I could retire and eventually delete my Z program!

    However ... it turned out the automatically created purchase orders did not have certain fields populated with the values we needed, and there was no IMG option to change this.

    So I used a bunch of user exits, using the code from my custom program to determine the values I wanted. Still I thought, when the Z program was retired I would end up with less custom code in total, and one day SAP might add extra IMG options so I could ditch the user exits (that was ten years ago and has not happened yet, but anyway hope springs eternal).

    The next problem was that for some reason I still cannot fathom in about 5% of cases the standard SAP code that creates the purchase orders fails. I can't risk the drivers not being paid, so it turned out I still had to keep my custom program running, it already checked for existing purchase orders so I did not need to change it, it just changed it's job in life to create the purchase orders the standard system had failed to create.

    So I ended up with more custom code in the end.

    The next case study is dispute handling - SAP did not have a standard system for that, so we created an all singing all dancing dispute handling system, based on the best features of several legacy mainframe dispute handling systems. It took years and years to develop but in the end it is the bees knees and does everything we might desire.

    Then we upgrade to ECC 6.0 and it has a dispute system now. Should we ditch our custom development and "return to standard"?

    The problem is you have to get someone to work out how to set up the IMG to get the system going, and then retrain all the users, and then it is possible it does not have every single feature a bespoke system would have (though it may have more).

    I know for a fact the business would not want us to take out even one feature that they are used to at the moment. How can you build a business case where the cost is maybe weeks of various IT staff time and the training budget and the benefit is that you might get a system that works almost as well as if you had done nothing.

    So to summarise:-

    ABAP is clearly not dead. The improvements in version 7.4 were nothing short of transformational. Furthermore languages rarely die which is why LISP and FORTRAN are still around after more than 50 years.

    The question is, do SAP want people to move to S/4 HANA in the Cloud or not?

    The answer will of course be "it depends on the organisations situation".

    I would then ask straight back "if their situation is that they have even one custom ABAP development they cannot live without (i.e. 100% of the existing customer base) then should they still consider moving to S/4 HANA in the Cloud?"

    Cheersy Cheers


    • The system I'm supporting covers the "extra" requirements of two separate heating utility companies - a parent and 100% owned subsidiary -- in about 3.9 million custom code lines. 5-6% of that -- the obviously dead looking code -- I deleted for our coming release. I'm yet to see a single release test bug related to that cleanup (I "know" there will be few - there always were some arising out of lesser cleanups, and I have not managed to convince colleagues to invest in setting up a custom way to use UPL without SolMan).

      Now the subsidiary is being folded back into parent and every difference in IT supported processes has in an instant become unwanted and must now disappear as fast as IT can deliver. Returning to "standard" so to speak - because it's silly, costly and confusing for the customers to have two kinds of processes for the same thing.

      It is possible to "return to the standard" most of the time, I believe, if the management understands the need for doing so, orders so and uses a mixture of cajoling and imposing its will to get the people on board. Is it possible to return to "standard" as SAP has programmed it? Most of the time, I feel, and for companies having trouble formulating decent IT requirements and/or coming up with "test management" it should actually be very advisable...

      I know for a fact the business would not want us to take out even one feature that they are used to at the moment.

      Same here, but only until their (new) bosses order so πŸ™‚



    • Hi Paul

      In terms of the cloud there are various different levels and types of clouds.

      There is a S/4HANA cloud version (the one that requires HCP) - this is managed by SAP and others customers will share the environment with you. SAP will proivde quarterly fixes/ updates.

      The S/4HANA on prem version can be consumed in a Cloud provided by a Partner such as Amazon or Virtustream. You can use ABAP in this environment. The way I see this, is rather than you buying the HANA kit - the providers will rent you space on their kit, and provide the support for the kit. This is a half way house as you get the benefits of the on prem solution, and the cost savings of renting the kit rather than buying it.

      So when someone says they are using S/4HANA in the cloud - it is worth checking - is that the Cloud VERSION or the on prem version in the CLOUD

      • The on premise version in the cloud would be the "infrastructure as a service" as I understand it.

        Instead of buying all the application servers and associated hardware this is "virtual" and SAP takes care of upgrading it to the latest and greatest technology - like the Intel Haswell stuff Hasso Plattner was blogging about last week. I can see the benefit of that given the ludicrous speed at which hardware innovations occur.

        A lot of companies - mine included - outsource this sort of thing currently to data centres run by companies like Fujitsu.

        A lot of companies - some of them German - are moving in the opposite direction, bringing everything back in house, physical machines in physical building owned by the company in question. Maybe it is all the security fears, worries that the US government is spying on their data.

        I will ask my next door neighbour what exactly Nestle is planning. Maybe it is just the on premise version in the cloud, so then SAP can publish and advert with both the word "Nestle" and the word "Cloud" in it, and not go into any detail.

    • I'm with you. Everything is clear except how to handle BADIs and user-exits in S4 Public Cloud edition. I get developments are done in HCP, but I really need to know that will happen to BADIs which can't be migrated to HCP because they are integrated in the business logic.

      • I think there should be a way to write BADIs within HCP for in app extensions (For S/4 public cloud).

        Also, what about the custom ABAP Workflows developed over the years?

        If you are not allowed to change that anymore or migrate everything to BPM/PO or future releases of HANA workflows, it will be an absolute nightmare. I am not getting whats the way around that.

        Is SAP NetWeaver Workflow not relevant in S/4 cloud (For custom development)?

        Someone please clarify πŸ™‚

        • Workflow approach is currently still in discussion on how to tackle best. It's understand that people will want to keep their existing custom workflows... More insights to follow soon...

        • I read them, but the picture is still a bit fuzzy. Don't take it the wrong way but saying I can "extend" isn't exactly what I want to know. I want to be able to know what, and how. Will that purchase order BADi which I always use be there in S4/HANA or not? The same for SD BADis and user-exits, which are always used in every project.

          I've been burned in the past by things like SAP Sourcing which had an awful scripting extension mechanism, which was so limited it was borderline worthless for someone used to SAP.

          Let's say I want to implement substitutions in FI, what are the limitations in S4/HANA compared to on-premise? I would love if someone from SAP could answer these very specific questions.

        • I might be mis-interpreting Bjoerns' answer but it looks like an "in-app" extension is somewhat like the user exits written in ABAP that we are used to today.

          My guess, and of course I have to guess, is that form based exits like you see in SAPMV45A are out as they are so unstable, but possibly we will still have BADIS as user exits with their clearly defined interfaces. Maybe. And you can still write them in ABAP. I think.

          And the enhancement framework would be a no-no in a cloud based S/4 HANA system.

          There are currently nine hundred and twenty six types of user exit in an ECC system, I imagine this will be simplified into less.

          The trouble is when we are told there will be "less" opportunities for user exits (if that is what an "in app' extension is) that could mean anything from 99.99% of what we have currently to 0.01%.

          I think the only way we are going to find out is when people get to talk to someone in the IT department of an SAP customer who has migrated to S/4 HANA in the Cloud (not the on-premise version in the cloud, but the cloud version in the cloud) and ask them what they did about their existing user exits.

          If there are already several hundred such companies - as SAP marketing alleges - then sooner or later I should find one you might think. In October I will ask everyone I meet in Las Vegas at TECHED and I might find one there.

          • Yes, I supposed SD userexits are gone as they used global variables and were everything an enhancement model shouldn't be, but when you talk about the enhancement framework chills go down my spine.

            The enhancement framework was a great leap towards the end of cloned transactions and upgrade hell. Customers cloned transactions because they had to, even yesterday I had to enhance the inventory differences report because it only shows the base unit of measure and the customer wanted to see the sales unit. In On-Premise there are explicit enhancement spots to achieve this, will I be able to do this is S4/HANA Cloud?

            SAP is asking for a leap of faith here, for SAP consultants to push S4/HANA Public Cloud but if are honest with your customers we really have to warn them against it, as there isn't enough information for the customer to support his investment.

  • SAP recently published a white paper on SAP® S/4HANA Extensibility for Customers and Partners:

    It explains in detail the complementary approaches of side-by-side (HCP) and in-app (ABAP) extensibility. And the different approaches for on premise an cloud edition.

    PS: Just to avoid disappointed comments: no, unfortunately it does not contain a concrete list of BAdIs and API that are available.

    • Many thanks for that. That was exactly the sort of thing I was looking for.

      It seems that user exits are still there and can be written in ABAP via a web based editor. Presumably this works by having the BADIS filter dependent, with the filter being the particular SAP customer that wrote the user exit.

      That way all the code stays in one big central place. Naturally I am only guessing but that sort of sounds right to me, explains how customer ABAP code can run in one whacking great shared code base shared by lots of organisations.

      The other notable thing is the statement "the list of ABAP commands available is restricted". That is the sort of thing that makes programmers break out in a cold sweat, especially as what follows is very woolly and programmers like precision.

      We really need to know what is and what is out. It mentions that variables and internal tables are still there (thanks) and conditional & flow logic (presumably IF/THEN and CASE and hopefully LOOP). But something will be missing, clearly. I wonder what?

      • Hi Paul,

        on page 22 of the document about S/4 customer extensions you find something called 'Managed Extensibility' (Talk to the marketing guys and you will get such names πŸ™‚ ).

        This kind of extensibility in the cloud is very close to the custom development that we are providing on premise. But you can imagine that ‘freestyle’ custom code in a cloud environment is not possible when looking at the cloud operations model.

        Therefore we have defined some rules new rules for developing custom ABAP code in the Cloud.

        For example modifications of SAP code are not allowed anymore and enhancements can only be done via Badis and not via implicit enhancement points.

        Another rule is that you as a developer can only use SAP objects that are released as public API. So we give you a set of APIs that you can use in your code and we guarantee the stability of these APIs. The syntax-check will ensure that customers do not use SAP objects that are not released. Typical candidates for this API are classes, interfaces, function modules, CDS views and data types. Most likely the CL_SALV_TABLE is part of the API πŸ˜‰ (Special thanks from my UI colleagues that you mentioned this framework in your book)

        There will be a session at Teched this year about the S/4 extensibility. Would be nice to meet you there at the session and have some discussion afterwards. Session catalogue should be opened in the next days.

        Kind Regards,


        • Hi Thomas,

          thanks for the quick reply. Exactly.

          As Thomas said: we are on the way of defining the API.

          On TechEd 2015 we will offer several sessions where we go into details of the released statements and APIs for the key user extensibility and the managed extensibility. At that time he can hopefully lift the curtain. We completely understand that you need this information for your planning of your cloud projects.

          Best regards,


        • Unreleased function modules and all kinds of classes are, in my experience, very much used by many clients. (I recall one APO site where the SAP consultants used unreleased FM that disappeared the next release...). There are even function modules that are "unreleased" yet are recommended for use in the documentation, and have sample programs.

          The use of only released SAP objects in general will also have a major effect on current installations. You only have to do a quick syntax check of almost any custom development to get yellow warnings that the object isn't in an accessible package.

          So either existing customers won't be able to move across without massive refactoring, or SAP are going to have had to invest enormous effort in making sure the APIs and exposed objects are comprehensive enough.

          Except for new customers, and those who use out-of-the box, I'm baffled to how these cloud solutions will work. It sounds like SAP have an idea of how their products should be used that is somewhat at variance with how it is actually used. But that's nothing new - you only have to consider, for example, the new SPAU which was utterly unfit for purpose (and has now been ditched).

          Of course it's possible that I'm really stupid and/or don't really understand what's being proposed, but nothing said so far has eased my bafflement..

        • Another rule is that you as a developer can only use SAP objects that are released as public API.

          I completly agree with this. If customers used unreleased FMs it's their own fault, except when SAP explicitly says in a note that we should use such an object.

          SAP should release and maintain all objects that it advised customers to use.

          On the other hand, we won't have BDCs to close the gaps, so SAP should really make sure every object in SAP has a released API. If I want to manipulate the picking of a delivery, it's not possible via released API (for example).

          • The problem is that in most cases you don't have any real alternative for unreleased FM, classes.

            Unless SAP are going to rebuild their public API from scratch (what should have been done long ago), I don't see how/why it would change.

          • Hi,

            for sure we will not have a released API from beginning that serves all use cases that you have developed over the last decades. The API has to grow with every Cloudrelease based on your input. The API will be at the end a mix of already exsting interfaces and newly created interfaces. 



          • Thanks for the clarification.

            If it was up to me, I would have start with real and complete object representation (in whatever framework you would like) of the main business objects in Logistsics and Sales: Material, Sales order, Purchase order, Material document, etc.

            I guess it covers almost 50% of the customer's requirements.

          • The community has complained for years that the API is lacking, what makes you think it will change with S4/HANA? Like Paul said, the delivery BAPI has been lacking for a decade.

            SAP should really analyse why customers make so many crap developments. Many times a lacking API is to blame, and you can't "run simple" when you use un-upgradable hack jobs (which shouldn't be necessary).

    • Hi Thomas,

      Thanks for the document. It says for defining new business process (i understand this mean developing new applications) SAPs recommendation is to use HCP. Whether SAP does not recommend to use ABAP for building brand new applications in S/4 HANA?



  • Many thanks to the two Thomas's for clearing up what will and will not be allowed in the cloud cloud non-on-premise version of S/4 HANA when it comes to ABAP programming. I will try and attend that session in TECHED in Las Vegas, if I can fight my way through the door.

    It is true that despite many attempts over the years SAP have yet to come up with a set of APIs for all the common business objects that can do everything a BDC can do. Often after calling the change sales order BAPI I have to do a BDC to update the things the BAPI cannot, and the delivery BAPIs have many critical fields missing.

    I have to agree with Matthew about any company which has used SAP for any length of time, and has a non-trivial amount of custom ABAP development, struggling to make a business case for migrating to the non-on-premise version of S/4 HANA. It seems so much simpler to migrate to the on-premise version and keep everything you have developed over the years.

    Mind you, I would be fascinated if someone would say "my company is 100% for sure going to make the jump to the non-on-premise version, and here is why".

    Any takers?

    • I'd add that the promise as I understand it is to gradually release a better "public API". That is not necessarily a promise to release the same API SAP application developers use to develop their applications or to adapt/extend cross-application components (like Business Partner or FI-CA Contract Account for Industry Solutions). So I feel that the gap between the functionality and capabilities of the two APIs (internal/external) is then kind of "inevitable".

  • I just noticed that Managed in-App Extensions have a $$$ sign but classic in-app doesn't. What exactly does this mean? Developer licenses are paid in the on-premise version, so how much will this cost on top of the subscription?

    • Section 4.2 Managed Extensibility explains this "SAP will offer customers and partners an additional service to use an SAP-hosted development landscape to develop ABAP add-ons that allow a very high level of in-app extensibility." The price information for this service is not yet available. When you compare this with an on premise scenario, you have to compare this with the price for the developer licence PLUS the cost for the development landscape (hardware, setup, operations, updates, ...)

      • The problem is that the cloud has $$$ and the classic doesn't have $$$. Either it is significantly more expensive, or it's just a poor job from the marketing team.

        Regarding price, that's the main problem. It all comes down to price, either public cloud is much less expensive (overall), or I'll be getting much less bang for the buck. Since I doubt it, I think SAP is overestimating the value customers will see in the quarterly updates cycle. Few will voluntarily cripple themselves to get that advantage, but that's my view.

        And of course every customer will want that extensibility, just include it in the base price. If you have ONE customer with a completly standard system let me know.

        • I have been reading that extensibility document and the more I read the more puzzled I get.

          On one hand SAP note that almost every customer has added some custom code. I would agree - I have come across one or two organisations which don't have their own development department, but are there any SAP customers 100% vanilla?

          Then they say if you want to do the sort of custom ABAP development you have been used to, it comes at an additional $$$ cost and the scope of what you can do is less. So the business case for this is - pay more than what you are used to, and get less than what you are used to in return.

          To quote from the South Park episode "The Human Cent-IPAD" I think I am going to decline.

          So I think the on-premise version of S/4 HANA will be my recommendation to the powers that be where I work. You would be amazed how many companies don't ever use the new features SAP provide e.g. go to a company on ECC 6.0 and asked if they have switched any of the hundreds of optional business features that came in with enhancement packs on and you might be shocked how many say zero or just one or two.

          Given that, the quarterly updates provided by SAP in the non-on-premise version of S/4 HANA may not be as appealing as all that, especially coming at the cost of losing existing custom functionality.

          However, time will tell the tale, as mentioned above I am going to be bursting to talk to someone from an organisation who has actually chosen the non-on-premise version.

          P.S. If I have a Z report or a Z module pool - does that come under the managed extensibility? I just have to rewrite it to conform to the reduced scope of ABAP in S/4 HANA?

          • Paul, I admire your (and others) ability to make any sense at all of these documents. I gave up after a few pages - marketing clearly went to town with this document. So I'm quite happy we have at least someone on SCN here who can translate it back to human. πŸ™‚

          • So the business case for this is - pay more than what you are used to, and get less than what you are used to in return.

            You get the automatic upgrades, which I really don't trust since 90% of the problems I've had during a upgrade are not related to custom development. If customer nowadays trusted SPs, this would be a great plus, but the reality is that every SP needs a lot of testing.

            In the end of the day it's not clear that you will pay less for the Public Cloud (with SAP's track record I doubt it) but you really should since like you say we are getting less functionality and flexibility. Not only on the development side, even the core functionalities are less.

            It would make sense to position Public Cloud for specific use cases with simpler implementations that need a quick startup, not to replace a full SAP instance.

          • interesting discussion. at the moment, imho, cloud instances are a quite expensive training option for practising the latest standard SAP and don't even come close to the custom integrated installations that have been built over the years and that need to continue working in support of existing business processes. rip and replace needs to offer a much more compelling business case before the control is surrendered to the cloud.

            my 2 cents,


          • Since SAP started talking about "Simple" I thought "This is double edged sword". On one hand SAP is complicated and end users prefer a shiny Microsoft "Something" (it changes names so many times, I'm afraid to get it wrong) and that needed to improve BUT, it's SAP's complexity and robust development platform that make customer pay the big bucks. .

            Usage simplicity without losing functionality is very hard ot achieve. SAP still has a long way to convince customers that S4 Public Cloud is a worthy sucessor to ECC 6.0.

          • Can't speak for everyone but for ABAPosauruses like myself - no, it doesn't really help. There are tons of buzzwords in the document, but what the customers really want to hear, I believe, are simple answers to simple questions like: 'I have tons of code in the user exits in include MV45AFZZ, where would all this stuff go?'; 'Where will our VOFM routines go?'; 'What will happen with our BDC program to update components in the planned order because SAP does not provide an API for that?'.

          • Just to play devil's advocate a bit, I would question why you'd want to persist with so much customisation as part of a move to cloud?  I think there is a broader issue for customers to move to ANY cloud solution, that they must really challenge just why they need customisations, custom solutions and/or extensions all over their IT landscape.

            Moving to cloud solutions shouldn't (IMHO) or indeed can't be a simple lift and shift of existing functionality, processes and customisations.  Where is the benefit?  I'm firmly of the view that moving to cloud is an opportunity for process re-engineering, consolidation and general house-keeping.

          • I can agree with you, Gareth Ryan, but this kind of process cannot be done if I (generic) can rely on features that are LESS flexible than previous.

            From someone like not so deep in cloud technology/opportunity/name it as you prefer, all i can read is SAP is trying to teach customers how they have to work.

          • When I started working in SAP 10 years ago this was already the "push", to make customer adopt best pratices. It was in fact one of the drivers for SAP projects, standardization ... in theory.

            In practice, everyone tried, but had to make some developments because one size doesn't fit all, especially in a highly transactional system as a ERP. And lets face it, some SAP transactions are plainly bad.

          • You are right in the sense that are probably tons of developments that need to be removed, but I don't expect to be able to completly remove MV45AFZZ validations, or pricing formulas.

          • As others already noted, it's just not feasible to have "one size fits all" ERP system for all countries and industries with no customizing whatsoever. For example, in the US alcohol trade can be regulated not just at state but even at county level. And those governments have no concern about Cloud or extensibility - if you want to trade in their jurisdiction you must comply with their requirements no matter how odd they are.

            But BDC and such is more of a concern to me personally because it looks like there would be no replacement at all. I don't like BDC at all but they work as a last resort. What will be our last resort in The Cloud when there are no APIs delivered for certain process?

            <Deleted a lot of other comments because they would get me in trouble with SAP Gods for sure> πŸ™‚

          • You're all right of course, that at the end of the day we will all HAVE to put customisations into systems.

            But let's turn this whole cloud thing around for a minute and instead of focusing on what it means to us as the customers/partners/implementers - what does it mean to SAP?  Other cloud providers, such as SalesForce for example, do offer varying shades of one-size-fits-all solutions.  Some are more strict on that approach than others.  However, they have to react to their customer demands and try to deliver functionality that their customers need.

            It's give and take, in that the cloud solutions have to be responsive to market demand and updates have to happen regularly, in short timeframes and with confidence to the user base that no harm will come to their business.

            Taking the cloud revolution back to cloud providers (in this case SAP) we can see that you can't simply just put an existing solution on a server in a remote data centre and call it cloud.  Other things have to change.

            I could go on but it is stealing a lot of thunder from a couple of 'blog posts I have in draft - suffice to say EVERYONE in the SAP ecosphere will have to change and give a little for cloud to be the success people are suggesting it will be.

          • First off by "customisations" what I mean by the term is custom programming (Z reports and user exits and self created Z applications) and modifications to the core system, as opposed to settings made in the IMG (what I call customising). The latter is still there in cloud systems.

            I recall the SAP projects around the year 2000 when SAP wanted you to change your business to fit their software (i.e. adopt "best practice" ) and many companies did just that.

            As a sign of how well that worked at my company whenever we see a web site of software application that just does not work at all or does something stupid or illogical we point at it and say "that must be world's best practice!".

            I recall working in Israel and one of the external consultants said (I think it was a joke) that life would be so much easier if my company stopped making ready mixed concrete and started making light bulbs instead. No doubt that would be easier from an IT point of a view, but a bit of a hard sell to the CEO.

            I think we can all agree that 75%+ of custom code/ exits / modifications was written to solve a problem that no longer exists, and so are unused and should be removed. SAP has a defined mythology (sic) to do this. However the vast majority of companies are too flat out busy to do this, hence all the unused stuff tends to build up forever.

            Where I work, apart from oodles of Z programs and user exits, we have about fifteen actual 'repairs' and we do want to get rid of those. The enhancement framework just brushes the problem under the carpet, we would prefer user exits or the functionality getting added to the standard system.

            So for fifteen years we keep asking SAP and get precisely nowhere. An example is transaction MRRL - one of the dates used inside the program defaults to today's date and no company I have encountered wants that, they want to specify a date on the front screen. So companies do a repair to add a parameter. If SAP added an extra parameter for that date variable, and defaulted that to today everyone would be happy. But it is not going to happen, no matter how many people ask SAP, and how can I move to a standard system where the incorrect logic would apply? All our truck drivers would be paid wrongly and we would be out of business.

            When the "Idea Place" was born I thought "hooray" this is just the thing, now we can add such things as ideas, they gets lots of votes, and SAP will change the standard system. All I can say is "hmmm". On paper lots of improvements get made via this mechanism. In theory. My favourite example is every 'customer' development department asking to make the SALV editable, and that idea being banned from Idea Place, even if it is the most popular idea ever.

            Moving to the cloud world, I would say - hats off to Ariba - they have a clearly visible list of enhancement requests that have come from customers and against each one is the current status. Some of the added features even came from my organisation e.g. handling schedule agreements which Ariba could not do some years back. An update to the software is done every single month now, mainly bug fixes but often a bunch of enhancements as well. This on top of a major release each year. And the monthly updates only started AFTER the company was bought by SAP.

            So, if the ERP part of SAP could get to the same stage - where people could log requests and actually expect something to be done about them, that would be a very different kettle of fish.

            You are of course still going to get very industry and geography specific requests e.g. a Japanese Mice Racing company is going to have some very Japan and/or Mouse specific business functions which it probably would not be logical to include in the standard system. You would need a user exit at the very minimum.

            The most important point is that when a company already has something that works (custom application), doing a project to use a newly delivered standard SAP solution for the same functionality will naturally involve more effort than doing nothing at all, and might not do 100% of what the existing custom solution does. Rebuilding the whole thing in a different programming language is also going to be a hard sell.

            That being said I would be fascinated to hear from anybody who had in fact moved from a custom solution and replaced it with new standard SAP functionality, to see how they went.,,,,,,

            Cheersy Cheers


          • Exactly that is what our customers ask us and we ask our seniors and we really don't know except for big slides. \

            What will happen to these investments once we move to s4/hana, the data model changes fine, the ABAP code structure changes fine, but where do i put the custom logic. The biggest concern is what remains and what does not remains of the SAP ABAP language.

            Please answer.



  • I have one additional question because of the $$$: Will the managed add-ins be available for customer implementation (coding) or will they be available exclusively to the SAP Consulting team (via extra development//support fees)?

    I've been hearing some mixed messages in the last few weeks on how SAP will handle SAP Public Cloud, even from a VAR perspective. Some messages seem to indicate that SAP will have a much tighter grip on public cloud, and some even seem to indicate that licencing Public Cloud won't be available for VARs.

  • Another excellent blog!   Personally - I won't be throwing away my ABAP knowledge any time soon.   πŸ˜›    Just saying..........   100% of the companies I've worked at have had Z screens, Z transactions, Z dynpros , Z data elements, Z tables, Z....   Well a lot of Z stuff.  

    Interesting to see Webdynro as dying out.   That was one of the biggest things released not so long ago.  I did notice things don't always go as planned, I still have JAVA for the ABAP programmer.   But as you said knowledge is never wasted.  It did help me with objects.

    After reading all the comments - no I wouldn't recommend the cloud version anytime soon.  Companies get an advantage based on some of the custom code written.   One size doesn't ever fit all.   I'm surprised any company would move to HANA cloud with those limitations.

    It sounds like you had a great time!   I'm looking forward to going to Teched in Las Vegas this year.   I hope to see you presenting!

  • I was flying up to Brisbane this fine morning, and on the plane I was reading an SAP presentation about the roadmap for HCM.

    This presentation was from a gentleman called David Ludlow who is a vice-president of SAP (not sure of what). It was session number 1550 from SAPPHIRE NOW in May 2015.

    At the end there was a section about S/4 HANA and he said it did not include any HCM components at all, you had to interface to either Success Factors (the integration already available today) or to an external SAP HCM system (integration not yet available).

    That was quite surprising. We have done so much custom ABAP development in the HCM space where I work, I could not imagine "upgrading" to a system which did not have such a component at all, especially having to rebuild all the custom stuff in a restricted programming environment that costs more than today.

    That also begs the question - leaving aside the extra cost for the managed extensibility feature - at the moment our HR/Payroll functionality comes sort of bundled in with the rest of the ERP system, presumably if it gets removed and we were to have to use Success Factors that would cost more?

    Once again if I have mis-interperated the slide (though I cannot see how I can mis-interpret the sentence "S/4 HANA has no HCM component" ) I am sure someone will tell me!

    • Paul

      The S/4HANA cloud based version will not include tradtional HR - you will need success factors (assuming a new implementation)

      There are a number of other things not available - however the message is they have been replaced by best of breed SAP solutions.

      So with SLOG (this will probably be re-named) - it will complete the Suite and leave HR to Success factors.

      In terms of your situation - you have SAP ECC 6.

      You will in time upgrade to Enhancement Package 7 - perform a database upgrade to SAP HANA - and then you can activate the various Add-ons (Finance at the moment - and the rest of the suite later). Your HR will still be there - but wont be simplified and Fiorified as the rest of the suite will be

      • I presume the other things not available will be in the areas where SAP has made acquisitions in recent years e.g. Ariba, Fieldglass, Concur, Hybris and what have you, in areas where there is a duplication of functionality between traditional SAP R/3 and the newly acquired solutions?

        Why do I get a huge feeling of Deja Vu with this? I seem to recall in 2001 a move away from a centralised ERP system to a bunch of "new dimension" products such as BW / CRM / SEM / SRM, some of which gradually migrated back into the "core" (e.g. SEM).

        It is rather like the Hokey Cokey Machine (HCM).

        You put the HCM in.

        You take the HCM out.

        In, out, in, out, shake it all about.

        You do the HR Kokey and charge twice as much.

        That's what it's all about!

        • Hi Paul

          A lot of the products dont align to core ECC products (except concur) so I was not refering to that.

          If you look at warehouse management - that is not in S/4HANA Cloud edition - it will be extended warehouse management.

        • Paul, I think quite a few of us traditional HCM customers are watching the whole SuccessFactors thing rather warily. Today, I can see using parts of it as an add-on, say for recruiting, etc, but there is no way it can replace our HCM and Payroll implementation wholesale. I understand that more of this "core" functionality will become available in SF in the future, but I've also heard rumors that give me serious pause. Will SF ever include payroll postings to FI? Will it include Concurrent Employment? Will it manage the complex scenarios of having a couple dozen union agreements, each with their own holiday calendars, benefits packages, and pay scales? And employees who have jobs across two or more of these agreements? What about partial grant funding of positions?

        • Why do I get a huge feeling of Deja Vu with this? I seem to recall in 2001 a move away from a centralised ERP system to a bunch of "new dimension" products such as BW / CRM / SEM / SRM, some of which gradually migrated back into the "core" (e.g. SEM).

          The advantage of SAP is and always has been integration. When you lose that advantage and need to rely on interfaces, customers end up choosing other "best-of-breed" solutions.

          CRM had integration with ERP, but it had so much configuration involved and some limitations.

      • Thanks, Sven. So when the FAQ states:

        "SAP ERP HCM will not be simplified –HR started with user experience Renewal earlier. These features will continue to be available including the FIORI self-service applications for employees and managers."

        Does this mean that on-premises HCM is considered already simplified via Renewal and Fiori, and this is the reason there isn't a further on-prem simplification planned?

        • We are not simplifying the codeline as we do in other areas, SAP Fiori of course can even be applied via HCP as a Service. It is just one part of the simplifications.

  • As you all probably know this week SAP published their 2015 Q2 results, and there were many interviews in the media with several top SAP executives.

    AS might be imagined SAP wanted to stress their impressive (100%+) year on year growth in cloud revenue, but they also wanted to mention the very strong growth in HANA customers. For example this week it was revealed that supermarket Lidl was moving to ERP on HANA.

    Online Journalist Dennis Howlett published an interview he did with SAP top dog Rob Enslin. There were many interesting quotes, but I found the most interesting thing was from when Mr.Enslin was talking about adoption of S/4 HANA.

    "We will see 1000 of our top 2000 customers do some sort of project in 2016. What's interesting is 41% are new customers. Elsewhere for example, Shell has multiple projects.

    In total we have 137 running (S/4 HANA) projects and all are on premise at this time"

    Every single company taking the on-premise option? Who would have thought.

    This may make it more difficult than I anticipated to find someone at SAP TECHED who works for a company who have moved to S/4 HANA in the non-on-premise cloud cloud version.

    • Who would have thought, indeed. Which just stresses the importance of support for the on-premise version which will keep being the main options for years to come.

      What explains the 100% increase in cloud revenue? Concur/Fieldglass?

      • 100% of nothing, is still nothing πŸ˜‰

        Very interesting it appears people are still going for on-premise.  I'm trying to understand, at a very high level, is that because either a) SAP isn't doing Cloud in the way their customers want or b) SAP customers don't understand how Cloud could benefit them?

        No doubt it is somewhere in between...

        • It is worth noting that some of the S/4HANA implementations will be in the "Cloud" - however it will be the "on-premise" edition and not the "cloud edition".

          net new customers will be directed to the cloud edition - but these will be smaller organisations.

          the on-prem version has more of an appeal to large enterprises.

          • Thanks Mark - think you've just summed up my thinking on this.  SAP as a platform is still "too big and complex" and therefore it's customers still aren't aligned to what true Cloud offers and can achieve.  There's still a fundamental mis-match for me.

            "On-premise" "Cloud" is back to my favourite definition of cloud - other people's computers...

    • I believe the Man City (football/ soccer) implementation will be the Cloud version.

      I am not working on this so cant be sure - I would assume this would be a Sapphire 2016 announcement

  • "On-premise Cloud" sounds like an oxymoron. Could bright minds in the SAP marketing department possibly come up with some new words?

    For example, take a cue from the chocolate companies and name S/4HANA editions after endangered species, for example. Who wouldn't want to buy S/4HANA Panda edition? πŸ™‚ Think about it!

    • Perhaps "Cloud Edition" could be "S4/HANA Sassy" (SaaS) and "on-prem" edition (whether hosted in the cloud or not) could be "S4/HANA Passy" (PaaS)... Sassy and Passy... who wouldn't go for that? πŸ˜‰

      • /
        • In one SAP Press book round about 2002 when the second edition came out somebody had clearly done a "find/replace" so that the word "application" turned into "e-application" as in "to improve the performance of your e-applications, proceed as follows".

          E E, E E, E E....

          There is no need to laugh!

          • I was at a Big-5 consultancy around that time (2000), and they proudly announced that the senior partners had been to an 'e-training' course and were now all totally 'e-literate'.

            OK, it sounded funnier when they said it out loud.

            Paul B.

          • I am sure many of us lived through the times of "add DOT com to the end of every company name" and "prefix E to every product/strategy/feature/department name". Those were some very "interesting" times. πŸ˜›