Three major misconceptions of SAP Enterprise Mobility
Working as the CTO of Neptune Software for the last three and a half years, I have spent most of my time working with SAP mobility and User Experience, meeting and discussing with customers and helping in mobile SAP implementations all over the world. This post will look at the three major misconceptions I have observed that in my opinion dooms your mobility project.
1 – Responsive Web Design is sufficient for Enterprise Mobility
With the emergence of HTML5 and great frameworks like SAPUI5, it is possible to create responsive web pages enhanced for viewing on mobile devices and even optimized for touch events. It is tempting to view mobile web apps as the most cost efficient and best option to roll out mobility in an organization.
Unfortunately this solution is ill suited for any serious mobility project and more so in an enterprise setting. I see more and more of the SAP community considering mobility as inherent in all other topics, which is good, but I am afraid that projects downplay mobility into adding some responsive UI5 or Fiori screens. Seeing how few pure mobile sessions there were in last year TechEd && d-code and Sapphire illustrates in my opinion a dangerous trend.
User experience, authentication, security, offline capabilities (For larger amounts of data), application distribution and access to native device features are the most prominent of the reasons why web apps is not a valid option for any serious Enterprise mobility strategy. Apps dominate mobile internet usage and consumers move away from the mobile browser, as can be seen in this publication from Flurry Analytics:
You do not use Facebook, Twitter and LinkedIn in a browser on your mobile device so you should not expect your users to feel differently about your enterprise applications.
Hybrid is definitely the way to go. You get both the advantages of native capabilities and responsive cross-platform development. Today you have several options to achieve this. I recommend looking into Cordova/Phonegap that can be utilized in SAP projects using NAM from Neptune (I am working in this company) or read up on John Wargo ‘s blogs regarding Kapsel and hybrid development with the Web IDE.
In addition to Hybrid Apps, you need to look at how to distribute these and secure them in a user-friendly manner. Neptune has support for this but there are many options and combinations of these on the market. You can look at the SAP Mobile Secure solution, SMP (HCPMS for Cloud Version), AirWatch (WMWare), XenApp (Citrix), Mocana, Apperian and others. The trend is moving from Mobile Device Management to Mobile Application Management (Blame BYOD) and remember that security should not impact usability too severely as this will drastically reduce user adoption.
Implementing a proper mobile solution is not as difficult or costly as many customers I have met seem to believe.
2 – Use “Vanilla” apps
Customers often want a “standard” app, at least before they start implementation. I am a strong believer in adapting software to fit the individual customer. Customization and enhancement possibilities is what has made SAP great. Customizing, for instance, logistics using SAP results in major competitive advantages.
Traditionally we have been stuck with a static user interface in SAP solutions and this has been a major pain point. It is bad on a desktop but useless on a small mobile screen. The first productivity apps from SUP had this issue and I vividly remember a consultant being asked to leave a meeting some years ago after suggesting that the customer should remove WBS from their cost assignment to fit the Time Recording app.
Today we have the opportunity to create great and customized SAP UX for individual customers. We can for the first time in SAP’s history focus on the end-user regarding UI and use modern development strategies (lean, agile and iterative) to create applications that fit them perfectly.
Use design thinking, include real end-users (Super users tend to be afraid of losing functionality and clutter the app with loads of elements). Test in production with a small but relevant pilot group with iterations improving the app (With a small monitored user group you can always fix postings in the backend, and once you roll out on a large scale you have one shot, so do it right )
This is the reason we refer to our premade Neptune applications as templates. Our customers consume these, then change and transform the templates into killer apps.
One size does not fit all unless you mobilize your SAP GUI screens and you don’t want an app like this:
3 – Base your Enterprise Mobility implementations on an API first approach.
The API first approach is gaining momentum. Theorists (I’ll pay for this 😉 ) claim that it boosts development productivity and helps create multi-platform applications more easily. A few years ago, we had the same hype around the ESR (Enterprise Service Repository) and SOAP was the solution for all integration and external exposing of backend data (I returned to good old custom IDOC’s after a short time). Well it was not. Our PI systems crashed and debug was hell. Why? The services were created for certain scenarios and often complex and not optimized for large volumes. Today we look at oData through GW services, often with nested structures demanding complex client-side logic and low performance. Performance is vital in a mobile scenario.
Therefore, it is better in my experience, to create your backend access in parallel with client functionality – Consumer first approach. This will ensure that you only fetch and send the data you need in each request. This (And superior offline capabilities) has been the main reason we use native JSON bound to element attributes in the Neptune Application Designer and not taken the GW path, even though external pressure has been big.
Great post Njål!
I especially lilke the "Use design thinking, include real end-users" advice and the neat way how you underly your points with the design decisions you took with Neptune - nothing better than real live experiences... (+ you manage to fly just below the marketing bla bla 😉 barrier)
Tried to keep away from the sales pitch (Which is difficult as a founder). Oh, and I still remember our Whiskey tasting with a remote Thorsten Franz after SITNL as a highlight session in 2013 🙂
Maybe a topic for a future SIT-talk: "Design decisions taken during Neptune development"
Would be interesting to hear why you did what you did during the development of Neptune and its different Versions + some Lessons Learned along the way 😉
Sure, that is a good idea. I am moving to the US soon so I guess I have to get Ole-Andre Haugen to attend the SIT's in Europe. (Maybe I will fly back for next years SITOSL as well 🙂 )
Thanks for sharing your insights Njål..
I was curious to know where “offline” capability ranks in company misconceptions? i.e. in your mobile experiences how often is the assumption “We don’t need offline” wrong?
Offline capabilities is definitely very important and in some scenarios vital. I used to think our world would be completely covered in regards to connectivity in the near future. But this issue is not going to be solved on a global level anytime soon so we need to take a offline-first approach when developing apps.
For example, our customers in the shipping industry have satellite connection a few times per day and field service engineers in the telecommunication industry is out fixing connectivity issues so they obviously need offline capable apps.
On the bright side, offline is not very technically challenging anymore. Here is a 60 mins video where my co-founder creates an offline sales order app
Very useful blog and personally helpful to me. Thank you very much.
Facebook and Twitter have native apps because there are competitors who will steal customers away if you don't optimize the experience to the fullest.
On the enterprise users must use your web app, there is no choice. That's why they use SAP GUI which is horrible. To me that makes using a study on general native/web app usage, where users have choice/competition, a bad match.
For B2C I believe native apps are the only real choice, but for enterprise apps HTML is good enough, and there are huge gains in software maintenance. Personally I prefer native apps, but from a application lifecycle / TCO there is a huge gap.
I do agree with 2 and 3.
Thanks for your reply. I completely agree that native apps is way to costly to develop and maintain for enterprise scenarios.
That is why I find Hybrid apps as the best fit for enterprises (and Gartner predicts that 60% of all apps on the app stores will be Hybrid by 2016)
If you look at some of the blogs regarding horrible SAPUI5 performance, you can see that running UI5 on a mobile browser is not an option, the load time of the framework and network cost is not acceptable for customers. Use the Firoi Client, Kapsel or Neptune AppCache and you will find that your maintainability is nearly as good as on a web app and your security usability and performance is vastly improved.
I guess you missed on the MDM solution provided by SAP- known as SAP Afaria
Thanks for pointing it out.
I believe Afaria is part of the SAP Mobile Secure offering. In addition they have included SAP Mobile Place which is an enterprise store and App Wrapping from Mocana that will provide you with encryption and jailbreak/root detection.
The solution is available as a free trial and Afaria is integrated with appwapping and Mobile Place in a very neat way.