How to Select a Mobile Device for Enterprise Mobility

Over the last few years consumer devices have overtaken enterprise devices in a lot of ways. Many of the features originally developed for the enterprise are now leveraged in mobile phones that we all have. Does this mean it's a no-brainer when it comes to choosing a device for an enterprise mobility project? Far from it, more choice brings more debate and more confusion. While BYOD may suit many organisations and mobile solutions it's worth looking carefully at your own situation to determine which devices are appropriate.

Obviously amongst the fields of consumer and enterprise mobile devices there is a lot of variety and the technology is changing rapidly. What does stay more or less constant is that businesses want to get value for money. I'll cover some of the key points to help you make up your own mind about what is right for your initiative. I'd suggest making a decision based on a good understanding of the current and future requirements. A good way to do this is by using a discovery, questionnaire, and/or workshop process. Try to ascertain what you can in the following areas:

Who are the mobile users?
When formulating a strategy for device selection I normally start with the user roles. For example:

• Executives
• Sales People
• Customers
• Subcontractors
• Service Staff
• IT personnel
• Consumers

What will each user group do with the device?
You might find a 1:1 match between use cases and users but normally there is some cross over, so it's important to understand what will be done with the devices. Here's some examples:

• Click through work flows
• Create content or enter lots of text
• Scan goods with a bar code or RFID
• Capture a customer's signature
• View large documents
• Take photographs of problems
• Search on the Internet for information
• Use mapping or Geo location services

Where and when will they use the device?
Of course the environment may vary within a user group. This might be the time when you determine sub-groups with slightly different needs. Thinking about the following use profiles may help you determine battery life, or IP rating requirements.

• In and around the city
• In rural areas
• Underground
• In a vehicle or forklift
• In wet areas, in the desert, in high temperatures
• With chemicals or explosives
• Occasional phone calls
• All day data entry

What are the needs of the software?
You may have covered this stuff when evaluating the use cases, however its good to cross check and consider any technical requirements that you will have for the devices:

• Particular operating system or version
• Browser that supports HTML5
• Anti Virus
• Offline Database
• Storage capacity
• CPU type
• Connectivity (Bluetooth, serial, usb)
• Printing

OK that's a lot of questions but once you have a handle on these areas you can map user groups, use cases, and form factors to help identify which device styles suit your business.  Often I do that in a spread-sheet format and if necessary you can apply weighting values to certain characteristics. So out of this work you should be able to determine the base requirements list for each device. Something like the following:

What are the device requirements?

• Screen Size
• Input Method
• Peripherals
• Battery Life
• 4G/LTE/Wifi
• Ruggedized or not

Let's not forget the non-functional, procurement, and policy type requirements you may have in your organisation. For example:

Non Functional Requirements 

• Vendors agreements
• Supportability of the devices
• Repairability / replaceability
• Staging and building the device SOE
• Security and IT policies

Now that you have a complete picture of the requirements you can factor in specific brands, models, and manufacturers. Around this point consideration is often given to whether a consumer device or an enterprise device is most appropriate. Remember you can always develop a policy or approval process that enables different devices to be chosen for different criteria. Here are some quick thoughts:

What are the pros and cons of enterprise and consumer devices?

• Enterprise device model life is much longer than consumer devices
• Enterprise devices have stable well tested components and operating system
• Enterprise devices tend to have better support
• Consumer devices initial purchase price is cheaper than enterprise devices
• Consumer devices tend to be better cared for than ruggedised enterprise devices
• Consumer devices have the latest technology (e.g. camera, CPU, OS features)

So certainly evaluate the Total Cost of Ownership (TCO). If possible consider the devices as part of your overall mobility solution and use a similar time frame for the cost calculation. E.g. if your ROI is over 5 years what will the device cost over this time frame? Will additional up-front costs be offset over time with better support and stability? As usual I'm in favour of understanding the requirements and making an informed decision. For some use cases and scenarios a ruggedised enterprise device will make the most sense and for many other applications a consumer device will work just fine.

Intuitive Prototyping

I've worked on a number of mobile and business applications over the years. And have always just used the tools I had at hand to mock up screens, write specifications, and show user groups what the application would look like. By tools at hand I mean print-screen and Paint, PowerPoint, Excel, or even Flash. However I always felt that there was probably a better way, especially when you have a large user community and are only able to leverage a small group in a workshop. I happened to be following up my testing mobility blog and came across Etay Gafni from intuito who had been kind enough to leave a comment.

