Is SAP’s ABAP a special snowflake or has a Git run it over?

SUMMARY:

A vibrant and important conversation among SAP Mentors provides insights into the challenges SAP faces in an open source led world.

abap snowflakeEvery now and again, a public discussion emerges around the SAP developer ecosystem that becomes an important talking point that reverberates around the SAP community. The topic of #abapGit is one such. It raises questions about the future and relevance of SAP across multiple topic domains.

A Royal Flush

It all started when I made a remark on Twitter about diversity at SAP. A few back and forths later and Nigel James (one of the co-founders of SAP Inside Track) skilfully finessed that thread to say this:

As Nigel correctly gambled, I bit the bullet, looked at abapGit (it’s on GitHub) and came back with:

SAPapalooza – game on

There then followed a spirited back and forth over a number of days and across 12 timezones. By any measure, that’s one heck of a conversation and gives you some idea of the passion that SAP technical topics stir.

Nigel rounded this conversation out with a blog post on the SAP Community Network with the provocative title: ABAP – The Special Snowflake coupled with the rather snazzy graphic which I have stolen for the purposes of this story. His summary covers the topic well:

  1. ABAP has legacy tools
  2. ABAP has legacy culture
  3. It is stuck there and will never ever move
  4. ABAPGit is the best thing that happened to the ABAP ecosystem since ABAPUnit
  5. Adoption of both of these toolsets are woefully low (Please see point 2.)
  6. These are exactly the tools that we need to create CI/CD platforms for SAP landscapes.

If you’re not part of the SAP ecosystem, this might sound Chinese to you and if you are then it’s pure SAPenese and you ‘get’ it. For the coders in the crowd – I urge you to check out Nigel’s excellent story. There is a vigorous technical debate which, while opaque to many business users provides valuable insights into the tensions that exist in the SAP environment.

A break in proceedings

I frequently get asked what I believe is the future of SAP. I don’t know any better than the next person. But these are a few things I do know and which I have observed over the years and which are directly relevant to where SAP finds itself today.

ABAP was a brilliant invention by co-founder Hasso Plattner’s team in the days of R/2. That’s pre-1992 to you. It was brilliant because it provided developers with a relatively easy (if, by modern standards) verbose way of building applications around the SAP core. If you want the full history then check out this Wikipedia entry.

A winning hand

ABAP is only meant to work directly with SAP systems. This has the side effect of creating a closed – as opposed to open – development environment. It is, in my view, the primary technical mechanism by which SAP locks its customers into its own environment. At the time it was being popularized, there was no internet and there was very little by way of integration as an imperative. So that lock-in was not obvious or even that important.

As we know, the client/server breakthrough that R/3 represented put SAP on a rocket ship path. It was THE enterprise unicorn of its time and today can lay claim to running 50-70% of the world’s production in some shape or form. Evidence of that may not be obvious to the casual buyer but you can bet that at ANY enterprise business conference, a good number of customers will also be SAP customers. As an example, at an event I attended this week, one customer talked about 200 SAP systems in their company’s ecosystem. They are, quite literally, everywhere.

A fatal flaw

The problem is that SAP’s massive advantage of the 90s and 00’s has suddenly become a liability. The rise of the internet as the primary transport over which we all get our ‘stuff,’ the emergence of cloud, the development of SaaS, the emergence of easy to use, open source platforms and, most recently, the explosion in API-based microservices fueling the XaaS economy has left SAP vulnerable.

On the one hand, the closed nature of SAP systems continues to provide the company with an advantage and one that it has tried to leverage through the concept of ‘indirect access.’ We have debated that issue here many times and it is a topic that remains very close to buyers’ hearts.

On the other hand, I cannot think of a single recent example where customers look forward to attempting to leverage SAP generated data – or processes – with or through non-SAP, open source or open platforms into 21st-century applications. It can be done after a fashion, which is kind of where abapGit is trying to play.

The cultural melee

But as Chris Paine pointed out:

