Device Management
Hardware
Operations
Considerations When Maintaining Mobile Device SLAs
The era of modern smartphones allows more flexibility through bring-your-own-device (BYOD) initiatives. Mobile device management (MDM) solutions have become a cornerstone of almost every organization’s end-user device operations. As such, services are often wrapped in service level agreements (SLAs). Maintaining these SLAs can be very time-consuming in the MDM space, and they rarely integrate well with other management solutions, especially within the automation space.
Smartphone History and Traditional MDM Focus
The use of smartphones can be traced as far back as 1992. They became popular in large enterprises for messaging with Research in Motion’s Blackberry devices, around 1999. One of the biggest selling points of the Blackberry was its device management and security features, which enabled mass management and a level of reporting, albeit very rudimentary.
Starting in 2007, with the introduction of the iPhone, smartphones became much more user-friendly. However, they also became more difficult to manage for enterprises. Much of this has been addressed with updates to the Android and iOS operating systems and the introduction of enterprise OS solutions; that, and multi-device management, which has become a default offering in any of the decent MDM solutions. Many MDM solutions have even expanded to laptops and tablets. Regardless of the type of device, the fundamental approach to SLAs in this space is still based on the management service’s availability.
While it is worth having an SLA, the SLA doesn’t add to the value of the device from the perspective of the employees – the end-users. From their point of view, the value of a modern mobile device is in the applications it provides and the flexibility it affords.
What is Supported?
As stated above, having an SLA around the operational metrics of the mobile device management service itself isn’t a bad thing. But it should not be where the SLA ends. That service is core to provisioning new devices and pushing the latest update and security policies out.
MDMs track things like location, device type, OS version, applications that are installed, and which applications are used. These can help with hardware lifecycles and, perhaps, the fine-tuning of a few policies. But not much else.
What’s Missing?
What if you could do more with the data you track? What if it could be used to determine the average time a device is registered with the system; and how often devices are decommissioned? This could help tease out critical infrastructure costs and device lifecycle management considerations. Imagine if such data could be used to predict precisely when a device might fail and cause downtime for your end-user in the context of dedicated devices. Maybe you discover a particular tablet model lasts 4 years but another hasn’t made it more than one year.
Additionally, you could leverage contextual data like the location of a group of devices experiencing battery failure, devices used in warehouses with cracked screens, or perhaps even a particular user persona damaging devices more frequently.
This kind of information will let you build SLAs that are suited to the different device types and different users. With this, you can plan a long-term device lifecycle strategy and end-users can have the confidence in knowing the device they are being issued will be supportable and supported for what they need and how they work. Providing business savings and a better user experience.
Other considerations are around application usage, which plays into areas like screen size, device storage, and the type of data plans that are offered. Take for example an insurance adjuster in automotive insurance who regularly needs to record and upload video. Their data plan can be set to accommodate this. Then there are the insurance adjusters in the agriculture industry who are often outside LTE coverage areas when taking videos of damaged crops and equipment. They need more on-device storage, but a smaller data plan, as they can wait and upload video from WiFi back in the office, at the end of the day.
Another aspect that can be included or improved in an SLA is resolution time. This can be improved by tying the physical device management solution into other core operational systems to take advantage of the automation that is available. Using APIs that are common in any good solution, parameters can be adjusted on the fly, as part of any good incident management program.
Conclusion
MDM is great, but it is just the starting point. The real value in the device management market comes along when a business and its end-users’ usage patterns and needs are taken into consideration. They can be incorporated into the policies and SLAs that are used to build and provide the services users rely on. Starting with the physical hardware and data plan, the SLA should relate all the way to the mobile applications, which can be as critical to a company’s success as any backend finance or claims processing system.
Vince Power is an Enterprise Architect with a focus on digital transformation built with cloud enabled technologies. He has extensive experience working with Agile development organizations delivering their applications and services using DevOps principles including security controls, identity management, and test automation. You can find @vincepower on Twitter.
