Critical Testing Criteria: Mobile Apps for Systems Management

The convenience of being able to perform common systems management tasks by using a mobile device rather than a full-blown desktop is appealing to IT managers and staff alike. Whether your preferred device is a smartphone or a tablet, there is a bewildering array of tools out there competing for your screen as well as your wallet.

Systems management is exploring a new frontier-your
pocket. Although the idea of using mobile devices for remote management isn't
new, the choices available to IT managers and staff are growing by leaps and
bounds. Of course, the more portable the device, the more likely it is that
you'll have it with you when you need it. With that in mind, here are 11 things
that are the most important considerations when you're evaluating go-anywhere
management tools.
1. Security,
Part 1: There's no way to overstate this concern. The tools you use have to
provide an acceptable level of protection both of credentials and of
communications. Encryption is a must, but take a good look at key lengths and
encryption algorithms as well, both for data stored on the device or data in
flight.

2. Platform
support: In the majority of situations, a tool that can work with 80 percent of
your installed base is more useful than a tool that's able to get very granular
with only half your systems.

3. Eschew
needless bling: Flashy apps may impress your friends when you're standing
around a bar, but make sure that alerts and event triggers are configured to an
appropriate level. There's nothing worse than having to pull out your mobile
every 10 minutes, on what's supposed to be a day off, for what turns out to be
a series of "never-mind" messages.
4. Only
carry what you need: It might be cool to have the entire IT equipment inventory
in a database on your phone, but do you really need it to follow you home?
5. Backup,
backup, backup: The phone is no place for irreplaceable data; put that stuff in
a proper repository. If you're collecting data in an app that doesn't let you
export it with ease to desktop or server applications, you're just asking for
trouble.
6. Security,
Part 2: Does the application provide its own security, such as a passcode lock,
or does it rely on the device's built-in protection, which may or may not be
active?
7. Offline
vs. online: Does the application provide for offline operation? Many server
rooms don't have very good mobile reception, and you may not want to provide
wireless access in this part of the operation. A trouble ticket application is
one example of an application that doesn't need constant network access to be
useful.
8. Assume
the worst: Your device will be lost or stolen, and someone will guess your
password, unlock your screen, and turn off network access before you can
initiate a device wipe. What do you do that's more constructive than updating
your resume?
9. Input
has its limits: Mobile devices such as smartphones don't have a lot of screen
real estate to devote to interface elements that are taken for granted on the
desktop. If the app relies too heavily on drop-down menus, it may be difficult
or frustrating to use when there are many items to choose from.
10. License
portability: "Who paid for the app?" becomes a problem when someone leaves the
company and you want to give the new hire a toolset matching that of the former
employee. Look into licensing that bypasses the user-oriented app markets of
device vendors.
11. Don't
forget the back end: What do you need to install or configure on other systems
in order for the app to be useful?

P. J. Connolly began writing for IT publications in 1997 and has a lengthy track record in both news and reviews. Since then, he's built two test labs from scratch and earned a reputation as the nicest skeptic you'll ever meet. Before taking up journalism, P. J. was an IT manager and consultant in San Francisco with a knack for networking the Apple Macintosh, and his love for technology is exceeded only by his contempt for the flavor of the month. Speaking of which, you can follow P. J. on Twitter at pjc415, or drop him an email at pjc@eweek.com.