AER expands: Android Enterprise Recommended for EMMs

The Android Enterprise Recommended programme, originally launched with Android handsets back in 2018 before later expanding to rugged devices and tablets, has recently once more expanded beyond devices and into EMM solutions as previously promised:

Throughout 2018, we will also be applying the Android Enterprise Recommended framework to additional partner types, including OEMs of “dedicated” and rugged devices, mobile carriers, enterprise mobility management (EMM) providers and systems integrators.

– The original AER announcement

Although a little later than the above timeline suggests, due undoubtedly to just how much effort was required to bring EMMs up to the level required for validation, Google have worked incredibly hard to bring AER to other areas of the Android Ecosystem since 2018, and I’m very pleased it’s now come to fruition!

As we transition away from device admin management and toward Android Enterprise this year, looking across the EMM landscape there are still examples of EMMs who don’t fully support the solution sets, don’t actively advocate Android Enterprise first with their customer base or simply don’t know very much about modern Android management in general.

We’ve definitely come a long way compared to how it was some years ago, with EMMs picking and choosing which OEM APIs to support based on customer demand or, often also likely, taking a gamble on what might be useful to customers, but there has definitely been a fair amount of fragmentation – even between top-tier vendors – in the industry which Google has aimed to address with AER.

Just as AER for OEMs set out to create a benchmark against which devices should meet or exceed in order to guarantee a consistent, reliable experience for management, AER for EMMs aims to do something similar.

To summarise the requirements for EMMs:

• Support advanced management of two of the three widely utilised deployment scenarios (COPE isn’t included, yet)
• Clearly demonstrate knowledge and capability of supporting the solution
• Proven ability to deliver advanced security and management features
• Offer a consistent deployment experience, with admin consoles that simplify set-up of Android Enterprise

The requirements are described in-depth in the glossary here, and an overview is available here.

In a nutshell, Google are going to validate EMMs who demonstrably put Android Enterprise front-and-centre over legacy management, have a healthy install base and can lean on excellent product knowledge, useful collateral and confidently sell the solution to the market. The obvious difference when compared to AER for devices is that it isn’t purely about feature support as such, even though that certainly forms part of the wider validation, but the whole experience of working with an EMM.

I’d seen first-hand some of the background work going into AER prep in the second half of last year, where EMMs were – as if by random – adding features available as far back as Lollipop, knowing AER was on the horizon, it wasn’t too difficult to connect the dots!

EMMs validated can be found here. Each validated AER EMM can be identified by the AER badge, those yet to pass validation are equally listed, but go without the little green shield.

There is a comparison function which is quick and easy to make use of, though I hope to see improved to display more information about the individual APIs/features the EMMs support, as currently it’s rather vague without clicking into each vendor:

In any case clicking any of the EMMs will offer an in-depth breakdown of features supported. While the breakdown is quite informative, I would very much like to see it more aligned to the solution sets, referencing each in the numbered list, and potentially linking off to more details. It may look less visually appealing, though would be far more useful. As an example for SOTI’s work profile implementation:

Could instead be:

DEVICE SECURITY

Set lock screen restrictions (2.1)
Set lock screen restrictions for work profiles (2.2)
Set advanced passcode restrictions (2.3)
Configure Smart Lock settings (2.4)
Wipe and lock work data (2.5)
Compliance enforcement (2.6)
Disable app installs from locations other than Google Play (2.7[.1])
Disable debugging (2.7[.2])
Check device integrity (2.9)
Enforce Verify Apps by default (2.10)

(2.8 doesn’t apply to work profile, in case you wondered)

All I’ve done there is reorganise the items as they’re displayed on the relevant solution set, and linked to each item for further information. It’s these sorts of small touches that encourage readers to seek out more information, and in turn form their own conclusions towards how an EMM aligns with the solution sets Android Enterprise offers (and perhaps if Google decides not to, I’ll do something similar based on data available on the vendor pages!)

Google are launching with a number of initial partners, namely Blackberry, Google Cloud, I3 Systems, IBM, Microsoft, MobileIron, Softbank, SOTI, and VMware (in alphabetical order).

