Categories
Applications News Services

Mobile Device Management: Is it the Answer … or is it the Question?

I was at a big AirWatch mobile device management (MDM) pan-European pow-wow last week. At it were CEOs, MDs and reps from Multinationals whose brand names are the stuff of the daily papers. In amongst them all were small firms, AirWatch’s channel partners and consultants like me who had some spare time on their hands.

Personally I like AirWatch: for their product, for their management style and especially for their in-house pre-sales and professional services team. I have used the software extensively and I have a lot of time for it. However, I think there is a problem specifically with MDM and the whole mindset that drives its adoption. I am not alone in this, and it is from a presentation at the conference by Chris Marsh of the Yankee Group that my current train of thought left the station.

The basic ambition of a pure MDM implementation, and in the rush to go mobile this is all that many firms have in mind, is that you can remotely control the mobile device from a console on a corporate server over the wireless networks. For Apple products, the server sends an Apple Push Notification Message to an MDM enrolled device which says “call home”. The device does and receives, by return message, an OS interpretable instruction such as “lock screen”, “clear password”, “install this app” or “reset the device to pre-enrolment status”. The device does what is requested if and when it can. Generally it reports success or failure back to the server but, say with reset message, executing the message necessarily involves clearing all of the enrolment server information including knowledge about where to report back.

What MDM can do is determined by what the list of message types the OS supports. Some MDM vendors provide an “agent” to augment the over-the-wireless services but given modern OS sandboxing and security models, the additional services are fairly circumscribed. Android supports a vaguely similar model and has a slightly larger set of controls.

The problems with MDM aren’t about its aims or implementation but, as with so much off-the-shelf software, the devil that lies within the detail of the operational manual that you must write for your L1 and L2 support teams. You can use your corporate console in the IT lair to do location tracking of all of your enrolled devices. It works and is an extremely powerful feature of MDM’s abilities. You can wipe clean the contents of the device’s storage with a press of a button. But when can you use these features, and their raft of companions, once you have implemented them? The examples below are not drawn from dreaming about a brochure-ware MDM implementation but from war stories from those who have done it.

Tracking employees’ location generates very large volumes of discontent. I cannot think of any organisation in which I have worked where employees would or did accept it. I can name even more organisations in which I have not worked that also have not accepted it. Apple’s micro-location service for devices that are never meant to leave the building would be acceptable probably because the feature confines its benefits for the business to within the geographic bounds of the business.

Wiping a device, especially a corporate owned device, when it is stolen seems a bit less contentious but on closer inspection it too has problems. Can you guarantee that, just because you press “wipe”, that the radio message will traverse the radio networks and the device will actually get the signal and complete the execution of the command?

If the fact that you cannot guarantee this doesn’t really bother you, and I can accept any number of reasons why, I imagine you don’t have any of your clients’ data on there about which you have critical business agreements to the effect that you won’t lose it.

For many businesses, losing client data to random third parties through loss or opportunistic theft might be acceptable provided there is a passcode and data encryption in place. At some point you need to do a risk assessment, set a budget for insurance and a plan for mitigation then act accordingly. However, what if the employee has personal or business data on the device, the continued existence of which is legally required by the courts and, although the device remains in the employee’s custody, it is wiped anyway? It may seem like a fringe case but I know of two large and extremely reputable companies that will not wipe a device without the express consent of the device’s owner because the devices can hold data relevant to regulators or to disclosure/discovery pre-trial phases of court cases (99.99% of the time they don’t, but these companies operate in industries that are unsympathetic to these kinds of errors).

The fact is people who work in a mobile way have data of real value on their devices and as, over time, the true internal/external business value of that work style develops, this data simply must not be wiped without due diligence.

My point isn’t that these fabulous features of MDM (as well as being able to set a password policy, black list apps etc) aren’t useful because they are. They should be thought of as small dots in the bigger picture of the policies and procedures you need to put in place around them. As the mobile picture continues to get bigger these dots will continue to get smaller. Or to use another analogy, MDM presents a range of tools that make every mobile problem look solvable in exactly the same way that a person given the use of a hammer sees every problem as a variety of nail.

So how do you develop a mobile strategy that is robust, encourages employees to get the full benefits of the technology, can be managed by the L1 team and will work in the general and fringe cases?

The trick is to have extremely strong business-led procedures around the devices. You can’t setup operating rules around using the device that are unreasonable to the employee because you can’t place any unreasonable restrictions on employees. Even if you have a clear idea of what is reasonable and unreasonable, make sure that your HR department agrees with you. Employment law (which is what this boils down too along with unfair or constructive dismissal) is not always sympathetic with headline features in the MDM tool set. You also can’t write L1 operations procedures which are too “reasonable” (aka nuanced) if your L1 team, along with a large percentage of your company, has English as a second or third language.

So rest assured that it can be done.

The most important step is to follow Chris Marsh’s advice and break the task down into two parts: device management is asset management; data management is best handled through encapsulation.

I mostly consider MDM a solution for corporately owned devices. Some non-corporate devices that need to access the corporate network, such as those owned franchise holders or sub-contractors, will possibly have their own MDM solutions already in place. Even employee owned mobile devices enrolled in personal MDMs will probably start to show upย  in work places before too long. You can’t enrol a device into two MDM systems concurrently. Asset management isn’t just about ownership of a device. Many of the asset management facilities of MDM can be still be implemented if you think your way around them hard enough and your vendor’s product supports what you are trying to do.

