January 25, 2021
Hot Topics:

Defining a Wireless Solution

  • By Prentice Hall
  • Send Email »
  • More Articles »

5.3.2 Wireless Applications

The requirements for wireless applications are driven primarily by two questions: What functions will the applications have to provide, and Who will use that functionality. The process of turning business requirements into functional specifications is fundamentally the same for wireless applications as it is for other business applications with a few nuances to cover differences in the wireless environment. Given the wide range of possible applications and the wealth of options for obtaining or creating those applications, a simple checklist approach is inadequate for specifying application requirements. Furthermore, choices affecting application functionality or design may drive or be driven by choices made in the other wireless architecture categories. Consequently, many important decisions affecting application selection, such as where to distribute functionality between the device, servers, and host systems, must be deferred until later stages of solution design. These issues and considerations are discussed in Chapters 9 and 12. Nevertheless, it is possible to offer some selection criteria to guide your considerations. As shown in Figure 5.7, these criteria are: functionality, approach, source, device/network support strategy, user experience, interface, host platform, and security.

The Wireless Application Cheat Sheet

  1. Functionality  The business issues you intend to address define the functional requirements for your solution. The particular requirements for a telemetry application monitoring an ice-making machine, for example, are wildly different from those for a trading application for stockbrokers. Despite these differences, all wireless applications contain one or more of the following generic functions: communicate, access information, collect data, update, transact, monitor, and locate/track. Use these functions as a starting point for describing the high-level functional requirements of your solution. For example, the ice machine application must monitor conditions such as temperature within an ice freezer and communicate problems to the host organization. With this high-level definition in hand, you should be able to begin researching possible solution options. For instance, do any software vendors offer applications with those functions? As you progress further into your implementation, you will need to flesh out this high-level definition with more detail. To create those specifications, you can follow the IT methodology of your choice.
  2. Approach  Will you need a new application to provide the desired functionality or can you extend an existing one? If your goal is to provide office functionality to field workers, adding a wireless channel to an existing application may be an option. Where feasible, extending an existing application can often be the quickest and least costly method of gaining desired functionality. If a new application is required, you will have to build or buy it as described below.
  3. Source  How and where are you going to obtain your desired application functionality? If your functional requirements are new or unique, building a custom application is the only option. To do so, you will need to invest in tools and expertise to develop and support the application, or turn to an experienced third party to do the work. Over time, as wireless adoption increases and more robust and varied packaged solutions appear, the need to create custom applications will wane. If your functional requirements are more basic or generic—providing wireless e-mail access, for example—it is likely that a package or other "off-the-shelf" software will meet your needs. You may be able to use this software "as is" or may need to do some tweaking to get it to perform to your exact requirements. Finally, some of the enterprise applications that your company has already implemented will have their own wireless interfaces, and gaining wireless functionality is as simple as enabling some pre-existing code.
  4. Device/Network Support Strategy  Depending on your strategy, you may choose to tailor your solution to work with a single device or specific network architecture (the "native" approach) or opt to create a generic solution capable of working with multiple device and network types (the "agnostic" approach). By focusing on a single device or network, the native approach can take full advantage of the unique capabilities offered by those components. In contrast, an agnostic approach takes a compromise path, not exploiting the unique capabilities of a single device or network type, but seeking to work on as wide a range of components as possible. An agnostic approach is the only choice if your application must support users, such as consumers, who may already be using a range of devices, and it offers the advantage of easily supporting changes in devices or networks. A native approach makes more sense when your solution is focused, such as providing salespeople with e-mail access via RIM BlackBerry devices, and you are able to standardize on a particular device and/or network.
  5. User Experience  Different types of users have different needs for interacting with the wireless application. Application design factors such as navigation, level of interaction, and visual presentation have to match the needs of the intended users to encourage adoption of the solution. Navigation, the steps required to find desired information, requires a tradeoff between ease/speed of use, and power and flexibility. A harried emergency room doctor will not use a solution that requires many layers of slow navigation to find the desired information, while a power user seated in an airline lounge is willing to trade simplicity for a full range of features. Similarly, an occasional user of the application, such as a consumer making a wireless purchase, will not recall application features and functions between sessions, and will need considerable handholding to complete the transaction. A stocktrader who constantly uses the application will want more control over his interactions with as little interference and overhead as possible. A person performing highly repetitive tasks will prefer a high level of automation. For example, a package delivery person will not want to enter a series of commands to upload delivery data every time he returns to his truck. Visual presentation requirements also vary. To convey one-line alerts on changes in commodity prices, plain text will suffice. Fuller visual presentation is needed to support more complex information demands, such as using color to highlight differences in order status or giving a demo to a customer. Presentation becomes critically important if a wireless application will deliver highly visual information such as x-rays or schematics.
  6. Interface  Most wireless applications will depend on a visual interface for interaction. In some cases, it may be advantageous to supplement that interface with speech recognition, to permit, for example, a user to interact with the application while driving. Multiple language support will be important if the application is used in more than one country or targets multi-lingual populations. If a diverse set of users will use the application, the ability to tailor the application to individual working styles through user preferences becomes important.
  7. Host Platform  The characteristics of your company's host platform are important selection criteria for wireless applications and middleware that must integrate with that platform. This criterion is not important for standalone wireless solutions, such as a wireless interface to an existing enterprise package. If you choose to purchase a package, it must be compatible with your existing platform or you will have to change the platform to support the application. Similarly, if you are developing a custom application, platform characteristics may affect your choice of development tools.
  8. Security  Security is an important consideration in all four wireless architecture components—applications, information architecture, devices, and networks. From an application perspective, security is enhanced through authentication (Are you who you say you are?) and authorization (Are you allowed access to a given function or piece of data?). Given the high rates of theft and loss among devices, application-level protection is vital if the device contains confidential or valuable information and/or can gain access to sensitive applications or data behind the corporate firewall. Application-level security is less of an issue for many telemetry and consumer applications, but is critical for applications that perform financial transactions or other sensitive functions.

Page 5 of 10

This article was originally published on October 16, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date