Skip to Content
Author's profile photo Richard Hirsch

Thoughts on the current debate about the Sybase Unwired Platform and options to energize the mobile development community

An important caveat: I’m definitely not a Sybase Unwired Platform (SUP) developer and I’m still trying to fully understand the SUP architecture.  This blog may contain more questions than answers but I’m hopeful that my explorations move the dialog further.

There will always be a love-hate relationship between enterprise software vendors and the developers who use their products. There are conflicting interests involved and heated debates often ensue.  The relationship between SAP and its ecosystem is no exception.  Although the relationship between SAP and its developers is quite good and many developers are quite passionate in their support of the company, there are often disagreements between the two – especially regarding licenses and the prices associated with new technologies.  SAP wants to monetize its investments in new technology and developers are interested in getting their hands on this technology with as few hurdles as possible.

Recently, there has been resurgence of the well-known arguments concerning Gateway and SUP.  Here are some examples:

Fellow SAP Mentor Graham Robinson examines the problem from the perspective as an ISV in a recent Thoughts on NetWeaver Gateway:

So back to my killer app. Why should I take the funds my customer has committed to my app and pass some of them onto SAP? Even assuming I could get a straight answer from SAP on what the price would be – why should I do it unless the benefits outweigh the costs? How can a recurring pricing model on a piece of technology be weighed up against the value of saving me development time on a project I already have approval for? And why should I just let dollars go to SAP for my idea? And by the way my customers’ employees (the target audience for my killer app) are already licensed to use SAP anyway. Why should they pay again? (I have a few other objections as well but you get the idea.)

Returning briefly to the Sublime Unwired Platform – how do I justify the cost (albeit unqualified) of this platform against the benefits of my single, albeit killer, app? I can’t. And even if I could why would I confuse my customer with extra technology and extra licensing when I don’t need to? I wouldn’t.

Fellow SAP Mentor Jarret Pazahanick also Is SAP Using the Right Mobility Strategy a useful analysis of the situation and provides a few suggestions on how to deal with the problem. 

No one doubts that the Sybase Unwired Platform comes with a slew of benefits and functionality but I think SAP should consider using the razor and blade business model in which they provide the underlying mobility technology/platform for a small incremental cost ….

Blogger Frank Scavo summarizes the arguments in a well-received blog.

Many of these customers would love to stick with SAP for mobile applications, which by most accounts will become the primary way that business users connect with business applications. If the SUP is low or no cost for the majority of customers, it will encourage thousands of developers, such as Graham, to embrace it, and tens of thousands of customers to make it part of their applications infrastructure. The same economics apply to the Netweaver Gateway. If SAP really wants to lock-in its customers, it should offer these platforms to the majority of its customers at low or no charge. This will liberate business value to SAP’s installed base, ensuring SAP’s relevance for years to come.

Many of these arguments suggest that charging for SUP and Gateway are counter productive to SAP’s interests to expand the mobile developer ecosystem. 

NoteThere are various other blogs (for example from Dennis Howlett) that also look at the issue from other perspectives (app store, etc). 

If you look at the majority of discussions about SUP, you often see SUP being described in very general terms:

  • No one doubts that the Sybase Unwired Platform comes with a slew of benefits and functionality but I think SAP should consider using the razor and blade business model in which they provide the underlying mobility technology/platform for a small incremental cost and get their money/benefits …. [Is SAP Using the Right Mobility Strategy]
  • If the SUP is low or no cost for the majority of customers, it will encourage thousands of developers, such as Graham, to embrace it, and tens of thousands of customers to make it part of their applications infrastructure. The same economics apply to the Netweaver Gateway.  [SOURCE]

This generalization bothered me. SAP was also guilty of this generalization as well  – individual components of SUP are often ignored / blurred in marketing material.

Based on my limited knowledge of the product ( I knew that the SUP architecture is relatively complex), I started asking myself: “What exactly do these developers / bloggers want and does SAP have the ability to even meet these demands based on SUP’s technical architecture?” The easy out is to say “We want everything” but this isn’t realistic and limits the ability of SAP to meet the demands of these developers in a manner that is acceptable for all involved.

The impact of the SUP architecture on developer demands

A big caveat: Once again, I’m definitely not a Sybase / SUP expert. I’m basing my analysis on my readings of the material.  In other words, my assumptions may be incorrect which would bring the whole edifice crashing down but I’m optimistic that others could build useful blogs/analysis on the remaining foundation / fragments.

If you look at the SUP architecture you will see that it is more complex than just a development environment, it also includes a server component – the Unwired Platform.


Reflecting on SUP’s complete architecture with all those moving parts, I thought: What exactly are these individuals demanding that SUP be free referring to?  Are they just referring to the Eclipse-based development environment?  Are they referring to the whole thing – server and all? If you look at the SUP Development Paradigm, you will see that the Eclipse-based environment is closely coupled with the Unwired Server.

Here is a different description of Mobile Business Object (MBO) development from the same document [Emphasis is mine]:

  1. Connect to back-end data sources.
  2. Connect to Sybase Unwired Server.
  3. Create mobile application projects.
  4. Create MBO attributes and “create, update and delete” (CUD) operations.
  5. Attach MBOs to back-end data sources.
  6. Edit, rename, delete, move, copy, group and view MBOs.
  7. Perform additional MBO design activities — create logical roles, search, and so on.
  8. Deploy MBOs to Sybase Unwired Server.