Then there’s the culture issue. SAP has a long and to my mind sad history of what is jokingly called NIH or Not Invented Here. SAP believes its German engineering heritage is the best in the world. I beg to differ. But what it means is that when SAP views technology, it rarely buys what it doesn’t have but it goes into a huddle an emerges with – ‘we can build it better.’

At one time that might have been valid for MRP and back office applications. Maybe even SAP’s forays into CRM. But it is absolutely not valid in the 21st century where we are seeing brilliant ideas around RPA, AI, blockchain etc coming out of the startup community.

Names we didn’t know existed five years ago are becoming powerhouses in their own right. Yesterday I met a software robotics company that’s coming out of stealth with 8-figure revenues, profit on the balance sheet and an expected cap of $200 million plus in the next year. It didn’t exist five years ago.

Not so hot

Even in the hottest of topics – blockchain – SAP’s partnership with IBM which produced Hyperledger is limping along at a time when blockchain technologies are being gobbled up in POCs at numerous SAP customers. Again, I saw that first hand this week.

The last 8-10 years, various leaders at SAP have attempted to embrace the open source community and, in fairness, SAP is committed to big projects like Cloud Foundry. Its flagship database HANA is based on open source. But as with all things SAP, appearances are not always reality.

Or, to put this into technical perspective, check out this part of the conversation that Nigel distilled:

and then:

The Special Snowflake

and finally…

All of which brings me back to where I started.

The final hand

The technical topics that commenters made above will be solved – one way or the other. But I think this conversation is noteworthy on two counts:

  1. All of those involved are or were SAP Mentors which means that in the eyes of SAP, they represent the very best of what can be achieved in the SAP world.
  2. As the best, they have eyes wide open and see the issues. the frustration of some is palpable.

While they won’t say it, I will. Those of us who have lived and worked in and or around SAP have a special affinity for a company that has been wildly successful and can still count on having a brilliant technical founder with whom we can not only chew the fat but enjoy valuable discussions. But – that won’t buy the goodwill of customers who want much simpler and productive solutions. If ABAP is holding them up then it only makes commercial sense to work around SAP.

And that is where the real risk lays because when viewed through that lens, SAP becomes irrelevant.

Image credit - Photo by Aaron Burden on Unsplash and via Nigel James