Anyway, for asset management try a two-pronged approach. Most importantly, use relatively few of the traditional mobile OS supported remote management features MDM supports. Choose your set based 100% around how your service desk team can be asked to use them. Maybe write your L1 and L2 manual around your use cases and then track backwards – whatever works for you.

In parallel, work out how to tie MDM into your asset management systems and configuration management database. It doesn’t hurt to read all of the L1 and L2 tickets every week and see if requests are coming in from employees that are being misinterpreted, escalated to L2 or L3 or related to functions you elected to leave out. It may save the service desk group quite a bit of money,ย in light of these reviews, to rewrite the knowledge base, adjust the MDM functions available and move some roles around if you find out you were wrong in your early analysis.

Next, if you can arrange a feed into your MDM setup from your asset ordering system, you can use MDM to send out mobile device enrolment information to staff as their corporate owned devices are delivered to them and then make sure the serial numbers match when they enrol. In jurisdictions where it is important that communications originating from corporately owned are fully managed (one of the deal breaking issues in the US in certain industry sectors) this can ease a lot of conversations with mobile skeptics.

Even better, if you can use MDM to dynamically update your CMDB with any company software that is installed (a good MDM system will be able to tell the difference between company managed and privately installed software) , then you can track licences using your company’s normal tool. There is no need to extend your general IT licence management processes to handle yet another exception, in this case for mobile devices, because MDM becomes merely an information source for your system of record. Essentially you can use MDM as a hub that incorporates mobile devices into your standard asset management toolset. The API of systems like AirWatch (using REST) are getting stronger all the time and this sort of integration is part of their product plan. I am sure that MobileIron, Mass360 and SAP’s Afaria (among all of the rest) are developing along similar lines.

How to manage encapsulation as a way of managing data is another step up in sophistication. Its benefits and techniques are useful equally on corporate owned devices as on BYOD.ย 

Thus it deserves its own article, so stay tuned.

By Julian Cooling

Julian is a mobile strategy and infrastructure consultant available for short and mid-length engagements. He is comfortable working with the mind leaders in the enterprise and engaging closely with the technical teams to get something working and demonstrable (taking his turn at the keyboard when appropriate). He is also a firm believer that technology is all about what companies "do" and not what they "have". To that end widely distributed operating procedures, training materials, documentation and help desk knowledge base articles lie at the heart of every successful mobile implementation. Julian can be contacted via his LinkedIn Profile.

6 replies on “Mobile Device Management: Is it the Answer … or is it the Question?”

Sorry to say this, but this is the biggest load waffle I have ever seen posted on MIR! Not impressed by a ridiculously long article pretending to give an authoritative opinion on something they are supposed to be expert on (?) when the fundamentals of device management are fairly clear, or am I missing something? Or maybe that’s the point trying to be made here? However, if so, please cut the crap and get to the point that could have been made in one paragraph! I read MIR for insightful news, not ‘cotton wadding’.

Robert, I’m sorry you react in that way to it — I’ve actually had a lot of great feedback from a number of executives commenting on how useful the first two of Julian’s posts have been (particularly his comments about preparation with HR/Legal).

…And I totally agree with that sentiment! I really enjoyed both of Julian’s first two articles and was looking forward to reading more from him. Maybe it’s just me on this one and I’m totally missing the point here. It’s well written, yes, but I can’t help but feel this is a subject that is being covered to purely fill a CV space to have published something about it. It doesn’t seem to really go anywhere. Let’s put it this way, I got to the end and thought to myself, for the first time ever after reading an article on MIR, what a waste of time it was reading it. As a regular reader who reads every article published, I am simply giving an honest opinion.

Bring on the honest opinion Robert. That’s probably the most refreshing and exciting point when it comes to the MIR audience.

I was buttonholing Julian back at the recording of one of the 361 Degrees Live events last year (or earlier this year, I forget!) asking if he’d share his experiences — and I think that’s the most valuable part here. It is pretty specialist. You’re going to have to be pretty keen on the whole MDM world to want to read this particular one in depth, especially with phrases like “data management is best handled through encapsulation” ๐Ÿ˜‰

Now, I could have edited Julian’s content down to 6 paragraphs. But that’s no fun. For anyone who really does care about these issues I think it’s particularly useful to read his viewpoints in big sentences and big paragraphs straight from the fingers of the chap himself.

For those who’re living this — and I know quite a few executives having these debates right now — I thought it would be useful.

I’ve got a few more from Julian to publish Robert… have you got any requests? ๐Ÿ˜‰

I totally agree it’s specialist, but here’s the rub, I am extremely keen on this as an area of interest as it is being unintelligently handled by the company I work for, despite my protestations to the contrary. I totally understand where he’s coming from and even agree that “data management is best handled through encapsulation” as this is the basis on which BYOD is best based despite what others would have you believe. Unfortunately, this doesn’t change my opinion on the article, but it also doesn’t prevent me from wanting to hear more from him. The only thing I would ask is that the next article is a little more concise please ๐Ÿ™‚

The next article about integrating mobile app dev into an SDLC (a hot topic in many firms right now) has been proofed and is waiting on Ewan’s publishing queue. However, if he is happy to hold off for a day or two, I am willing to try and make it punchier.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.