Skip to Content

Dude, Where’s my API?

Yesterday I had a conversation with Jon Reed and Ethan Jewett about how SAP are tracking in regard to developer relations. You can catch it on Youtube, iTunes or download the audio here.

One of the topics discussed was the lack of open and usable SAP API’s.

There are no shortages of SAP Platforms. Depending on your definition of “platform” they might include the HANA Cloud Platform, the SAP Real-Time Data Platform, SAP NetWeaver, SAP Jam, the SAP Mobile Platform and something called HANA. SAP is positioning itself as a “Platform Provider”. Integral to the success of a platform is the need for developers to build applications that leverage them. I mean what would happen if you built it and nobody came?

The community of traditional SAP developers cannot provide the ideas, innovation and applications at the scale that SAP are looking for. So they need to attract large numbers of a completely new type of developer. The rebranding and repurposing of SAP TechEd to SAP d-code is a very visible example of this effort to reach out to new developers.


But developers are a difficult bunch. They are antisocial, late night pizza eating, coke drinking, role playing game addicted trekkies with questionable personal hygiene regimes. No that’s not right – according to Big Bang Theory that’s physicists. Glad I’m not one of those geeks! 😏

Let’s just agree developers are a difficult bunch to reach. It’s generally understood that most developers like – in no particular order – recognition, recognition and recognition. And the way a developer gets recognition is to build cool stuff – and developers need existing platforms to build stuff on because other developers have already been recognised by building platforms. If a developer is going to build something cool and get recognition they need to do it quickly before some other developer gets the same idea and beats them to it.

This is where API’s become important.

An old story that many have heard before. Way back in the 1980’s I decided to learn 8088 assembler – or maybe it was 8086 I forget. So I bought a book, fired up my IBM-compatible PC running MS-DOS and went to work on the first example, which involved writing something to the video display. It started pretty easily – you just had to write the character you wanted displayed into the appropriate memory location and the graphics adapter would do the rest of the work and make it appear on the screen. But there was a problem. If my program happened to be writing into the graphics memory at the same time as the video driver was reading from it the result was screen flicker – more like screen flashes really. The solution to this problem was to ensure that I only wrote to this area when the electron beam of the CRT was switched off – and that only happened during a screen retrace when the beam is repositioned from the bottom right of the screen to the top left to begin a new pass. So I had to put a character into the graphics memory each time a screen retrace commenced, then wait until the next screen retrace to put in the next character, and so forth. A great lesson on assembler but boy would I have killed for a graphics library to handle this problem for me.

Fast forward to 2014 and every piece of software around has to interact with others – probably many others. So we start at the bottom of the stack and build a layer of abstraction (maybe a 8088 graphics library) that encapsulates a discrete set of functionality. This layer provides a standard interface to all who want to consume it and hides the deep dark plumbing complexities from those consumers. As we work our way up the stack these abstraction layers sit across more and more complexity exposed through appropriately simple interfaces. Today I can get a list of customers from the Northwind database simply by sending a HTTP GET request to the URL and I have no issues with screen flicker. I have forgotten everything I ever knew about assembler.

SAP are reaching out to developers to encourage them to use their platform(s). A great example is the SAP HANA Startup Program that has recruited over 1100 organisations with great ideas. They are using the SAP HANA platform to develop these ideas upon. But the attraction for them is primarily the reach the SAP ecosystem gives them to market their product once it is built. My impression is that very few of these organisations have been attracted by the unique features of SAP HANA. Rather they decided SAP will be a good organisation to partner with once their application is built. Hopefully as they start to better understand the capabilities of SAP HANA it will trigger in them new ideas that will really leverage the power of this platform.

Similarly I think most other developers will be attracted to work with SAP not so much because of the new technologies such as HANA or HCP, but more because of the large installed base of SAP customers that they hope will buy their solutions. If a developer has a great idea that is relevant to enterprise users it makes perfect sense to target SAP customers due to the potential size of the market. So in this respect the SAP platform they are interested in working with is the business execution engine that is SAP Business Suite – or even more specifically SAP ECC. ECC is the SAP Platform.