I had a great chat with Etay, who incidentally has a fantastic side project bankaroo, about how he addresses some of the problems associated with application development. Intuito provides a mobile application prototyping solution with analytics, heat mapping, testing, and feedback capability. From our discussion it became clear that this wasn't just a product that was whipped up based on a brainwave. The need for this capability has come out of years of real-world application development projects. Etay was quick to point out some of the benefits including:

• Requirements validation
• Early user input & feedback
• Accelerated development cycle (RAD)
• Empowering non-technical folk

The product currently has a flexible subscription model, ability to brand, and numerous partnering options. It's encouraging that the tool is used by a number of large software houses and enterprises. For me I could see great use as an accelerator for presales, blueprinting, and design work. I'm sure intuito could find a happy home with System Integrators, Software companies, or Enterprises that develop their own applications.

Future of Mobile Computing

It's true that the lines between traditional mobile computing and desktop computing are blurring. The big OS vendors like Microsoft and Apple are producing products to enable a common approach to both mobile and desktop computing. Certainly work has been going into the 'one OS to rule them all' story even amongst smaller players like Ubuntu mobile. Also exciting is connected, m2m, technology for example with Blackberry's QNX. All these concepts & products are of course not the final step in a mobile world and history shows that arguably the best technology does not always win out (e.g. BETA vs VHS).  But I'm hoping that the concepts and new technology, if not the next best thing, are a stepping stone towards it.

It could be argued that User Interface is one area that really enabled a massive uptake of computing. Not that long ago a lot of companies had a secretarial pool and hand written business would be retyped by the pool. Once user friendly computers where introduced there was a real shift to word processing and shared documents.  Likewise with IOS and gesture based input the tablet market exploded. I'm excited to see the advances in the "minority-report" style interfaces, tactile feedback, and hope that more is done with mind machine interfaces.

Another angle driving change is technology and materials sciences like with bendable glass, larger screens, faster processors, smaller higher capacity memory, and better batteries. With the advent of powerful smart phones and tablets a lot of computing shifted from the desktop. I for one now use my tablet/phone more than my desktop PC at home. With everyone scrambling to make "smart watches" and new device form factors this area of wearable technology is a growth segment.

