The New MDM Paradigm: What it Means for Devices to be First Class Citizens

Historically, mobile device management (MDM) software was created to manage corporate employee devices. Every laptop and mobile phone was tied to an individual user, meaning when the user logs in, linked to SSO and their corresponding enterprise user role, they get all the settings and apps associated with their profile. In this paradigm, there’s a 1:1 mapping — every device has an assigned user (the device owner) — and the user is the first-class citizen. In other words, everything that happens on the device is a result of the user’s profile. You’ll even find that many MDM providers still use user licenses as their primary unit for pricing and packaging.

Today, there’s a proliferation of a new class of devices, like self-checkout kiosks or POS terminals, that are used by multiple users and managed by multiple administrators. You no longer have that one-user-to-one-device mapping. You have many users and many different types of users potentially using and managing the device, who, in many use cases, aren’t logging into the device and accessing their employee or user profile.

Today’s devices are also frequently unattended and require little supervision. Think about a vending machine in an airport terminal or a tablet in the back seat of an Uber or Lyft car. The IT operator still needs to ensure the device is always working and functional, but without constant supervision. They can no longer depend on the assigned user or the user profile to dictate what happens to the device.

In the traditional MDM paradigm, users are first-class citizens and can supervise the devices. In this new world of unsupervised devices used by multiple users, devices become first-class citizens, and it’s the role of modern device management to be able to monitor, interact with, manage, troubleshoot, etc., the devices and the software experience running on them directly and often remotely.

Let’s look at what that really means. I like to start by thinking about how workflows must change and what new workflows are required for a world where devices must be treated by MDM software as first-class citizens.

How Developer Workflows Change in a Device-First Landscape

A new stakeholder in the MDM game is the developer, who is responsible for building the software experiences delivered through modern devices. Modern MDM must enable the following developer workflows (which you’ll notice interact directly with devices rather than through users or user profiles):

• Building apps and deploying them properly to these devices
• Remote troubleshooting, including secure tunneling to devices
• Pulling specific telemetry data from the devices so dev teams can incorporate and take actions based on different events or scenarios
• Device grouping to improve the efficiency of management processes — essentially applying what works well in the cloud ecosystem, like CI/CD or DevOps concepts, and bringing that to device management

When it comes to developer productivity and understanding the impact on effectiveness and efficiency, it’s important to understand that devices are just the medium for which organizations deliver novel and differentiated customer experiences (i.e., deploy their developer-built applications). They have an engineering org (or contract with a third-party ISV) to build the experience, test and validate it, and so on. 

But that doesn’t end the workflow. Those applications now need to go to the fleet of devices. This brings us back to the productivity question: If an application is built on a regular sprint cycle of one or two weeks, how long is it taking to deploy that application to a fleet of devices? If that time period is longer than you like, that’s what you need to solve. Engineering productivity should result in code changes, security fixes, and any app updates being deployed to enhance end user experiences on the device as quickly as possible — and (modern) MDM should play a critical role in that entire pipeline.

How IT Operator Workflows Change in a Device-First Landscape

Business or operator workflows are the other side (again, working directly with devices rather than through users or user profiles):

• If you’re putting a device like a kiosk out in public, the most important thing to consider is security — you want to know that it can’t be hacked or broken into and can always do what it was intended to do
• Second, you want to ensure they are all running the latest and greatest workload (delivered by your developers). It’s no longer just a certificate, as you want to continuously update your entire workload package, which might consist of many files and applications.
• Finally, a fact of life is that, eventually, devices will have problems. They’ll stop behaving how you want them to, and it’s the role of MDM and operators to help debug that. The operator’s role is to figure out those problems as quickly as possible. From a productivity perspective, it’s all about how quickly your MDM enables the operator to identify the issue.

Ideally, an MDM makes the life of IT operators as easy as possible. It’s not just shortening a workflow from 15 steps to 3 steps or 10 clicks to 2 clicks. When things work right, the operator’s workflows are so streamlined and automated that they rarely need to use the management console at all for operations to function properly. Now that’s productivity.

The next generation of device management caterers to both of these personas and checks off both of their requirements.

Confident Software Deployment Means Shorter Feedback Loops

The requirements for new platforms have changed. The simplest is that organizations need to deploy multiple times a month, a week, or even sometimes multiple times a day. Ten or fifteen years ago, a new cloud deployment would have taken a month or maybe even more. Now, it has become a norm to do multiple deployments a day. Users are asking the same requirements for device management.

This also means shorter feedback loops. Traditional deployments used to take a long time to get usability or performance feedback on the apps they deployed. Now, those feedback loops have been shortened, and the QA time has been accelerated.

The teams building the apps that need to go on the device are able to build faster, and now they’re asking their counterparts responsible for deploying those apps to match their speed and agility.

Managing at Scale

Finally, let’s talk about managing devices at scale. How do you manage tens of thousands of devices? Let’s use New York City taxis as an example. Every single taxi has a kiosk tablet or two in the back seat. These are revenue-generating devices. They can collect payments, they can play ads, they can be used for entertainment, etc. Let’s say you want to deploy a new app version — how do you do that with a controlled, descriptive mechanism? We call it the “desired state” architecture, where the desired state ensures the apps are updated, the appropriate settings are updated, and other relevant changes are seamlessly integrated.

The users of those devices (New York City taxi riders) have no stake in the device’s security, and savvy users will immediately try to break the device out of kiosk mode and access various device settings. How do you lock a device down so that it does what you want it to do, and only that? All while doing that at scale and improving the experience constantly?

Managing Heterogeneous Device Fleets

Heterogeneity is another complexity that modern device management needs to address. Compared to just a few years ago, there’s so much more device diversity. Not only across operating systems but even within the Android ecosystem, there are so many OEMs with their own Android builds, peripherals, and other customizations. The last thing you want is to be locked in to a specific device brand or make — that just stifles scalability.

One Simple Question

To wrap things up, here’s a good litmus test for whether your device management tools are built for the modern world: whether you have a small, large, or rapidly growing device fleet, whether your device fleet composition is heterogenous or homogenous, or whether you have simple or complex workflows, does your MDM increase your confidence in deployments?

If not, it’s time to consider alternatives.