← Back to Learn
ArticleVirtual Reality in Education

MDM Is Not the Solution. It Is the Admission.

Mobile device management for VR is usually presented as an advantage. I see it differently. In many education deployments, the need for MDM is a tacit admission that the headset and the proposed “solution” cannot independently handle their most important responsibility: manage content.

By Dave Dolan
MDM is not the solution to most problems
MDM is not the solution to most problems

Mobile device management for VR is usually presented as an advantage. I see it differently.

In many education deployments, the need for MDM is a tacit admission that the headset and the proposed “solution” cannot independently handle their most important responsibility: delivering and managing content reliably.

A third-party platform must therefore be brought in to make the collection of products appear to function as a complete solution.

The relationship is becoming rather crowded. The school is no longer dealing with one accountable provider. It is dealing with a headset manufacturer, a VR solution provider and an MDM company—three parties in a bed that was already too small.

What pedagogical need does the MDM serve?

None.

  • It does not make the lesson more effective. It does not improve understanding.
  • It does not make the experience more meaningful. It does not produce better learning outcomes.

Whose problem is it solving?

In many cases, not the school’s original problem. It is solving problems created by the solution provider’s choice of hardware and delivery model.

What Does the MDM Actually Manage?

It may be used to:

  1. Deploy and manage content online because the chosen consumer headset was not designed to arrive with a complete, controlled education library already installed.
  2. Manage operating-system changes, application updates and patches associated with devices developed primarily for gaming and entertainment.
  3. Configure accounts, permissions, kiosk modes and user access because the underlying platform was built for individual consumers rather than simple, shared classroom use, or under-designed by not allowing for individual accounts to be added at the headset level.
  4. Monitor devices, batteries and connectivity because the proposed system has introduced additional operational dependencies.
  5. Help IT troubleshoot a complicated device with two controllers, numerous buttons and features that have little or nothing to do with the learning objective.

These functions can be useful. But usefulness should not be confused with pedagogical necessity.

The provider first chooses a convenient consumer device. That decision introduces accounts, connectivity, updates, configuration requirements and usability problems. The resulting offering then requires another product to manage those newly introduced problems.

  • The school pays for that additional product.
  • The school learns another system.
  • The school manages another supplier.
  • The school assumes another layer of technical and operational risk.

The convenience belongs to the provider. The burden belongs to the school.

It resembles an absurdist play: complicate the offering, introduce a product to manage the complications, and then present that management product as evidence that the original offering is complete.

This Is Not an Attack on MDM Providers

I know people working in this field. They are smart, capable and well-intentioned. In particular circumstances, MDM can provide a genuine lifeline.

Suppose an organization has already invested heavily in unsuitable hardware. That capital expenditure cannot simply be abandoned. An MDM platform may help make the devices manageable and recover some value from the investment.

Send in the MDM cavalry.

MDM may also be appropriate for genuinely complex deployments in which remote configuration, security policies, multiple applications and distributed device fleets are real organizational requirements.

But that is different from claiming that every classroom VR system naturally needs another paid management layer.

Start With the Learning Problem

A solution is supposed to solve a problem.

Education providers should begin with the pedagogical requirement and choose the simplest system capable of meeting it. They should not select hardware for their own convenience, introduce unnecessary complexity, and then sell the school an additional service to manage the consequences.

The right question is not:

  • “Does this VR system include MDM?”

The right questions are:

  • “Why does this system require MDM?”
  • “Which problems does it solve, for me?”
  • “Did the school already have those problems—or did the proposed solution introduce them?”

MDM is not inherently bad. Sometimes it is necessary, and sometimes it is extremely valuable.

But when it is required merely to make an unsuitable consumer device function in education, it should not be presented as a feature.

It should be recognized for what it is: evidence that the underlying solution was never complete. That’s not sensible.