Based on this tight coupling, it really doesn’t make sense for developers to just have the Eclipse-based environment. This dependence is associated with Web container-based development as well as native application development. Providing SUP to developers for free would mean providing much more than just a development environment.  

It is also critical to remember that SUP is not only a development platform – it is a runtime environment as well.  The applications created by the SUP development environment usually require the Unwired Platform server to function correctly. For example, an examination of existing Sybase applications on the Apple Store shows this dependence: “Sybase Mobile Sales & Workflow” – “To connect to SAP systems, the client requires use of the Sybase Unwired Platform server and a client access license.”    Or another application “Sybase Mobile Workflow” which states “A connection to a Sybase Unwired Platform server is required.”    Thus, I assume that customers require Sybase Unwired Platform server to run many applications developed with SUP.   If a partner has 20 customers for a mobile application, then if SUP was free for all,  that would be an expensive proposition. Of course, another alternative would be to provide SUP free to developers but customers would have to buy licenses.  

Note:  I have no idea if this association is still necessary when using Gateway-based applications in SUP 2.1 or whether direct access to Gateway without using the Unwired Server is a valid option.

I assume that it would be possible to develop mobile applications on the SUP environment that don’t use the functionality of the Unwired Platform server but there are other mobile development platforms (such as PhoneGap) which are often more lightweight and simpler to use. If you look at the YouTube videos put out by the SUPDeveloperProgram, they all understandably focus on using the functions provided by the Unwired Server (MBOs, etc). 

I’m not saying that Sybase / SAP couldn’t or shouldn’t give away the entire SUP platform (Eclipse-Dev environment + Sybase Unwired Platform server component) to jump-start SUP-based development in the partner and/or SI community – just that it is more complicated than providing a few Eclipse plug-ins.

A rhetorical and perhaps heretical question might come in response: “Based on this architectural complexity, is SUP the ideal platform to develop mobile applications that access SAP data”.  The current marketing push from SAP on mobile apps is motivated by the desire to acquire additional revenue via Sybase products (SUP, Afaria, etc) as well to allow customers to increase their ROI by exposing more data from back-end SAP systems to a larger audience (either internal or external).  The complexity of the SUP architecture assumes a certain level of mobile application complexity to allow customers to recoup their investment – the SUP Runtime architecture doesn’t come for free – in terms of hardware, administration, etc.

The demand that SAP provide SUP free of charge to developers isn’t going solve all problems associated with the necessity of developing mobile applications. It is based on the assumption that SUP is THE tool for all use cases involving mobile access to SAP data.  I’m not saying that there aren’t use cases where SUP is the perfect tool – I’m just saying that it isn’t the perfect tool for every use case.  SAP and Sybase understandably focus on SUP as THE development platform for mobile.  You want zillions of developers developing mobile apps that use SAP data not zillions of developers using SUP to create these mobile applications. To meet this goal, what other development options – besides giving SUP to everybody for free – should be actively promoted?

Option 1: Apache Callback / PhoneGap and other mobile development platforms

As Dennis Howlett suggests, there is a new breed of mobile applications that is emerging and which is based on a development paradigm quite different from that of traditional enterprise software.

However, such models cannot hope to cover all eventualities or for that matter the whole of the market. We can envisage thousands of situational, ad hoc, even one-off applications where the need for fast tracking is paramount or where value comes from volume usage. This is already happening in the universe where cloud brokers like Appirio are working on a 4-6 week develop/release cadence for proof-of-concept to initial deployments. Having ready access (which has to include easy, clean, cheap licensing) is the only model framework that will encourage those types of developer shop to flesh out the 80% SAP claims it wants to see from its ecosystem. [SOURCE]

Can you meet this new paradigm with SUP? Sybase / SAP will of course, say ‘Sure’. But there will be some mobile applications that are very lightweight and which don’t require the developmental baggage / costs associated with the SUP. 

My suggestion to SAP is to select a few other mobile development platforms and actively support them for developers to use to access SAP data.  The important word here is “actively”.  I’d like to see SAP admit that there are some use cases where SUP isn’t the best choice – based on price or other reasons. Instead of angering developers by restricting their focus to SUP, SAP should proactively embrace a larger audience of developers – many of whom have experience with applications in the consumer market rather than enterprise software. 

Let’s concretize this suggestion by looking at the possibilities provided by Apache Callback (which was formerly PhoneGap) and which is a new project in the Apache Incubator. The project has the following goal:

Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview.  [SOURCE]

What is the relationship of PhoneGap to other mobile development frameworks? “Although PhoneGap gives you a convenient way to bundle a web app as a native app, and hooks into the devices native APIs, you are totally on your own with respect to what web-app framework you use, if any”. [SOURCE] So, a developer may combine Apache Callback and JQuery Mobile, for example. 

This approach has already been used by Bluefin Solutions to build a Mobile Timesheet Application that accesses the ERP system via RESTful web services.   John Moy also used this technology to Extend your SAP jQuery Mobile web app with HTML5 concepts and Native device features – Part 1 without Gateway, SUP, etc. Thus, this approach is not unknown in the SAP ecosystem.