And this is where, in my opinion, SAP has dropped the ball. Where are the open useable API’s? Where are the simple interfaces that abstract the complexities and minutiae of the actual business transactions? All SAP ever seem to provide is technology to build API’s but not the API’s themselves. The SAP Business Connector, ICF, XI, PI, SOAP handlers, NW Gateway, etc. have not delivered the API’s required. They are merely toolsets that can be used to build API’s. (Sorry BAPI’s just don’t cut it – see the Northwind example above.)

All that business execution knowledge, deep industry insight, 30+ years of experience baked into the SAP Business Suite is difficult for an experienced SAP developer to leverage – and impossible for a non-SAP developer to do on their own.This makes it very hard for developers to quickly build something and get that recognition we are told they crave so much.

SAP have indicated they are re-platforming their applications starting with Business ByDesign. Given that the core of this new applications platform will be SAP HANA we can expect the business API’s I am talking about will also be delivered. After all SAP HANA in itself does not have any user interface capabilities and therefore exposes all functionality as light-weight services available to any and all technologies. But this transition will take considerable time and meanwhile the entire SAP customer base will be still running on platforms like the Web Application Server ABAP.

Developers don’t have the time or inclination to wait for their recognition. They want to be building stuff now and they need the appropriate API’s to leverage the SAP business process engine now. Unless and until SAP can provide them I fear attempts to recruit developers to the SAP ecosystem will remain underwhelming at best.

