It's a decision only you can make.

Mobile devices must be one of the most popular products ever made. Everywhere you look, people are busy with their mobile devices. They sit, stand, or walk tapping and touching a phone or tablet, as if the devices are an extension of their being. To capture the attention of customers, shoppers, and product searchers, companies require mobile apps.

If your line-of-business (LOB) systems run on IBM i servers and you want to embark on a mobilization project, which mobile architecture should you choose? Does it matter? Is one mobile app architecture more appropriate than the others? Do you need apps built for multiple architectures? Should development tools determine the choice? Perhaps the sensitivity of the data is the deciding factor when choosing a mobile architecture? The mobile apps will integrate with your LOB systems, so should ease of integration influence your decision? And what about developer tools, skills, and ongoing maintenance?

The decisions will influence the success of your company's mobile apps. Your mobile apps should improve your business processes and help you sell more goods and services. How do you achieve this outcome? Before choosing a mobile app architecture, select the business processes to mobilize, work out the data you need, analyze security requirements, examine integration possibilities, and then determine which mobile app architecture is the best fit to your requirements.

The rest of this article examines business processes, data, integration, development tools, developer skills, and maintenance to determine how these topics may influence the choice of a mobile app architecture.

Mobile App Architectures — A Reminder

Here is a quick reminder of the characteristics of HTML, native, and hybrid mobile app architectures:

1. HTML Apps--HTML apps are built using HTML5, CSS, and JavaScript and accessed using a browser on a mobile device.
2. Native Apps--Native apps install on a mobile device and are compiled to run on the device's operating system. Developers build native apps using languages including Swift on iOS, Java on Android, and C# on Windows phones and tablets.
3. Hybrid Apps--Hybrid apps combine two components: an HTML app and a container. The container is a native app that hosts the HTML app and provides access to mobile device features, including the camera, location services, and sensors. Developers use HTML, CSS, and JavaScript to build the app and tools to package the app with the container.

Hybrid apps offer a number of variations, including packaging HTML apps to run offline on a mobile device. This article is not an evaluation of all possible models of mobile apps and considers the HTML, native, and hybrid architectures in the context of choosing a mobile app architecture for a first adventure in mobile app development.

Business Processes

Efficient and effective business processes improve productivity and reduce costs. Efficient business processes deliver timely outcomes. Customers receive deliveries when promised, or the process informs them that an item is out of stock when they place an order. Effective business processes produce accurate data. Validation, error checking, and notification occur before saving the data, thereby removing the need for incorrect orders and costly rework. If your business processes are not efficient and effective, extending them into mobile apps will highlight the process inadequacies.

The volume of data collected by a business process can make data entry on a mobile device a chore. If your order-entry system requires users to proceed through several screens to complete an order, it's not ready for a mobile app.

Duplicating existing functionality seems to be the easiest transition into mobile apps, but this approach may not take full advantage of the possibilities offered by the features built into mobile devices. For example, a restaurant chain can include a list of restaurants or take-out locations on a website, and customers can use their mobile devices to access the website to find a location. From a business perspective, this functionality provides limited incentive to help customers into a restaurant. Developing a mobile app allows the company to use location awareness features on a mobile device to prompt a customer with more information than just a restaurant location. The app can show the nearest restaurant with a route from the customer's location to the restaurant. It might suggest a discount or notify the customer of special menu items. If the customer is a member of the restaurant's frequent customer program, the app can show the customer's points balance and offer bonus points as an incentive to visit the restaurant. The extra features allow the company to change its business process and drive customers to more frequent visits.

The goal is to turn existing business processes into small, discrete transactions and think about how a mobile app can do more than the existing process and provide improved customer service.

Can business processes help you determine an appropriate mobile app architecture? Native and hybrid apps can use the features and services of mobile device hardware and operating systems. They can store data on the device and operate without a connection to a server. These capabilities provide the means to extend and enhance your existing business processes. HTML apps require a connection to a server. While connected, they can use device features and store data on the device, but they cannot operate without a server connection. If changing your business processes is not an option, or extending their functionality to use mobile device features is impractical or inappropriate, HTML apps are the most suitable for IBM i. Native or hybrid offer the same possibilities for operating existing or extended business processes. Business processes are an influential factor when choosing a mobile app architecture.

What Data Will You Need for Mobile Apps?

