Take Charge Of Your Mobile App Strategy

Most IT shops are outsourcing the actual development of mobile apps. But IT leaders still must set a clear strategy for how they'll develop, deploy, and support these apps.
InformationWeek Green - Sept. 26, 2011 InformationWeek Green
Download the entire Sept. 26, 2011 issue of InformationWeek, distributed in an all-digital format as part of our Green Initiative
(Registration required.)
We will plant a tree for each of the first 5,000 downloads.

Take Charge Of Your Mobile Apps What's the killer app for smartphones? It's a trick question--it's apps, and lots of them. Forty-three percent of cellphone users have apps on their devices, and most use them regularly, according to a May survey by the Pew Internet Project. Business technology pros surveyed for InformationWeek's 2011 Enterprise Applications Survey rank mobile applications as their highest enterprise software priority. It's no wonder most businesses are looking to leverage the explosive growth of apps to help drive marketing, sales, and customer service.

But building and deploying a quality app can be daunting. Most companies don't have deep mobile app dev skills in-house. There are multiple operating systems to develop for, and hundreds of OS-device combinations. As companies consider their mobile app development strategy, one critical decision is what type of app you'll deploy. A second critical decision is how you'll deploy those apps--link your development strategy with mobile device management.

There are three main ways to develop mobile apps:

>> Develop a native application for each platform--Android, iOS, BlackBerry, etc.

>> Buy and use a cross-platform development framework, leveraging its APIs to write code once but have your app run on multiple platforms.

>> Use a mobile enterprise application platform, which provides prebuilt, enterprise-ready apps that integrate with your existing business systems via a vendor's framework, enabling rapid deployment of apps without much development.

Let's start by looking at each development approach, as each has notable pros and cons.

Native Apps

The main reason to develop a native smartphone application is because the app needs access to specific functionality provided by the device, such as an accelerometer, camera, or GPS, and needs the benefits of integration with other native apps and local processing. How many times have you downloaded an app on your phone and the drop-down boxes or check boxes aren't working like they do with the built-in applications on the device?

While it's easy to understand the pros of a native app, there can be many more cons if you don't have on-staff developers with considerable knowledge of the mobile platforms--and what IT organization has a lot of those skills?

While the pool of developers with experience writing for smartphones and tablets is growing, most IT organizations will turn to outsiders to develop native apps. Keep in mind these factors specific to today's mobile environments.

First, make sure the vendor has experience with developing the specific type of app you want, not just experience with the operating system platform. So if you're converting a CRM application for iPads, don't work with a company that has no experience with multiple input forms and database-driven applications. The risk is that it will develop a clumsy interface.

Second, make sure the vendor shows you the user interface before it builds the app and during development, using tools such as storyboards. Once it builds the full app, make sure that its quality assurance team is using handset-simulator software to test the native app on many different mobile devices. Different screen sizes, processors, and RAM can change the way an application functions.

Third, make sure you have a service-level agreement governing how quickly the vendor will fix problems. Unless you've standardized on one device for your app, the large number of mobile platforms and devices makes the likelihood of finding an incompatibility high. App users will want a patch immediately, but your vendor might take 30 or 45 days to turn one around. Android alone supports more than 200 devices and operating system configurations, and even Apple's closely controlled iOS has many versions that need testing.

The other major con for developing native apps is security. While secure software development practices have been around for years, most mobile development groups simply aren't following processes such as the Secure Software Development Life Cycle. It isn't just small companies that can run into mobile app security problems. In the past year, Citibank, Wells Fargo, and MasterCard have each released mobile applications that stored data, including PINs and credit card numbers, insecurely on mobile devices. This type of vulnerability is well-documented within the Common Weakness Enumeration database--as CWE-312. Yet mobile development groups seem to forget that mobile apps are going to be attacked frequently, just like any other app.

Compounding the security risk is the fact that native applications are custom to their various operating systems, such as iOS and Android, which makes analyzing their security more difficult because many tools that scan for vulnerabilities don't support these new platforms.

To read the rest of the article,
Download the Sept. 26, 2011 issue of InformationWeek