You must be Logged on to comment or reply to a post.
  • Good points Graham. I didn't listen to the recorded discussion you have here, so pardon me if am repeating what you all may have already discussed. My take is this, if SAP exposed the business functions as easily usable APIs, is there anything to stop the developers from using other platforms than SAP's. Why would I not build a CRM UI on SFDC or Google App Engine or any other platform than to wrestle around the WebUI framework, which wasn't even supported in modern browsers for the longest time. Well, indirect access restrictions can only be taken so far. Maybe, that is what is preventing SAP from exposing the APIs. Regarding attracting developers(not the gray haired ABAPers like me but the younger ones) , SAP platform needs to simplify further. Simply put, I don't want SAP to give me 50 different tools and platforms, just give me one and give me the one that works well and keep building on it. If BSP was THE UI framework, SAP developers would have jumped in to HTML5/JavaScript/CSS3 bandwagon much earlier. WebDynpro only took us for a detour and more importantly restricted the developers, boxing then within a proprietary framework. I agree, hindsight is 20/20, but I believe the path forward is to consolidate all these different applications, frameworks in to one platform! HANA->XSEngine->OData (REST APIs)->UI frameworks(including UI5). Am I oversimplifying?, yes. But simplifying the platform is a must now as SAP is moving from a packaged software company to a platform company. 

    • Thanks for your comments Kris. I would encourage you to listen to the entire discussion if you have the time because we covered considerably more than the API issue.

      I agree with you that the pretty obvious way forward is the simplification that is enabled by the SAP HANA platform. But this does not address current needs of the majority of the SAP customer base who are running on a good old ABAP application server - even those early adopters who are running business suite on HANA.

      While SAP may deliver what I am asking for in new applications that are written for the HANA platform I wonder if the market will have the patience to wait for them? Developers are not known for their patience and SAP are trying to grab their attention right now.

      Your suggestion that SAP may have felt there was some benefit to keeping the existing business functionality locked up inside their proprietary platform is certainly possible. I am sure that if such a discussion was held there would have been people arguing against the short-sightedness of such a strategy. Those people would now be able to say "I told you so" - probably much earlier than they expected.


      Graham Robbo

  • Hi Graham

    I thought the Google+ recording is very good, I have listened twice now, will probably listen again as it covers a lot of ground, not that it covered eveything, there was probably more you could have covered which you didnt for time constraints. Collectively you do a good job of highlighting the current state of SAP developer engagement, I highly recommend others to listen.

    My takeaway is a lot of the initiatives are taking a long time, in a few areas too long and this means SAP may have missed the boat.

    wrt to the API's, lowering the barrier for entry by providing tooling and familar techniques is one thing, but to quote Branson "Complexity is your enemy .. It is hard to keep things simple." The Gateway Productivity Accelerators GWPA for example do not reduce the complexity, the ones i have seen and used i would say 1 steps forward, 2 steps back. Now I have created the simplest of applications / API, where do i go next?

    As you point out you need to start with content and data. The business suite functionality needs to be available for developers as self describing, easy to find and consume API's, there needs to be examples and dynamic test tools available and THIS ALL NEEDS TO BE EASILY ACCESSED by the masses.

    To put it in business terms there is very limited IOT or Mobility opportunities for external developers without this.

    MyPOV when it comes to developer engagement - culture eats marketing for breakfast, like others i am sceptical of the DCode change.



    • Thanks for your comments John. Kicking myself for not using "culture eats marketing for breakfast" in the blog. 😳

      p.s. Yes - there was plenty more we could have covered.

  • I listened to the whole video and while I am not a developer I learned a great deal.

    Regarding SAP Store - I thought this was mentioned in the video - as a buyer/consumer, why can't I buy certain apps from this store?  I don't want the "Contact me" button - quite honestly I will *never click* that.  Why can't it be like iTunes where I actually can buy something?  Wouldn't that be more attractive to outside developers if potential buyers (like me) can easily buy their apps?

    • HI Tammy,

      Thanks for your comments.

      Certainly SAP have had mixed success with the various attempts at an online store.

      For me the big roadblock to a one-click shopping experience in the SAP world is deployment. In the app stores we know and love, Apple being the obvious one, you can click a single button for both purchasing the app and deploying it. That is all but impossible in the SAP world because even the simplest apps require something to be deployed to the backend system. This never has - and probably never will be - an option for a ERP system.

      Now, of course, if the ERP system came with a full set of open and useable API's.......


  • Hi Graham,

    Thanks for the blog and thanks also to Jon Reed and Ethan Jewett for the Google+ discussion.

    My perspective ... sadly, the older SAP's on-premise architecture gets, the harder it is to achieve the end-state of simple and useable APIs that we wish for.  These days you might find a NetWeaver Gateway service that calls a BAPI that underneath calls a BDC.  How does that architecture lend well to being able to offer a simple API.  Overlay on top of that the fact that many customers have spent years hacking their systems by adding their own customisations (Dennis' quote that 'Customisations are Industrial heroin' rings in my ears) makes it very difficult for SAP to achieve these useable APIs.  And then lets add the engineering effort for SAP to build out and to offer these APIs ... that will cost much time and money for SAP to achieve.  Perhaps that is why SAP sees a need to charge for Fiori.




    • Thanks Graham and Ethan. I was going to chime in on the API point but John made the kinds of points I was thinking of. I thought SAP tried to release all these soap end points that were the be all and end all of api's but alas that is not the case. Even with gateway an api just becomes a facade on a crumbling building.

        • Yes, APIs can hide complexity.  But sometimes we want to know there is good architecture underneath.  Otherwise SAP could simply use the screen-scrapping approach to enabling Gateway services and have a number of APIs enabled instantly.

          • /
          • Yeah, fair point.  I guess the challenge for SAP is that it isn't so easy as using the screen scraping approach to create simple and robust APIs in NetWeaver Gateway.  Which is why there is plenty of re-architecting going on under the covers right now to support the Fiori apps.

  • Hi Graham,

    Good blog post and I also enjoyed listening to the Google+ discussion.

    Reading the last paragraph I'm a little bit confused though. It looks like you're saying: "Hey SAP, give us the business level APIs for ERP etc, and do it quickly, or you'll never attract us outside developers". But do you seriously expect SAP (even if they shared your POV that an simple open API of the BS functionality should become available on the 'old' platform) to deliver that API in a good enough timeframe?

    Let's face it: these APIs are never going to be available for the current Business Suite. So our only chance to attract outside developers is for the new platform to expose them. And since the new platform doesn't have a UI layer built in, we actually might stand a chance here IF SAP is indeed planning to rebuild BS stuff natively on HANA (as opposed to the Business Suite on HANA road, where we'll stay stuck with NW app server ABAP including Gateway etc).

    So, yep, outside developers won't come flocking to SAP anytime soon because of open APIs. But IMO that's not the only thing that should attract them: the platform itself should attract them to build great stuff, just like the startups are doing already.

    So, thinking like an outside developer for a moment: "I don't care that much about the APIs, as long as I can build apps on top of the platform. Now I only need a great idea to build an app...".

    Sorry for the long comment, I'm hashing out my thoughts while typing 🙂 .

    Cheers, Fred

      • Because there is not really a business level API available, unless you count BAPIs. That was as far as I understood one of the points made in the Hangout, and a good one. Or am I misunderstanding you (very real possibility)?

        • At TechEd last year I heard a couple of times that the Gateway services used by Fiori applications (wave1 -> wave(n)) could be used by customers to build their own non UI5 applications.

          This is just one of many existing application scenarios whose Gateway services should be made available.

          I would make a guess that there are 100's of Gateway services that could be made visible and publicly available right now. The advantage being the heavy lifting has been done already, those services are optimized, meeting internal metrics, they have been thoroughly tested, documented, QA'd etc. And if they dont work for your scenario you can search for others which might or use one that is close to your requirement as a template.


    • Hi Fred,

      thanks for your comments.

      I don't think I am expecting SAP to provide the Business Suite API's - but I guess I am putting forward a view that SAP can't expect to attract lots of outside developers without them.

      If something like the HANA Cloud Platform provided a compelling case to choose it over the many other PaaS offerings out there then maybe that would change things - but my perspective is that HCP is yet to make the case that it has significant advantages over others.

      So when I think like an outside developer (and let's face it I am not one so I am just guessing) I don't care about the platform unless it provides me with something I can't live without.

      And who's to say these developers won't want to use their own platform, or no platform at all, to run their applications. Maybe they will just be downloadable apps that call light-weight services to consume corporate data and execute business processes?


      Graham Robbo

      • OK, expecting was too strong maybe. I get your point, and you might be right. And of course, I'm guessing too 🙂 .

        One of the strongest arguments in favor of saphcp would be easy access to the SAP install base, even if you're not consuming Business Suite data in your app.

        But maybe I've already exposed myself too much as a backend developer. For me, an innovative app (which I'd hope an outside developer can provide) has to do something real and significant. Not just tying together a few BS data points and execute a business process that could as well be executed within in the BS itself (since that's where the data is anyway). I think that can be handled by the current ecosystem, even if it requires a mobile-enabled UI.

        And maybe you're right and these downloadable apps etc are (part of) the future.

        I'll stop guessing. Thanks for making me think.

        Cheers, Fred

  • Great conversation and happy to finally have found Jon's Podcast feed again. 🙂

    Wanted to chime in on the "Free Fiori" topic - I have thought about this a fair while and have come to the conclusion that it really doesn't matter, don't get me wrong I have always felt it should be "free" but I feel now like the major cost to implement a Fiori app isn't in the license cost. Here is why I think this:

    • To start with most SAP customers won't be paying list price for Fiori (shock-horror SAP do deals with their customers 😯 ) so if you have negotiated your license well (or it's the end of the quarter) I would bet that you are going to get a fairly hefty discount on the license.
    • Secondly the majority of the cost will be found in the implementation (dare I say customization) of the apps and the ongoing support. I'd argue the license cost is less than 10% of the overall cost (maybe less)
    • Finally I think Fiori is probably used in a lot of deals as sweeteners (like a set of steak knives) - I'd argue that very few customers are going out to buy Fiori on it's own, many will get it thrown in to get the deal signed anyway. So having it priced gives the AEs something of value that they can give away for free.

    The most important thing in my mind is getting people using it, making the business users aware of it so they want to have it - whether it is free or not isn't going to accelerate adoption too much I'd say.

    That's my $0.02 anyway... now back to listening.

    Thanks for taking the time to share this.