Five Handles For The Mobile Application Pot

March 26, 2012 Dan Burger

Developing mobile applications that access IBM i data have caused a wheel to come off more than one development team wagon. If it’s happened to you, you’re not alone. The widespread popularity of smartphones and tablets in the business world has violated the comfort zones of countless IT departments in the IBM midrange. Enough so that the debris and the success stories can be assembled into an article, which managers can use to better plan future projects.

Consider this as a five-step problem-solving exercise.

Begin with the belief that this can be done and should be done from an IBM i perspective or at least not without the input of the IBM i perspective.
Recognize whether you have the skills and the resources (including the available time) to do this. Factor in the choice of technologies.
Figure out a reasonable time frame and cost. Take into consideration application maintenance.
Set this up as a pilot project–keep it small and simple. Learning on a small scale is easier and mistakes are less costly. This becomes a phased project accomplishing incremental steps.
Know your end users. Make sure it solves a business problem.

The majority of information in this article comes from four sources with considerable mobile application project experience in the trenches. During the past week, I spoke with Aaron Bartell, who works with Krengel Technology; Roger Pence of ASNA; and Marcel Sarrasin and Kevin Cronin at BCD. All of these guys have written articles and made presentations on topics ranging from the vision of project management to the nitty-gritty details of application development.

The IBM i Perspective

Reality bites. And the reality is that often Web development and subsequently mobile development have been handed to the .NET and the Java programmers in shops where these development teams already exist. It’s not unusual for even the marketing and sales teams to have had more input than the IBM i staff. But when the facts hit the fan revealing that information on the IBM i is necessary for business to move forward, another decision has to be made on who is involved.

The best approach is to get all the development teams involved. And the good news is that more RPG programmers are invited to be on the team. And even better news is that more of them are smart about modern technologies.

If this is the first time the application development teams have sat down together at your company, you’ll find this can be more than a little awkward. No surprise. In more cases than not, there’s a history of incompatibility that managers have generally ignored. Building a cohesive team is not easy. You want members who are passionate without foaming at the mouth, thought-provoking rather than simply provoking, and technically savvy without being exclusionary or close-minded. Even if the IBM i team is in complete control, it can be difficult to find the right mix of skills and personalities.

One piece of advice is to avoid the platform-specific problems that take us back to the early days of RPG versus client/server architectures. Concentrate on data flow and flexibility regardless of the front-end technology. In shops where browser-based applications have become part of the norm, these arguments may already be resolved. If not, be prepared for many of the traditional battles that rage over who is competent and who is ignorant.

Skills and Resources

Managers need to build cooperation and recognize that all the skilled people have to be part of the team.

Skills for mobile application projects are directly related to a company’s overall browser-based application strategy. I’m told the majority of IBM i shops moving into mobile environments have experience in browser-based development. It may not be highly sophisticated, but it’s a head start on those that have made little or no progress in Web development and who are less likely to attempt a mobile project.

The tools and technology to build browser-based apps are mobile friendly. And rendering Web applications in mobile devices is the preferred method of delivering mobile applications. The other option is developing thick client applications that run natively on specific devices. This can work, but is considered to be development intensive even when it is done for a single device and exponentially more costly when developing for multiple devices. It also means the applications are subject to official approval by the App Police that maintain law and order for the device manufacturers–Apple for iOS and Google for Android, specifically. With an approach that uses Web apps rendering in a mobile device some functionality may be sacrificed–depending on how sophisticated the application is–but application development time is greatly reduced.

Because the experience in Web application development can be easily applied to mobile development, managers of successful mobile application projects either have staff with appropriate skills in designing modern user interfaces or they know where to contract for skills that fit in with the companies’ business partner relationships. They are also aware that when those skills are in-house the time to apply them to new projects may be limited or non-existent, which is useful in project planning.

The primary difference between browser-based and mobile application development is obviously screen real estate. When you define the user experience, you can’t fit 30 fields on a single screen like you can with a green screen or even a Web page. The skill comes in knowing how to separate screens and make them flow. The collection of data requirements or project requirements that need to be implemented doesn’t change. The concept remains the same, but it is accomplished with different technologies.

