SAP's mobile apps strategy - a discussion

What is needed to write apps in SAP's mobile architecture?

There seems to be allot of options and developers that I speak with are rather confused, so here is an overvierw of the offerings based on my recent research:

• SUP (Sybase Unwired Platform). SUP enables you to build mobile apps (both native and with the hybrid web container) which can connect into your SAP backend systems via MBO's (Mobile Business Objects). MBO's can be developed within Eclipse and can cater for data caching and synchronisation. It provides for secure channels between SAP and the device.
  SUP needs a server insisde the corporate network.
  
• Relay Server or any other proficient reverse-proxy tool that can sit in the DMZ if you're going to use external mobile devices (and who wouldn't).

The above will enable you to build apps that allow mobile devices to access SAP backend data, synchronisation (for offline use), notifications and security. But not enough to run most of the SAP-developed apps already on the SAP app store.
(Check out John Moy's SDN blog which includes a great analysis of the system requirements for each app in a matrix.)

Now as additional elements it seems we have:

• SAP Netweaver Gateway. Essentially an abap add-on product so it needs an abap stack (See all recent twitter discussion on that. My thoughts are it should be just part of standard abap runtime like web-services are). This would enable your mobile applications to access data via the OData (RESTful-like) protocol and is another avenue into the SAP backend system without using SUP's MBO's. (Why would you use one over the other I wonder? Please comment below. SAP look to be positioning the use of Gateway for "online" apps and MBO's for apps that can work offline: see recent SDN blog by David Thirakul from SAP.)
  Something to note is that the OData client API's are currently only provided by SAP in native code, which rules out using web technologies like html5, jQuery Mobile, etc (or even SUP's hybrid web container) for the client app.
  
• Data Orchestration Engine (DOE. Seems to have previously gone by the name of SAP MI - Mobile Infrastructure). This looks to be another abap stack based toolset that provides some sort of wrappers around SAP BAPI's, enabling access from a mobile device via SUP.
  
• More... There are possibly more options as well. There is the "Portal on Device" initiative, which enables the SAP Portal to serve up html5 and jQuery based pages to mobile devices. (Personally, I think the Portal is very bloated however and complex to manage.)

Each and every one of the above requires a server somewhere. Each and every one of the above has licencing costs, infrastructure costs, maintenance costs and knowledge costs (staff need to learn).

Imagine when you add in the typical 3-tier landscape!!!

The SAP clients that I have knowledge of, already seem to be weighed down by the sheer weight of servers everywhere.

From looking at the SAP App Store most of the mobile apps require both SUP 2.0 and Netweaver Gateway 2.0 as minimum requirements. It just seems like a very complex and confusing setup to me. Something that could be far easier... And I haven't mentioned the Afaria (or another vendors') device management tool, which would mean another server(s) to look after.

Maybe if all of the above was enabled as a PaaS offering (hint hint).  PaaS (or Platform as a Service) being the situation where the hardware and system is hosted in the cloud and clients can use it to develop their own mobile solutions.

With mobile device development something that I have a keen interest in, I've been investigating the alternative approaches to development of apps. Using HTML5 and frameworks like jQuery Mobile it is relatively easy to build mobile cross-platform apps. They can be "native" as well by using the web container approach (i.e. PhoneGap - which SAP are kind of replicating with the SUP Hybrid Web Container).

As other community members have shown in recent blogs its also possible to easily use the ICF built into every Netweaver ABAP stack to serve data in a RESTful manner to these mobile apps.

Is this the easier route? Are there security implications? You would still use a reverse-proxy setup to enable devices outside the corporate network to access data. SSL etc. Devices can still be locked, tracked or remote wiped.

What about "offline" scenarios. SUP does provide for this in a secure fashion but it can also be done with HTML5 and javascript if necessary and their are jQuery frameworks already becoming available to do this (i.e. jquery-offline).

So... which way is better? Will SAP clients jump onto the SUP and Gateway bandwagon (and Afaria)? At this stage what I can imagine is a situation where clients take the easier option of using open source frameworks for their mobile app development to "test the water"; maybe even with Gateway. If they decide upon a full-blown mobile rollout at large scales, then I'm sure they will go with the SAP recommended solution of SUP & Gateway... but this is probably a few years away...

Lets hope for the following in 2012:

1. Change the SUP/Gateway pricing model to remove the barriers for clients to get onboard.
2. Enable access to SAP for the development community and not just large SAP partners (for FREE!)
3. Please look at a PaaS offering to ease the server burden.