What exactly am I suggesting then? I expect SAP and the greater ecosystem to work together to define the use cases that fit this new development model. Instead of ignoring this approach, SAP should embrace it and promote it as an accepted option for developers.  Even more useful would be to actively work with the Apache Callback project and contribute extensions (for example, Project Phoenix ??, or tools that better support oData processing, etc)  that might make life easier for developers using these lightweight development platforms accessing SAP systems. If you look at the original list of contributors to the proposal, you will see that the majority are from Adobe/Nitobi and IBM.  They obviously see value in contributing. Hint – hint.

By the way, PhoneGap is currently being downloaded 60,000 times / month [SOURCE]! It is available free of charge.  Compare that to the Hey Web Developers! SAP’s Sybase Unwired Platform Wants YOU that often surround SUP (finding it, downloading it, etc) and you have two very approaches to interacting with the mobile developer community.

Option 2: Let’s add some PaaS

SAP is currently developing a Java PaaS that will be going into private beta in Q4 2011.   This platform adds a variety of new opportunities for SAP to involve mobile developers in new and innovative ways. 

Here is a diagram depicting three possibilities:

  • The River Description Language, a model-driven development environment supporting the implementation of front-end Web/Ajax-based applications [SOURCE] provides a rapid way to access data from SAP and other platforms.  Combine this functionality with the River Javascript SDK (Not for productive use – yet) and jQuery Mobile and you have the ability to rapidly create mobile applications.
  • A developer / partner can also create applications with Java, Ruby or Spring that have REST APIs which jQuery Mobile-based clients could easily use to access data from back-ends (either from Gateway or other sources)
  • In one description of NetWeaver OnDemand, I found the following curious reference “Over time, SAP wants to make it very easy to do other critical tasks on NetWeaver OnDemand, such as build and integrate mobile applications. Technologies from the Sybase Unwired Platform will be built into NetWeaver OnDemand” [SOURCE]. So I assume that parts of the SUP will move to the jPaas. What exactly will be moved – MBOs? – isn’t described in more detail. I imagine that some version of the SUP Eclipse-based client might be provided that could exploit this functionality in the jPaaS.

In comparison to the first option, this option could be used for mobile use cases that are more complicated – perhaps based on back-end-related requirements (BigData, more performance, etc).

Since we are on the topic of SaaS, I suggest that SAP should take a closer look at BuildGap an OnDemand compiler for mobile apps:

Simply write your app using HTML, CSS or JavaScript, upload it to the PhoneGap Build service and get back app-store ready apps for Apple iOS, Google Android, Palm, Symbian, BlackBerry and more. By compiling in the cloud with PhoneGap Build, you get all the benefits of cross-platform development but can still build apps just the way you like.

I love the idea and would like to see something similar in the jPaaS as well as a link to the upcoming SAP Mobile App Store included.

Option 3: Sybase’s Managed Mobility Program

As I was researching this blog -especially after I discovered BuildGap – I was surprised that SAP hadn’t put SUP in the Cloud and offered it as a SaaS.   I was even more confused when I started seeing quotes about SUP’s ability to support multi-tenancy.

Sybase Unwired Platform 1.5.3 introduced support for multi-tenancy. This functionality enables a hosted cluster of Sybase Unwired Platform servers to service multiple customers from the same cluster. To keep different customers’ applications, data, and administration separate, we introduce the concept of domain [SOURCE]

At the same time, he emphasized that there remains plenty of opportunity for mobile ISVs to customize or build mobile SAP apps that target a specific industry or region.

Moreover, Sybase won’t build apps targeting smaller customers. That leaves room for partners to set up SUP as a multi-tenant Web-based service that hosts multiple apps for different customers with say 20-30 users each, [Jagdish Bansiya, CTO for enterprise mobility at Sybase] said. [SOURCE]

I thought a hosted SUP solution would be the perfect answer for use cases (perhaps for smaller companies) where the full functionality of SUP was required but the customer was unwilling or unable to support the necessary SUP-related infrastructure.

I then found a SAP press release that described a new Capgemini offering based on Sybase’ Managed Mobility technology: Capgemini will host mobile solutions powered by industry-leading Sybase® Managed Mobility technologies and offer them on a software-as-a-service (SaaS) and platform-as-a-service (PaaS) basis.

The first thing I wanted to understand was the Managed Mobility technology. Here was the “eye-catcher” on the Sybase site:

But many enterprises – even large Fortune 500 companies – simply do not have the resources to support mobile services, and the current global economy is forcing them to make hard decisions on which IT projects get the green light. With limited budgets and growing mobility business needs, many of these companies are striking the right balance with a different model: mobility as a service.

This was technology that wasn’t for customers/end-users but rather for partners / SIs. There is a impressive list of partners who offer this service: Orange Business Services, VeliQ, Verizon, Vodafone, etc.  What is very interesting about this offering is that SAP or Sybase never moved into this area themselves.  With the importance of “mobile” in SAP’s global strategy and the obvious link to the OnDemand world, it would appear to be a smart move.

A deeper analysis of Capgemini’s offer (thanks to Capgemini’s social media team for providing me additional material after my plea for more details on twitter) provided me a better insight into the potential of the Managed Mobility technology.  The close link with particular mobility scenarios in the form of application suites in Capgemini’s offer is an excellent idea – the combination of SUP-based hosting and provision of already developed mobile applications gives customers a one-stop shop that gets them up and running quickly.


