As many of you know, last week SAP delivered some new announcements around HANA and mobility. 

From a mobility perspective, one of the major announcements (the other being the intended acquisition of Syclo) centred on new partnerships with mobile framework providers Adobe (for PhoneGap), Sencha and Appcelerator. If you haven’t seen the press conference, you can find a recording on YouTube here (kudos to SAP for making it available in high definition – watching it on my home TV made me feel like I was virtually there).

Developer Ecosystems

It was refreshing to see SAP recognize the need to capture the interest of mobile developers.  Lets be clear, there is a real need to do this because mobile developers out there have a multitude of choice when it comes to mobile ecosystems to develop for.  By embracing open mobile frameworks such as Adobe PhoneGap, Sencha and Appcelerator, battle lines are being drawn to capture the hearts and minds of millions of mobile developers to develop for the SAP ecosystem.  Of course, I was thrilled by this news, especially as I am a fan of PhoneGap in particular (as those who have read my blog about it a year ago can attest).  One point of interest to me was the absence of any mention of the jQueryMobile open source mobile framework, which was already embedded into the SUP hybrid web container last year and announced with less fan fair by Sybase.

In the developer ecosystem there certainly still are challenges, including some highlighted in the Q&A towards the end of the press release, dealing with such matters as developer licensing, access to software for developers, and ability to easily publish and monetize apps in app stores.  There is no need to discuss these issues in depth for this blog, as many others have done so already … SAP Mentor Vijay Vijayasankar writes a good blog on the challenges for developers here, as does Dennis Howlett here.

The Plumbing Problem

Interestingly, developer community challenges aside, I can’t help but draw parallels to the situation SAP was in over a decade ago with the Java community.  I recall back then a strategy to leverage the worldwide Java community (which outnumbered their ABAP counterparts by a significant magnitude) and use this community to drive the user interface layer for SAP. Sound familiar?  Things didn’t quite eventuate to the intended vision of those times.  Many of the reasons why Java didn’t take root as strongly as hoped have no relationship to our current times – for instance, SAP’s focus on a proprietary UI framework in WebDynpro Java had the effect of immediately turning away a proportion of Java purists (right now SAP is looking to embrace open mobile frameworks, so the situation is much better).  But there was another reason why Java adoption didn’t take root so quickly with SAP enterprise customers … simply because it took time (in some cases years) to convince customers to purchase and adopt an SAP Java platform (eg. SAP Portal) which was a pre-requisite for coding in the preferred SAP UI framework of that era, being WebDynpro Java. 

This is where I roll the clock to today, and think about the parallels.  Using SAP’s mobile architecture, a common pattern for online apps is to utilise the SAP mobile platform in combination with SAP NetWeaver Gateway.  With this pattern the SAP mobile platform provides services such as device registration and connectivity, whilst SAP NetWeaver Gateway exposes the core business logic and data from the business suite necessary to service the mobile application.  The simplified diagram below illustrates this architecture (this is not the only possible architecture, but it is a common one when looking at SAP’s own online mobile apps) …


Note: ‘SAP Mobile Platform’ includes Sybase Unwired Platform, Sybase 365 … (and possibly others?)

This presents potentially two platforms which customers need to embrace before they might mobile enable their business suite functions. 

In my mind the SAP mobile platform challenge is mitigated when it is offered as a PaaS as I described in an earlier blog.  And as an aside, the constant evolution of this mobile platform reaffirms my belief that the mobile platform should be in the cloud so customers need not concern themselves with rapid evolutionary changes (ie. upgrades) to an on-premise version of this mobile platform.

But this does not solve the conundrum with SAP NetWeaver Gateway which typically needs to be on-premise.  SAP NetWeaver Gateway provides a bridge for mobile apps to interact with SAP data and resources using oData REST services.  And make no mistake, this is the software product that is doing much of the heavy lifting with SAP’s most recent mobile apps – just look at the table in my blog from January this year.  For a large scale SAP mobile ecosystem to succeed, I see SAP NetWeaver Gateway as a critical component because it provides a consistent approach across all customers to achieve lightweight REST-like integration into on-premise SAP systems. 

Importantly, you might have noticed in the press release about embracing the open source platforms that Sencha (for instance) had “newly delivered support for the oData protocol”.  Read that as meaning “you can integrate your Sencha app to your SAP systems as long as you have SAP NetWeaver Gateway”.