Data is a strategic corporate asset. The effort that goes into data collection, validation, analysis, governance, security, data quality management, and meta data management illustrates the importance of data. Mobile apps will expose data outside corporate confines and beyond the protection provided by an IBM i server.

Data sensitivity and data's competitive advantage can be constraining factors for data used in a mobile context. Native and hybrid apps may have data on the device, especially when apps require on-device data storage. Encryption will help to secure the data, but that adds complexity to the app design. HTML apps display the data on the device, and the data remains on the server, which is an advantage when you want absolute control over the data.

Business processes built into a mobile app require data regardless of the mobile app architecture. The data security requirements for one business process will differ from data security requirements for another business process. Complex and/or sensitive business processes may require a server for storing and manipulating data to avoid saving data on a mobile device. In this case, developers must be familiar with securing communications between a server and a mobile device (e.g., TLS/SSL) and applying encryption to data using middleware or the app.

Mobile apps are an inevitable method for conducting business, and you will expose at least some of your data. Take control of data security by building apps that add security layers to those provided by mobile platforms. Design apps so that critical data, including personal details and credit card numbers, do not reside on a mobile device. If you require critical data on a device, store it securely. Security mechanisms include using a VPN and encrypting data travelling between a server and a mobile app. Layers of security mechanisms can be a barrier to mobile app development and mobile app use. There will be a trade-off between the ultimate in security and ease of use for a mobile app. The important point: make an informed decision about storing data on mobile devices. Evaluate each business process and its data to determine how best to secure the data.

The most secure data is on a server, and if data security is a concern, the HTML mobile app architecture is appropriate for your IBM i. When app requirements include data stored on a mobile device and offline use, native or hybrid are viable choices, but data security can complicate app design.

Integration

Very few mobile apps for business can operate solely on a mobile device, where storage is a constraining factor. Therefore, integration is a fundamental aspect of mobile app design for most business requirements.

Integration on a server or on several servers in a data center is a well-defined practice with tools to help developers build integration solutions. In cases where IBM i applications use a distributed database, the database management system manages the complexity of manipulating the data, and applications can operate without knowing the database distribution. The HTML mobile app architecture fits into this context as business logic, and database access occurs in a data center. Integration and distributed databases are part of the environment.

Native and hybrid mobile app architectures are distributed applications with business logic and data distributed between servers and mobile devices. Application design becomes more complicated, requiring developers to work out where business logic will run and determining which data will remain on a server and the data required to operate the app on a mobile device. At some point in the life of a transaction, data from a mobile device will update a database on a server, and as a consequence, apps that store data on mobile devices require data synchronisation services. Transaction data will travel from a mobile device to a server. Reference and constant data will travel from a server to a mobile device.

To simplify integration, choose the HTML mobile app architecture. Integration is more complex when using native and hybrid apps.

Mobile App Development Tools

Which mobile app development tool is right for IBM i? The choice of tools is wide—make a list of tools and take your pick. Unfortunately, the decision is not as easy as choosing a tool from a list.

One of the criteria for selecting mobile app development tools might be the choice of a mobile app architecture. Choosing a mobile app architecture first reduces the list of tools. Select the architecture and compile a new list of development tools that support the architecture. Using mobile app architecture as the criterion for choosing tools may conflict with requirements forced upon the mobile app by the business processes.

Suppose native apps are your choice. The next decision is which mobile platforms to support. You require native apps for iOS and Android if you sell products and services to a wide population. The choice of development tools now involves iOS development tools and Android development tools, or a cross-platform development tool.

Choosing a mobile app development tool is a complicated task when you face no constraints. In cases where you have freedom to choose any of the HTML, native, or hybrid app architectures, select the one that provides the closest fit for optimizing the business processes.

HTML apps are appropriate when data management requirements prohibit data residing outside the data center. If you develop HTML applications for desktop devices, your existing development tools may be adequate for building HTML apps for mobile devices.

If your IT is all IBM, the Worklight Platform maybe the right tool for your IBM i. In other cases, any choice is right for IBM i when you consider the many factors that influence the choice of mobile app development tools.

Developer Skills

Developer skills ought not to be among the criteria for choosing a mobile app architecture.

Mobile apps are widely known and used and people have become accustomed to a style of user experience on the device. Your mobile app initiatives will fail if your developers cannot reproduce the expected user experience.

