Over the past year VCG has been engaged in three main Enterprise Mobile Development App projects. These span industries from educational technology to precision agriculture to behavioral health. And while they are in very different industries, they all have several project aspects in common. Each Enterprise Mobile Development project has a hybrid team with some client team members. It also has some VCG local and remote team members. We are constantly managing a distributed team dynamic within our projects. Most of our Enterprise Mobile Development projects are 2,000 – 10,000 hours of work, so they are decent sized projects. Most Enterprise Mobile Development Projects have a mobile app component as well as a web service component to them. And, most of our projects are releasing mobile apps on Android and iOS so we’re managing a multi-platform release.
We’ve sat down and tried to distill some of the same effort that overlap most Enterprise Mobile Development App Projects. We also considered some of the pitfalls to avoid. So here are the 12 things to always consider with a mobile application development project:
Enterprise Mobile Development
Web Services – What are the set of web services the mobile app will consume?
It’s important to plan and model the exact web services the mobile app will consume before developing. Before overlapping the Enterprise Mobile Development of the web services and the mobile app, you need to consider one thing. You need to design and spell out the web service method signatures and the exact function calls with parameters beforehand. This will save on re-work later, almost guaranteed. This type of re-factoring is expensive because it touches all layers within the application.
We saw this important factor in one of our last projects. During the project, the client was responsible for the web services and VCG was responsible for the Enterprise Mobile Development. The web services layer supported several web apps and now the upcoming mobile app. Unfortunately, not enough detailed planning was done and assumptions were made on both sides.
The client product manager and the client technical lead made assumptions on which set of services were to be used. And we all know what assumptions can lead to. We had to do a lot of re-work and re-factoring. This was needed since the web services weren’t fully thought through regarding the differences of the app’s need. We also collectively failed to plan all the way to an object model or class diagram. There are times when you have a distributed development team. Such teams have certain groups responsible for certain aspects of the application architecture. In such case, it’s critical to plan more detail down to a class or database diagram. That way it’s clear where exactly the hand-off is.
Security Model – Where and what do you need of encryption, authenticate and authorization?
In the past year, we had 3 very different enterprise mobile application development projects, each needing a customized security model. For the precision ag client, we needed authentication to support profiles and accounts. We also needed authorization to present different features based on a user type. Encryption was not needed however. We did need to bring in a standardized security model, like oAuth. It had not been a part of the legacy application. With the behavioral health project, we needed to build a HIPAA-compliant mobile app. That meant we had to build in encryption, both across the wire and storing the data locally on the mobile app. We also needed two authentication procedures. We needed one authentication to allow patient data to only show to specific authenticated accounts. We needed another to display different functionality and datasets based on the user type.
Synchronous or Asynchronous – Does your application build in asynchronous data calls to solve availability issues and/or improve user experience?
In each of the three of our latest projects we really had to consider user experience and data flow in the application architecture. It was important for our users to be able to have occasionally-connected computing and for the application to work without the requirement of an Internet connection for Enterprise Mobile Development projects. Also in our precision ag project, there were several connections to third-party APIs and we wanted our application availability to not be dependent on those APIs for synchronous data calls. For building application robustness, we recommend looking at various ways you can have asynchronous calls that are syncing local and central databases to provide optimum user experience and application availability.
Mobile Device Configuration: Auto-lock & Time-outs – What are the various cases for each mobile device?
There are several issues to think through regarding the mobile device configuration. All mobile apps have certain ways they handle time-out and away times that lock the screens. Android and iOS handle each of these slightly differently, as well. There’s a distinction between auto-locking the screen, a user’s time-out based on non-activity and a configured time-out after so many minutes. There can be different events to manage and trap within the mobile app, so it’s important to think about all the device configurations during planning. It’s important to think about where in each section of the application there could be configurations or timeouts that would interrupt the application flow. We recommend you consider each mobile device and the different app usage for timeout and screen auto-lock as well as time-out length for session.
Web Server Configuration & Tokens – What are the session time-out and security token configurations, if any?
There are several web service configurations to consider as well. Most web servers have a session time-out configuration along with other authentication configurations, like tokens, that can affect user experience. If a web server is set to time-out after 30 minutes or if a security token drops after 30 minutes, how does your mobile application behave? What if one of those configurations are set and the user times out on a session? We found in our experience across all 3 of the latest mobile apps, that we needed to design for elegantly handling discontinuous user flow. How does your application handle that? It’s important to design the application to handle these use cases elegantly.
Version Control Management – How do you handle version control in the mobile app and web services?
It’s important to set up version control management inside the architecture of the web services, so you can have a smooth upgrade path for each new release. Old interfaces can/will be supported, but new app versions will consume the new web services. With web services, it’s important to be able to distinctly and discreetly manage each version that exists in the production environment. Therefore, it’s important to think about version control and how you will handle various versions in production. We recommend that you design a version control scheme that allows exposing versions within your web services layer. This will enable the current version and the previous version to be supported continuously without service interruption. This may mean building a custom web service version control system that’s outside the simple mobile app release model.
App Stores Release Processes – How do you handle that stores have different release criteria?
The Release Manager will have to deal with the fact that the Google Play store and the Apple store have different review and release policies. This means new versions of the app will come to production at potentially different times through each store. The Google play and Apple iTunes stores play differently. Each of them have different creative and process control for releasing your app to production. There are two levels within apples iTunes store. One is the first time you deploy an app and they have a more rigorous testing platform.
Then the incremental updates have a less stringent mechanism. The initial Apple iTunes release can take up to a week whereas the updates to Apple can take 2 to 3 days. This is different from Google Play where criteria is much less strict. The Google Play Store typically takes one day to release. So if you’re releasing multi-platform mobile application, it will be important to consider these release differentials. We recommend that you deploy to Apple and have it released through Apple iTunes first and then release your Google Play application. This will have the most current versions be more consistent across both platforms. This will also have you avoid the issue if Google releases your app, but there’s a blocking issue during the more-strict Apple review process.
Safely Store Your Certificate/Key Files – Did you save your key and certificate file in a safe place?
Make sure to keep your key/certificate/APK file stored and saved in Git or your code repository. Each of the android and Apple iOS platforms have developer certificates and keys that are important to keep during the development and support phase of an application. These keys allow developer authentication so the stores know a particular app is being updated by a correct and verified party. Do not lose these certificate key files because there’s no way to get one reissued. Clients can run into issues if they lose those developer certificate key files so it’s important to save those in your standard repository like Git. Otherwise you will have to deploy basically a new app within the construct of the store and that may not have a continuous user experience for your user base.
User Data, Syncing & Upgrades – Have you thought through all the use cases of user data and app upgrading?
If you have Syncing of data, work out all the potential issues with users upgrading versions. You need to sync data before any upgrade can occur. In many cases, you’ll have to handle the upgrade slightly differently than the standard store version update function. Some applications require you to have a local data set that then is synced with the central database. If you have this type of application architecture it will be important to fully think through the upgrade cycle.
One use case is if an application has a new version but a user has not saved or sync’d all of his local data to the central database, you can run into issues. It’s important to fully think through how data is not lost and how data will be synced before an upgraded version of the application commences. There are several priorities to think about but this is an important aspect to plan through prior to developing.
Time-out Issues – Does your app elegantly handle any time-out issues?
All timeout issues from a User’s device need to be elegantly handled within the application. Don’t have user lose data or have syncing issues due to timeout on the device. This can come from web session timeout and/or device lock. It is important to design your application to elegantly handle any discontinuity due to a time-out. So if a time out occurs how have you designed your application to smoothly handle either data or logging in. So, this is the complete information about Enterprise Mobile Development Projects.
One of the worst user experiences can be a user filling out several forms within a mobile application and then walking away for period of time and then coming back having either a timeout from the device or a web service session timeout and then somehow losing all of their work. It’s important to design the application to handle any discontinuous user flow.
Consistent Data Accuracy – Do you handle synchronized data across your environment?
Sometimes Enterprise Mobile Development there can be data state-full-ness to manage within an application, especially if you’re syncing various data stores. There are always going to be unforeseen, unthinkable issues with data integration between the web and mobile versions of the app. They are both updating key data and there are always use cases to work out. If you have web services that are supporting web apps and other applications it’s important to think whether or how each application will affect one another. In one of our projects we found it was important to expose a separate set of web services for the mobile application for various project priorities and requirements, but that would have left the mobile application and the web application out of sync.
Production Release Checklist – Did you create a checklist to follow for promoting to Production Release?
We found in all of our projects that it’s important to document configuration management. We recommend that each of the Enterprise Mobile Development project processes are defined in the form of a bullet list or a checklist. We found that a production release checklist allows us the best way to produce consistent production release results. Without a checklist and a release manager following and filling out a checklist for each production release we found there are potential for error. So we always recommend a management team write the release process checklist. and a release manager follow the checklist and sign off on each production release.
This list represents some of the planning and thinking. that’s required when developing enterprise mobile apps. Planning up front will save you a lot of developing time in re-factoring and re-work. Thinking out all the use cases and designing the application to handle the various cases will lead to higher team productivity, better project velocity, faster development time overall and a better user experience.