Although this option focuses more on the requirements associated with the SUP infrastructure, I’ve included it in this list, because it is a viable alternative that developers should consider when proposing mobile solutions to their customers. The idea would be that a developer creates an application using SUP and then instead of having customers host the application; it is hosted by one of the managed mobility partners or perhaps by the ISV itself. This is similar to the idea behind What is the relationship between Sybase’s ‘SQL Anywhere OnDemand Edition’ and SAP’s other OnDemand offerings?.  This might be prove an initial entry point for customers with just a few SUP-based applications and reluctant to have pay for the whole SUP infrastructure with such a small number of mobile applications.  Thus, developers who are interested in providing a low-cost mobile solution would be able to share the infrastructure-related costs among a number of customers rather than having a single customer bear the cost of the entire infrastructure.


There are other aspects of this story (for example, a SAP Mobile App store) that must also be considered if SAP is going to be successful in this area but I’ve concentrated in this blog on the development platform.  A developer’s decision to use a particular development platform is nuanced. There are always various options that are available.  Regarding mobile development, this reality has to be accepted by SAP as well as its ecosystem. Indeed, acceptance isn’t enough – there must an active promotion of this variety in order to be able to meet SAP’s goal of broadening its mobile development ecosystem.  

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Mark Teichmann
      Mark Teichmann
      We are also investigating in the development of mobile apps at the moment (who is not?) but for us the investigation in a SUP platform is definitely not the way to go.
      Personally I favor Gateway 2.0 at the moment because of the decoupling of app development and SAP development. But I do not know anything about the amount of licensing costs for Gateway.

      Regarding SUP I foresee the same problems that came with SAP NW CE. Although it might be a good technical solution (CE 7.1 did not pass the test for us but CE 7.3 is much better I read somewhere) it was too much overhead for our customers to use it.

      If I would know today that all employees of a customer will use a mobile device from tomorrow on then I could rely totally on a complete solution like SUP but in reality everyone is starting with some tiny apps in order to test the advantages of using apps. Therefore an approach without the need of heavy investments in infrastructure and licenses would be better.

      The trial version of Gateway 2.0 is a step into the right direction. I wish there was an unlimited developer licence available. That would attract more developers to get started with mobility and SAP.

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author
      I agree that SUP is often too much - especially for smaller firms. The main question is how to assure that such customers continue to trust SAP's mobile strategy. A certain flexibility by SAP is necessary in order to assure that initial steps in enterprise mobility are supported rather than alienating such efforts with an over-emphasis on SUP.  I also like your comment regarding CE - it is an excellent comparison and I'm hopeful that SAP has learned its lesson and positions SUP differently.


      Author's profile photo Former Member
      Former Member
      as I understand, Gateway is (not technically but from a licensing point of view) only available as part of SUP. Is this wrong?

      and which developer actually requires the unlimited developer license to get started with SAP mobility?
      The so called long-haired app developer? will he want to have to do anything with an ABAP app server (no matter how easy it is to setup)?
      The so called gray-hair ABAP developer? will she be providing anything on Gateway or rather just supply suitable backend services?

      I am a bit confused by actual discussions.


      Author's profile photo Tom Cenens
      Tom Cenens
      Hello Anton

      "as I understand, Gateway is (not technically but from a licensing point of view) only available as part of SUP. Is this wrong?" --> That is also what I have heard.

      The technical infrastructure is often waved off. Some time ago I party crashed a usergroup event at which Sybase showed SUP. The comment on the slide about IT infrastructure was "IT will take care of that, don't worry about it".

      One thing that made me grin was the fact that they were showing off their mobile solution and they didn't bring any mobile device to show an actual application. Of course one of the customers asked if they could show an application. I offered them to borrow my iPad for a few minutes but they didn't want to.

      When one of the customers raised the question "so with what we see here we can build our own app store?" the answer was "no, that requires an additional component (server)".

      Kind regards


      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author
      I can imagine that Sybase wanted to avoid talking about the required infrastructure at the event. Everybody likes the shiny blinking mobile apps but no one really wants to take a look under the covers to see what infrastructure is required to support them. Yet both sides are required.  SUP provides excellent functionality - especially regarding SAP integration. SAP shouldn't have to hide the Unwired Platform server in the cellar behind a locked door but should bring the server out into the light and let customers see its potential but also understand the reality in terms of the associated costs (administration, etc) of its usage.


      Author's profile photo Jarret Pazahanick
      Jarret Pazahanick
      My guess is one of the reasons SAP is hiding the licenses/infrastructure in the "cellar behind a locked door" is that 25% of the newly provided mobility apps are HR related and one of their largest competitors in North America (Workday) is offering their mobility solutions for FREE as part of their customers subscription (similar to SAP user license).  As they are a SaaS vendor there are obviously no infrastructure costs.

      Just another challenging piece to this complex mobility/pricing discussion.

      Author's profile photo Former Member
      Former Member
      Check out Blag's blog:

      No SUP in sight.  But yes, he used Gateway.  🙂

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author
      Yet it is exactly these long-haired developers that SAP should court by displaying a greater degree of flexibility in its preferred mobile solution architecture.

      I think that Gateway is also offered outside of the SUP because it can also used in non-mobile application development (for example Duet).


      Author's profile photo Mark Teichmann
      Mark Teichmann
      let me explain why I like to have an unlimited developer license:

      a) I am booked most of my time in projects therefore I sometimes can only evaluate a thing just some hours per week over a longer period. Therefore 90 days are too short for me here

      b) As a long- and gray-haired ABAP and app developer I evaluate many platforms sometimes without ever selling a product on it. So why should I have to pay for this evaluation at all? Here I act like a ray of light: I choose the fastest way for me be it with or without products from SAP. My customers do not want to buy a platform, they will buy a solution.

      Just because there are so many technical designs in order to build mobile apps it is very important to be able to test many different approaches without much overhead or extra costs.

      Author's profile photo Former Member
      Former Member

      Your blog definitely advances the #SAPCommNet discussion regarding the options for deploying mobile applications. The architecture discussion and diagrams provide graphic evidence of the complex nature of the "SAP-preferred" methodology to the Apache or PhoneGap platforms.

      Your statement: "I’m not saying that there aren’t use cases where SUP is the perfect tool – I’m just saying that it isn’t the perfect tool for every use case.".. is dead on. The open source solutions, PaaS or SaaS options delivered through partners offer some of the flexibility and scalability for the non-enterprise scenarios.

      As Mark mentions in his comment, many customers are looking for the quick proof-of-concept that will help determine the feasibility of widespread mobile application development and deployment. Aside from the 90 day trial for SAP Gateway 2,0, SAP has not shown enthusiasm for providing the lightweight option to the customer.

      Hopefully the discussion will continue and provide some assistance for determining the course that makes the most sense for each company.

      Again, thanks for the excellent article.


      Kevin Grove

      Author's profile photo Graham Robinson
      Graham Robinson
      Hi Dick,

      thanks for this blog on a really important topic.

      To repeat Myself again, and agian, etc. SAP needs to rethink the whole concept of trying to monetise the development AND runtime environments as much as possible.

      If developers have easy access to the SAP development and runtime platforms they will build great applications.

      If developers build great applications people will use them.

      When they use them they will have to pay SAP a license fee for the user.

      quod erat demonstrandum.

      Graham Robbo

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      Let me try and understand your request: The development environment should be offered free but the runtime environment (used by customers) should be purchased.   This is probably more acceptable to SAP than saying that the runtime environment should be available free as well.

      Now if only SAP would follow the example of the many open source development platforms where the download link is on the front page of the project and open to everyone without registration or jumping through legal hoops. 


      Author's profile photo John Moy
      John Moy
      Hi Richard,

      I must say this is a superb blog.  Many of your statements echo my thoughts, but you articulate your thinking in the written word much better than I could hope to. 😉

      Ironically, at an architectural level I am wondering whether NetWeaver Gateway on its own holds more promise (licensing concerns aside, and let's just say developers are willing to live with oData).  As other commentators have indicated, it architecturally decouples the client technology, so you can tether it with practically ANY client (be it web, native mobile, or desktop apps) to consume Gateway services.  It means you are unrestricted in your choice of client technologies, and also in the release levels for those technologies.  With SUP, you are beholden to the mobile platforms supported by SUP, and this will naturally lag current releases of the native platforms.  For instance, it is only very recently that Android has support (to my understanding).  And Windows Phone 7 has no support yet (once again to my understanding).  Compare that with the wide range of supported platforms by PhoneGap for instance.

      I should add another thread of information.  I have sat down with SAP representatives and analyzed all the true platform requirements for the 30 or so apps that SAP currently have available for customers.  Here is the interesting thing.  The platform requirements include SUP (of course), but also (in some cases) a NetWeaver Mobile DOE server, NetWeaver Gateway, and (whilst not required) you are encouraged to add a 4th server in Afaria.  That is as many as four new servers for your production environment, not to mention requirements for non-production instances.  Precisely why I agree with you that a hosted offering is much more desirable for our current times. 

      The situation with NetWeaver Gateway is very interesting.  Early diagrams of it a year ago depicted what was to me a very appealing architectural intent.  Abstraction of the client technology.  Interestingly this is what WebDynpro was intended to do, albeit in a different and more ambitious way, relying upon SAP providing client rendering engines for all possible future client technologies (in hindsight, this was probably too ambitious).  Gateway accomplishes it's aims simply by providing a client agnostic data interaction service, which can be plugged into practically any client technology.  To my understanding, Gateway was conceived BEFORE the acquisition of Sybase.  Anyway, what I am seeing now in slides (eg. from TechEd) is an altered version from the ones I saw a year ago.  Whereas a year ago the slide depicted a Gateway server with lines to iPhones, Android devices, Blackberry devices and even non-mobile devices, now I have seen the same slide altered so that for mobility scenarios the Gateway server has lines feeding into SUP, and from there into mobile devices.  As I understand it, SUP in these scenarios (where there is no offline support) simply serves as a device registration and authentication platform.  Anyway, whilst a year ago it seemed OK to connect a Gateway server directly to mobile devices, now it seems it isn't.  One can read into that what they wish.

      So, let's consider another architecture.  What if SAP released Gateway to all customers (and shipped it as part of the standard delivery for 7.02 systems and above).    What if SAP then delivered standard configuration for Gateway, so you could effectively expose standard services (eg. getEmployee) by activating them, much like you would activate a standard SICF service.  So, what if developers could simply code apps in their own choice of technology, whereby these apps could be built to connect with these pre-defined services?  These apps could be published to existing marketplaces, giving developers an avenue for financial reward.  So, for instance iOS developers could choose to code a native app for Employee Leave Request and place that on the Apple App Store.  Alternatively if you wanted a cross platform solution you could combine something like jQuery Mobile and PhoneGap to deploy to multiple marketplaces.  End customers would need Gateway and the applicable services enabled.  Connectivity would be via VPN using the iPhone's built-in VPN capability.  What about device management you say?  Well, device management is a separate matter that you can consider separately.  You could consider Afaria, and there are also some cloud-based device management solutions appearing in the marketplace.

      Another reason I think NetWeaver Gateway is more relevant for our times?  The fact is that from my own experience, customers are looking more urgently at customer-facing mobile scenarios because they offer opportunities to actually raise revenue.  A solution like NetWeaver Gateway is better suited for consumer-facing apps.  There is a concept of MCAP (mobile consumer application platform), which differs from MEAP (mobile enterprise application platform).  Looking at MCAP providers (based on Gartner analysis), there are a number of cloud-based providers that can provision consumer facing apps quite readily as a service.  ALL THEY ASK FOR IS RESTFUL APIs delivered by your systems, which they 'plumb' into their apps.  Sound familiar?  That is where Gateway fits in nicely.

      I know the better developers will cry 'but wait, I can code RESTful APIs myself without Gateway'.  That is true.  But using that approach how does one achieve standardization?  If we accept Gateway+OData and can surmount any licensing concerns, I believe that should be higher on customer's priority list.  And (like an extra set of steak knives) it also services non-mobile use cases as well ... including DUET Enterprise (but let's not open up  that can of worms!).

      Thanks again for your blog, and the mention.



      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author
      First of all, thanks for your amazing comment. It is longer than many blogs on SDN. ;->

      Regarding SUP and Gateway: I've also heard rumors that SAP is trying to run Gateway-based mobile interaction via SUP. It is an option but I'd hate to see it being pushed as the only option or even the preferred option.

      Reading your detailed analysis of Gateway led me to think about partners providing hosted Gateway environments - similar to Sybase's Managed Mobility technology. I don't know whether this is possible due to the tight technical association with the SAP back-end or the ability of Gateway to support multi-tenancy but I think it is still an interesting idea.


      Author's profile photo John Moy
      John Moy
      "I've also heard rumors that SAP is trying to run Gateway-based mobile interaction via SUP" ... I think you are referring to the Hybrid Web Container.  SUP 2.0 shipped with a web container, similar in style to PhoneGap.  I fact the web container actually ships with an alpha release of jQuery Mobile.  I had one hands on session with this at TechEd LV.  To my understanding the Gateway feed passes straight through SUP and is processed at the client.  I'm not 100% about this however because I asked the presenter if the architecture when connecting with Gateway utilised the REST adapter to populate a MBO, or whether the feed was passing through SUP (whereby SUP behaves like a reverse proxy).  Sadly the presenter was from Sybase and admitted they didn't know the answer to the question. 

      The inclusion of the web container provides Sybase with a necessary path to embrace the world of HTML5-based apps.  It does bother me however that if in future more and more apps are simply HTML5-based, not requiring the complex native code generation components of the product, is the value of the SUP product diminished over time (ie. it begins to look more like PhoneGap)?  To be fair however, there are device onboarding, registration and authentication features that SUP provides.

      Mobile architectures are changing so quickly, I recall a Gartner recommendation that any investment into mobility solutions and architectures should have a ROI within 18 months, since the mobile world may change in that short space of time.  With the need to install so much infrastructure and license multiple products, it is no wonder that many customers are having difficulty justifying the expense of SUP, Afaria etc..  18 months is not a long time to achieve a payback.

      IMHO this is why I believe NetWeaver Gateway itself has a good proposition, because you can swap different client layers in and out over time at your will.  You can code your own native apps, you can connect it to cloud-based solutions, you can swap over to HTML5-based apps in the future.



      Author's profile photo Graham Robinson
      Graham Robinson
      Hi John,

      Your mention of MCAP options is an interesting one. It seems SAPs current ideas about licensing Gateway by number of service calls also means you have to connect all such calls using the same non-dialog user account. In other words not a "named user".

      For me this is a problem as I want to able to identify each named user.

      So maybe a MCAP can provide user authentication for my apps and then I can consume Gateway services as you describe.

      An, interesting option that I need to investigate further.

      Graham Robbo

      Author's profile photo John Moy
      John Moy
      Hi Graham,

      I should add a side note about MCAPs.  Earlier this year I had the opportunity to meet and work with a few to assess their capabilities.  Note that these platforms differentiate themselves from MEAPs because they need to include other features, such as author and surface dynamic content (promotions, advertisements etc.).  One very interesting thing I learned is that some of these providers had the option of both web-based mobile apps and 'native' mobile apps.  When I drilled some of them on the details, some were using PhoneGap-like approaches to create their 'native' apps.  Even more interesting was that one of them eventually admitted that they did use PhoneGap!  Probably their customers didn't realise a component of the service they were paying for was based on a free open source framework.  Anyway just wanted to add that little anecdote.



      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author
      Now that PhoneGap has moved to Apache, I expect the number of such integrations to increase. The fact that IBM and Adobe developers currently form a strong foundation of committers on the project also leads me to expect an awareness (if not a focus) on the enterprise mobile market.


      Author's profile photo Former Member
      Former Member

      Well said. At the last partner event I posed these same exact questions. The response from the SUP side was basically this: (not verbatim)

      "We've found that most developers creating apps that consume SAP solutions have said that 70% of the effort is getting the data to talk to the SAP system. SUP provides all of that infrastructure out of the box. Also it allows you to store data encrypted when the device is online.'

      This is where I'm still confused. With a RESTful API via Gateway you can already do all of this. AND it allows you to view the data in other views (HTML5, Web App, etc) by exposing the same exact APIs. Also I'm not sure why SUP has any real technical advantage to "analyzing data offline". I could do this already...

      p.s. Great blog Richard!


      Author's profile photo John Moy
      John Moy
      Hi Mike,

      In relation to your quote ... ""We've found that most developers creating apps that consume SAP solutions have said that 70% of the effort is getting the data to talk to the SAP system".  I am wondering if this is a marketing position from over a year ago, when Sybase was able to differentiate itself from some other platform providers, because they went to the trouble to build a SAP Adapter into their platform?  So a SAP Adapter exists, alongside a JDBC adapter, REST adapter, Web Service adapter (and I cannot remember if there are others).  But the SAP Adapter is simply an implementation of the JCo connecter, so SUP can communicate with an SAP server using RFC.  Sybase people might think that is ground breaking, but for us SAP developers we know that these days the ability to connect via RFC isn't all ground breaking, if other channels such as Web Services and REST are already available. 

      Just my thoughts anyway.  I could be misreading it.



      Author's profile photo John Patterson
      John Patterson
      Hi Dick / John
      I agree with John.

      Last week I attended the session CD202 HTML5 for Lightweight SAP Applications at TechEd Bangalore. During this session there was a quick demonstration showing how easy it will be to directly consume Gateway services from the Netweaver Development Toolkit for HTML5. In approximately 10 lines of code maybe less, we saw the creation of model based on a Gateway service and that model then being bound to a table control, impressive stuff, would have taken at least twice that with JQuery alone.

      A couple of minutes later was a slide on Lightweight SAP Mobile Applications, which showed SUP components sitting ontop of Gateway, one component was sitting in the DMZ acting as a reverse proxy and the other inside the organization providing mechanisms for onboarding, authentication and push notifications.

      The slide on Mobility looked a little out of place, almost forced in, it prompted me to ask the following question during the remainder of the conference each time I saw that slide - Given how easy it is to consume Gateway services and the functionality available in HTML5 and on the device itself, what advantage does SUP provide me for Lightweight or Online mobile applications? The answer each time was Provisioning and Security, good answer, but not compelling.


      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author
      I just found two interesting blogs about running SUP on the Amazon Cloud.

      This is one option that I didn't consider and it would be interesting to look at this possibility in combination with Sybase's Managed Mobility technology as well as for standalone installations. This might also be a good option for creating quick Proof-of-Concepts for customers.


      Author's profile photo Former Member
      Former Member
      Very good discussion, highlighting that SAP is not doing a great job in communicating and supporting the developers/consultants that want to help themselves and SAP moving forward in the Mobile area.  I personally have been trying for months to make sense of the way forward with enterprise mobile apps as well as trying to help the people around me (both long and gray haired developers) getting their feet wet with building prototypes and demo apps that can help us and SAP gain some momentum.  SUP is extremely hard to get unless you pay the 2000$ fee that comes with the enterprise developer version, the 90 day version we are not able to get at all.  That leaves us with blogs like these, the help pages on and anything else we can find from teched and SDN.

      What we hear from every single customer is the question about what SAP is using to develop the standard SAP Apps that they will deliver and that clearly is SUP+Gateway.  This is followed by a lot of solid questions such as how do we then distribute these apps to the mobile devices (Afaria seems to be the answer), can the standard apps be modified/enhanced, branded to the liking of the customer - to that question I believe the answer so far is no but most of the time Sybase/SAP have ignored that question in the last few webcasts I have joined (HCM apps webcast being one of them). 

      If you add to that mix the complexity and the amount of servers needed (not even counting the apps that need Netweaver mobile DOE server), the licencing of both SUP and Gateway that is not very clear but seems to be expensive then you end up getting nowhere, stuck in the mud if you will.  As this blog and comments highlight, developers know that their are alternatives and some very good ones actually but the risk is that the customer will complain that what we suggest (going with PhoneGap for example) is not going to give them the standard apps from SAP which is going to be a showstopper for many customers.  They are therefore going to select to wait until the confusion is cleared and the developers and other sap techies have gained their experience with one of the few customers that decide to go ahead anyway into the SUP/Gateway/Afaria despite the costs. 

      It's a friday so that should not be a day of too much complaining and whining but SAP employees/Sybase people are more than welcome to brighten the discussion with some positive input and news.  One example of such news that would be appreciated would be access to a cloud based SUP server - linked to a SAP IDES backend/sandbox where all of us are invited to get our feet wet later in the afternoon, all linked to an afaria system/sandbox where our small and big prototype apps could be distributed from and later even shown to potential clients (in the end meaning hungrier and more convinced customers with their checkbooks willing to hand over the money to SAP)  That news would certainly make my day, or a link/mail from someone from Sybase finally giving me my developer SUP 🙂 

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author
      I think your point regarding the customer demand for standardization instead of other mobile frameworks (ie PhoneGap) is a good one. I see two options - either SAP / Sybase must show more flexibility in promoting mobile development standards or lose customers who are unwilling or unable to use the standard toolset.


      Author's profile photo Joao Sousa
      Joao Sousa
      From a developer perspective there is something that is clear to anyone who has tried to use SUP. It's way to hard to get our hands on it. Let's make this clear, I still haven't tried the framework, I still don't know if the value proposition for my clients is good, why should I bother?

      Because it's the the only way to develop mobile application? It isn't. Let's make another thing clear. This is not 1990. In a SOA environment we don't need a shiny complex application do make different technologies talk to each other.

      My story with SUP:

      - I read about SUP and enrolled in a Sybase course (in the last day of the course, 2.0 is released, so the 1000 euros I paid are already obsolete);
      - I tried to get a trial of SUP 2.0. Not available, I had to ask my company to talk to SAP about this.
      - In the meanwhile I started looking at alternatives, like interfacing with SAP via SOAP webservices;
      - Still waiting for SAP response;
      - I have my first functional iOS application. It's great, I can approve purchase order in my iPhone;
      - Still waiting for SAP response;
      - I have some really complex application, cool SAP Retail application with graphic, offline storage, etc;
      - SAP provides a licence!
      - We try to install, lots of problems, 30 day license expires. Request extension;
      - I make demos of my great SOAP based applications, my clients love them and want to buy them.
      - License is extended. Finally we get SUP installed, but still trying to get purchase order approval working (my first demo).

      Why should I care about SUP anyway (or SAP Gateway for that matter?). Client are buying my applications without paying an additonal license to SAP.

      Yes, it's more scalable (at least in theory) but remember this. Clients are already paying a lot of money to SAP. A truck load of money per user. You're going to tell them they have to pay MORE money to SAP? Really? And I can't even tell them how much ... "Talk to your Account manager for that". Maybe they would pay to Sybase, but more money to SAP? No way.

      Finally the nail in the coffin. Why should I really invest in a technology when SAP's account manager can just screw the whole value proposition with an absurd license price? One that I don't even know.

      Author's profile photo Former Member
      Former Member
      As a customer - I am thinking of course I would Sybase first.  Why?  Because it is "SAP".  It will be supported.

      But thinking about the cost associated, and not knowing the true advantages, it is an interesting question.

      I know 0 about Sybase.  I did not go to those sessions at Teched.  I had others I was more interested in.  I think we are a couple of years away from a real app.  IPAD yes, Iphone or Android - probably a couple of years.

      It should be interesting to see what develops.


      Author's profile photo Former Member
      Former Member
      Good discussion, I can definitely add my 2 cents to this, as I have done some mobile middleware product development 2 years ago.

      1. Gateway: I have built several iPhone and Android apps that connect to SAP via soap based services. I never needed Gateway, the performance is good so far. However it is a good idea to go REST based as it is light. I have worked on oData with gateway, it is simple. I am not sure about the protocol level encryption and security one can achieve though. But to say Gateway is mandatory for mobile is unwise. Gateway is very useful for say facebook promotions for retail scenarios. If Gateway comes cheap (I know the license) then it may make sense. Now it is way too expensive!

      2. SUP: If you build offline mobile apps then a middleware is a must. Again SUP can offer this functionality but is meaningful only if its not priced like other SAP products. It can necessarily improve performance when a large user base connect via mobile, no doubt. SUP at best is a framework to enable offline synchronisation. For online I dont need SUP. Again like PI customers may want one routing place for both online and offline.

      SUP is good as the data is always encrypted and it is aligned with a relay server so that you dont open ports to Internet directly. It can help to reduce data volume, hence save on 3G costs.

      3. MDM: This is the most important part of a mobile environment. I definitely need to know which devices connect and how to provision them. But again Afaria is not the only option. I can use a cheaper MDM and connect that to SUP. Morever SUP comes with Sybase Control Center which is good enough for basic administration.

      UI: I would say SAP stays away from this. For mobiles native development is the best. I can not even in my dream imagine SAP match iPhone, Android and WP7 UIs. SUP should serve as the backend framework to collect data from Mobile UI and relay them to the SUP server.

      Having said all this, I would say SAP needs a mobile strategy and Sybase is a great starting point. But certainly the pricing is pulling SUP projects down.

      Author's profile photo Former Member
      Former Member
      Thanks a lot! You brought this discussion to the ground - from generic whys and whats to specific functionalities of SUP.

      SUP has a very specific set of functions and if application don't need those functions then it can safely skip SUP. The irony is that offline data submission, push notifications and device management often not considered at the project inception phase, but later it turns out that customers just assumed that all this is available in the final version. I always like to offer scrolling, cut-n-paste and drag-n-drop in Windows applications as an example of similar assumptions.


      Author's profile photo Tamas Szirtes
      Tamas Szirtes
      Hi All,

      I would like to mention another option: SAP Portal On Device. I think this is very interesting if we talk about easier/lighter entry into mobility for SAP customers.

      If we believe in the future of HTML5, this is really interesting. SAP will even provide a hybrid approach, where a SUP-based app can consume web content. Obviously Gateway can be used too to communicate with the backend.

      Wiki about Portal On Device: