Why MDM doesn’t work at scale

If you’ve ever worked with an MDM (Mobile Device Management) provider to build and manage an Android fleet composed of hardware like POS systems, kiosks, rugged tablets, or displays, you know how one-sided that relationship becomes once your hardware is in the field. And you can do better.

MDMs are built on a model that chiefly rewards enrolling devices, not supporting them. It’s hard to blame them, either — devices have become a critical concern across dozens of industries, and scale talks. But if you’re scaling mission critical hardware like POS or mPOS, you’re already asking the kind of hard questions your MDM probably isn’t very eager to answer. And if you aren’t asking these questions, you probably should be! Here are seven that’ll stump them.

Why won’t your console just let me update my devices?

Managing your Android fleet with a typical MDM’s tools could be described, charitably, as a challenge. It’s doubtful anyone is truly happy with the tools their MDM provides for fleet management, and that’s why Esper built an incredibly powerful and customizable console. We could go on about why MDM consoles are underwhelming, but it’s probably easier just to tell you what ours can do.

We support staged app updates, but how “staged” are we talking, here? With our console’s advanced pipelining tools, your subgroups can have subgroups.

Only want your next application update going to the top 10% of your self ordering kiosks by engagement, and only then among those kiosks on the latest hardware revision that are also in a particular market or office? With Esper’s console and Pipelines, you can build it.

We understand that the way you grow and scale your fleet is going to change the way you manage and deploy software as the complexity of that fleet grows. Pipelines also allow you to execute tasks on select groups of devices, like sending a reboot command to every device in the lab, or pushing an application update en masse out into the field.

We also get that fleet management is a human challenge, and that maintaining and deploying Android devices with arcane MDM tools can slow down your business. Just as there’s no reason you shouldn’t be able to control your own OTAs, there’s no reason your team should have to spend weeks deploying the latest application build to devices out in the field, one by one.

Esper was built on a simple truth: You know what’s best for your fleet. Your MDM was built on what’s best for theirs. That’s why Esper and Foundation are uniquely positioned to realize the kind of complex Android device deployment and management scenarios MDMs simply can’t (and that they aren’t motivated to address).

Why can’t I bring my own devices? What about custom hardware?

If you need to iterate rapidly on hardware or support an extreme variety of form factors and use cases, a traditional MDM can leave you feeling locked in. As your company matures and evolves, so too will your needs from hardware partners, and MDMs are notoriously inflexible. That inflexibility could cost your business serious time and money.

No one wants to make the wrong bet when it comes to a platform, but with your MDM, you may be making a platform choice you’re not even fully aware you have the power to change. If your product development cycle pivots, it logically follows that your Android fleet management should be able to easily pivot with you. But with an MDM, your options for iterating and diversifying your hardware are on their schedule, not yours. This can present a difficult choice: switching MDMs entirely — and good luck with that migration of your existing fleet — or choosing a potentially suboptimal solution in order to avoid a huge headache.

Esper doesn’t think your product roadmap should be subject to the whims of a single partner. With the Esper console and Esper Foundation for Android, we’re setting you up to build and iterate for years to come — regardless of what “flavor” of Android you run or which hardware you choose to do it on. We practice what we preach, too: Esper is designed to manage the full gamut of Android devices, from consumer-grade GMS handsets to digital display signage running customized AOSP. We even support Android on x86 (no, really — ask us about it).

In five years, it’s probably hard to predict what your Android kiosk fleet will look like. We want to make sure that no matter how diverse your hardware becomes, deploying and managing it will always be a seamless affair (unless you’re building smart pants, in which case, seams are advised). For more on Esper’s hardware compatibility, just head here.

Do you actually offer remote debugging capabilities?

Imagine, you’ve just kitted a hundred new POS systems and promptly shipped them out into the field. Two days later, you see ninety-seven of those new systems up and running error-free in your console, and you’ve got three trouble tickets. You try remote diagnosis, rebooting, and even to teach someone in the field how to generate a log (this, predictably, does not go well). This isn’t fun for anyone.

Esper does not want you to get on that plane. Need to take over touch control? Easily done straight from the Esper console. Start a remote ADB session? Easy. We even can send real-time outage alerts for your entire fleet, giving you the observability to spot problems before they’re… Problems.

As your Android fleet expands, the ability to remotely diagnose and resolve issues is crucial to meeting the challenge of scalability.

Why can’t I opt out of FOTA updates? Or roll them out at my pace?

Anyone supporting kiosks or POS systems in the field knows that the worst update is the one you didn’t know you were getting. Traditional MDMs aren’t interested in helping you manage firmware deployment at a granular level (or frequently, at all). When a firmware update happens to reach your fleet, you’re left to either find a band-aid — a way to block the update, often only temporarily — or take it. This isn’t good!

If you want to control your own firmware image, Esper Foundation for Android gives you the tools to manage and deploy it exactly when and where you want. You manage your software with an exacting degree of control — we think updating your fleet should feel exactly the same way. And we don’t see a way to do that without putting you in the driver’s seat of your fleet’s OTA strategy.

That’s why if you choose Esper Foundation for Android, you’ll have a partner in the Android business. We’re not just building a deployment and management platform, we’re building a device innovation ecosystem that is growing with our customers, their use cases, and the mission-critical roles their hardware fulfills. MDMs, by contrast, aren’t motivated by individual customer stories, and neither is their Android update philosophy.

Are my devices vulnerable to attacks? Can they be patched?

If the update you really don’t want is the worst one, we all know which one takes second prize: The update you do want that doesn’t show up. Android devices — with or without GMS (Google Mobile Services) — are all eligible to receive Google’s monthly security patches. These patches address exploits that could leave your Android device fleet vulnerable, and (in most cases) should be deployed as soon as practical.

With Esper Foundation for Android, we offer a better way to keep your fleet secure today — and long into the future. We give all our Foundation customers Android security patches published by Google (though they’re also able to opt out). And for Foundation on x86, we give you up to eight years of updates. To learn more about what we’re building with Foundation (including on x86), check out this page.

Can I automate provisioning?

Even Google’s own “Zero touch enrollment” for Android Enterprise devices is not truly zero-touch, requiring some level of user input in order to connect to the internet and start the enrollment process.

With Esper Foundation for Android, you can build truly seamless, touchless provisioning (let us show you). Just ask our customers, one of whom is dropshipping devices straight into the field — power it on, and the device handles the rest, using our predefined configuration options in Foundation.

With Foundation, your kiosk or POS system can immediately connect and provision on boot, and you can immediately begin managing it — a key consideration as more businesses explore the possibilities of 5G. From there, you can push app updates, pull device info, reboot, or start an OTA. That is true zero-touch.

How bad would a migration to Esper from my MDM actually be?

Not very! Nobody likes migrations, but we’ve worked to ensure the process for switching to Esper from your existing MDM solution is as simple as possible. We can get your existing Android fleet up and running in the Esper console (FYI: we can support very old versions of Android, all the way back to 4.4), potentially in a matter of days.

Learn how to get past MDM

Managing fleet growth at scale is the challenge we know we’re uniquely able to solve, and we’d love to talk with you about what you’re creating, and how Esper can help you build it faster, stronger, and more sustainably than an Android MDM.

And did I mention that this is just the tip of the iceberg? Esper is certainly happy to replace or augment your Android MDM, but we can offer so much more. Have a question? Just wondering how you can try Esper out? Want to build Foundation for a POS system or kiosk in your lab? Get in touch and set up a demo, we’re happy to help.