Thursday, May 12, 2016

First thoughts on Native Enterprise Fiori iOS Apps

On May 5, SAP and Apple announced a partnership to deliver native iOS Apps that will connect into SAP business suites:
My personal first response on this news was astonishment and non-understanding. Since 3 years SAP is full promoting SAP Fiori build through SAPUI5 (or openUI5) web-technology as THE future-proof way to build user-friendly SAP Apps. SAP applies itself in all new and updated product developments, as SAP HANA Analytics Apps, NetWeaver Business Client, SAP Enterprise Portal. SAP made and evidently applies the decision to go full-stream for web-based UI in favor of the platform-specific native product developments (of which SAP tried several variants, most notable through the Sybase Unwired Platform). And now all of a sudden, SAP appears to return on this decision and [also] to put full steam on platform-native development. Starting now with first Apple/iOS, and already communicated plans to follow later with Android.
I expressed my surprise and concerns on a SAP post in which Steve Lucas communicated on the SAP-Apple partnership. His responses gave me more insights in the why of this renewed native-attention, and the positioning towards web-based. Not to say that I in all agree.
Steve in particular replied with statement ‘There’s a big different between “semi” native and native’. On this I disagree, regarding the qualification ‘big’. I do acknowledge that for interactive consumer Apps this may still (and likely remains to) hold, as those may need the local computer power and platform-local capabilities. Games are a good example that really benefit from direct access to the local resources and computing power. But I personally doubt that platform-native capabilities add considerable extra value for business / enterprise Apps.
As a true architect, I made a Pro/Contra enlistment for Fiori-native and Fiori Web-based:
Fiori-native

ProAbility to use device-local capabilities (e.g. geolocation, camera, local storage)
 Rich UI
 Consistent UI for the specific device-platform
 Optimal local performance (power)
 Fast graphics
 Push-notification supported
 Possible to run / continue in background
 Data-integration possible with other local Apps
 
ConNeed to build + support per device-platform
 Mobile-Only
 Version-upgrades must be explicit brought to each individual end-user device
 Requires SAP HCP
 
Fiori web-based (SAPUI5/openUI5)

ProOne version usable on all device-platforms
 Mobile-First / Mobile + non-Mobile
 Easy deployment: Version upgrades only on central webapplication level, transparent to end-user devices
 Via Fiori Client or Kapsel: possible to act as semi-native App, direct user-launchable from the device
 Via SAPUI5 and other frameworks (jQuery), possible to use device-local capabilities (GPS, Camera)
 
ConFunctionality limited to common denominator across the platforms
 UI is not on-par with the device-specific experience (e.g. Fiori UI differs considerable from iOS native UI)
 Push-notification is complex (and requires Fiori Client or Kapsel [Hybrid App]
 Local file storage not available (although from security perspective, this is not per se a disadvantage for business / enterprise Apps. Dependent on the business App, it may be prohibited to locally store sensitive / business-critical data)
 Not possible to run in background
 Less performant due browser javascript engine + interpreted rendering
Based on these (and more) pros/contras, individual companies/architects can decide whether to go for web-based SAP Fiori or platform-native Fiori. Noticable especially is the HCP dependency in case of Fiori-native. Implication is that companies that are no subscriber [yet] of SAP HCP, cannot go the Fiori-native path. But they can expose their on-premisse SAP Business Suite(s) via web-based/SAPUI5 Fiori Apps.

No comments:

Post a Comment