Cool Solutions

The Future of MDM, Part 3: Service Gaps and Related Threats



By:

March 15, 2011 11:27 am

Reads: 3195

Comments:0

Score:0

This entry is part 3 of 4 in the series Mobile Device Management

Part 3: Service Gaps and Related Threats

The world doesn’t slow down to let anyone take a breath—and if the technology world as a whole is running, then the mobile device world is sprinting. This means that just as organizations begin to effectively address one mobility challenge, three more sprout up demanding attention. Welcome to the service gap.

Managing mobile devices was simpler when it was only executives and senior management using smartphones with basic communications needs—but thankfully there weren’t a lot of executives so managing a small pool of devices could be done in an ad-hoc fashion. Maybe someone in the IT department was the “mobile” guru and was asked to manually assist employees directly with their needs. The solution was simply brute-force IT and it worked for a time. No more. The flood gates have opened and now these devices are the norm across many organizations. Fast-forward a few more years and it will be unusual for the common worker to NOT have a smartphone or other mobile device. Brute-force can’t keep up. So what are the obvious gaps, what are the risks of not addressing these gaps?

SERVICE GAPS
A service gap is simply the difference between the service demands of a user and those available to that user (whether the gap is reasonable or not is of course another matter). A common example was, for a time, iPhone and enterprise email. Back in the day they often didn’t play nice and that meant either you couldn’t get corporate email on your new iPhone, or the service was inferior in some way. While email can still be an issue, service gaps now include everything from proper application compatibility to mainframe data access and more. The important point here is for organizations to understand service gaps, prioritize remediation, and communicate this to their employees—this last part being critical. Why you might ask? This leads to the next point.

SERVICE GAP THREATS
Again, going back to the opening analogy—the word does not stand still, and neither does an employee waiting for an organization to address their service gaps. They improvise. They innovate—but often in reckless and occasionally dangerous ways. In the case of iPhone email, many organizations were concerned that email wouldn’t be properly secured when going through an iPhone, so they didn’t support these devices (I’ve read reports suggesting up to 70% of a company’s IP “lives” in email). Did the employees simply accept this and patiently wait? Some did, but many didn’t. They found out that they could get Gmail on their iPhone so they began setting up email forwarding rules in their corporate email to send everything to their private Gmail account—completely bypassing all IT safeties and putting their email, basically, out in the open. This is the essence of a service gap threat.

If a company’s workforce is demanding access to something through their mobile devices, it is foolish to ignore it. Even if the particular service being sought isn’t possible, it shouldn’t be dismissed. It should be understood, plans to address it should be made, and this should all be transparently communicated to the workforce so they understand they don’t need to become recklessly innovative. Make them a part of the solution and avoid them becoming part of the problem. In fact—the workforce can often be the most imaginative resource available for solving the woes of mobile device management while ultimately brining the masses what they really want and need.

Next time—Part 4: The Future of MDM—the New Paradigm of Service Consumption and What It All Means.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Series Navigation<< MDM Part 2: Leveraging Mobile Devices Today–a Crash CourseThe Future of MDM, Part 4: The Future of MDM is User-Centric >>

Tags: ,
Categories: Expert Views, ZENworks Mobile Management

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

Comment

RSS