Industry leaders give developers and IT managers their best advice on questions surrounding network access by mobile devices.
Mobile devices and applications seem to be sweeping the world and are presenting special challenges—and rewards—for developers. As users come to expect access to corporate networks and applications from their mobile devices, developers will be tasked with weighing in on how their companies should approach this challenge.
We worked with several people familiar with mobile devices and access to devise a series of questions that we posed to a number of industry experts. We published the first round of the responses in MC Systems Insight last month in the first installment, "Power i Forecast: Smartphones and Mobile Apps, Part I." Because we had so much material from respondents, we broke the article into two parts. People were asked to pick one, or more than one, question—whatever they felt comfortable answering—and give their written response. This is the second installment, represening a different set of respondents.
Below are the questions we asked, and many are repeated further on with their responses. We know there are others who are actively engaged in mobile development whom we didn't pulse, so please feel free to express your thoughts in a comment in the MC Forums.
- What should IT/system administrators be thinking about when considering deploying mobile apps? What kinds of costs might be incurred when operating on a 3G or 4G network? Are security risks tolerable, and how can they be mitigated?
- Do you think mobile devices should be standardized—perhaps company-issued—or should everyone be allowed to bring their own device (BYOD)? What implications would there be for an environment supporting BYOD?
- Should the mobile apps be browser-based, native—i.e., device-specific—or some version of a virtual desktop? And why?
- Should the development approach for the mobile device applications utilize low-level coding, high-level coding/frameworks, or one of the variations of pre-fabricated Mobile Enterprise Application Platform (MEAP) solutions? What are the factors in minimizing the developer's learning curve, maximizing productivity, standardizing skill set, etc.?
- What types of internal assets should be exposed to mobile device applications (databases, documents, programs, and other data sources)? Should the mobile apps be straightforward extensions of a current application or utilize new enhanced device-specific capabilities for novel solutions?
- Would the mobile device applications be operating only when connected to the network, or should the apps support offline processing? Would a local data store make sense under certain circumstances? How can developers reduce the complexities of data access and transfer?
- Is it sufficient for IT to focus on what the packaged software vendors decide to deliver for mobile app services, or should IT tailor solutions to specific business needs?
- Going beyond existing internal apps, what new solutions could the mobile device enable, such as BI/data discovery/analytics, location-based services, collaboration/social media, and workflow/business process improvements?
Eamon Musallam
Product Manager
Eamon Musallam: If you are considering extending your RPG- and/or COBOL-based IBM i applications for mobile devices, there are some basic steps that can help ensure success with users and management. We would recommend starting with a small subset of existing functionality in your current application that will provide some real value to some existing employees. For example, if you are a manufacturer/distributor running an ERP package, a very useful first step would be to provide users the ability to look up customer details, product information, and order status. Given that mobile devices such as smartphones typically have smaller screens, you will want to be very careful about using that real estate as sparingly as possible, only displaying the essential elements for the required function. This alone will make the application much more intuitive and easy to navigate.
From a technology standpoint, you will need to decide which devices to support at an early stage and [whether] you will be implementing generic browser-based apps for mobile devices or device/OS-specific apps. It is typically much easier to develop a browser-based mobile app, and in doing so you will be able to support various devices. For example, HTML5 is fast becoming the standard supported by Apple, Google, BlackBerry, Microsoft and others, and provides a rich and responsive user experience (UX).
Obviously, you will want to ensure your applications and data are as secure as possible. Today's mobile devices typically have support for VPN and SSL built in, which can ensure only authorized users have access to the application and keep unauthorized users out.
Find a technology vendor that has had success helping similar companies implement mobile solutions; it can save a lot of time and effort to learn from the experience of others rather than go it alone.
What should IT/system administrators be thinking about when considering deploying mobile apps? What kinds of costs might be incurred when operating on a 3G or 4G network?
EM: It varies worldwide, but the trend is away from unlimited to tier-based plans, as cellular providers realize they can gain larger revenues as the reliance on Internet access through cellular networks increases. In the U.S., a corporate cellular account that includes enough support for employee 3G/4G data usage is typically less than $50 per user, per month (data only).
Are security risks tolerable, and how can they be mitigated?
EM: Yes, the security features are advanced enough to provide sufficient protection, and the business benefits of providing access to applications from mobile devices typically outweigh those concerns. However security is immensely important and shouldn't be underestimated. As long as features such as user authentication, VPN connectivity, and SSL are configured correctly, then concerns about security should be minimal.
Do you think mobile devices should be standardized—perhaps company-issued—or should everyone be allowed to bring their own device (BYOD)? What implications would there be for an environment supporting BYOD?
EM: The implications are significant. There are so many devices available from different manufacturers, running different versions of mobile OS, and different capabilities, that it would be impractical to develop, test, and support every one of them, especially older (2 + years) models. The more developers take advantage of specific features or technologies that mobile devices offer, the narrower the number of devices typically supported. Even within one manufacturer this can be a challenge—for example, BlackBerry has seeded the community with many different models that vary widely in their capabilities and support. However, if the app is mobile-browser-based—and many are today—the developer should support a range of devices that would support BYOD fairly well. For example, a typical browser-based mobile app today can support iOS 4.2 + (iPhone, iPad, iPod Touch), Android, BlackBerry OS 6+.
Should the mobile apps be browser-based, native—i.e. device-specific—or some version of a virtual desktop—and why?
EM: It really depends on the scope and usage requirements of the applications. With the increased prevalence of 3G/4G cellular networks and Wi-Fi networks, browser-based apps that are dependent on Internet connectivity are becoming more and more acceptable. However, there are still areas and places where Internet access is not available, and as long as users have that expectation, it will often be sufficient to implement a browser-based mobile app. Device-specific applications do provide additional richness and capabilities, but typically at the cost of minimizing the devices that can run the apps and more extensive application development tasks. The tradeoff between browser-based and device-specific apps is reach versus richness. Again, the user requirements, scope, and functionality of the project will typically determine the approach taken.
Should the development approach for the mobile device applications utilize low-level coding, high-level coding/frameworks, or one of the variations of pre-fabricated Mobile Enterprise Application Platform (MEAP) solutions? What are the factors in minimizing the developer's learning curve, maximizing productivity, standardizing skill set, etc.?
EM: Before mobile development begins, it should be determined which devices will be supported and what functionality is essential. This will help determine the right technology framework/development tool to be considered for implementing the specific solution. For example, if is it determined that the mobile app will be browser-based and support both Apple iOS and Android devices, then there are tools and frameworks that would greatly assist in the development, testing, and maintenance of these applications. In this case, frameworks such as Sencha Touch and JQuery would be ideal platforms to consider.
What types of internal assets should be exposed to mobile device applications (databases, documents, programs, and other data sources)? Should the mobile apps be straightforward extensions of a current application or utilize new, enhanced device-specific capabilities for novel solutions?
EM: A good way to start mobile development is to start with something simple. Perhaps take a subset of the application that would lend itself to mobile support…a good example would be customer and order lookup from an ERP…and then implement that for mobile device consumption. It is fairly easy to implement some basic integration such as Google maps, email, and phone dialing, so those would be good candidates to start with, before taking on more advanced features.
Would the mobile device applications be operating only when connected to the network, or should the apps support offline processing? Would a local data store make sense under certain circumstances?
EM: Yes, a local data store would make sense under certain circumstances. For example, if a requirement were to be able to work offline and be available in the absence of 3G/4G or Wi-Fi, then typically a local data store would be needed to support this functionality.
How can developers reduce the complexities of data access and transfer?
EM: By eliminating it! If a developer can avoid the requirement to run offline, then the implementation becomes a lot simpler in scope.
Is it sufficient for IT to focus on what the packaged software vendors decide to deliver for mobile app services, or should IT tailor solutions to specific business needs?
EM: If the package vendor provides the capabilities required by the customer for mobile apps, then that would eliminate the need to train developers and manage the process internally, which is often very desirable from a business standpoint. However, if IT doesn't have that option or a company has very specific requirements, then they will either need to develop internally or outsource to an implementation specialist.
Going beyond existing internal apps, what new solutions could the mobile device enable, such as BI/data discovery/analytics, location-based services, collaboration/social media, workflow/business process improvements?
EM: Some simple examples beyond existing apps are Maps (location-based service) that can provide directions between current location (GPS) to an address of a customer, dialing a customer phone number directly from the screen, and email integration. Text messaging (SMS) can also be leveraged in some creative ways to send announcements or instant notifications based on some event. Beyond that, there is so much that can be achieved in terms of collaboration/social media/workflow/business process improvements, etc. It really comes down to having a vision, identifying how it can help from a business standpoint, and funding to make it happen.
_________________
Trevor Perry
Chief Strategist
Trevor Perry: An interesting trend in these questions is what type of apps should an IT organization support on mobile devices? The answer to the question is "yes."
If a company standardizes on a single mobile platform, it is advantageous to leverage the power and functionality of that platform. Writing tailored applications will provide the most function- and feature-rich solutions, customized specifically for the company and the user community.
Where a company does not choose a particular mobile platform, delivering browser-based applications will provide the widest range of support to their user community; however, they will not necessarily take advantage of device-specific technology.
Some companies see their user community as separate internal and external users. External users will typically not standardize on a mobile platform, so apps they use should be browser-based. Internal user apps would be determined by the level of control over which mobile device platform.
Eventually, this differentiation will become much smaller. HTML5 and CSS3 already provide rich functionality that closes in on native mobile device functionality. In the not too distant future, browser-based apps will be able to perform the majority of needed business functionality that would be deployed to a mobile device.
More importantly, an emerging trend for mobile apps is to provide the capability to run apps on your chosen mobile device from any platform. For example, I am running a Windows app on a remote server by connecting from my Mac OSX desktop. I am able to connect to the same Windows app and run it from my Apple iOS devices, and it appears to be running native there. With this approach, companies can build apps that run on their platform of choice and leverage third-party tools to provide virtualization for the user platform of choice.
________________
Trevor Seeney
Technical Director
Should the mobile apps be browser-based, native—i.e. device-specific—or some version of a virtual desktop, and why?
Trevor Seeney: Mobile apps should be browser-based, aka a "Web App." We have service programs that enable output to the browser. Server-side programs are written in RPG against a DB2 database. Security is standardized using IBM i user profiles with verification using the QSYSGETPH API. All familiar stuff to the IBM i developer. Using meta tags, we can optimize the Web page to the smaller canvas. With a server-side application, there are no distribution issues.
Should the development approach for the mobile device applications utilize low-level coding, high-level coding/frameworks, or one of the variations of pre-fabricated Mobile Enterprise Application Platform (MEAP) solutions? What are the factors in minimizing the developer's learning curve, maximizing productivity, standardizing skill set, etc.?
TS: To attain wider adoption of a browser interface and a gentler learning curve, I recommend eschewing frameworks and interactive development environments in favor of the more familiar low-level coding in RPG ILE and the CGIDEV (and CGIDEV2) service programs. The novice IBM i Web developer will have enough client-side technologies to learn, such as HTML, JavaScript, and Cascading Style Sheets, etc. without having to learn a new development environment as well.
Would the mobile device applications be operating only when connected to the network, or should the apps support offline processing? Would a local data store make sense under certain circumstances? How can developers reduce the complexities of data access and transfer?
TS: There is a technology known as Data URLs (aka Data URI) which enables you to encapsulate a static Web page into an object that can be saved and subsequently executed on a smartphone without requiring an Internet connection. A Web site, iWebSaver.com, will [take] a flat HTML document and convert it into a Data URL which will function much like a native i app.
One would use a Data URL in, say, an order-entry application where an order can be tapped into an Internet form. The email application and the browser are tightly coupled on smartphones so that the Submit button would actually evoke a "mailto:" tag that would launch the email application where the message body contains the elements of the order. Hitting the Send button would cause the email message to be placed in the Outbox, and once an Internet connection was subsequently established, the message would automatically transition to the Sent folder. A POP3 client available from www.easy400.net would retrieve the email message and save it as an IFS document, whereupon it could be posted to the enterprise order-entry application.
By using the technique above, storing data on the smartphone is obviated and would simplify "data access and transfer."
____________
Ken Singer
CEO and Co-founder
Do you think mobile devices should be standardized—perhaps company-issued—or should everyone be allowed to bring their own device (BYOD)? What implications would there be for an environment supporting BYOD?
Ken Singer: I'm always surprised when I hear senior executives acknowledge that their company is bowing to the inevitable and accepting the Bring Your Own Device trend. For good or evil, they say, employees will buy their own mobile devices, install their own applications along with the ones their job requires, and use them simultaneously and seamlessly.
Isn't this a little short-sighted? Companies should absolutely not accept this trend. They should embrace it.
Let's back up a little here. Too many of the naysayers seem to have fond memories of the first wave of enterprise mobility, when companies could choose between the BlackBerry and...well, that was pretty much it. That platform had great email functionality, the necessary contact and calendaring applications (just about the only business apps that everyone needed), and reliable tech support. For purchasing decision-makers, it was a no-brainer.
Also, in that world, there was never any doubt about where personal rights ended and company jurisdiction began. The desktop PC belonged to the company. The laptop, even if it traveled with the employee, belonged to the company. And that first generation of BlackBerries belonged to the company—even if employees put their personal data on it and carried it everywhere.
As a result, companies didn't really need a separate policy for mobile devices. Sure, your personal contacts were blended with your company connections, and maybe the doctor's appointment showed up in the calendar next to a business meeting, but it was all fairly routine corporate governance. The company owned everything and "locked down" everything.
It's a very different world now. Today, there are literally thousands of permutations of device, operating system, firmware version, and operator. Form factors continue to emerge and evolve, while user habits and preferences undergo constant change. We're not just talking smartphones here; the explosion in tablets threatens to make a big chunk of the laptop market obsolete and introduce a whole new set of complications.
Perhaps most importantly, there are hundreds of thousands of mobile applications, with more arriving every day.
But the real change is even more fundamental. The unprecedented explosion in mobile functionality, combined with the increasing consumerization of IT, has changed human-technology relationships forever. The simple truth is that by sheer dint of capabilities—what we can do now that we couldn't do before—the mobile device has become a more personal computer than the Personal Computer (the PC) ever was. It's the first true technology appendage to our physical beings, an extension of our very personality.
This is one genie that's not going back in the bottle. In fact, ever since the phone went past the three Cs—communication, contact, calendar—it never was in the bottle.
So now that employees have countless choices with regard to device, operating system, carrier, and application—and have every intention of exercising those choices—what's an IT department to do?
There's no question that this raises a lot of questions. Some involve thorny legal issues: for example, do companies have the right to lock or wipe an employee-liable device if it also contains employer-liable applications and information? Some questions are around policy: Should companies dictate which devices and applications employees can use? Some have to do with resources: Should companies try to monitor and manage everything on every employee's device? And some, of course, just bring headaches: Should companies back up employees' personal data, images, and applications on corporate servers?
These are all good questions, and they deserve a fair hearing. But here's the bottom line: The new generation of app-enabled smartphones and tablets really does deliver on its potential. In a recent Forrester report, 75 percent of enterprises said they experienced increased productivity by deploying mobile apps. In fact, with the right policies and processes, companies can save time and money while avoiding management headaches.
IT administrators nervous about managing a bizarrely heterogeneous mobile infrastructure should also remember that they really don't need to worry about the device; it's all about the corporate applications and the corporate data. Once they can manage and secure those, they can reap all the benefits. So let's get together and figure out the best ways to do that.
Editor's note: The forgoing reply from Ken Singer is a summary of Ken's blog post, "Go Ahead, Bring Your Own Device," that he wrote last April for the AppCentral Web site.
I would again like to thank to Bill Gravelle of Boulder, Colorado, an independent consultant at TenMile Solutions, who spent time helping me formulate the questions and devising a list of respondents. I would also like to thank Paul Tuohy of System i Developer, who helped frame the topic, which will be covered in a training track planned for the upcoming RPG & DB2 Summit October 17-19 in St. Louis.
as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online