Finally software that combines the best features of OS and hardware along with improving the way we communicate, work, or play is integral to advancements in computing. Sometimes this might be a new way of doing something we are already doing (like Microsoft's ribbon in Office) or a completely new way of leveraging the crowd, take social networking and marketing as examples.

It appears to me that it is a combination of technologies coming together that produce step changes in how computing is used. For example a great interface without the processing power may be unresponsive and stop user adoption. Or connected devices without useful software may limit uptake.

So stepping back to try to understand where mobile computing is going I figure a good starting point is to consider the high level use cases. I've come up with some categories:

• Communicating (phone calls, basic emails, facebook, twitter, texting)
• Alerting (push, pop-ups, pager style events)
• Searching (research, location based, historical, previous interests, or other meta data)
• Capturing (photos, video, text, voice)
• Working (work flows, checklists, order taking, approving, timesheeting)
• Entertaining (gaming, watching content)
• Creating (editing spreadsheets, video, design, complex email creation)

Now for each of these categories I looked at how (for me) do different computing device styles rate for each category. Note I also use my television for the communicating, searching, and entertaining categories but I'll leave that discussion for my post on the Internet of a thing.

	Mobile	DeskTop	Tablet
Communicating	High	Low	Medium
Alerting	High	Low	Medium
Searching	Medium	High	High
Capturing	High	Low	Medium
Working	Medium	High	Medium
Entertaining	Medium	High	High
Creating	Low	High	Low

Of course your use of computing could be slightly different and you can argue around each of the classifications for individual users (for example a power user may find that they can only search effectively on a desktop) but my thoughts are:

• A mobile device / phone fits in the pocket, is easy to quickly access enabling better alerting, communicating, and capturing.
• A desktop has the best CPU, security, screen real estate, memory, and input mechanism but is not portable, takes time to start up, and I cannot be in front of it all the time. 
• A tablet is basically a phone with a slightly bigger screen (and arguably a better CPU, ram, storage).

What about laptops you ask? Well from this perspective they are the same as desktops. They can be moved from desktop to desktop but do not start up fast, their screen real estate is limited compared to desktops, they are not suitable for taking quick snaps of events, typically are not always on and therefore not reliable as an alerting/communication mechanism.

So mobile computing is not for every task (yet) and I believe a combination of improvements to interface, hardware, materials science, and software will continue to bring mobile computing closer to just being computing. My longer term vision of the future: 'google glasses' style contact lenses with mind machine interface, augmented reality, and swarm/cluster style processing, data storage, and device integration. I look forward to hearing your thoughts on this exciting area of technology.

Is it time to BYOD?

Is it time to BYOD?

Should you allow employees bring their own device (BYOD) into the enterprise? It’s a question that raises many others. Is the business data going to be at risk?  Can the business save thousands of dollars per year through not buying devices? Will the employees finally get the latest gadget they want?

The idea of employees using their own equipment at work is not new.  Using private vehicles for sales representatives, couriers, and truck drivers has a long history in industry. Likewise enterprise mobility is not new. Companies like Intermec and Motorola have developed fit for purpose mobile devices since the 1970s.  What has changed and continues to advance rapidly is the sophistication of consumer mobile devices. These are now more powerful and feature rich than ever before.  With the explosion of mobile device technology early adopters immediately brought the latest devices into the workplace. Before the iPad was released in Australia, it was being used in Aussie workplaces to show videos, take notes, and access email. Therefore the big question for enterprises isn’t “should we allow BYOD,” but “how do we allow BYOD”?

BYOD strategy success factors

If we further explore the analogy of vehicles in the workplace you will see some governing factors that ensure their successful use. Firstly there are situations (dare I say applications) where it may not be appropriate to use a private vehicle. For specialist fields like mining, police, and health or where there is a need for branding a company vehicle may be a better fit. Secondly there are mature policies that outline how a private vehicle can be used.  For example bicycle couriers may get a fee per delivery whereas taxi drivers must prepare and service their vehicle following strict guidelines. Another challenge to consider is that employees expect to be able to use their private vehicle in their own time for their own purposes. So what should the Enterprise do to prepare for the BYOD that is already happening? A useful technique is to develop a BYOD strategy that encompasses the requirements, risks, policies, and technology.

Current usage of mobile technology

The first factor to consider is how your enterprise currently uses mobile technology. The most common answers are phone calls, emails and associated attachments, calendar, internet, and map services. These features maybe low risk for most, however consider the specific risk to your enterprise and data. If a phone was found by a competitor what data could they get access to? Could a malicious user release commercially sensitive information or compromise a government regulation?

Increasingly, enterprises already use or are planning to use mobile technology to access the corporate network and back-end systems. These features of mobility warrant a closer review of the requirements and risks.  Typically these applications fall into the category of either Web Based or Rich/Native applications. Consider carefully what data and features the mobile applications enable? Could a malicious user download all of the customer data? Some rich mobile applications are akin to the police car in the vehicle analogy and require specific equipment to run properly (e.g. bar code scanning, a specific Operating System, or utilise a printer).  It may help to document each type of user and the features and applications they require.

Managing other risks and factors

While loss of IP and corporate data is of paramount importance there are a range of other factors your enterprise should consider for BYOD including:

·         Cost of support - how will you handle problems on BYOD devices?

·         Personal data – what if employee data is wiped or accessed?

·         Who’s paying – for the device, data, calls, and support?

·         Short lifespan – with models changing every 6 months what will your upgrade plan be?

·         Employees leaving – clean up the Enterprise data?

The right policies for your enterprise

This is a real “horses for courses” question. I’ve worked with small businesses that love technology and utilise every feature including geo-fencing and remote control of devices for support, but don’t require strict regulations on their data. At the other end of the spectrum government regulated industries that only use technology when they have to and every feature needs to be encrypted and locked down. In my opinion sensible polices should protect the Enterprise without hamstringing productivity and innovation.

When you have a good picture of your requirements, data, and risks think about the policies that your enterprise would want to include in relation to mobile devices. These policies may in fact be appropriate for both BYOD and corporate devices.  Most Enterprises have an acceptable use policy for their desktops and/or the internet and these may be a good starting point. Don’t just consider the technical policies (for example security, authentication, password strength, and data segregation) also think about the commercial (that is who pays for the data, calls, and support).

Managing the mobile fleet

I’ve seen a number of organisations where the mobile fleet is out of control and monthly fees are paid for dormant SIM cards sitting on a shelf. Consider all the device models, brands, and operating systems that you have out in the field. Do you have a mixture of old and new devices, iPhones for executives and ruggedized devices in the field? 

Just because your enterprise will support BYOD doesn’t mean it needs support every type of consumer device. Look at the popular consumer device models and consider your enterprise requirements and policies. You can create a whitelist of devices that are suitable.

Supporting tools and solutions

Once you have a handle on the BYOD requirements and policies you may need to consider a toolset like Mobile Device Management (MDM) to assist with the implementation of your strategy. Typical MDM features include:

·         Application management

·         Asset & lifecycle management

·         Authentication, policy & security management.

An MDM can help segregate personal and corporate data, establish a standard operating environment (SOE), and support fleets of devices more easily. However MDMs are reliant on the features provided by the operating system or hardware manufacturer. For example you may be able to remotely view the screen on a Windows mobile device but an Apple device might not support this feature. Likewise some MDM products are offered as a hosted service and others must be installed on your own hardware. Investigate the toolsets; a good starting point is Gartner’s magic quadrant for MDM.  If you’re thinking about IOS a great public resource is the Department of Defence IOS hardening guide.

Employees always want to utilise the best tools and mobile technology is an area that continues to evolve.  Be prepared so that your enterprise can cost effectively leverage the benefits of mobility. Develop a BYOD strategy that considers the requirements, risks, policies and technology. Consider that BYOD is happening but may not be suitable for every mobile enterprise need.

BYOD may suit:

·         Phone Calls

·         Email

·         Web Based Applications

·         Simple Workflow style Applications

·         Reporting & Business Intelligence

BYOD may not suit:

·         Applications that rely on rich device integration like RFID, scanning, keyboard,  or stylus

·         When a specific Operating System or API is required.

·         Scenarios where a rugged or IP rated device is needed

·         Where the business process is wholly reliant on the device

This article was originally published in Inside SAP magazine and also on Fujitsu's website.

Testing Enterprise Mobility

One challenge for any IT project is to ensure that testing is performed efficiently and effectively. As with many things the goal is to try to find a happy balance. In this case ensuring quality without spending forever on the testing cycle. Before I go any further my intention here is not to dwell on V charts, and testing frameworks but rather to talk specifically about testing enterprise mobile applications.

Key Considerations

• GUI
• Screen flow/work-flows
• Integration
• Mobile device/s
• Communications
• Infrastructure
• Security
• Roll-out

GUI, Screens, & Integration
Certainly a lot of the focus when testing enterprise mobility should be the application, its screens, and integration. Involving end users early (when managed correctly) can really help to ensure that the screen flows work under real use scenarios. Often functions can be tested independently during the development cycle. Device Emulators/simulators on a desktop can help rapidly test while waiting for the infrastructure and comms to be put in place. If the mobile application works in an offline way then ensure to test for data conflicts, locks, and test the resolution process. How can the solution recover from an integration error?

Mobile Devices
An important consideration that is sometimes overlooked is the wide variety of Mobile devices, models, operating systems, screen sizes, peripherals, and input methods that are being used in the solution. Don't assume that everything that works on Model X will automatically work on Model Y.

Battery life - does your shiny new mobile application drain the battery flat in minutes? Is it using lots of CPU when decompressing or encrypting data? Does it constantly require communications or gps? Schedule some tests to simulate different levels of usage.

Communications
Communications (or lack there of) should be checked. What happens when halfway through a transaction the comms is lost. What happens if comms is slow or poor? I've seen some creative ways to test this. For example underground car parks, driving through dead spots, or using a Faraday chamber. When projects first move from simulators to devices they are often cradled or connected via wifi. Ensure at some point to factor in tests based on real world communication scenarios.

Infrastructure
With infrastructure it's often not possible to directly replicate the production environment. However it's definitely worth looking at simulating traffic. Try running functional tests while ramping up the load and find out at what point problems occur. MEAPs often come with tools for capturing, simulating, and amplifying traffic.

Authentication & Security
Its obviously important to test the authentication and security mechanisms. Consider carefully how the authentication works and schedule appropriate testing. What happens when passwords expire or the user enters it wrong too many times. Some companies hire in specialists to attempt to compromise the system.

Roll-out
As part of the overall strategy consider using a technical go-live where the mobile application is put into production and tested without being used for real business. This may require assistance from the business to run through some transactions and then back them out. Once the technical solution is confirmed then one or two key users can be introduced to the solution. At this stage monitor the system thoroughly and adapt any changes as necessary. Once proven expand the user base gradually and ensure that performance is managed. On some projects it's necessary to initially throttle the performance so that the first user group does not feel negatively impacted once the entire community is live.

Please let me know your thoughts and any additional lessons learnt from testing enterprise mobile applications...

Not So Scary Spydr

Had a great conversation the other day with Michael Pratt the CEO of SpydrSafe. They have a very interesting new product that protects mobile applications and Michael has a wealth of knowledge in the enterprise mobility arena. Currently available for Android, and in Beta for IOS, SpydrSafe has a refreshing approach to enterprise and personal security.

What I found particularly nice about the product is its user focus. For example it clearly indicates which applications are protected and which are blacklisted. And while it looks good and is easy to understand don't worry its not just a fluff application. Underneath is a strong Data Loss Prevention (DLP) heritage with features like sharing control and copy/paste restriction.

Michael and I discussed the control dashboard as well as how SpydrSafe can fit into an enterprise ecosystem alongside MDM offerings for device management.

With the proliferation of mobile computing and the blending of personal and enterprise technology there is definitely a space for this kind of product. Obviously the MDM and Operating System providers are increasing their footprint, adding more and more features, and I bet some of them would love to get their hands on this spider.

Disruptive Mobile Tech

I had the pleasure of chatting with Kelly Fee from Capriza today. She did an excellent job of showing me their great looking product for "instantly" mobilising workflows. With this tool web based applications like Sales Force can be turned into mobile applications with impressive speed.

Starting with the Capriza browser plug-in Kelly showed me just how quickly and easily a workflow could be made into a html5 mobile application. At its simplest just step through the workflow as the user normally would, indicate which elements are required in the mobile application, and the app is built on the fly. Sounds easy and it really did look easy. As an example Kelly showed me how to create a mobile application in under 5 minutes with:

• Log on Screen
• Recent Leads List
• Display lead details
• Edit Leads

While stepping through the workflow to "record" the mobile application a wysiwg display on the side of the screen showed the elements as they would appear in the published application and allowed some resizing/editing. Once finished a look and feel could be applied to the application before publishing it ready for use.

Kelly and I then discussed at a high level some elements such as the architectural model (which can be either hosted or on premise) and the licensing model (which is typically per user). Also what use cases and scenarios would best fit the product and who the users of the product could/would likely be. As a previous business user of Sales Force I've seen the super user type who is always building new dashboards and reports along with the complete opposite users who only log in under sufferance. From a business-IT standpoint I could see that you could defiantly use Capriza to create mobile workflows. And from a Systems Integrator point of view it would be great to be able to use the Capriza framework as a starting point or accelerator to create and pilot applications. Perhaps an advanced mode or developer mode that could be sold to SI's allowing a template to be built or combinations of applications to be joined together like building blocks.

All and all I felt that this was an exciting product that had a lot of potential. Honestly if you have been in enterprise mobility for any time you would know that the simplest looking things are often the hardest to get right. Some things to consider of course are that the HTML5 approach is not suitable for every type of mobile application or use case but if your starting point is a web based application then it will probably fit.

B2B Mobile Applications

Business to business (B2B) mobile applications, like all enterprise mobility apps, are becoming more prevalent throughout industry. These applications continue to be explored as an improvement to paper based interactions and are often looked at to replace or augment EDI type interfaces between organisations.

Use Cases

• Pharmaceutical industry providing solutions to pharmacies to manage inventory and reordering.
• Third party logistics (3PL) providing solutions for inventory management and proof of delivery.
• Wholesale manufacturers providing mobile product catalogue applications to retail buyers.
• Marketing companies providing mobile survey applications.
• Utilities providing service and/or data collection mobile applications to subcontractors.
• Mobile applications developed for conferences and trade fairs.
• Real estate industry providing mobile application for outsourced valuations and inspections.

I've just scratched the surface and as you can see this is a broad brush of different types of mobile solutions. Some would work best with dedicated hardware & native/hybrid solutions and some may be better suited to a web-HTML5 style application.

From the simplest solution where data is collected and imported via a report or spread sheet through to fully integrated solutions used by many parties. These applications offer some great rewards for businesses and for IT departments. However they are not without their challenges. I've listed a few experiences of the challenges and rewards below:

Challenges

• Licensing (named users, volume of transactions)
• Scheduling of work in subcontracting scenarios
• Integration to back end systems
• Application updates and changes
• Security
• Change Management and training

Benefits

• Lock in a customer to your products/solution
• Reduce effort related to paperwork
• React more quickly
• Reduce IT complexity
• Enforce your process
• Have an edge over you competitors

I'd be interested to hear of more use cases, challenges, and benefits so please contact me to discuss :)