Mobile devices are, by their very nature, extremely mobile. Their very mobility is one of their great strengths. Yet, riddle me this: how can device mobility create a double-dip hurt on productivity by simultaneously being too mobile and at the same time not mobile enough?
The answer to the riddle is simple: when a mobile device is used by application developers or testers. There are plenty of times when a device isn’t mobile enough: it is needed in the morning by the testing group in Omaha and is needed in the afternoon by a testing group in New Delhi. There are also plenty of times when a device is too mobile: it is needed today in the test lab but sits in the backpack of Sally who is at home with the flu. This dichotomy, mobility that prevents using a device and mobility that is insufficient to enable using a device, plays out in dozens of scenarios in test and development labs every day.
Its Easier to Buy a 777 Than a Tablet?
One wry joke making the rounds in IT these days is that it is easier at a trucking company to buy a new 18-wheeler or at an airline to buy a new 777 than it is to buy a single mobile phone or tablet. That this should be true makes sense, in a way, when you consider that a truck or an airplane may in fact be cheaper. That idea makes no sense until you recognize that everyone in the company usually wants and professes need for one – or more – mobile devices.
If an organization has 100,000 employees and buys each one a phone and a tablet, the outlay could reach north of $100,000,000. With that kind of money at stake, it’s no wonder many companies have put enough red tape between an employee and a new mobile device to weatherproof a cell tower. The logical answer, of course, is that the company should recognize the special needs of development and test and make exceptions to the rules. However, one QA manager at a major airline resignedly told me earlier this year that it takes her six months to get approval to buy a single tablet.
Playing Mobile Musical Chairs
If the assets are hard to acquire, they are even harder to track and find. If a typical group of 10 testers shares three iPhones, a game of musical chairs results. Some organizations use shoeboxes of phones and a spreadsheet to track who has what device. Such systems may work in a small lab where everyone is within shouting (or walking) distance. But as soon as teams become dispersed by as little distance as a single floor, when the music stops, someone ends up with no seat and no idea where to find a needed device. Defensive measures ensue. Devices are checked out before they are really needed or are retained because the developer or tester thinks she will be ready to test in the next day or so and doesn’t want to give up the device only to end up later with no device and no prospects. The two days that the device sits on Frank’s desk because he may need it by the end of the week are completely wasted time.
In fact, all of the problems I have mentioned so far cause wasted time. If the device is home, or lost, or in a desk drawer and forgotten, or is being hoarded by a well-meaning developer or tester, time is likely to be lost by others who could benefit from the device in the meantime. What is needed is a way to make all devices available 24×7 from a central location using a virtualized access model. A tester should be able to contact a server, obtain permission to use a device, connect to the device, and then return it to the pool. With increased odds that the device will be available later, at the time it is needed, the tester or developer is less likely to hoard. Administrator controls can also show management when devices are retained but idle so they can be quickly brought back online.
The final, unlikely but nonetheless devastating possibility is that a device becomes permanently “appropriated” either for legitimate business reasons or because it has just plain been stolen. If it takes six months to acquire a replacement, the lost productivity will soar. Asset management, security, and explicit lack of mobility are all factors that raise the dichotomy: we can protect the device only at the expense of its most salient feature, which is that it moves easily from place to place. Stopping the mobility is the only way to protect it. Virtualizing access is the only way to make it available without compromise.
Managing the Unmanageable
There are probably business-school paradigms and algorithms to model and manage such problems. But there is also a simpler solution: virtualizing access using an internal device cloud. In such a scenario, devices are pooled to form a central lab that is accessible by local area network and by virtual private network anywhere within an enterprise’s worldwide infrastructure. For such a solution to be viable it should accomplish the following objectives:
- Secure the devices in a central location that can be made physically secure if needed. We thus stop the mobile devices from moving – and becoming lost or stolen.
- Make the devices available remotely to authorized users wherever they may reside in the internal network. We have thus made the devices – in a virtualized sense – infinitely mobile. A device can be in use by a developer in Omaha at 10 am and then used by a tester in New Delhi at 11 am. All that is needed to make the solution work is a management interface that inventories devices, enables authorized users to access them, shows which are available or in-use, and contains the needed housekeeping functions to keep the pot boiling.
The Old Public vs. Private Debate
Some firms have offered public-access clouds of mobile devices, but such solutions involve giving up too much control to the public vendor. Like the old party-line telephone, it is too easy for others to snoop into what happened on a mobile device before its current use or to mount man-in-the-middle attacks. Moreover, if such a remote cloud solution requires jailbreaking or rooting the devices, the user and the cloud implementer face the possibility of license violations, copyright violations, and the unknown of running third-party so-called ‘jailbreaking’ code which may alter test results or perform what Apple called in its brief to the Librarian of Congress, other “mischief.” Such mischief might include keystroke logging, identity theft, or virus propagation.
For the kind of device cloud that I foresee to be truly viable, it should accept the organization’s mobile phones without the need for jailbreaking or rooting (running unexamined third-party code), and it should be possible to use the full force and pressure of the enterprise’s network and data protection mechanisms to keep proprietary data from leaving the enterprise.
Bringing Order to a Fast-Paced, Chaotic Mobile World
Business-school algorithms should be able to confirm what I see intuitively: productivity and security will be greatly enhanced by making it possible to move access to devices around the world instantly and yet know where they are both physically and logically and that they – and their data – are secure. Let’s call this concept private “mobile device lab management” that can bring order to a very fast-paced and chaotic world. Such a product doesn’t have to be ‘heavy’ or built of racks of equipment. It can be light, support, say, eight or sixteen devices, and be installed on a mobile cart. We could achieve the best of both worlds – enforcing a needed lack of mobility for mobile devices and yet granting instantaneous, virtualized availability. App development and test groups would greatly enhance productivity while increasing control and manageability of what has heretofore been an unruly infrastructure.[social-bio]