Over the years I’ve taken a keen interest in SAP’s twists and turns with its mobile strategy, and I felt it would be a good time to reflect now that SAP has announced an end date (note: The SAP author adjusted their post … the original version is here) for its on-premise mobile platform. With this announcement SAP is staking its mobile future wholly on the SAP cloud platform. If anything, I believe SAP should have moved more aggressively to position its cloud-based mobile platform offering much earlier. I blogged as such almost six years ago. In the intervening years I’ve seen many changes to SAP’s strategy.
The origins of SAP’s on-premise mobile platform lie in the acquisition of the Sybase Mobile Platform back in 2010. At that time it instantly gave SAP a leadership position. As mentioned at the time … “According to the market research experts at Gartner, Sybase is one of the leading providers in the mobile sector”. Looking back I feel SAP faced real challenges with this acquisition. SAP was pitching to customers to purchase a new development platform, whereas historically most customers purchased SAP for its off the shelf applications. Yet SAP was challenged with convincing these same customers to purchase a new development platform, one with which their iOS/Android/Windows developers could build apps on top of SAP. Back then these customers struggled to muster the right ABAP developers with modern skills in core SAP, let alone new mobile app developers with skills in different programming languages across iOS (Objective-C), Android (Java) and Windows (.Net).
In my mind this conundrum lead to several major shifts …
Firstly, SAP’s realization that selling a mobile development platform was not enough led to the subsequent acquisition of another mobile platform Syclo in 2012. Syclo came with pre-delivered apps for mobile asset management and field services functions. SAP seemed more successful with this acquisition insofar as it could sell a ‘mobile applications’ story rather than simply a ‘mobile development platform’ story. But the acquisition did confuse the mobile platform landscape, so SAP sought to address that by combining elements of the Sybase acquisition and the Syclo platform into a unified ‘SAP Mobile Platform’ product. This is the product which now ends its mainstream maintenance in Dec 2020.
A second shift by SAP was the introduction of new HTML5-based offerings in ‘Fiori apps’ leveraging SAP’s HTML5 framework SAPUI5. Whilst this wasn’t purely a mobile-only solution, it did fork in as an option for customers seeking to mobilize their SAP processes and data. This approach reduced the range of skills needed to deploy mobile applications across various mobile devices (with HTML5 you can target iOS, Android and Windows platforms with a single code base). Although even then the need for HTML5/Javascript skills was still too much for many ABAP developers, leading to the advent of third party enablers such as Neptune Software. Over time SAP also introduced its own development productivity enablers for SAPUI5 such as WebIDE and Fiori elements.
In 2014 SAP announced the first incarnation of a cloud-based mobile platform, HCPms (now SAP Cloud Platform mobile services). Back then the platform lacked maturity compared with other cloud offerings. It also added to the confusion for customers seeking to make sense of how to mobilize their SAP processes and data: Do they go with an SAP on-premise mobile platform, the cloud-based mobile platform (which didn’t support the same range of apps as the on-premise edition), an HTML5-based strategy using Fiori, or a combination of these?
Then in 2016 SAP threw another fork in the road with the announcement of a partnership with Apple introducing a Fiori for iOS SDK. This SDK only worked with the SAP cloud platform, giving us the first indication of SAP’s ‘cloud-first’ focus for mobility going forward. It also only worked for iOS devices, bringing back the spectre of customers developing in a device operating system-specific manner (eg. coding in one way for iOS, and another way for Android) which reminds me of the challenges originally faced with the Sybase acquisition. Time will tell whether this approach is successful this time around.
Probably the last change has been SAP’s partnership with Mendix to sell their rapid application development platform capability, whereby you can conceivably build apps with no or minimal (low) code. I’ve yet to deploy an app with Mendix, but I’ve used other such tools such as the excellent GoCanvas offering and absolutely see the merits of this approach for a subset of use cases.
Looking back, clearly there were too many options for customers and SAP would have been seeking to cull some of these from the list to reduce confusion and rationalize the engineering support burden. I can’t help but wonder if the constant shifts in strategy have alienated some customers and developers from blindly following each turn in SAP’s strategy. As one developer who self-funded his training in Sybase and sought to establish a presence on SAP’s app store once told me: “I’m tired of SAP constantly changing their strategy … they need to pick a direction and stick to it”.
So where does that leave us? Customers would do well to take a close look at the SAP Cloud Platform and its mobile offerings. They should also take the opportunity to look at alternatives in the market. I’ve provided input to various customers over the years with their mobile strategies and here are some of the considerations that customers would do well to consider …
Ensure you can cover a vast breadth of use cases with your choice of platform – If embarking on a mobile strategy, it shouldn’t be just an SAP team doing that, because the only scenarios that will be considered will be SAP-related. I’ve worked with customers that have tackled all sorts of non-SAP scenarios … you want to make sure your technology solution can handle those as well. The true measure of success here is how many apps you can deploy with the single platform, implementing a range of use cases, and connecting to a range of systems (not just SAP).
Ensure you can cover multiple target devices (eg. iOS + Android) with your choice of platform, and with a single code base – For enterprises, it’s not cost effective to manage different code bases for apps deployed to both iOS and Android devices. That’s evident from the lessons of the past when SAP struggled to sell the Sybase offering which demanded this multi-code approach. The common solutions to this are to follow a HTML5-based path (eg. SAPUI5), or if pursuing native-like UX and performance I’ve seen enterprises standardize on solutions such as Microsoft’s Xamarin or Facebook’s open source ReactNative technologies. These latter approaches provide the ability to code mobile apps which perform better than HTML-5 based apps, using a single language and sharing code across iOS & Android. I wouldn’t be surprised if SAP embraces this style of mobile development in future years.
Ensure you have the tools and skills to deliver the best possible user experience – Optimizing user experience often means going ‘native’ in appropriate cases with mobile apps, as well as supporting the ability of apps to function with poor or non-existent network connectivity. That ‘native’ argument was reinforced by SAP with the introduction of the Fiori for iOS initiative. It’s also why those technologies Xamarin and ReactNative (described above) are popular with enterprises and developers.
Be sure to protect yourself from indirect licensing risks – SAP has drawn much unwanted attention for legal cases relating to indirect licensing in recent times. Customers need to ensure that whatever the mobile platform solution they adopt, that they comply with appropriate licensing requirements for their underlying SAP systems.
It’s been a wild ride watching SAP’s mobile strategy unfold over time. With the impending demise of the on-premise SAP mobile platform, all of SAP’s hopes and desires will be focused on the SAP Cloud Platform. It will give SAP much more focus in its future R&D for mobile. And that’s a good thing.