Building business apps for mobile devices should be easy (part 2)

Mobile should be easy part 2

This is the second blog of series of three.  The first blog covers how Native, Hybrid and HTML Mobile App Types compare and the third blog covers Development Tools for Mobile Apps. The blog series is based on an article by Richard Lancaster, published in MC Press at http://www.mcpressonline.com/wireless-/-mobile/you-want-to-build-business-apps-for-mobile-devices.html#sthash.G9xwG1TP.dpuf

This second blog covers:

  • Which business processes and transactions to mobilize
  • How the target audience may influence design and platform decisions
  • Considerations for buying apps or building your own
  • Criteria for choosing a mobile platform

How do you choose the business processes and transactions to mobilize?

Processes that work best in mobile apps:

  • Are discrete and finish in a short time (such as retrieving the balance of an account)
  • Have few or no external dependencies (such as retrieving data from a database on a server)
  • Must be easily understood by the device user. If a user can’t operate the app without reading a user guide, the process is too complex.

This decision requires an analysis of line-of-business (LOB) systems to determine the processes and transactions that will fit into a mobile app. Orders are an often-quoted example. However, if the order requires 10 screens in an ERP application, with real-time access to a dozen database tables, it might work on a tablet but will be impractical to use on a phone.

App Audience

Who will use the apps? Apps for employees and apps for customers have different objectives. Employee apps focus on productivity, providing information on demand and capturing information required by the business process. The user interface design may be compromised for the sake of productivity. Apps used by customers provide and capture information but can also assist sales by suggesting complementary or alternate products. Many businesses fall into the trap of creating apps from their perspective and ignoring the customer perspective. For customer apps, the user experience is paramount and it must entice customers. Adverse app reviews in the app stores can influence customer willingness to use your app.

The app’s target audience influences the mobile platforms you may have to support. If you supply devices to employees, you may be able to dictate the mobile platform. In cases where employees can bring their own device, a homogeneous mobile platform is unlikely. Similarly, customers will choose their devices, and the variety of devices is likely to widen with an increasing number of customers. It might be helpful to find out the types of devices your customers use and prepare for a growth in the support workload as the number of app users increases.

Buy or Build?

Should you buy apps or build your own? The Apple and Google app stores have hundreds of thousands of apps, and the number of apps in the Windows phone app store is growing. Surely you could find an app that fits your requirements. However, you will find that the majority of apps are social, personal, or games. Most business apps are provided by companies for use with their business, examples being banking and ERP software providers.

With a diligent search, it is possible to find apps that you can buy and configure for your use. Two examples are apps for mobile purchases (shopping-cart style apps) and human resource management. For cross-industry requirements, such as HR, buying an app might be adequate for simple processes. Companies trying to interact with their customers face dependencies when buying apps, including lack of influence over the app’s features and no support for integration with existing LOB systems.

Most companies will build apps because they can control the features, platforms, development tools, and integration capabilities. Using in-house developers or outsourcing development becomes an economic decision after resolving the platform choice. Choose development partners carefully when outsourcing the work.

Choosing the Platform(s)

Prominent platforms are Android and iOS. Other platforms include BlackBerry, Symbian, and Windows Phone. Which platform or platforms do you choose? The criteria for choosing platforms include ideology, largest number of devices, and/or available developer skills.

You have no control over the mobile platforms. What actions can you take if a platform fails, closes, or changes?

The consequences of choosing platforms are significant. Choosing only one platform simplifies the choice of development tools and the skills developers require but isolates customers who do not use the chosen platform. A choice of multiple platforms allows you to reach more customers with your app, but the cost is a heavier developer workload.

If you choose multiple platforms, do you choose native apps for each platform or a cross-platform development tool that supports your chosen platforms? One approach to resolving the platform choice is to select a platform and then build and publish an app to gain experience and test customer or employee reaction.

Here are examples of criteria for choosing a mobile platform:

  • Viability and maturity of the platform
  • Customer reach (i.e., most devices)
  • Appeal to customers (some customers buy on price, and others pay extra for perceived quality)
  • Development and maintenance costs
  • Manageability and fit with existing IT infrastructure
  • Developer skills

Security and encryption may be a mandatory requirement for some industries.

Choosing a platform is one of the more difficult decisions as it confines the choice of mobile devices and development tools.

Richard Lancaster

Author: Richard Lancaster

Richard Lancaster, 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 held a range of roles from Computer Operator to Systems Development Manager at various banks and insurance companies.

Leave a Reply

Your email address will not be published. Required fields are marked *