- A TechNote on Wireless and Mobility
- Joanie M. Wexler
- Technology Analyst/Editor
- Editorial Director, TechNotes
What's the big deal about managing mobile applications? Can't IT just take the same approach it uses for managing desktop software when deploying, updating and securing apps on wireless smartphones and tablets?
Not entirely. Mobile environments present some unique challenges that call for new types of tools. For example, the uptick in the number of users choosing their own wireless devices has led to a lack of uniformity across mobile operating systems accessing the enterprise network. This means that, unlike in the PC era, IT must keep up with software versions and patches for several different platforms. But how?
As you've likely heard, there are emerging automated mobile tools to deal with the complexity of this situation. Most are policy-based and fall under the closely related categories of mobile device management (MDM), mobile application management (MAM) and enterprise app store (EAS) solutions.
These tools are key. But it also helps to know about some common mistakes to avoid as you deploy them.
Dodging the 'Don'ts'
There's a learning curve to using MDM, MAM and EAS tools successfully. Compiled with some assistance from wireless consultancy Core Competence and MDM and expense management company Tangoe, the list below suggests several pitfalls to avoid:
1. Don't overlook each app's system requirements on different devices. Be sure the mobile app you are deploying will peacefully coexist with mobile apps already installed. This involves making sure you account for the OS version, memory constraints and all other system resource requirements before deployment. Despite the inconsistent nature of mobile platforms in use, multiplatform MDM client software installed on employee devices (as well as some mobile OSs) will report memory and storage statistics to your MDM server. Use this data to make the necessary system resource checks before rolling out software to each device.
2. Don't assume that tools and OSs work the same way in mobile environments as they do on the desktop. For example, when you push out a mobile software update, you can't take for granted that the newer version will simply overwrite the older version. Some platforms require that you remove the older version before installing the newer one. Also note that some mobile OSs, such as Apple iOS and Google Android, operate in more of an "app pull" than an "app push" model, requiring some level of user involvement to allow an app's installation.
3. Don't disregard a mobile device's network status. If you are delivering new or updated application software to devices over the air, it's probably not very thrifty to do so when devices are in roaming mode. Roaming occurs when users are outside their primary carrier's network coverage area and are automatically switched onto the network of one of the carrier's partners. Roaming incurs carrier-to-carrier settlement and usage charges, which can be shockingly hefty when employees travel abroad. It's best to push the software out via an approved Wi-Fi access point (for cost, security and capacity reasons) or to an otherwise local device on a flat-rate or pooled data plan.
4. Don't forget to verify app installation. Some updates might fail because a user has his device turned off, for example. Provide a retry/error resolution process for those that do fail.
5. Don't forget to audit installed apps for non-compliance with your internal or governance-mandated best practices and provide a process for bringing them into compliance.
6. Don't rely on users to configure apps. Instead, automate the distribution of settings and licenses as well as software and updates.
7. Don't depend on public/consumer app stores for custom app distribution. If you build an internal enterprise app that connects to the back-end systems behind your firewall, you probably don't want to put it in a consumer app store, if only for security reasons. Also, IT usually can't distribute public apps the same way it distributes enterprise apps because of mobile OS limitations and vendor rules surrounding app distribution and licensing.
8. Don't assume your MDM system supports all your platforms. Not all MDM systems support all mobile OSs, so it's important to check that the system you select supports the platforms in your environment. Employees bringing their own devices makes this difficult, but it's still a good idea to identify what you can and cannot support.
Not entirely. Mobile environments present some unique challenges that call for new types of tools. For example, the uptick in the number of users choosing their own wireless devices has led to a lack of uniformity across mobile operating systems accessing the enterprise network. This means that, unlike in the PC era, IT must keep up with software versions and patches for several different platforms. But how?
As you've likely heard, there are emerging automated mobile tools to deal with the complexity of this situation. Most are policy-based and fall under the closely related categories of mobile device management (MDM), mobile application management (MAM) and enterprise app store (EAS) solutions.
These tools are key. But it also helps to know about some common mistakes to avoid as you deploy them.Dodging the 'Don'ts'
There's a learning curve to using MDM, MAM and EAS tools successfully. Compiled with some assistance from wireless consultancy Core Competence and MDM and expense management company Tangoe, the list below suggests several pitfalls to avoid:
1. Don't overlook each app's system requirements on different devices. Be sure the mobile app you are deploying will peacefully coexist with mobile apps already installed. This involves making sure you account for the OS version, memory constraints and all other system resource requirements before deployment. Despite the inconsistent nature of mobile platforms in use, multiplatform MDM client software installed on employee devices (as well as some mobile OSs) will report memory and storage statistics to your MDM server. Use this data to make the necessary system resource checks before rolling out software to each device.
2. Don't assume that tools and OSs work the same way in mobile environments as they do on the desktop. For example, when you push out a mobile software update, you can't take for granted that the newer version will simply overwrite the older version. Some platforms require that you remove the older version before installing the newer one. Also note that some mobile OSs, such as Apple iOS and Google Android, operate in more of an "app pull" than an "app push" model, requiring some level of user involvement to allow an app's installation.
3. Don't disregard a mobile device's network status. If you are delivering new or updated application software to devices over the air, it's probably not very thrifty to do so when devices are in roaming mode. Roaming occurs when users are outside their primary carrier's network coverage area and are automatically switched onto the network of one of the carrier's partners. Roaming incurs carrier-to-carrier settlement and usage charges, which can be shockingly hefty when employees travel abroad. It's best to push the software out via an approved Wi-Fi access point (for cost, security and capacity reasons) or to an otherwise local device on a flat-rate or pooled data plan.
4. Don't forget to verify app installation. Some updates might fail because a user has his device turned off, for example. Provide a retry/error resolution process for those that do fail.
5. Don't forget to audit installed apps for non-compliance with your internal or governance-mandated best practices and provide a process for bringing them into compliance.
6. Don't rely on users to configure apps. Instead, automate the distribution of settings and licenses as well as software and updates.
7. Don't depend on public/consumer app stores for custom app distribution. If you build an internal enterprise app that connects to the back-end systems behind your firewall, you probably don't want to put it in a consumer app store, if only for security reasons. Also, IT usually can't distribute public apps the same way it distributes enterprise apps because of mobile OS limitations and vendor rules surrounding app distribution and licensing.
8. Don't assume your MDM system supports all your platforms. Not all MDM systems support all mobile OSs, so it's important to check that the system you select supports the platforms in your environment. Employees bringing their own devices makes this difficult, but it's still a good idea to identify what you can and cannot support.
Joanie,
Good points for mobile business communications. However, what is still missing is the flexibility for choosing the appropriate use interface for a multimodal smartphone or tablet. This would depend upon the individual end user's particular circumstances, e.g., driving a card, sitting in a meeting, in a noisy or public environment, etc.
While a user can simply manually set their "status" to identify their environment, it would be nice if it could be more automated.