SAP announced its cloud strategy in
2012. Since then, several thousand customers have moved some or all their solutions to the cloud. SAP Mobile Services was one of the first services available.
Let’s have a look how productive mobile solutions can be moved from the on premise to the cloud. There are several options and opportunities. . The idea of this blog is to give you the insides and the clear picture what the options are and what the efforts are.
Option 1 Lift and Shift Mobile Apps
Execution:
- Server:
- Move all mobile app configuration from SAP Mobile Platform to SAP Mobile Services.
- Apps:
- Adapt the code of all deployed mobile apps to point at SAP Mobile Services
- Adapt the authentication to work with the SAP Mobile Services
Efforts:
The efforts which have to planned in are pretty low on the Server and on the App side.
Pro:
The efforts which have to planned in are pretty low. Risk of migration are also low. The user won’t have to adapt as the app behaves the same.
Con:
Since the Apps are using the old SDKs, they are built using old technology and programming models.
Maintenance cost for those apps will be high as the technology stack is outdated (iOS is using objective C, Hybrid is using Cordova …). Adding new features will become more and more expensive and, at a certain point, not even possible. The stability and performance of the Apps build with the old SAP Mobile Platform SDK will suffer as all development is focused on the
new Cloud Mobile SDKs.
Option 2 Migrate Model Layer in Mobile Apps (Native Android and iOS Apps)
Execution:
- Server:
- Move all mobile app configuration from SAP Mobile Platform to SAP Mobile Services.
- Apps:
- Android:
- Generate a new base application with the SAP SDK Wizard for Android.
- Bring the existing business logic and UI classes into the new Project.
- Rewire the existing controllers to the new generated model.
- iOS:
- Generate a new base application with the SAP SDK for iOS Assistant.
- Bring the existing business logic and UI classes into the new Project.
- Rewire the existing controllers to the new generated model.
Efforts:
The efforts for the Apps will depend on how big the apps are and how complex the model is. This has successfully been done though by some customers for simple Apps.
Pro:
The big advantage is that the Apps are now based on the new SDKs so they have full support. Cost of maintaining those apps will be low as they are on the latest technology and support all
runtime features of SAP Mobile Services like crash reporting. The user won’t really have to adapt as the app behaves the same.
Con:
Rewiring an existing UI to a new model is not simple. Especially if the programming language changed (objective C to Swift and java to Kotlin). There are limitations to what can be reused in the real world. The Risk increases with the age of the App and the complexity of the model and the UI.
Option 3 Rebuild the Mobile Apps
Execution:
- Server:
- Move all mobile app configuration from SAP Mobile Platform to SAP Mobile Services.
- Apps:
- Reevaluate all mobile apps what is the core function the app have and who is using it
- Make a decision which of the Cloud Mobile SDKs (see below) fits best for the user and use case
- Get SAP Mobile Experts to rebuild the Apps
Efforts:
The efforts for rebuilding the Apps depends again on the complexity of the App. From my experience most mobile apps are 3 to 8 screen apps. An app with a few screens can be built relatively fast with our Cloud Mobile SDKs. The SAP
Cloud Mobile SDKs are generating the sync layer completely and have a lot of features and tools to accelerate the development. We have customers who have rebuilt Apps and gone productive in less than a month. Please talk to SAP Consulting or other mobile experts who have experience with our tool chain, to get a real quote on those efforts.
Pro:
The big advantage is that the Apps are now based on the
new SDKs so they have full support. Cost of maintaining those apps will be low as they are on the latest technology and support all
runtime features of SAP Mobile Services like crash reporting.
Con:
There will be impact on the users as the Apps might completely look and feel different (modern). There will be Cost which will depend on the Apps and the expertise of the implementation team.
Summary:
In my opinion Enterprises should always look at the cost of running a mobile solution for several years.
The issue I encounter often is that implementation teams offer the cheapest solution to build a mobile App. Teams which operate the solution then are stuck to handle high cost of debugging, fixing … .
Hence, I enterprises to consider Option 3. And only use Option 1 or Option 2 where the expected life time of the App is short (meaning the app will be replaced in near future anyway).
PS:
Option 3 is also the recommendation if you already built your mobile app using SAP Mobile Platform SDK and you are looking to modernize it.