There are a few expected names in that list, MobileIron and VMware for sure given there’s little doubt they’re leading the way for Android Enterprise in the market today – not only due to COPE support, but things like VMware’s video series, MobileIron’s blogs and whitepapers and the general AE-first approach the vendors are taking. No one would disagree with the likes of IBM and SOTI (who’s dedication to Android management over the years has been incredible) either!

There are a couple of AER partners on there that you may not expect though; if seeing Microsoft surprises you, you’re not alone! I ran a poll on Twitter to garner the views of the wider community on technical capability alone and the results speak for themselves:

Should Microsoft qualify as an #AndroidEnterpriseRecommended #EMM today?

– Yes, they support enough of the solution sets for customers
– No, they're missing too much functionality to be considered recommended

Please RT #enterprisemobility #androidsecurity

— Jason Bayton (@JasonBayton) January 16, 2019

Unlike AER for devices however, technical capability on its own, as mentioned above, isn’t what Google are relying on to validate EMMs. On that, Microsoft are joined by Google Cloud Identity in being the only two solutions with an asterisk (*) beside them, and this is for a very simple reason:

They’re not quite up to scratch just yet.

These partners have validated solutions or will be launching their offerings throughout 2019

– Will Ro, AER EMM announcement

Google are keen to highlight that although these two vendors are potentially passing with flying colours other aspects of validation, their feature set support is not yet at the level Google deem acceptable for AER, hence attaining only standard and not advanced across the board:

The asterisk is intended to suggest they’ve committed (ie. roadmap) to meeting Google’s requirements and recommendations in the near future, and will continue to develop their product through 2019.

Speaking for Microsoft (as I can’t for Google Cloud), they are the first big vendor to adopt the Android Management API (AMAPI) as I’ve pointed out before, they’re also incredibly active in the ecosystem and despite a late start, are working around the clock with Google to bring missing features to fruition. In fact, COBO support just launched in preview.

It would appear as such Google are giving both of these vendors the benefit of the doubt and have brought them into the programme with the very clear caveat there’s work still to be done.

Until fully validated and the asterisk removed, These vendors should not actively use the badge, so any concern of this causing confusion from an EMM marketing standpoint is suitably subdued.

That said, the wider industry will take from seeing these vendors in the list what they want, and I’ve more than enough examples already from customers to partners, carriers and other vendors to suggest this could have potentially been far more clearly explained. Hopefully this article will go some way to helping with that!

The programme is definitely an eye-opener into the capabilities of EMMs broadly; particularly for me having neither the access nor the capacity to be constantly jumping in and out of various platforms for testing, being able to pop on over to the partners site and pull up what vendors do and don’t support without needing to find a tenant is very useful. Hopefully it’s frequently updated to maintain this information.

As Google continue to expand the programme, it really can’t be overstated how important Android Enterprise Recommended is for the ecosystem.

From the profound difference AER for devices has made over the last year for device selection – whether how OEMs support and market their devices, customers select them or MSPs recommend them – AER has improved this process across the board by adding clarity, setting expectations and instilling confidence in what was once a process laced with uncertainty.

I believe AER for EMMs will do the very same, offering more consistency across the management ecosystem, providing more control to Google in ensuring the management experience continues to improve (they set the bar for AER, after all), and ultimately resulting in the best management experience for organisations and providers alike.

With that said, I’m looking forward to seeing far more EMM players in the market begin to show up, and perhaps even AER subcategories might be considered in the future – some EMMs will focus entirely on dedicated devices for example, such as Wizy or Shoonya, others MAM or BYOD, like Appaloosa; these vendors may never opt to apply for AER because they don’t fulfil the broader requirements, irrespective of how well they support the devices of their chosen solution set or meet other requirements for validation.

So, with AER both for devices and EMMs now publicly available, it’s only a matter of time before MSP validation turns up. I’m very much looking forward to that one!

How do you feel about AER for EMMs? Is it what you were expecting? If you’re a customer, does AER have any impact on EMM choice? For vendors, how do you feel about the validation? Let me know in the comments, @jasonbayton on Twitter or /in/jasonbayton on LinkedIn!