Supporting Android in the enterprise is no longer optional, it is necessary. With Android holding on to a solid majority of global smartphone market share, it’s high time enterprise IT managers started integrating Android into their mobile strategy.

Enterprise mobility is constantly changing, and the recent rise of trends like BYOD are broadening the idea of what it means to be a mobile-savvy organization. Big businesses no longer have the option to pick and choose how they will engage mobile, and that especially applies to Android.

“Mobility is about putting data and computing in the hands of your employees so that they can use the technologies of their choice to better do their work,” said Ojas Rege, VP of strategy for MobileIron. “An organization will have to support Android in order to get the maximum benefit from their mobility strategy.”

Android, just like other major operating systems, has its fair share of advantages and disadvantages. However, there are steps you can take to make an Android deployment a little easier.

Here are some considerations to make when planning an Android deployment within your organization.

Taking first steps

All successful deployments begin with a well-thought-out plan of execution. Begin by listing your goals for the deployment and what steps you think you’ll need to get there.

Mitch Black, president of MOBI, said that planning is paramount to the process when you are dealing with a large organization. Keep in mind that every step you denote will likely have to be repeated tens, hundreds, or even thousands of times, depending on how many users you have.

Next, you need to be sure your infrastructure can handle the additional support of Android apps and devices. One of the biggest barriers to Android in the enterprise is the supposed security risk it brings, so addressing security should be a high priority.

“The security model of each operating system is also different, so IT needs to understand the Android data and connectivity architecture in order to establish data security guidelines and select the appropriate management tools,” Rege said.

There are many third-party security options, such as Samsung Knox or startups like Bluebox, if you want to further secure the Android devices on your network. Also, be sure to study up on the new security features that are being rolled out for Android 5.0 Lollipop, especially the new Android for Work initiative.

Once you have developed an approach to Android security, the next piece of of the puzzle is building out a support team. According to Black, deployments can quickly bring you a mountain of questions, and “support is critical before, during, and after deployment.”

A big part of that support is deciding what Android devices you will support. Android offers more choices than other systems, but it comes at the cost of fragmentation in terms of device, model, and OS version. It’s up to your IT team to determine how broad support will reach, according to Rege.

Managing the complexity that comes with the constantly changing mobile environment is difficult for every OS, but especially so for Android. Rege recommends assigning someone in IT to act as the dedicated “Android Guru,” the person who will seek out and test new products and features as they come out. She or he will test new features and devices and pass along what they learn to the rest of IT.

Another thing to consider, according to Forrester analyst Michael Facemire, is analytics. You need analytics to measure the effectiveness of deployment iterations, so that you can better understand what works along the way.

Shipping an app

In many instances, supporting Android devices also means making proprietary enterprise apps available for Android users. What’s true about Android devices is true of the apps themselves, it all comes down to user experience.

“User experience is the litmus test for adoption in mobile — if the app or set of services you deploy to your employees don’t offer an easy, intuitive, and consumer-grade user experience, adoption stalls,” Rege said.

In addition to easing adoption through a quality user experience, you have to maintain focus on data security when you’re building the app as well.

When you set out to build the app, research the different components that make building an Android app different from an app on another operating system.

For example, Facemire said, if you’re going to be doing more than one app for a given company, be aware of the reusable UI components that Android calls “fragments.” There will be reusable parts like login panels, so build them in a way that they can be reused for multiple apps.

Writing the code is step one, Facemire said, but ensuring that code works across multiple devices in multiple network conditions are things that need to be considered.

“The biggest thing is going to be your QA, how do you ensure quality before you go out the door, because of the number and type and nature of Android devices,” Facemire said.

The fragmentation associated with the Android ecosystem means that app testing will be complicated. How complicated depends on what devices you choose to support.

One of the final considerations to make is where you will distribute your app. There are enterprise app stores available, and Facemire said that they offer distinct advantages over deployments through the public Google Play store.

By employing an enterprise app store, you can allow your company devices to only be able to download apps from that enterprise app store. Also, you can give permissions to certain roles or departments to download certain apps.

According to Facemire, this gives you an additional layer of analytics to determine what apps your top-performers in a specific role are using, and how they are using it.

What do you think?

We want to know. What are other best practices when deploying Android devices and applications?