Disclosure - SAP is a premier partner at the time of writing

    Comments are closed.

    1. Hasso Plattner says:

      hi everybody,
      i don’t know what sap systems you are talking about. yes, s/4hana is mostly written in abap and java script, but in the public cloud nobody has access to the source code any more. add ons can be written in many languages, abap was added only recently on customer request to the sap cloud platform.
      what makes abap valuable for the developers are the several hundred microservices, reused again and again in business apps. for analytics, machine learning, intensive math, etc other subsystems are used.
      the data is stored in hana and can be accessed from many languages, abap doesn’t lock anybody in at all. i don’t know who came up with that idea.
      in a new project the abap microservices are embedded in another language, scala, and completely invisible to the developer. probably you might like scala better. with scala we can hopefully get rid of java script as a language we have to code in.
      a large part of sap’s revenue comes from the cloud and most apps aren’t written in abap at all.
      it’s time to move on and off the ecc6.0 (r/3) version of sap.
      btw, do you care about the language hana is written in? i give you a hint: it’s not java.
      cheers h.p.

      1. says:

        Thank you Hasso. You are 100% right to say “it’s time to move on and off the ecc6.0 (r/3) version of sap” – trouble is, that’s not where 60% of SAP customers are at or will be for many years to come and they (rightly) worry about what they perceive as the ABAP (and indirect access) lock-in while other ecosystems evolve rapidly and provide an open environment. That’s what I hear day in and out. If they are wrong then SAP needs to make a bold and unequivocal statement to that effect.

        1. greg misiorek says:

          @den,

          i think you’re onto something here. it seems that as hard it was to get implemented into r/3 (and it was not easy) it may even be harder to deimplement into s/4. the sheer number of bolt-ons with their own versioning and sometimes mission critical business logic stops a lot of upgrade conversions from the get-go.

          thx, greg

          1. says:

            As Hasso said to me privately – 20-year-old tech. The sad thing is that it has proven so robust they managed to rebrand and sell all over again while customers customized the crap out of it.

        2. says:

          Hi Den,

          Thanks for trying to sneak the Indirect Access licensing threat into this thread :-). I noticed that no one dared pick up on it. It always amazes me how the one topic that can turn all of these conversations inside out just gets glossed over…or should I say “normalized”…in these discussions.

          Indirect Access is the single largest deterrent to innovation in the SAP customer base. Maybe not at the geek level but certainly at the CEO and CFO level. As long as the specter of an excessive indirect access licensing fee is in the air, innovation in the SAP world will be limited…SAP’s proclamations to the contrary notwithstanding.

          SAP really can’t have it both ways. If they choose to open up their core platform to new technologies and applications than they must make them accessible and affordable from a licensing standpoint. If they want to pursue a closed and monopolistic approach, either market, or government, forces will eventually rectify the situation for them.

          This isn’t about ABAP or javascript or CI/CD. The #1 issue here is Indirect Access. How quickly and how fairly SAP works through their licensing issues will determine the extent of their ability to migrate their ECC clients onto S/4 and the number of new S/4.

          I hope you’re still monitoring this thread Hasso. As Den says “SAP needs to make a bold and unequivocal statement” in this area.

          Sam

          1. As I recall. Shai Agassi first called out a new model for licensing indirect access was required speaking at the Churchill Club on November 9, 2005. Document based licensing borrowed from EDI isn’t the type of digital licensing that Paul Buchheit invented in AdSense as part of his work on Gmail. SAP needs to innovate or find itself disrupted. Buchheit’s partner Bret Taylor now works for Salesforce as CPO.

    2. Fred Verheul says:

      Hi h.p.,

      I’m sure you’re right about SAP as a company embracing other languages and platforms (you’d know that right?). The current discussion is IMO more about the SAP developer ecosystem though, and there we’ve got about 99% ABAP devs, many of which have no interest in or are not capable of learning new languages/tools/dev processes/etc. Which is were the request to add ABAP onto SCP is coming from. And sadly the current state of ABAP as a platform, with its integrated code, infrastructure and management (quoting Ethan Jewett here) means a hard stop to innovation and agility.
      I hope I will be proven wrong here, especially with ABAP on SCP, but once customers start realizing that their ABAP IT shop is stopping them from innovating and competing, my guess is they will move to other platforms and hire developers that can help them innovate.
      So IMO the choice is up to SAP: either bring ABAP into the 21th century, or try to build a new ecosystem of cloud developers (Scala? Love it, but will that scale?).

      Cheers, Fred

      1. says:

        Bingo – rock/hard place? You choose…

      2. Hasso Plattner says:

        hi f.v.,
        ok, you want more from abap. sap has hired over 100 additional abap developers to modernize abap for the cloud. the abap community should articulate what their priorities are and help to shape the future development. please describe where abap hinders innovation. the ui is not part of the abap world any more and completely in html and javascript (till we get something better).
        what do you mean by integrated code? in s/4hana public cloud all extension have to ‘no touch’ via scp.
        imo scp offers all or most modern code management and deployment options of the cloud world.
        many of the abap improvements will show up first in the cloud, only there sap can make more radical and incompatible changes because of the separation of standard code and extensions.
        all customers i talk to want to reduce modifications at all cost. the new data model (no aggregates or totals) helps tremendously to simplify analytics. using hana and full sql (instead of abap sql) reduces coding often by more than 50%. the customer developments have to follow and a reorganization or recoding of their extensions in order to take advantage of the new world is a logical consequence.
        the transition to s/4hana and c/4hana is progressing much faster than what the people in this forum have obviously experienced.

        -hasso

        1. says:

          Hello,

          My view may be slightly outside of the rest of my peers, but I thought it worth restating here.

          The area in which I predominantly work these days is providing extensions to SAP SuccessFactors customers that tightly integrate into their HCM solution but provide for a little something more than the standard solution offers. I use SAP Cloud Platform (Neo) to deliver this. The way that SAP has enabled this is a huge competitive advantage over other HCM SaaS vendors.

          I can use a “modern” CI/CD approach without problem. And that SAP doesn’t do this to the core product I am enhancing facilitates this. I wrote about this years ago… https://www.wombling.com/cloud/continuous-integration-vs-phased-deployment-in-a-saas-world/

          1. says:

            (Sorry, slightly trigger happy on the post button, Continued…)

            The approach of stable core, innovation/extension outside works really, really well for me. I would love to see more customers adopt this in the S/4HANA space, by going public cloud and extending outside.

            The issue comes with helping people on that journey. I’ve publicly stated that I thought ABAP on SAP CP was a mistake. https://www.wombling.com/cloud/on-abap-in-the-cloud/ but I fully understand that there are many nuanced reasons why it had to happen. Not least is that this is a key part to getting existing on-prem customers to move towards a SaaS enhanced by PaaS model.

            What I think we need to consider as part of that process of moving and educating people on how to move to that model is how we can make their existing on prem experience as much like the experience they will have when they move to public cloud SaaS version of S/4HANA.

            This means making tooling like ABAPgit part of the standard code migration process, and allowing for smarter ways to handle conflicts of metadata driven configuration that has lovely UI for building in SAP, but then is reduced to trying to parse XML if it something changes/conflicts.

            Having spent many years coding in ABAP it was always good to get SAP based, real world examples of good practice… Unfortunately where the frameworks were built by geniuses, often the implementation was substandard. Having some good real code to reference that uses ABAP unit testing and could even link out to external testing/regression tools is vital.

            To recap, we need to introduce CI/CD tooling into the people that currently don’t and won’t use it, so they can have an opportunity to reset their mindset to embrace it. Once we have that shift, we may get them to make the perhaps bigger shift to SaaS and PaaS.

            Cheers,
            Chris

        2. says:

          Hi h.p.
          For me the key issue is centralized development model and central locking. This makes applying a hotfix to production harder that it needs to be. Yes I am still working on on-prem systems with STMS as the deployment tool.

          UI5 working outside of that model two (or more) developers can use git source repository tools to branch the code, work on features independently and merge later using unit tests to confirm viability. UI5 itself does this. It is a massive advantage.

          ABAPgit brings that advantage to the ABAP codebase and I would hope that SAP is able to put some resources behind making ABAPgit a core part of ABAP on SAPCP.

          Thank you for your attention.

          Kind regards,
          Nigel James

        3. Graham Robinson says:

          Thanks Hasso for firing up this discussion.

          I think most of us have a common understanding about where we are heading. The problem is that many customers, partners and practitioners are having trouble seeing how they get there and where, or even if, they belong.

          To your point about the ABAP community articulating their priorities and helping to shape the future I can assure you that is happening. This post from Dennis was – in part – triggered by one of those discussions.

          I find that sometimes SAP is a little hard of hearing – and that can frustrate us. I am sure you understand. 😉

          -Graham Robbo

          1. says:

            @graham – one of the problems that large co’s like SAP face is that the ground level grumps almost never get heard at the top table unless a Big Name customer (or three) yells at the board.

            The SUGs sure as heck don’t bring those issues to them.

            That’s a motivating reason for my pushing this out with the backing of so many Mentors and with the hope of getting Hasso’s attention.

            He says – and I get this from others near or close to the top (i’ve had it on email today) – that they’re not seeing this kind of problem. I totally believe that.

            It throws a massive spanner in the works because as we know, the snowflake syndrome needs a (not inconsiderable) mind shift at a time when SAP is running fast down a different path.

            I say give them kudos for at least hearing the issue but suggest you all follow through on your own terms but with the help of your colleagues in the community. It does work though rarely at the speed you/I might wish.

        4. Fred Verheul says:

          Thanks for the invitation to articulate how we’d like to see the ABAP platform evolve. I won’t repeat here what Nigel and Chris already outlined below. For a more comprehensive overview please read Ethan Jewett’s pieces at http://www.esjewett.com/blog/abap-development-the-dream-and-the-reality and https://searchsap.techtarget.com/tip/SAP-needs-to-bring-ABAP-development-into-the-modern-era followed by https://searchsap.techtarget.com/tip/Implementing-modern-practices-in-an-ABAP-development-shop (where SAPLink should now be replaced by abapGit naturally).
          So IMO the community, or at least a vocal minority in the community, knows what it wants, it’s more that SAP still hasn’t delivered. ABAP on SCP presents a once-in-a-lifetime opportunity to do just that, and as Chris states below, to help a whole army of ABAP developers to bridge the gap to modern development practices while continuing to use the one language they love.

          Thanks in advance, Fred

        5. ABAPisnotforKids says:

          Great topic Den Howlett and love how you’ve handled the topic in a very balanced way.

          I do have to agree with Hasso’s perspective => “the abap community should articulate what their priorities are and help to shape the future development. please describe where abap hinders innovation”

          There are statements about ABAP expressed by some(which you’ve summarized in your blog) but it needs to be articulated why those things are pain points, otherwise those are just sentiments or opinions and not true pain points or roadblocks. Below are my counter-opinions:

          1.ABAP has legacy tools => So what? The tools work brilliantly for a person doing ABAP development. The exception being the UI/UX tools(dynpro) in ABAP which as Hasso has said are not that relevant anymore in S/4 because UI is now mostly built using HTML/Javascript.

          2.ABAP has legacy culture => This is the same culture that has helped 75% of Fortune 500 companies run their back-office Finance/HR/Logistics systems in a stable way for decades while being able to handle reorgs/acquisitions/mergers/constant legal changes. It’s not a replace the whole system every 3 years culture that pervades other “cool today but gone tomorrow” languages. Its a “solid as a rock” culture!

          3.It is stuck there and will never ever move => If someone checks out just a few of the release notes for ABAP, they will know this is not true.
          https://blogs.sap.com/2013/07/22/abap-news-for-release-740/
          https://blogs.sap.com/2015/11/27/abap-language-news-for-release-750/
          https://help.sap.com/viewer/53a5091ea9e945839b860232b7796747/1709.001/en-US/62a8a348e36d4b398e6bb21f15de4a7c.html

          4.ABAPGit is the best thing that happened to the ABAP ecosystem since ABAPUnit
          Adoption of both of these toolsets are woefully low => Perhaps this is because the tools already available in the ABAP Server are adequate or in some cases more suited for the mission-critical applications ABAP is used to build? Perhaps because multiple developers working on the same object is not the typical scenario in most SAP shops?

          1. Good points raised here. Salesforce.com end customer business analysts rarely share much. More the underlying Force.com app platform devs who share as Android or iOS devs do. Both communities can use the same SFDC platform to test apps, force.com requires or notifies in order to update the platform 3x per yr as ToS.

            Looked at another way. Should SAP not have already moved devs up to app composition away from database integration and last era software licensing to where indirect access to data meets customers and suppliers.

            Alas, Hasso’s thinks differently “the ui is not part of the abap world any more and completely in html and javascript (till we get something better).

            Apparently Salesforce thinks completely the opposite.

            Interesting to review in 10 years time who was right. XaaS or abap.

          2. ABAPisnotforKids says:

            Some more interesting counter-points for anyone under the impression that ABAP is stuck and not moving. ABAP server as a Docker container along with SAP Cloud connector.

            https://blogs.sap.com/2018/05/10/abap-is-here-and-it-stays-in-the-dna-of-sap-even-in-the-new-age-of-sap-development/

          3. Geppart Alexander says:

            ABAP on premise is for sure a special snowflake.

            More specifically its infrastructure is.

            Compared to other languages used for enterprise solutions
            its legacy tools, legacy culture and infrastructure for software delivery
            are not evolving fast enough.
            I am not talking about the language itself.

            Developers, from my point of view, are facing innovation not only in the cloud and on modern frontends. There is and always will be a need to integrate innovative approaches with on premise systems.

            And this is the problem.
            ABAP developers are not able to keep up with the speed of frontend and cloud guys.

            Even if multiple ABAP developers would work on the same object (for a feature and an issue fix), they also would have to invest a lot of time to solve the problem of dependencies and the lack of branches on different organizational levels.

            This costs time and money and that is why ABAP infrastructure
            is not competitive any more to other development infrastructures outside of the legacy ABAP world.

            So from my point of view the ABAP on-premise backend is currently the bottleneck of innovations.
            ABAPGit is for sure a step in the right direction.
            But it needs a lot of SAP attention and support to renew the outdated ABAP infrastructure.

    3. Ian Daniel says:

      Great post and comments, my two cents is SAP now make it easier than ever to expose SAP via services, with a license model to support it.
      This is entirely a culture thing, and getting crossover and collaboration between the two streams in the bimodal model will be key to true innovation.

    4. Nishant Gopinath says:

      This is a very relevant article and accurately represents the perception of SAP ecosystem! It’s clear that open environments are the future and SAP has to do more in rallying the ecosystem behind this transformation to succeed. I also find Hasso’s defense quite interesting as it throws light into a mindset and differences in perspectives.

    5. The transition to s/4hana and c/4hana by accelerating a modernization of abap into the cloud is misaligned towards 2020-2030 era. Because moden integration should allow customers to be “deployment agnostic” by building compositions of data with UI and AI, not customizations of logic and database.

      SAP has done the hard part by solving “no aggregates or totals” (Salesforce did so earlier in Force.com CRM platform).

      Stopping exfiltration of customers confidential data seen in Facebook apps is the hardest part. Composing robust resilient applications with blockchain technologies offers methods to solve ecosystem insecurity as we rebuild to be “deployment agnostic”.

      1. says:

        SAP has its own flavor of blockchain with the joint developed (IBM) Hyperledger. But when you find there are only 2 current SAP job openings for Hyperledger and…some of its most well-known customers don’t know it exists then you also know it’s one of those ‘half pregnant’ situations.

        1. greg misiorek says:

          well, 100% more job offers than that last time i checked and covering such locations as Singapore and Australia and if anything, SAP has a very long history of dealing with IBM, competition included.
          i’m impressed how SAP were able nimble to develop their Fabric service, without publicly participating in the linux foundation project, something that Microsoft have not chosen to do or support, even though obviously interested in expanding their Azure platform.

    6. Colin says:

      Gr8 discussion on the technical side, but customers are also asking about the commercial implications. ABAP developments in the core have no direct licensing impact, but doing extensions on SCP does have. Any thoughts / pointers on handling this objection from customers eg., data on overall lifecycle costs?

      1. says:

        Colin,

        The only thoughts on the topic today are “be prepared to negotiate with SAP”. Unfortunately, because of SAP’s market power over all of their clients (aka Monopoly) these are typically not fair nor are they fun negotiations.

        Thanks for raising the issue though. Technologists often forget that they only get to play if the commercial implications are sorted out…which in the case of Indirect Access are far from being sorted out.

        Sam

    7. Sascha Junkert says:

      Very interesting discussion! Unfortunately I noticed it only last week, but still want to add some information.

      Since last year in July several sap customers joined forces (including SAP mentor Markus Theilen) and are discussing DevOps methods / practices in ABAP landscapes in a dedicated DSAG (german speaking sap user group) working group. At the beginning it was mostly a self-help group to discuss the issues and pains, but also the success of the specific companies in several areas. Over time the group got bigger and now includes SAP employees and ababGit contributors as well.

      We created an overview for the DSAG Tech Days in February 2018, which you can find here: https://t.co/sxfAKNnRRh.

      At the moment we are discussing how to spread our insights in more detail. A SAP Community post will probably follow soon!

      The next meetups are planned for August (knowledge exchange with SAP IT) and September (ababGit), stay tuned.

      Cheers,
      Sascha