In cases where your developers are familiar with HTML application development tools, you might be inclined to choose the HTML mobile app architecture and use familiar development tools. This is a convenient path but not necessarily the best outcome when your business process and data requirements suggest native or hybrid mobile apps.

Outsourcing mobile app development to overcome a lack of in-house mobile development skills may seem attractive. The cost of outsourcing the development and the need for faster response to change requests will become expensive. The apps require integration with existing systems, and your developers are better equipped for this challenge than an external development company.

Ultimately, you can acquire mobile app development skills by either training your developers or outsourcing mobile app development.

Ongoing Maintenance

Statistics suggest that ongoing maintenance is the most expensive component in the application development and operation life cycle. Therefore, getting ongoing mobile app maintenance costs under control from the beginning of your mobile development can reduce costs and improve the return on investment.

Ongoing maintenance for mobile apps divides into two types, app maintenance and deployment.

App Maintenance

App maintenance includes user interface design, business logic, business rules, database, integration, and fixes. Changes in business requirements and/or legislative obligations drive app maintenance, and all apps require this type of maintenance, regardless of the app architecture.

Deployment

Deployment includes version management, packaging, and distribution (e.g., into app stores).

HTML mobile apps avoid version, packaging, and distribution maintenance. HTML mobile apps run in a browser connected to a server, and mobile devices can operate the apps without version, packaging, and distribution costs. Deployment costs for HTML mobile apps are the same as deployment costs applicable to HTML applications for devices other than mobile.

Native mobile apps require version, packaging, and distribution maintenance. The maintenance tasks include managing app versions, packaging apps for one or more app stores, and managing the app approvals or side-loading the apps.

Hybrid mobile apps require version, packaging, and distribution maintenance to varying degrees. Hybrid mobile apps that run in native app containers and download HTML, CSS, and JavaScript into the container require version, packaging, and distribution maintenance only when the native app container has a new version. Hybrid mobile apps that produce a native mobile app require a deployment similar to that required for native mobile apps.

Two deployment complications apply to native and hybrid mobile apps. You cannot guarantee all users are on the same version of a mobile app, especially so for users who are customers. You can't force users to use the most recent app version; at best, you can cajole and entice users to upgrade. Managing multiple versions can be challenging for developers and support representatives.

What's the Conclusion?

Companies running applications on IBM i servers are used to a controlled environment with proven application development and release practices. When they move into mobile apps, they face a new set of challenges for app development, and here are four examples:

• Give up large-screen thinking—Don't design a large screen for a mobile app. User interface design requires a different way of thinking.
• Build apps for mobile—Build apps with the content and functionality customized for mobile.
• Don't overload mobile apps—Don't include every feature you can think of in your mobile apps.
• Faster version cycles—Maintenance cycles for mobile apps are faster than for green-screen applications.

What are the influences that will determine the appropriate mobile app architecture, and is the IBM i a determining factor?

The easiest path to mobile apps for companies using IBM i server is the HTML mobile app architecture. Some of the reasons are:

• Develop HTML mobile apps once—no requirements for multiple mobile platforms.
• HTML mobile apps are easier to deploy, and avoid app stores.
• Anyone with a browser can use HTML mobile apps.
• All users operate the same version of the app.

Maybe the HTML mobile app architecture is right for IBM i.

The easiest path to mobile apps may not bring the most desirable business outcome. Other factors can influence the choice of a mobile app architecture. Perhaps competitive pressure can force a company to build native mobile apps, or HTML mobile apps cannot satisfy business requirements, or app users do not have consistent communications connections.

Choosing the right mobile app architecture is a complicated decision.

Is there a mobile app architecture that is right for IBM i? The decision is up to you.

Richard Lancaster is Product Manager at LANSA's Product Center in Sydney, Australia.

 

Richard is LANSA's Technology Evangelist with a deep understanding of development and integration technologies on the IBM i, Windows, UNIX, and IBM mainframe platforms. With over 30 years of experience in the technology industry, Richard previously worked as a solutions architect for systems integrators Aspect Computing and the KAZ Group, and he held a range of roles from Computer Operator to Systems Development Manager at various banks and insurance companies.

Also Read

TechTip: A Primer to Bootstrap 4, Part 2

TechTip: A Primer to Bootstrap 4, Part 1

A Hand-Holding App Builder for Handheld Devices