When RPG programmers learn these technologies, they become a more valuable commodity. When they don’t, browser and mobile application development moves to someone with the new tech skills. That’s tough for a lot of staffs that are up to their chins with the day-to-day activities. But that doesn’t change the fact that a project manager still needs a group of individuals who are able to use current technologies and know how to support data access.

The number of companies that need help with services are in the minority, according to my group of experts. The majority are using development tools and have acquired at least a functional level of core skills that are mobile friendly.

A familiarity with modern Web and mobile technologies can be learned, but only with willing participants. Don’t assume you have them and don’t assume you don’t. Find out before decisions get made without this input.

Calculating Time and Costs

If you are managing a project in a shop with little or no Web development experience, begin your planning with the knowledge that Web development–screen for screen–will cost more than green-screen development. Be advised that this learning curve can be painful for those up the chain of command. The reaction of an IT manager or CEO frequently depends on whether the project is viewed as a burden or a benefit. Without a cost-saving calculation, project benefits often are easily overlooked. For instance, when the savings in customer service hours go unnoticed, the project can quickly and inaccurately be labeled as overly expensive.

Because mobile projects are closely related to browser-based projects, the estimated time and costs can be figured on past browser-based development experiences. Of course, that doesn’t do you much good if your company hasn’t traveled that road. If that’s the case, then you are probably in need of acquiring services from an external source. And the cost estimating will be that company’s responsibility.

You can know, however, that if the app dev initiative encompasses laptop and desktop as well as mobile apps, it can be modularized so that data access and business logic can be leveraged by both.

If this is an internal project, consider that it takes time to stay current with technology. Application frameworks, browsers, and operating systems are all changing, and the former two quite quickly. Three years ago, Google’s Chrome browser was hardly a blip on the radar. Now it is huge.

User interfaces will surely change in the years ahead. Technology advances and companies have to adapt. One of the keys to development projects is to make sure the application front end is loosely coupled to the messaging system and the back end.

Pilot Project Predictability

If you only take away one piece of advice, plan a pilot project before diving into the deep end of a mobile application project. Keep things simple and on a small scale. A project with a half dozen screens is adequate.

Inexperience can be a harsh teacher, but when the ramifications of decisions made on a trial project come home to roost, the penalties will be far less severe.

For teams that are unfamiliar with the unique constraints of browser-based applications, a pilot project allows the time to gain familiarity with real-life deployments of technologies such as HTML5, JavaScript, PHP, RPG OA, and the development tools for building user interfaces, calculating the workflow, and dealing with the challenges of accessing data.

A lot of this comes down to testing the technical waters, but don’t miss the signals from the users concerning their likes and dislikes.

End User Feedback

Know and understand the users and the mobile devices they will be using before getting under way. Many factors impact the development. In some situations you have control of the type of devices being used, which provides real advantages. Other times there will be no control and a mix of smartphones and tablets have to be accounted for.

Even if there is a single prescribed device for all users, there could be multiple versions of the operating system and variations in browsers, which sometimes render HTML differently. Mobile projects involving Blackberries of varying ages have had to deal with this, as one example.

It may make sense to have all users on the same device, OS, and browser, if the project allows that extent of control–usually this applies to employees accessing internal applications. If there are added development costs related to supporting multiple devices, it should be weighed against the cost of putting all the users on the same device or perhaps limiting the choices as much as possible.

When you don’t have control over the choice of mobile devices, it frequently causes application functionality to be “dumbed down,” or if you do different UIs for different environments, then development costs and maintenance costs will rise due to the creation of multiple UI interfaces and applications for each device.

One of the common problems with ill-planned mobile application development is that the desire for the project is there, but little is understood beyond that. Someone thinks it needs to be done, but it is never tied to solving a legitimate business problem. That’s the ultimate in bad planning. The next most common problem is simply not knowing where or how to start coming to grip with the project. Hopefully you know more about that now than you did yesterday.