Developing a Mobile App Strategy

The use of apps in the enterprise involves more than just downloading the "right" app for the "right" job, which is why developing a mobile app strategy is so important.

Craig Mathias

October 7, 2018

4 Min Read
Mobile apps

With the proliferation of smartphones in the enterprise has come a proliferation of mobile apps. As most users--and companies--can attest, some apps are better than others. Some apps are also more secure than others. Developing a mobile app strategy is therefore key to making the best, safest use of mobile apps.   

Ever since Apple opened the iPhone to third-party development a decade ago, an entire industry has grown to meet the demand for apps of every mission, both business and consumer. When it comes to adding value, it's not all about the apps themselves; rather, it's about the data those apps access, transform and manage. To most effectively make use of that data, companies must have a solid mobile app strategy.

In this mobile-first business environment, organizations must determine, for example, what data is needed by what individuals and/or groups and under what circumstances (location, device, time of day, and so on). They must also figure out what security and integrity measures are required. This means that BYOD, acceptable use and security policies must be in place before any thought is given to which apps to use in any given case. App strategy follows overall IT strategy, not the other way around.

There are three key decisions essential to developing a mobile app strategy:

1. Make vs. buy: It's become cliche, but typically there is an app for that--even when "that" is a business need. Indeed, it’s tempting to use third-party apps to quickly fill a business need (with or without IT's knowledge). The problem is that it can be difficult to tell if any given app contains bugs or even malware that might result in compromise to sensitive data; instability or outright failure; or added management and support costs. It’s vital, then, to verify the functionality of any app intended for production use well in advance of general deployment. It's also important to check for any new releases of apps. Enterprise apps stores can come in quite handy here.

But in some cases it will still be advisable to build custom apps intended for customers or (sometimes; see below) for use only within the organization. The same provisos apply here – test, test, test, and verify. Note also that software development, a labor-intensive activity, after all, remains an expensive undertaking, so be sure to do a risk, opportunity-cost, and ROI analysis before committing to any internal (or subcontracted) custom software development project.

2. Apps vs. web services: It’s often possible to implement a desired service for a mobile audience that’s written in HTML and thus runs within a mobile browser. Development costs should be lower with this alternative; that’s the primary attraction, along with faster time-to-solution. While it’s important to test with all approved browsers (and not every browser available will be approved, given the support costs involved with each), we generally recommend a simple rule of thumb here: If the app is customer-facing, it should be a standalone app so as to completely control the customer experience. If it’s just for internal use, a browser-based implementation should be fine.

3. Native, carrier or third-party apps: Every smartphone comes with a set of apps for phone calls, messages, calendars, contacts and more. These functions may be linked to services from the smartphone vendor, the designated wireless carrier, a third-party service or other source. Apps with similar functionality are often also available from third parties, aimed at individuals, groups and/or organizations. Choosing the right combination of apps from the right combination of providers can be confusing, and the frequent lack of interoperability among various services can leave your teams unable to communicate. It’s therefore vital to set requirements for the communications apps and services within a given organization--in whole or in part--and to specify any limitations on specific selections in policy. Regular reinforcement is usually desirable, given requirements for organizational record keeping and meeting any applicable regulations and laws. Note that the latter two can vary from locale to locale, so consult your legal team before a final policy, app or service selection is finalized.

It's clear that the use of apps in the enterprise is much more than just downloading from an app store and firing it up. IT organizations clearly have some work to do here.

About the Author(s)

Craig Mathias

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like