So therein lies the challenge. Now that SAP is in the process of enabling hundreds of thousands or even millions of potential developers to develop for the “170,000 customers of SAP” (as quoted from the press conference), we have to ask an important question.  How many of these SAP customers have access to a SAP mobile platform?  How many of these SAP customers will have SAP NetWeaver Gateway installed in the near-term?  How can SAP entice customers to license SAP NetWeaver Gateway and implement it in their environments quickly?  For sure, the adoption rates will need to be fast.  Otherwise our millions of newly embraced long haired developers may find themselves with no SAP customers to connect to.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Mark Teichmann

    I wonder why you stress the connection through SAP NetWeaver Gateway (GW) so much. Although it  is a nice option to connect your mobile apps to SAP using GW there are some obstacles with it:

    • GW is only one  option you have in order to connect SAP to SUP
    • Currently you can ONLY use GW for Online apps and not for synching Mobile Business Objects (MBO)

    Therefore for many use cases you are well done using the JCo connection to SAP which also supports the synch process for MBOs.

    On the other side it is a nice thing to connect all SAP systems through Gateway to the outer space and SUP will support this scenario sooner or later, eventually even for JSON and not only for oData.

    In this case I would be really happy if you could get Gateway as a free AddOn to all SAP servers which would be included in the existing license of the ERP systems.

    1. John Moy Post author

      “I wonder why you stress the connection through SAP NetWeaver Gateway”

      … good question.  I think it is for two reasons.  Firstly, mobile developers from the worlds of Sencha etc. are used to interacting with central systems using ‘simple’ RESTful services.  I don’t believe that these people will be expected to learn a new proprietary technology in SUP, along with the concepts of modelling MBOs and sync processes (otherwise that defeats the purpose, because SAP will be imposing a proprietary skillset, much like WebDynpro Java which I described in my blog).  Secondly, most of SAP’s recently published apps utilise SAP NetWeaver Gateway.  The oData feeds pass straight through SUP (so apart from providing onboarding and device registration services, in these scenarios SUP acts much more like a simple reverse proxy).  In these scenarios the app designer might design some ‘limited’ caching on the app itself to support some basic offline capability.  Of course for complex offline capable scenarios (eg. field services) requiring MBO sync etc, my argument doesn’t hold up.  But really these scenarios in my mind are less common and will probably coalesce around specialist app developers such as Syclo.

      But really, that is just my opinion.

      Thanks for your comments.


  2. Frank Koehntopp

    Great blog (as usual), John!

    Right now I see this as SAP trying to cater for every customer need, which most certainly needs to be developed into a consistent decision tree for customers.

    The one constant I see is Netweaver Gateway, which needs the right kind of licensing to be able to succeed. If done well it can act as _the_ central hub for mobile solutions.

    The “fight” – or “choice” – right now is between the SUP world with all implicit features (user & device management, secure storage etc.) and “other apps” directly working with exposed gateway services which will find a way to work nice with a company’s user management and security procedures (authentication, authorisation, device management).

    If you thing 5 years into the future, all those different apps will need to be managed and administrated by customers. I still don’t see a common standardized way to do that.


    1. John Moy Post author

      Thanks for your comments Frank.

      “The one constant I see is Netweaver Gateway, which needs the right kind of licensing to be able to succeed.” … I completely agree!!  To me this is a critical enabler for mobile ecosystem success, but I don’t recall it being mentioned much (if at all) during the press conference.  Yes, some people know how to custom build REST services through the ICF without using Gateway, but the problem is that approach doesn’t SCALE across the SAP customer ecosystem.  So any app developer relying on this approach has an opportunity of 1:1 rather than 1:n.  Of course, if not many customers take on NetWeaver Gateway due to such things as licensing costs, then we also end up with the same problem.


  3. Jason Scott

    Thanks for another interesting and thought provoking blog John. Some of my thoughts follow:

    How to get customers to use sapnwgw? Easy. Make it a free ABAP add-on! I simply cannot see the economic benefit nor how it “really” helps developers, when you can quite easily (with little developer effort) use the ICF (and for better productivity use the ADL framework and JSON provider available on Code Exchange) to expose the same data from the backend system.

    Gateway is just an enabler to access your sap backend data; no different to using web services, rfc’s, file downloads, etc. In my opinion, it’s a short-sighted money-grab by SAP which seems to be the way they do business these days… (yep – no point holding back here).

    Look at AIF (for interface monitoring) as another example. 

    It’s also a shame that it seems you must use sapnwgw to gain mobile app certification.

    They need to get developers and customers back on-side and take a long term view.

    A PaaS offering would certainly be a step in the right direction if for nothing more than reducing the sheer number of servers required. But without the right pricing it won’t work either… Perhaps a freemium model that is common with other players in the mobile field would be the way to go… Allowing developers easy, free access to the product suite with pricing ramping up based on volume for example.

    SAP’s recent announcements of partnerships with phonengap, Sencha and Appcelerator are also interesting.

    The phonegap deal doesn’t sound like much at all though when you read the fine print. It seems that it just “assists” developers in porting phonegap projects across to the SAP Mobile Hybrid Web Container (HWC). It’s not just a matter of copying the code assets across either; developers need to re-write the data later for SAP Mobile MBO’s. So what are we getting here… Very little! I assume there is more to come and that SAP and Adobe will be working on something great. Fingers crossed on that.

    Sencha and Appcelerator. From what I can tell they have jointly worked with SAP to offer an OData adapter of some sorts. Developers in the Sencha and Appcelerator communities are probably scratching their heads and wondering what OData is (outside of the Microsoft community it’s not widely known). I think SAP need to enable JSON with gateway. In fact better still… abstract it with plugins to handle any format.

    I agree with your point John, that “allot” of SAP customers will need to be using sapnwgw for these partnerships to bear any fruit. In fact I’d go as far as saying “most” customers will need sapnwgw for mobile developers to even think of writing code (I’m referring to the non-sap, heavily open-sourced type developers of course). Back to the first paragraph: make it a free ABAP add-on.

    What about sapui5? I understand that SAP are working on the mobile version of this right now… How does that fit in given the announced partnerships discussed above? Interesting. Covering all options maybe.

    Please SAP… I want to see you succeed in the mobile arena; so listen up to the developer community. I guess this could’ve been written as a blog – but it probably would have been moderated out.   😉

    Regards… Jason (a developer trying to advise clients on mobile stuff).

    1. John Moy Post author

      Hi Jason,

      Great thoughts you have added here.  And I must tend to agree that licensing is a concern.  It seems there is a license toll at so many points in the architecture that the rapid construction of a vibrant mobile ecosystem will be far from frictionless. 

      One thing customers need from SAP is certainty around the licensing models for interacting with non-licensed users.  This is especially relevant as customers begin to tether their SAP systems to consumer mobile apps (providing such data as fulfilment information).  I am no licensing expert, but this has always been a grey area to me.  And unfortunately ADL might solve the technical challenge of exposing services (without gateway) but it doesn’t in my mind resolve the licensing issue.

      I disagree that your post would have been moderated out.  You have good rationale arguments to share and I would encourage you to post them as blogs in future.


  4. Simon Kemp

    Hi John,

    Firstly thank your for taking the time to share your views on this. I agree with practically everything your saying here and would also like to thank Jason for his comments, many of which I fully support too. To my way of thinking all this needs to become much more simple for both the developer and the customer. Back at the end of last year I asked SAP “… So your really expect customers to pay 3 times for an application?… First for the app itself then for the mobile platform (SUP at that time) and then of the gateway too..?”

    People are used to going to an app store and downloading an app and a few seconds later it is up and running… I doubt that this can ever be made to work as seamlessly in the enterprise market but that should be the goal I think. SAP should be thinking “how do we make this easy for everyone, make some money and keep our customers and partners happy too..?”

    Making the whole platform available as a service would certainly make it easier for customers. Do you think it would be possible for the gateway to be part of a hosted offering too? You mention that that would need to be on premise… But I am just trying to think of ways to simplify things.

    Anyway just a few things that came to. Mind that I felt like sharing. Keep up the great work!


    1. John Moy Post author

      Hi Simon,

      “Do you think it would be possible for the gateway to be part of a hosted offering too?”.  … I’m not sure.  My gut tells me it makes more sense to have that installed against your on-premise business suite system(s).  When installing NetWeaver Gateway, there is one part (IW_BEP for the OData Channel) that must be installed against the back end SAP system anyway, even if you are using a standalone SAP NetWeaver Gateway architecture.  So in that respect NW Gateway is somewhat ‘tightly coupled’ to the backend.  In my mind the architectural line outwards from NetWeaver Gateway to a SAP Mobile Platform makes more sense to be the cross-over point between on-premise and cloud.  Also, if SAP NetWeaver Gateway was installed on-premise you could theoretically also leverage it for use cases within your network (eg. for serving RESTful feeds into your intranet), completely separate from the SAP Mobile platform.  Finally, in all my discussions to-date with SAP and hosting partners, it has always been assumed that SAP NetWeaver Gateway will be installed on the customer on-premise side.  In fact, one of the hosting providers I talked to is only licensed to host Afaria and SUP, but not Gateway.

      Anyway, that is just my 2 cents.


  5. Phil Gleadhill

    Hi John, All,

    Another great article, with really good comments and contributions from all.

    John your analogy between the current situation with Mobile, and the case 10 years ago with Java are in IMHO very valid. If SAP want to succeed in the widespread uptake then they need to make it fast, easy, lightweight and uncomplicated. At least when taking the first steps, otherwise as for SAP with Java, we will end up with “SAP Mobile” and ‘Mainstream Mobile” and they will be vastly different beasts, just like “SAP Java” and “Mainstream Java” have become.

    Cheers, Phil G.

  6. Andre Urban Blumberg

    Looks like SAP takes the shortcut to reach the magic “million coder KPI” by simply luring the long-haired developer community promising to strike gold … lovely, just what TCO minded enterprise mobile platform buyers love to hear.

  7. Thomas Bezak

    “SAP is in the process of enabling hundreds of thousands or even millions of potential developers” I would love for this to be the reality but frankly it is not.

    I want to install SAP gateway in our development environment but
    it’s locked away behind some secret SAP licensing and we are a partner. Heck I
    had to research just to find out that there even is a SAP Gateway because if you don’t
    have a license the items are invisible to you in the software download center.

    If you make getting the software a protracted, mysterious, painful and costly process for your own partners (the ones who develop for SAP customers) how do you expect to get “millions” of developers onboard?

    Lets say you do manage to attract a developer in the current state of things. They spend 90% of their time cutting through red tape and jumping through hoops just to get an environment setup. Meanwhile their competitors who have chosen a more open ecosystem are off and running.

    1. John Moy Post author

      Hi Thomas,

      I hear your frustration!  I have similar stories around obtaining SUP last year.  One thing you may not be aware of however is that there is new leadership around building a mobile ecosystem for SAP, and the announcement I referred to is only the first step.  All the issues you point to relate to what was put in place last year.  Doesn’t mean that things going forward will be everything we wish for, but I would give the new leadership some time to execute on their plans.  Hopefully we will hear more at Sapphire.  I can say that I have had the opportunity to speak to some people looking at the new ecosystem, and I am convinced that they have the right intent to solve the type of problems you speak of (to illustrate, one person I spoke with had only recently joined SAP and comes from the outside world where they are familiar with the open ecosystems out there).  Lets give these people a chance to execute on their ideas.



  8. Joao Sousa

    I believe anyone who has any experience in SAP Mobility will agree 100% with your blog since you point out all the important topics.

    One topic that is not mentioned is the positioning of SUP in the future landscape, since the focus on Gateway and now on open platforms seems to be throwing SUP into a device management role only (together with AFARIA).

    1. John Moy Post author

      Hi Joao,

      I must admit from my perspective the positioning of SUP is less clear going forward. Already the fact that it is now embedded into the ‘SAP Mobile Platform’ (along with Sybase 365) obfuscates things a little.  And I’ve been looking at Syclo lately and noticed if SAP really have a future roadmap to merge the Syclo Agentry middleware into this platform then that further dilutes the emphasis on SUP (and as an aside, I don’t think that merger will happen anytime soon).  Afaria appears to have kept its brand in the device management space, probably because it is so well regarded. 

      Your comment about throwing SUP into a device registration / lightweight management role makes sense.  Especially as recent architectural diagrams I have seen for the latest BI mobile architecture effectively ‘plumb’ SUP into the picture precisely for that role.

      Thanks for your comments



      1. Joao Sousa

        The “problem” with reallocating SUP to a “plumbing” role is that Sybase will have to be integrated into the SAP portfolio both from a licensing and brand point of view. I don’t see anyone managing to sell SUP just for that role, since it’s way too expensive. They are having enough problem selling SUP as it is currently.

        From the onset I was very skeptical of SUP in an open standard world where an iPad can connect directly to a SAP ERP system, my only problem was load-balancing and security which in my view can be achieved more simply using SAP Gateway. SUP made sense 5 years ago, I feel it will just keep getting less relevant and SAP latest moves seem to point in that direction.

        As a side note, if you compare Native programming in iOS, with a custom Core Data iOS application you can see the similarities in logic. The benefits I get from using SUP haven’t matched the flexibility I have with custom development (for the synchronization).

        1. Frank Koehntopp


          I understand your reasoning, but I would like you to look at the other side of SUP as well:

          customers will have to tackle the challenge to manage all those new mobile solutions by many different vendors:

          • backend connectivity – which app may talk to which backend
          • user and device management
          • user authorizations by app or device
          • password changes
          • log files and error handling
          • caching data for non-available devices
          • push services
          • and much more…

          You can all do that quite nicely for your one app for one customer, but once the wave of many apps by many developers hits the customers it will very quickly become unmanageable.

          I’m also surprised we’re not focusing more on this aspect in our communication, but this will surely be an important consideration for customers. Currently I don’t see another (productized) infrastructure that provides that kind of functionality.


Leave a Reply