3 common pitfalls when developing Enterprise Mobile Apps

Your rating: None (2 votes)

This has been said and heard over many times but I thought it will be good to reiterate since many enterprises will dive into creating their first mobile App and my goal is for them to avoid these pitfalls

1) Taking over 6 months from start to deploying the mobile App's first version: Everyone is very comfortable with traditional water flow implementation approach where you take 2 to 3 months to gather requirements and then go into design and build phases. You even extend the timeline to accommodate all the requirements. However this model is lethal for several reasons. First, mobile space is fast growing space where the OS sees a major version upgrade 3 to 4 minor upgrades every year. Second, you have plethora of new devices and accessories coming in everyday and current model become absolute in less than 2 years. So if your App is somewhat dependent on a particular device type then the device may become absolute even before you deploy the first version. At times, device compatibility becomes an issue if your App utilizes accessories to work
Solution: Take the traditional development approach and reverse it. Identify 1 to 2 must have requirements and reverse engineer the timeline. Identify and develop foundational elements such as logins, navigation, UI design items and create a template so that new view controllers and additional page can be easily developed later. Deploy that 1 functionality to the end users and get their feedback. 1st deployment should be within 10-12 weeks and after the first deployment go into 3-4 week update cycle where incremental functionality is introduced

2) Connecting the mobile App to existing backend systems sitting inside corporate data center: I have seen this scenario many times. The requirement goes like this...You have a desktop application that is connected to your On premise backend system such as SAP or Oracle or even mainframe. Now the requirement is to develop a mobile App that uses the integration web services to send and receive data directly to the backend system. The App is developed in xcode by instantiating the web service directly to send and receive data. In theory everything should work great because users can use either mobile App or desktop to access the backend system data and update them at the same time. However it screws up the user experience because the integration to the web service is not optimized for mobile traffic.
There are huge differences between how a desktop application sends data and mobile device send the data. In desktop application,
○ Bandwidth is not an issue so the payload size (actual data size) is always big.
○ Mostly they are request/reply interfaces where the data is sent and it waits for confirmation before "Success/failure" status is returned and the connection is closed
○ There are minimum of 2 to 3 hops before the data is handed off (it may hit gateway, application server and then the database)
Now this is opposite for mobile App… Mobile App requires small payload, multi-threaded, reduced connection time, and least no. of hops
When user open the App it takes at least 30 sec to get to the main screen because it is getting all the data in a single thread. During updates the user sees the loading spinner for more than 30 sec because it is waiting for the backend system to provide confirmation before the App can let the user go. Imagine a user trying to use the App while not on Wi-fi but with their wireless network. That might be the last time the user will ever use the App...
Solution: Do not connect your mobile App directly to your backend system but introduce a staging area where the data can be stored and retrieved by the App. The staging area can be even housed within a cloud provider outside of corporate network as long as there is VPN connectivity to the corporate network. This provides great user experience when the user opens the App and within seconds all the data is already loaded. Use background App refresh to preload the data where applicable. When saving the record, the data updates goes into this staging and then the sync occurs between staging and the backend system. The App will be really fast and the end users will love it.

3) Using existing business process with mobile App rather than creating a new one: it is hard to manage change and expensive to change the existing tried and tested business process. When creating mobile App the same business process is extended rather than changing it or introducing a new one. It is totally wrong if the goal is to create a mini me version of desktop so that the users can use mobile device.
Solution: Take advantage of new assets on the mobile device such as Camera, GPS, Bluetooth and add change time consuming business process. In this article American Airlines CIO talks consumerization, the CIO talks about how baggage mishandling was reduced by 65% by scanning the bags.

Overall, I think there is a lot of disruption to be made with enterprise mobility if the right solution is developed and implemented the way the employees can use them effectively. As always feel free to correct me and add your comments.

Share your ideas

jamesmartin057's picture

3 Basic Pitfalls

Your rating: None

These are basic guidelines of every web applications development company.

Top
webdesignvalley's picture

There will be a case to work

Your rating: None

There will be a case to work out from these development of website. and simile way.

Mike @ best wordpress themes 2015

Top

Recent Activity