Six Tips to Craft Your IBM i Mobile Application Strategy

Development Tools / Utilities
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Carefully consider what mobile apps can do for your business before you shop.

 

Mobile computing is hotter than the heat of a thousand suns in the IBM i arena right now. Like a lot of technologies that have come down the IBM midrange pike before it, mobile computing is surrounded by hype and hoopla of the highest order. But make no mistake; mobile computing is very important and needs to be considered by nearly every IBM i shop. This article identifies several things IBM i decision-makers need to understand about IBM i mobile computing.

 

Don't wait for mobile computing to mature on the IBM i. It's real today. It wasn't that long ago when very few mobile computing solutions were available for the IBM i. But in the last few years, many vendors have stepped forward with high-quality mobile solutions. There are a variety of models and implementations, so as you've done with any other important IBM i decision, you have to perform due diligence to be sure you select the right thing. With that understanding, there's very little merit in saying, "Well, we're just gonna wait a little while longer before we start investigating mobile on the IBM i." For most IBM i shops, if you say that, you might as well also email your biggest competitor your customer list.

 

Think big, but take baby steps. You can do amazingly cool things with mobile computing on the IBM i right now, but do you know what mobile can really do for your business? Don't consider mobile in the context of what you're doing now—those problems are solved. Think about the new doors that mobile could open for you. Be broad and be bold. On the other hand, as your ideas start to get a little more concrete, don't set out to completely re-craft your entire business workflow with mobile. Get a little tactical experience under your belt with focused, small mobile solutions first. These early forays into mobile computing will help you understand how, in your environment, your bigger dreams and goals can be accomplished.

 

Beware the BYOD challenge. For years, you've provided your employees with their IBM i workstations. Today, they all come to work with a potential workstation in their pocket or purse. As you discuss mobile computing with your employees, you probably find little consensus on what brands are best or even what models within a brand are best. For anal retentive IT managers, the notion of BYOD (Bring Your Own Device) is cringe-worthy. You may want to provide with them all with an "official" device, but you'll probably encounter pushback on that; one of the benefits of mobile computing is convenience, and it's hardly convenient if requires another device. We all have too many devices already!

 

If you elect to let employees use their own devices, be aware that even across different versions of any one phone, capabilities can vary widely. You'll want to test early and often across lots of phones (another reason for the "baby steps" approach) before you can be comfortable announcing who can use what. Gone are the days when you screw a coax cable into the back of a commodity 5250 workstation and call it a day! Consider devices, needs, costs (especially if you think you need to buy everyone devices), and capabilities carefully. For most typical users today, Android and Apple devices prevail in the U.S., with a smattering of Windows 8 devices. BlackBerrys and other earlier-generation devices are pretty much out of the loop (however, even older brands/models remain popular in Europe).

 

Consider the security aspects of mobile computing. I don't have empirical data, but I'm inclined to believe that any one IBM i-related vendor's mobile offerings are as inherently secure as the other vendors' offerings are. While architecture and implementations are worthy of questioning, I think a bigger exposure lurks. And that's with your users and the login credentials they could have cached on their mobile device.

 

Imagine what your security policies would have been back in 1989 if it had been possible for your users to leave signed-on Model 5251 display stations running at Starbucks (you also need to imagine that we used Starbucks for remote offices back then, too!). With IBM i mobile apps, that's effectively what your users can do today with their pocket- or purse-bound devices. As you consider devices and device usage, have a well-considered plan in place for how "convenient" your mobile apps make logging in. Cached user ids and passwords are great—if you're an end user. They aren't so great if you're an organization's enterprise security officer. Stand your ground! Tell your users that your mobile apps will be as convenient to use as possible but that security comes first.

 

Native versus HTML5. There are three primary types of mobile applications today:

 

  • Native: Native apps are written specifically for a particular device. Apple, Android, and Microsoft mobile apps all require different languages and different development environments. Because there are three code bases, three specialized skills required, and essentially the three efforts to write these different versions of the same app, this can be an expensive option. Native apps are typically installed from a vendor "store" such as the Apple Store or Google Play.
  • HTML5: HTML and JavaScript have matured to the point where together they provide a good cross-platform solution for mobile apps. The look and feel of this type of app can rival that of a native app. Take a look at the jQuery Mobile Gallery to see the kind of look and feel that can be achieved with HTML5 apps. HTML5 files also provide good affinity with the hardware (so, for example, it's easy to integrate HTML5 apps with device facilities, such as dialing a number, determining its GEO location, or initiating a text message). One set of developer skills provides an app that can run across multiple devices. HTML5 apps aren't installed locally on a mobile device; they're launched from the device's browser.
  • Hybrid: Although HTML5 apps integrate well with device hardware, there are gaps. Barcode integration, for example, isn't natively accessible from HTML5 and JavaScript today on most devices. These hardware integration gaps have given rise to the third type of mobile app, the hybrid app. A hybrid app provides a native browser shell that runs an HTML5 browser in that shell. These device-specific shells do a couple of important things. Most notably, they provide device integration between the phone and HTML5 for things HTML5 doesn’t currently support (such as barcode scanning). These shells also provide more control over browsers, such as the potential trouble that a browser's back button can cause.

 

Which is best? That's subjective. If you're a nationwide retailer and you need to offer a first-class shopping experience for a variety of different users, the native app is probably your best bet. But it's also probably fair to say that if you're a nationwide retailer, you have a large, diverse, highly skilled development team that can handle the challenge of writing three different versions of a shopping cart app.

 

If your needs are more departmental and your development team matches the profile of most IBM i shops today, you're probably most interested in the HTML5 or hybrid approach. Using IBM i tools from several vendors today, RPG programmers with little or no mobile development experience can create great departmental apps for you.

 

Have realistic offline expectations. I've spoken to several IBM i executives who claim, or at least initially claimed, that the ability to use a mobile app offline (that is, not directly connected to the IBM i and able to upload and download data when a connection is available) is very important. The reality is that the work to do this correctly and with reasonable assurance that data integrity can be maintained is very challenging. The pipe dream is that a salesperson can continue to take orders, or make quotes, while in a cabin in Meadow, South Dakota. Consider, though, the data required, on the mobile device, to achieve this goal. You need to be able to push a lot of IBM i data onto the mobile device (all that it takes to calculate discounts, assume inventory levels, and determine shipping costs), and you need to be able to synchronize that data with the IBM i reliably. And you need a gracious way to tell your customer that the order taken with your phone may not be doable because some of the data changed on the IBM i after you populated the phone with its data.

 

There are rational ways to do this, but they're probably more tablet-driven than they are smartphone-driven. And, if the recently announced Microsoft Surface 3 excels at anything, this type of application may be it. That device is half tablet and half laptop (Tabtop? Laplet?), and you can install a rational database of good size on it. Not so much on a smartphone. The bottom line: carefully consider your offline needs and think them through with rational expectations. Offline operation of mobile apps is something that's easy to claim but very challenging to do in a way that truly meets expectations.

If Only It Was Easy!

As I said earlier in this article, mobile computing is available today for the IBM i and it should be very high on your radar. The day is rapidly approaching when mobile computing won't just give you an edge; it's going to be necessary for survival. Don't ignore it!

 

Is there a silver bullet for you? Is there a way to minimize the risk and stress associated with acquiring IBM i mobile apps for your organization? Yes, there is. And you've done it many times over the last many years: Don't believe anything any vendor shows you and believe only about half of anything any vendor tells you! Do your homework. Carefully and rationally consider what mobile can do for your business and go into the conversation with tough, challenging questions.  

 

BLOG COMMENTS POWERED BY DISQUS