This is a summary post that ties together six previous posts that were written as a series. The idea for the series comes from a recurring scenario that I have encountered. Several times in the last few years I have been in a meeting discussing a Mobile Device Management (MDM) strategy and when asked about business requirements the client responds with something similar to the following:
“I want to be able to do all of the things that I do on my desktop on my iPad.”
The statement illustrates the confusion around both MDM and strategy. I don’t want to get too bogged down with all of the problems with that statement. I will call out a few items of note:
- This is not a business requirement as it is not tied to any business process that creates value. There may be value in achieving the end result but the statement does not convey the value. Additionally, the cost associated with the solution may eclipse any value.
- This does not in itself create any new capabilities for the organization. It simply shifts existing capabilities to a new form factor.
- The user experience of trying to use desktop applications that are designed for a mouse and keyboard on an iPad could create negative value.
- Most experienced tablet users would agree that tablets are better suited to content consumption rather than content creation. While technically possible, data/content creation is generally more efficient in a more traditional form factor.
- Apps designed specifically for a tablet form factor for specific mobile solutions like form completion that includes prepopulated selections (E.g. point of sale, survey taking, etc.) create new business capabilities that take advantage of the mobility enhanced form factors.
The rest of this post is intended to help the reader avoid some of the pitfalls of this type of approach to MDM. This post is not intended to provide a complete MDM strategy but to help you understand the important elements of the strategy and the types of questions that need to be answered. The major areas of focus for this post will be:
- Data Access and Protection
Notice that Devices is dealt with first last. Many organizations are designing their MDM as a reaction to the devices that are being brought into the workplace – This is akin to designing the aircraft while it is in flight. Although I take a more strategic approach that avoids dealing with devices at the outset, don’t dismiss this approach if you already have devices that you need to deal with. Remember that the device refresh cycles can be very short and the cost of new devices is very low. A well planned strategy can create ROI even if device replacement is required.
Do you have specific applications that you need to run?
While this question seems academic, many organizations simply use mobile devices for voice, email, SMS, browsing and other out-of-the-box functionality. For these organizations, applications LOB or otherwise are not part of their use case scenario. If you answer no to this question, you don’t need to read any further than the next sentence. Your options for devices will be very broad and you will need to find other ways to rationalize the devices you will support. If you answer yes then please read on.
Are they COTS or Custom Applications?
Are the applications that you require commercially available or are they custom built?
If the applications are COTS, what platforms does the vendor support and what licensing model do they have for each platform? If they support multiple platforms, do they support mixed environments? What about application deployment? Do they support enterprise deployment and managing through sideloading (or some other mechanism) or is the only option purchase from the platform store (iTunes , Google Play, MS Store, etc.). Is the application available in all geographies and languages that you require?
If the application is an in-house or outsourced custom application, the same questions that are required for COTS applications need to be addressed however, some additional questions need to be answered as well. For example: What is the level of expertise that your development team or partner has with various mobile platforms?
Does the application have any specific security requirements?
Does the application have specific requirements based on the data that it will manage and process? For example: Will credit cards be processed and are there PCI compliance requirements? Is there personally identifiable information or health information? Does your organization already have policies for dealing with this data and does the mobile app need to comply with them? Think about items like encryption for data at rest and data in motion, VPN, passwords, etc.
Does the Application have any other specific requirements?
Understanding any hardware or software requirements for the applications will also help to filter the list of potential devices. Consider some of the following as a starting point: Does the application require a specific browser or browser support? Does the application require a camera? Are there any networking requirements (Wi-Fi, 4G, etc.). What about disk space and memory? Is support for adobe flash or java required?
The objective of answering these questions is to start narrowing down the list of potential devices that can meet your requirements and identifying any non-technical challenges (policies etc.) that must be addressed.
Understanding User Requirements
Many of the same techniques we would use as part of a standard workforce analysis are useful to build a mobile device user strategy. Typically we would create a series of personas that represent the user population. Personas are fictitious, specific, and concrete representations of target users. For an overview of workforce personas, please refer to the Ted Schadler’s blog. Once personas are created, you will need to understand the use case scenarios that each persona will be presented with. In an organization with many personas and scenarios, it might make sense to prioritize both personas and scenarios to focus on the most important combinations. It is the combination of personas and use case scenarios that will lead to the solution design.
Once the personas are use cases are defined, create a matrix similar to the one presented above. For each cell in the matrix consider the following question and record the answer:
Which of the following does the Persona in this Scenario require?
- Access to web-based apps on-premises
- Access to web-based apps in the cloud
- Access to corporate mobile apps
- Access to files located in file servers on-premises
- Access to files located in the cloud
- Access to computers using Remote Desktop
- Access to other computers located on-premises
Do you need to link Users to Devices?
Although we are not addressing devices specifically at this time, it is also a good time to determine whether or not there is a requirement to map users to the devices that they use. This requirement may be driven by many factors including:
- Asset Management (SAM/ITAM)
- Compliance Requirements
Data Access and Protection
Data Access deals with how users gain admission to data (and applications). What we need to address is how the various personas and use canes scenarios impact current security policies, applications and infrastructure. Some of the questions we need to be asking include:
- What are the authentication requirements for users to be able to remotely access company apps from their devices?
- Where will the authentication services reside and how will they be managed?
- Is the current platform able to enforce authorization per user and per app without having to rewrite the apps?
- Is it possible to enforce Multi-Factor Authentication according to a user’s location?
- Are current remote access methods adequate for the mobile scenarios you’ve defined? (When we deal with devices we’ll determine whether the UX (User Experience)is acceptable)
Protection and Access go hand in hand. Data Access provides capabilities to enable specific use case scenarios while data protection helps ensure that the data remains safeguarded. The safeguarding of data is a balancing act as too much security can make the UX
- How will data be stored on user’s devices? Will it be encrypted? What is the risk of data loss is it cannot be decrypted?
- What is the risk of data los if the device is lost and the data is not encrypted?
- Will any corporate data stores be accessed by the device? Where is the data located (datacenter, cloud, other)? Will additional safeguards be required for the data being accessed? Will it be encrypted?
- How will data be transferred to and from the device? Will it be encrypted in motion (HTTPS, IPSEC)?
- Will any infrastructure changes be required (PKI, firewalls, gateways, etc.)
- Will the safeguards impede the UX?
- Are there any regulatory compliance issues that need to be addressed (SOX, PCI, etc.)
These are just a sample of the items you might want to consider as part of your MDM strategy. Please let me know if there are other items that you would consider when defining your data access and protection strategy for mobile devices.
“Management” is part of the phrase “Mobile Device Management” but what does it mean in the mobile device context? Management refers to the services and capabilities that will enable IT to measure and meet the objectives of the strategy. These services and capabilities include (but are not limited to) the following:
- Monitoring (users, devices, compute, storage, etc.)
- Provisioning & Configuration
These services and capabilities can all be very complex depending on your use case scenario. In the following sections I will provide some key questions that should be answered for each of these services and capabilities.
- Do you have the legal ability to monitor the devices (consider BYOD)
- Do you require agentless or agent based monitoring capabilities? Perhaps a mix depending on use case? Are agents available for your devices?
- Will you enforce policies or simply monitor adherence?
- Will you require remote management capabilities (E.g. remote/selective wipe)
What are your reporting needs? Do you have specific compliance reports (regulatory or otherwise) that need to be available to auditors? Is your device ownership model (BYOD, CYOD, COPE. Etc.) driving specific reporting requirements. Some examples of the types of reports that might be required include:
- Device Hardware (make, model, firmware, memory, camera, IMEI, SIM, carrier, etc.)
- Device Software (OS Version, Apps Installed,
- Device Configuration (PIN, encryption, certificates, jail broken, etc.)
- Which users are using which devices
- Which users use the most bandwidth (exceed quota, etc.)
- Which users are roaming regularly
- Last successful connection by device and user
- Failed connection attempts
- Device Locations
Provisioning & Configuration
Provisioning deals with how devices will be delivered to users. IT might be driven by your device ownership model and will involve answering some of the following questions:
- How will devices be delivered to end users?
- How will Applications be delivered to devices?
- Will it be different for different platforms?
- How will configurations be maintained overtime?
- Will automation be required to make it more efficient and scalable?
So far we have focussed on elements of an MDM strategy that are more heavily weighted towards created a high quality user experience while meeting enterprise policy and management requirements. We’ve really avoided discussing the actual mobile device. For many organizations the Mobile Device Management strategy evolves out of the device choice that they (or their users) make and are often reactions to incidents or tactical manoeuvres to address specific concerns. Organizations that want to be more proactive can find it difficult to shift the paradigm because the consumerization of IT is accelerating and IT departments are struggling to keep up. I know it’s counter intuitive but in order to have a successful MDM strategy it is imperative to understand the business requirements at the outset and prudent to understand the benefits of strategically selecting the devices that will be part of the strategy.
I have ignored to topic of devices up until this point not because of the relative importance of the subject, but because it is extremely important and in order to make educated decisions about devices, it is essential to understand the other subject areas as they all impact upon the device in some way. In essence, by the time all of the questions about the other subject areas are answered, the majority of the decision points for devices will be addressed. For example, once you understand your mobile application strategy, you should know the mobile device operating systems that you will need to support. This will drive the device selection. As such the number of questions in this section is small compared to the other sections. The biggest new decision points are focused of device capabilities mapping to other requirements.
Based on all of the information you have gathered so far, here’s a starting point of the types of questions you need to answer in this part of your strategy:
- What mobile device operating systems will you support?
- Will you require them to support Open Management Alliance Device Management (OMA DM)?
- Will you require that the device support specific management agents?
- Will you require specific networking functionality from the device (WiFi, 3G, 4G, VPN, etc.)?
- Have you reviewed the application requirement questions?
Devices are evolving at a rapid pace. They computational capacities are astounding and the built in manageability is iterating very quickly. Don’t let the capabilities of your current installed base of devices influence your long term strategy.
There are many things to consider in designing an MDM strategy. A great place to start is by asking what new capabilities your strategy needs to enable and what outcomes are desired. A good approach s to project your business at some point in the future (2 years) and envision what the business, customer, and user experience would be like if you had an effective MDM strategy in place. Capture that vision and use it to help you answer the questions that will shape your MDM strategy.
A great reference for BYOD with a Microsoft slant can be found on TechNet. I got a many of my ideas from this guide.