An IT Professional’s Guide to Vetting and Deploying Enterprise Augmented Reality Solutions
Written by Alex Karim, Mixed Reality Technical Sales at Kognitiv Spark.
With every passing year, Augmented Reality and Mixed Reality solutions are becoming more commonplace in enterprise environments. Like any new technology, this introduces fresh challenges for organizations and IT departments to solve.
In this report, we will address some of the key challenges and provide an outline for effectively vetting and enrolling AR/MR solutions into your organization.
AR & MR Solution Design for Enterprise Applications
When architecting any technology solution, the most important thing to do is start with the business problem you’re trying to solve and understand its key requirements. In an AR/MR project, a thorough business analysis will help you select or design the best solution for your organization.
Once the requirements have been gathered and you move into design, it’s important to consider the lifecycle of the project and one aspect commonly overlooked is the IT integration.
From an IT professional’s standpoint, the key design items to consider are:
How will the hardware (and software) be adequately managed?
How do we ensure that the organization’s cybersecurity standards are met?
How will the solution be supported on an ongoing basis?
Overcoming the Key Technology Challenges
In this section, we will investigate these key questions and discuss best practices when designing your solution for enterprise success.
For your initial AR/MR pilot, it’s unlikely that you will require full management of your selected hardware and software. The key aim of the pilot phase will be to prove that the solution delivers value for your users and organization.
However, when it comes to deploying these solutions at scale, it’s crucial that time has been spent considering MDM (Mobile Device Management). Your decision making here will likely be driven by these two factors:
How your organization currently manages mobile devices.
What MDM systems your preferred AR/MR hardware supports.
In Table 1, we provide a rough outline of how to approach this depending on your organization’s “MDM Maturity”.
It’s likely that cloud adoption is part of your company’s digital strategy. It can therefore be advantageous to use “halo projects” such as AR/MR to accelerate your overall internal digital transformation.
As is clear from the table below, most head-mounted devices are primarily managed through cloud MDM systems. By combining workstreams, you can simultaneously drive cloud adoption (through migration to cloud MDM) and provide your AR/MR projects the best chance of success.
Recommended Actions
Current MDM Maturity
Use the AR/MR project as an opportunity to deploy a cloud MDM solution to manage your mobile device estate
If using mobile devices (e.g. iOS / Android): Maintain your existing MDM solution as it will likely support these platforms
If using head-mounted devices (e.g. HoloLens): Build a migration path to cloud or hybrid MDM
Verify your chosen hardware can be enrolled into your existing cloud MDM solution
Currently no MDM system or process in place
Currently using on-premise MDM solution in production (e.g SCCM)
Currently using a cloud MDM solution in production (e.g. Intune or Workspace ONE)
AR/MR Security Considerations
Cybersecurity is always a key consideration when deploying new technologies or systems into your organization. AR/MR solutions are no different and, in some cases, require more scrutiny.
AR/MR headsets and devices require various cameras and sensors to operate effectively. In secured environments, this can add a layer of risk that must be mitigated. Here are a few of the key items to consider for AR/MR projects from a cybersecurity perspective:
Enroll your device into MDM and ensure sensible security policies are “pushed” to your AR/MR devices and business apps are deployed/managed centrally.
Consider policies that require a minimum set of requirements to be met before a device can be enrolled (e.g. genuine OS installed, minimum OS version…).
Ensure the ability to remotely wipe the device is configured and document the steps required to do this (in the event of a device being lost or stolen).
For device authentication, consider using one or multiple of the below options.
Use existing corporate identities for users to login to devices (via Single Sign-On).
Enable/Force two-factor authentication for device users.
Enable/Force the use of biometric authentication (e.g. the Microsoft HoloLens 2 can be logged into using Hello iris scanning).
Review the OEM telemetry data taken from your AR/MR devices and consider the implications on your internal data protection policies.
Some AR/MR devices collect anonymized data from their sensors by default.
If required, turn off the default OEM telemetry data to reduce exposure.
If using the solution in a secure environment (e.g. Military, Nuclear, Aerospace Manufacturing, etc.) consider AR/MR solutions that can either run on-premise and/or require no internet connection
If your chosen solution does require an internet connection, use LAN network rules and network segmentation to secure the devices and data
Ongoing support of hardware and software
Another key aspect that’s commonly overlooked in AR/MR projects is ongoing support. As a new technological category, it’s important to understand which internal and external support structures are required to support these devices well into the future. Here are a few items to consider when developing effective AR/MR solution support strategies:
Choose AR/MR suppliers who are willing to partner with you during your entire project lifecycle (from pilot to institutionalization).
Ensure you have direct contacts within their service and business development teams to triage and troubleshoot issues with your solution, train new users, or roadmap a scaled rollout of the technology.
Ensure that before project closure, appropriate internal support documentation has been produced, approved, and made accessible to the relevant internal teams.
This makes it clear which internal teams and resources are responsible for each aspect of the live service and should cover all basic issues identified during testing.
It will act as the “cheat sheet” for when users raise issues with the AR/MR solution.
Build a support workflow from issue identification to resolution. A basic workflow could look something like this.
Problem identified by the frontline worker or end-user.
A worker raises an internal IT department ticket.
Assigned internal support engineer works through defined troubleshooting as outlined in internal support documentation. If internal support documentation is unable to provide the information required to resolve the ticket, reference the vendor’s support documentation.
If unable to resolve, internal support engages with the AR/MR vendor depending on the issue (e.g. hardware vendor may be different to software).
If deploying a large AR/MR solution and internally led support is not feasible, consider outsourcing the solution to a support partner.
The two main options here are traditional IT outsourcing companies (with relevant knowledge) or specialist AR/MR organizations.
You should engage with support partner(s) during the design phase to ensure a smooth transition (as they may insist on being part of the delivery phase).