Defining a Wireless Solution

By Ian S. Hayes

This is an excerpt from the book, Just Enough Wireless Computing.

Turning a set of business requirements into a successful wireless solution is an exhilarating and challenging assignment. The technology is new and exciting, the results are very visible, and if the project is based on a strong business case, the impact on your company will be high. The most obvious parts of the exercise, such as selecting the type of wireless devices that will be deployed, have a “toy factor” appeal, making them appear fun and relatively straightforward. As you delve into the nuances of the selection, however, arriving at the right decision no longer seems so simple. The myriad options, issues, and considerations appear to grow exponentially. Worse yet, you will find that many of your desired choices are incompatible or require painful tradeoffs of functionality or features. From networks to devices to applications and implementation tools, there are simply too many complicated choices. Your seemingly straightforward solution has somehow turned into a jigsaw puzzle, composed of disparate pieces that must somehow fit into a complete picture. And, like a jigsaw puzzle, these pieces fit together only in a certain way. Put in one wrong piece and you won’t be able to fit in the next right piece later. If approached in the wrong way, pulling together a complete wireless solution can be a daunting proposition even to experts.

Selecting the right components for a wireless solution requires navigating a complex and confusing maze of options and solution providers. The magnitude of capabilities, choices, and limitations of wireless components preclude the creation of a “one size fits all” wireless solution applicable to any business requirement. An architecture that works perfectly for one solution will be hopelessly inadequate for another. For example, the wireless solution used by American Airlines to track freight carts and dollies at the airports is vastly different from the one used by Fidelity Investments to allow investors to monitor stock prices and make trades.

Fortunately, a number of techniques can greatly simplify the conversion of business requirements into a well-defined wireless solution. Perhaps the most important trick is to reduce your range of options before becoming mired in the details of solution definition. Assembling a workable solution in a reasonable period of time is almost impossible if you must consider every potential device, network, application, and implementation option. The nature and constraints of your business requirements can be used to your advantage, however, to eliminate many of these options before you start, greatly reducing your research and evaluation efforts. For example, let’s assume that we operate a food delivery service throughout the New England area and wish to provide our drivers with directions to drop-off locations and capabilities to accept on-site credit card payments for deliveries. As shown in Figure 5.1, these constraints significantly reduce our pool of options. We need only consider network options that support moderate data volumes from providers offering full coverage across New England. Short- and medium-range network options such as infrared, Bluetooth, and 802.11b don’t apply, and the data volume requirements eliminate satellite networks. Since coverage varies by carrier, we’ll have to pick a network service provider who covers New England. Similarly, our choice of devices is limited to those that can handle outdoor conditions, support credit card scanning, and work with our selected network. The implications of these decisions set parameters and refine options for other aspects of our solution. We have to choose (or develop) software that operates on the selected device; we need strong security to protect credit card information; and our training and support processes must be designed to fit this solution.

This chapter describes the process for turning business requirements into solution requirements. It uses the answers to the Why, Who, What, When, and Where questions from Chapter 4 to provide a framework for winnowing your wireless decisions into a manageable number. As shown in the example above, each business requirement imposes needs and constraints that create specific technical and operational requirements for the major components of our wireless solution. This chapter will explain how to develop specific requirements for devices, applications, data, and wireless networks. Comparing these requirements against the tables and other component-specific information in the second half of this book will enable you to quickly identify the wireless options that best apply to your needs.

FIGURE 5.1
Shrinking the Solution Spectrum

5.1 Wireless Building Blocks

Before jumping into the mechanics of solution development, it is worth reviewing the basic building blocks that compose a complete wireless solution. While wireless solutions vary widely in characteristics, they all draw items from four categories of architectural components: client devices, wireless applications, information infrastructure, and wireless networks. These components are shown in Figure 5.2.

Client devices are the most visible component of a wireless solution. They are the physical platform for wireless applications and provide services such as voice communications, data capture and display, information processing, and location detection. These devices may be carried by users, mounted within shipping containers, or installed inside a car. Client devices include smart phones, pagers, PDAs, e-mail appliances, and special-purpose units for scanning, bar coding, and credit card reading.

FIGURE 5.2
The Components of a Complete Wireless Solution

Wireless applications supply the business functionality behind the wireless solution. They can cover any need from personal productivity to safety and asset monitoring. Depending on the functionality required, these applications may be “off-the-shelf” packages, custom developed, or “re-purposed” from existing web applications.

The information infrastructure is the repository of knowledge incorporated within the wireless solution. Although these data components are invisible to most users, access to information is the “raison d’être” for most wireless solutions. This information may be environmental data captured on an oil rig for display at a monitoring station or it may be an amalgam of customer information drawn from a variety of corporate information systems and databases. The information infrastructure consists of the back-end applications, databases, voice systems, e-mail systems, middleware, and other components needed to support the information requirements of the chosen wireless application.

Wireless networks serve as the conduit, or transport mechanism, between devices or between devices and traditional wired networks (corporate networks, the Internet, etc.). These networks vary widely in cost, coverage, and transmission rates; they include options such as infrared, Bluetooth, WLAN, digital cellular, and satellite.

Together, these four components constitute the wireless solution’s architecture. In the simplest case, this architecture consists of a single device type, using a single application and connected to a single network. However, many business solutions will be more complex, supporting multiple client devices, offering a variety of applications, and stitching together multiple networks to gain the desired level of coverage.

The solution’s Implementation and Support Infrastructure provides the processes, tools, and resources used to create, operate, and support the wireless solution. This infrastructure ensures that users are trained, data is backed up, secured and synchronized, system and application software is kept up-to-date, devices remain functional, and networks operate efficiently. Although not part of the wireless architecture, the quality of this infrastructure is crucial for the success of the overall solution. As such, it merits as much consideration as the other wireless components when designing the solution.

Business Processes form the final component of a complete wireless solution. These are the processes that inspired the solution in the first place. Depending on the goals of the project, the wireless solution should enable your company to perform these processes faster, cheaper, and more efficiently than before. Gaining these benefits, however, requires redesigning and implementing new versions of processes that take advantage of the wireless solution. To capture the benefits of immediate, on-site invoicing offered by the field service example in Chapter 2, a company needs to change processes and job responsibilities in the customer service, field service, and billing organizations. Without these changes, work orders will still be entered manually in the company’s systems by customer service, invoices will still be produced by the billing department, and the wireless device will simply end up as a new toy in the hands of the field service worker. While they are an integral part of a successful solution, business processes are usually outside the scope of responsibility of the technical team implementing and supporting the wireless solution. Implementing new business processes is its own project and requires knowledgeable resources backed by management commitment to the change.

5.2 Wireless Decision Process

Since wireless solutions depend greatly on the specifics of the problem they are solving, the process of selecting the right wireless solution is greatly simplified by focusing on the business requirements first. A given business requirement, such as the ability to deliver work orders to a user who spends many hours away from convenient power sources each day, imposes some critical technical constraints that have major implications for the entire solution design. The need for long battery life drives the selection of the client device. This selection may put constraints on the size and type of display and network connectivity options, which, in turn, affect the quantity of work order data transmitted, and its formatting and presentation. The resulting wireless architecture has implications for security, support processes, development tools, and service contracts with network and software providers.

This basic flow is true for every type of wireless solution, enabling us to offer a structured, top-down decision approach for turning business requirements into a design for a complete wireless solution. This approach proceeds in set levels from business requirements down to implementation strategy. It quickly narrows technology choices to a manageable number by focusing only on choices that are compatible with previous decisions. At each level, a set of choices is made and our breadth of options shrinks. If we follow the approach through to its conclusion, we have proven that it is conceptually possible to address our business requirement with a wireless solution and we have identified a “straw man” candidate for detailed analysis and feasibility assessment.

The diagram in Figure 5.3 illustrates the Wireless Decision Process. It uses a combination of business requirements gathered through the “Why, Who, What, When, and Where” questions from Chapter 4 and management considerations to drive requirements for devices, applications, data, and wireless networks. When combined with technical considerations, such as the ability to secure the company’s network, the solution requirements allow us to pick a specific set of components for our wireless architecture. The resulting technical strategy drives the implementation requirements for our solution, which defines the tools, processes, and resources for our Implementation and Support Infrastructure.

FIGURE 5.3
The Wireless Decision Process

In practice, this process is not purely linear. Choices within each level interact. For example, our desired network option might not neatly match our application data requirements or our preferred client devices. To address these issues, we must cycle between levels, resolving an incompatibility by moving up in the hierarchy and rethinking our approach within our now known and understood technology constraints. We continue cycling in this manner until we have a solution that balances our desired capabilities with the available technologies. In the unlikely case that compromise is not possible, or our business requirements drive incompatible and irresolvable technology strategies, wireless technology is not a feasible solution for our problem.

The sections that follow provide an overview of the activities and deliverables within each layer of the Wireless Decision Process.

5.2.1 Business Requirements

This layer identifies the characteristics the wireless solution must have to successfully address its desired business objectives. It defines the goals of the project (why), identifies who is going to use the solution, what functions it must perform, when its information must be available, and where the solution will be deployed. Answers to these questions are business focused, leaving the technical details for the subsequent layers. For example, we need a solution for our field service representatives that will work at any client site. It must have access to information in our corporate billing application. We need to collect time spent, actions taken, and parts used. We need to be able to print an invoice on the spot, and so on. To implement this layer, gain a thorough understanding of the business objective being addressed and conduct a detailed analysis of the environment in which the solution will operate. Use standard business analysis techniques, such as interviews, assessments of current and desired processes and tools, and documentation reviews, guided by an assessment questionnaire that focuses on the nuances of a wireless and mobile solution. The final deliverable of this phase is a formal, documented set of business requirements. This document is the starting point for developing solution requirements, supporting cost justification efforts, and soliciting proposals from external solution providers.

5.2.2 Management Considerations

Wireless and mobile solutions raise a host of issues with implications for corporate policies, standards, and operations. For instance, allowing workers to perform important tasks at off-site locations may have audit impacts, affect union contracts, or expose the company to a new set of legal issues. Remedies to these issues, although not necessarily part of the original business requirements, will certainly affect the design and implementation of the final wireless solution. They also have ramifications on the supporting business processes. For example, the wireless solution may require a new set of audit policies and procedures.

Management considerations permeate all levels of the Wireless Decision Process, down to the details of the project’s implementation and support infrastructure. Begin implementing this layer by reviewing the project’s business requirements with company executives and appropriate individuals within the corporate legal, audit, human resources, and operational areas. Treat management considerations as a filter through which project requirements and design documents must pass. For more information on management considerations refer to Chapter 8.

5.2.3 Solution Requirements

The solution requirement layer translates the business requirements into technical requirements that will be used to select specific items within the four components of the wireless architecture. For example, a business requirement to provide a user with extended access to the wireless application in remote areas creates a technical requirement for long battery life. Many technical requirements flow directly from the answers to the business requirement questions. Who will use the solution sets requirements for the choice of device(s) and the design, function, and user interface of the application(s). Answers to the What question drives requirements for application functionality, data sources and access, and impacts device capability requirements. Major technical requirements are generally obvious and quickly determined, for instance, the mobility and location of an emergency room physician immediately rule out options such as laptops and satellite access. More detailed requirements will necessitate research into available options. Depending on the size and complexity of the wireless solution, this layer can be performed by an individual or a small team of solution designers. The major task is to translate business requirements into the parameters used to select specific components. For example, device selection parameters include size, weight, battery life, and display characteristics. The deliverable of this layer is a formal, documented set of technical requirements for the wireless solution.

5.2.4 Solution Considerations

Solution considerations are similar to the management considerations described above, but are technically oriented. Wireless solutions face a host of externally imposed technical constraints and design considerations. Unless the wireless solution is standalone, it has to work within the company’s defined technical strategy and standards. For example, your company may prefer to standardize on a single vendor’s products wherever possible or it may require a product “agnostic” approach that trades unique features for the ability to easily switch vendors and products at a future date. Other design considerations involve issues such as security, transaction integrity, and development environment standards. Like management considerations, solution considerations are a filter affecting all subsequent levels of the Wireless Decision Process. Implement this layer by reviewing the project’s technical requirements with experts within your IT organization. These experts include IT strategy, security, database, network, and standards specialists. If the proposed solution requires integration with corporate applications, appropriate application specialists should be consulted. For more information on solution considerations, refer to Chapter 9.

5.2.5 Technology Strategy

The technology strategy layer produces the wireless architecture design. Using the technical requirements from above, the solution designer evaluates options and selects the appropriate items in each of the four wireless architecture categories. For instance, based on the solution’s device requirements, the designer may recommend the use of a Palm or Pocket PC PDA as the preferred client device. Steps within this selection process can include researching option specifications, performing product evaluations, and visiting corporate users of the desired technology. While the decisions made in each architecture category flow directly from their respective requirements, choices must be compatible with each other. Incompatibilities can be resolved by changing one or both competing selections or by devising an appropriate workaround to be incorporated during implementation.

5.2.6 Implementation Requirements

This layer provides the requirements for the Implementation and Support Infrastructure component of the wireless solution. The characteristics of the wireless architecture automatically impose many requirements on the solution’s implementation. If the architecture uses a digital cellular network, that portion of the implementation involves negotiating a service contract with a cellular provider. Conversely, an infrared network may be created from components purchased and installed by the solution’s users. Selecting a particular wireless device means buying into that device’s operating system, which in turn, drives the development tools used to create applications for that device. The choice of a particular wireless consulting firm as a partner may be based on its experience with the chosen technology. While the wireless architecture is the source of many implementation requirements, the other layers of the Wireless Decision Process provide additional input. If the wireless solution needs new audit procedures, those procedures must be designed and deployed as part of the implementation. The solution designer gathers implementation requirements at each step of the Wireless Decision Process and consolidates this information after completing the wireless architecture design.

5.2.7 Implementation Strategy

The final layer of the Wireless Decision Process turns the implementation requirements into an implementation strategy and project plan. The implementation strategy identifies all of the people, processes, and tools needed to implement and operate the wireless solution. For instance, the strategy might opt to perform development work with internal company resources or to hire a consulting partner. In addition to addressing the construction and roll-out the wireless solution, the strategy also covers training, user support processes, system management tools and processes, and the myriad of details needed to support the production use of the wireless solution. The level of effort for creating the implementation plan is proportional to the scale and complexity of the wireless solution. A simple solution, such as providing RIM BlackBerry devices to executives for e-mail access, will have a relatively simple implementation, although it will still involve training, support, and other roll-out and operational issues. In contrast, a large-scale solution, such as supporting UPS delivery drivers throughout the U.S., is a major endeavor and implementing each solution component can be a significant project requiring its own plan.

5.3 From Business Requirements to Technical Requirements

This section describes how to implement the Solution Requirements layer of the Wireless Decision Process. It offers guidance for translating the business requirements captured through the 5 W’s approach from Chapter 4 into a set of technical requirements to facilitate component selection and architecture design. This process is primarily an exercise of mapping solution needs, described in business terms, into technical parameters by wireless component category. For example, evaluating the physical environment where a building inspector performs his or her job identifies the ability to operate under poor lighting conditions as an important business requirement. Within the wireless architecture, lighting conditions are addressed by the characteristics of client device’s display. The building inspector’s lighting needs translate into a requirement for a backlit display within the Device Requirements section.

The table in Figure 5.4 shows the mapping of the 5 W’s questions into the major
selection criteria for the four wireless architecture categories.

FIGURE 5.4
Five W’s Table

The subsections below help you to identify quickly the major technical requirements for each wireless architecture category. Each subsection has a short “cheat sheet” questionnaire to assist you in setting high-level selection parameters. Use these parameters to hone in on the component options that best fit your needs. While more thorough and detailed research is needed to create formal technical requirements documentation, use the “cheat sheet” approach as a shortcut for moving from requirements to design in Section 5.4.

5.3.1 Devices

The two biggest influences on device selection are the solution’s users (Who) and the functions or applications (What) the solution will provide. Other important factors are the environments (Where) where the devices will be used and business considerations (Why) such as cost and extensibility. The relative importance of these business requirements to device selection is shown in Figure 5.5.

FIGURE 5.5
Device Requirements Table

The characteristics of the application(s) will largely determine the device, since the device must have features to facilitate the operation of the application. If the application is highly specific or closely tied to a vertical process, then a special-purpose device may be needed. An inventory management application may call for a bar code scanning device, while a parts replenishment application may call for telemetry equipment. If the application is aimed at improving mobile worker productivity, then a more versatile, general-purpose device will likely suffice, and factors like user preferences, device portability, extensibility, and cost will greatly rule in or rule out certain device types. Since devices are the most personal component of your wireless solution, your future end users are likely to have strong opinions about which devices they are willing to use. For example, executives may not have the patience or inclination to work with a multi-featured device. Repair technicians that will simultaneously operate other equipment may favor a device that can be used with a single hand. Salespeople may avoid stylus-oriented devices for fear of losing the stylus while traveling. In some cases, such as consumer applications or sales applications, your solution may have to support the devices already owned by your target audience. Try to develop a profile of your target audience so that a device can be selected that meets the group’s rather than individual’s needs.

The major criteria for defining device requirements are shown in Figure 5.6, the Device Selection Cheat Sheet. Refer to Chapter 10 for more detailed descriptions of each criteria.

FIGURE 5.6
The Device Selection Cheat Sheet

FIGURE 5.6—Continued
The Device Selection Cheat Sheet

When selecting requirements, remember that some device features are more important than others. For example, a color display may be a nice feature but add nothing to an order status application, and even be detrimental to battery life as compared to a monochrome unit. An application that relies primarily on voice processing may call for a device optimized for voice, such as a smart phone or communicator. In general, a laptop device will offer the richest functionality of all the mobile devices. When it comes to display size, data input mechanisms, processing power, memory, extensibility, wireless communications, and availability of third-party software, a laptop can’t be beat. Laptops, however, may fail to satisfy user preferences. The large size and weight of a laptop, the long time to power on, and the complicated software and hardware environments lead many users to select a more portable, faster, and simpler device.

1. Voice  Will the device need to support voice communication instead of, or in addition to, a data application? As described in Chapter 10, wireless device features are starting to merge, with PDAs supporting voice processing and telephones supporting data displays and Internet access. Additional capabilities are required if the solution calls for other voice processing such as recording or speech recognition.
2. Size/Weight/Portability  These requirements—size, weight, and portability—are largely influenced by how the user expects to carry or wear the device. While some types of devices, like laptops, may be disfavored because of their size, other devices like PDAs may fit a wider variety of needs. In general, if a device is burdensome in terms of size, weight, or ability to be stowed, or limits the performance of other activities (e.g., requires two-handed use or cables), then a user will tend not to carry or wear the device.
3. Display  Our natural inclination is to select the largest and most visually appealing display possible. Selecting the right device display, however, is likely to involve a compromise between display capabilities, portability, power requirements, and cost considerations. For example, a color display may be irrelevant to an order status application, and even be detrimental to battery life as compared to a monochrome unit. The best approach is to define the minimum requirements for the planned solution and to upgrade from those requirements when feasible during device selection. Three major criteria help to define device requirements: display size, display quality, and performance in variable lighting conditions. The volume of information that must be displayed at one time determines display size. At one extreme, a pager may display one line of text. At the other extreme, a laptop provides a full screen display. The quality of a display includes its resolution and color capabilities. Simple text can be displayed monochromatically in low resolution, while high resolution is necessary for graphics or video, or to display larger volumes of information on a small display. Variable lighting conditions require more flexible displays, such as a backlit display for dimly lit locations.
4. Data Input  How will the user interact with the device? How will information be entered into the device? How much data will be collected? Data collection may be automated through the use of scanners, readers, or sensors. In most cases, however, the user will interact with the device through a keyboard, touchscreen, or other data entry mechanism. The choice of mechanism depends on the volume of data being entered and the working style and personal preferences of the user. A full keyboard may be required to enter a large volume of text, but an inspector checking items on a form may work best with a stylus. A small, thumb-typing keyboard may be perfect for short e-mails, but difficult to use for someone wearing protective gloves. A user sitting at a desk can use a foldout keyboard, but a trader on the stock market floor needs a portable mechanism that can be used while standing.
5. Processing Power  Processing power is determined by the needs of the application(s) that will operate on the device. If the device merely displays data from other sources, processing requirements are low. Conversely, if the device has to support multiple concurrent applications or heavy calculations, it will need greater processing power. Limitations in processing power can sometimes be addressed through careful partitioning of functionality between device and server, a topic discussed in Chapter 12.
6. Memory  Like processing power, memory is determined by the needs of the application(s) that will operate on the device. Running a single, simple application takes far less memory than supporting multiple concurrent applications. Multimedia applications, for example, will require more memory than a standard word processing application. The ability to add external memory to a device can help ease storage demands, but will not alleviate a persistent lack of memory.
7. Durability  Mobile devices are often subject to adverse conditions and abuse.
   A stationary device within a controlled office environment faces the fewest
   durability issues, while a device used outdoors on a construction site must be
   rugged to survive. A device used in dusty or damp conditions better have good
   sealing. If the device is apt to be dropped, and most will be, can it withstand the
   impact? Will it be dropped on carpet (in an office), or on concrete (outside or in
   a warehouse)?
8. Battery Life  Battery life is not an issue for devices installed in offices or on vehicles with easy access to power, but becomes an important issue for mobile devices used away from convenient power sources. Factors that affect battery life are expected level of use (occasional versus constant use), power draw by the device and application, availability of recharge power sources, length of downtime needed to recharge, and the convenience of carrying and inserting spare batteries. Figuring out power needs before a device and application are used in real versus simulated conditions is guesswork. If loss of battery power could cause significant damage or problems, however, it pays to consider battery options and mitigation strategies upfront.
9. Built-In Capabilities  An important tradeoff when selecting a wireless device is whether to have as many of the necessary capabilities already integrated in the chosen device or opt for an extensible device amenable to add-ons. Fully integrated devices tend to be bulkier, heavier, and more power-hungry than extensible general-purpose devices, affecting portability to a degree, but eliminating the inconvenience of carrying a device with separate attachments. When carrying and accounting for multiple pieces of equipment is problematic, simpler is better. For example, a package delivery person collecting signatures at each drop-off location, or a lineman climbing a telephone pole, won’t want to carry any more components than necessary. Conversely, an executive user may prefer a smaller device, and be willing to keep extra components in a briefcase until needed. Consider whether the additional capabilities will be used constantly, such as a network connection, or only occasionally such as a foldout keyboard for an executive’s PDA. If a wireless application requires a highly specialized set of features, the best approach may be a custom-built device that integrates all of the features. In addition to network support, special features that could be incorporated in an integrated unit include bar code scanning, credit card processing, and voice recording. One disadvantage of a highly integrated device is the need to scrap and replace it when capability requirements change over time.
10. Extensibility  Extensibility is the flip side of built-in capabilities. It assesses the ability and desire to add and attach new features to the selected device. Extensibility is a means of getting around constraints, such as adding a foldout keyboard to enable higher volume data entry into a PDA. Add-on features include flash memory for back-ups and data transfer, plug-ins for voice and games, modems and cards for network communications, and other data entry mechanisms such as scanners and credit card readers. Special-purpose devices such as e-mail appliances tend to be less extensible, whereas PDAs and laptops are more extensible. Extensibility adds to the lifespan of the device and solution by allowing it to evolve to meet new requirements. On the other hand, users may resist carrying separate add-ons for commonly used capabilities.
11. Bundled Software  Devices, such as PDAs, are provided with a set of bundled software. This software includes the operating system and applications such as a spreadsheet and word processor. In single-purpose solutions, such as e-mail on an e-mail appliance, the particulars of the bundled software are unimportant to the solution. In other cases, the availability of a particular bundled application, such as word processing, may be an attractive feature that can differentiate between two otherwise close options. For other applications, the characteristics of bundled software are critical. For instance, the choice of application or middleware may necessitate the use of a particular operating system. If you plan on developing custom applications, your developers may come up with their own specific requirements for the device.
12. Availability of Third-Party Software  Depending on the business problem being addressed, availability of third-party software for a given device may be the number one factor driving selection or may be totally unimportant. Third-party software can provide base application functionality, add-on applications, and/or development and support tools tailored to the specific platform. Some ERP, CRM, and SFA software vendors offer mobile extensions to their solutions for certain wireless devices. The availability of third-party software for a given platform can be an important proof point of its level of adoption within the marketplace. If the business requirements are sufficiently unique or leading edge to require a custom programmed solution, availability of third-party software may be unimportant.
13. Personal Information Management (PIM)  PIM tools such as contacts, calendars, task lists, and alarms were the original applications provided on PDAs. These tools are increasingly offered on a variety of wireless devices. They may be important and attractive to sales and executive solutions, but less important or unnecessary for many special-purpose applications. If PIM features are desirable, it is important to ensure that the wireless versions and office versions are compatible.
14. Internet Access  The ability to access and surf the Internet through a mobile device is not a requirement for many applications. In other cases, such as for executives and salespeople, it can be a “nice to have” feature that is used occasionally. Given their smaller display size and slow data transfer rates, devices such as WAP telephones offer access only to specially enabled web sites. For the mobile professional, Internet access may still be useful for information such as weather reports and stock quotes. If full Internet access is a necessity, a laptop and access to a high-speed network become requirements.
15. E-mail Access  E-mail is the killer application for many wireless solutions. Devices vary widely in the quality and ease-of-use of their e-mail support. If e-mail is an essential application, it is important to evaluate how well the device can send/receive, display, and manage e-mail messages and attachments. If limited access to short text messages is sufficient, a wider range of devices can be considered. While e-mail access may be essential to an executive solution, it may be entirely unnecessary for a device used on a manufacturing shop floor.
16. Cost  If you are providing a wireless service to end users who already own devices, device costs are irrelevant. Similarly, the cost of supplying an executive with a PDA is insignificant compared to the value of fast response to business issues. Price sensitivity may be an issue, however, for users, such as students, that must purchase their own devices. Also, although wireless devices can be relatively cheap compared to desktop workstations, total device costs will mount quickly if there are thousands of expected users.

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.

FIGURE 5.7
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.

5.3.3 Information Infrastructure

Information exchange is the underlying purpose of virtually every wireless solution. The data source, volume, and confidentiality requirements of a wireless application affect many aspects of the solution architecture, and implicate back-end application integration, data security, and network choices. The solution’s information infrastructure supports the wireless application’s information needs. For certain types of wireless applications, the information infrastructure is pre-supposed. Wireless Internet access or WLAN access takes advantage of pre-existing information infrastructures. Conversely, special-purpose wireless applications will likely need a separately defined architecture to handle information needs. For example, providing a field service worker with access to current customer status may require capturing and integrating information contained within various back-office customer and support databases.

The main drivers for information infrastructure requirements are the answers to the What and When categories of questions. In many ways, application functionality sets data requirements, especially from a source and content perspective. When a user needs access to data and how long that data remains useful define the mechanics of data transmission. Who is using the data and where it will be accessed affect considerations such as data formatting and display and security and back-up requirements. Like wireless applications, information infrastructure requirements are not easily captured through a simple checklist; however, the criteria in this section will help you develop a high-level understanding of your needs. As shown in Figure 5.8, the criteria in this section are: data sources, type of data access, volume, format, latency, immediacy, data integrity, synching requirements, and security. Refer to Chapter 12 for additional information on these topics.

FIGURE 5.8
The Information Infrastructure Cheat Sheet

1. Data Sources  This criteria applies to wireless applications that exchange data with corporate information systems and other repositories of information. A source may be a host database, file, a web site, or a wireless interface into a host application. Information from a single source may be delivered directly to the application, for example, a query sent to the wireless interface of a CRM package returns a response specifically formatted for the application, or it may have to be drawn from several sources and merged or processed before sending. In the latter case, the information infrastructure will have to contain the additional hardware and software needed to process the data. Processing may involve calculation, extraction, summarization, or reconciliation of disparate data to make it useful for the wireless application. As a starting point, list each potential data source needed for your application.
2. Type of Data Access  Data may flow in either direction between host and device. Data may be intended for viewing only, or for update (added or modified). A more complex architecture is needed to support data modification than simple data viewing. For each data source selected above, identify the appropriate data access requirements. For instance, an inventory tracking application may capture bar code information on the device for uploading into the corporate inventory database. A wireless banking application will allow customers to transfer funds between accounts. These types of applications require the ability to update host data.
3. Volume  The volume of information that the application will exchange has implications for data display, storage, and transmission. Given bandwidth constraints, data volume is an important consideration for network selection, but also affects application design. Application users may not tolerate the time and effort required to process and display large volumes of data, requiring creative design techniques to extract and present only the data most relevant for their needs. Volume of data ranges from very low, such as alerts and short messages, to very high for videoconferencing.
4. Format  Data format affects the level of processing needed to get the information into a form useful for the wireless device. Simple text data, web pages formatted for mobile display or files compatible with a given wireless application (e.g., a word processing document) may be exchanged “as is” without further processing. Other information exchange formats, such as XML and its variants, use stylesheets to allow the same data to be presented in different ways on different devices. This approach is used to “re-purpose” web-based data for simultaneous use on a wireless device. Given the limited data capabilities of many wireless devices, relevant data may need to be extracted from larger sources. At the high end, a complex query, such as providing a summary of sales activity across five territories, may require considerable processing to return the data to the wireless device in an acceptable format.
5. Latency  Data often has a useful “shelf life” or latency before it loses its value. Latency affects how and where data is stored and how frequently it must be refreshed to maintain its value. Some data, such as a list of inflation figures for 1990 through 2000, will never change and has infinite latency. Perishable information, such as the price of an individual stock during trading hours, changes on a moment’s notice and loses value quickly. In contrast, an e-mail message may retain its value while it sits in an inbox for several hours. Estimate the latency of the major information exchanged by your wireless solution.
6. Immediacy  Immediacy addresses how quickly a given unit of data must be exchanged between the device and server. Stock price movements may require instant dissemination while inspection data may require only periodic updating. Serving the stockbroker with price information requires real-time processing and an “always on” network connection. The inspection application requires only hourly synching between device and server. Immediacy requirements affect both sides of the wireless exchange. A server-resident application that tracks packages may expect immediate notification of delivery problems from the field, but only periodic uploads regarding successful deliveries. Some server-resident information, such as stock price fluctuations, may require immediate dissemination while other information, such as last week’s closing price, can wait until the broker specifically requests it.
7. Data Integrity  Data integrity assesses the risk to the organization if a piece of data is corrupted or dropped while in use by the wireless application. When data problems occur, if the symptoms are obvious rather than subtle, and if the data can be quickly and easily recreated, then data integrity is not really an issue. For example, if a download of the latest news from a web site is interrupted, the transmission can be restarted without concern for integrity. Conversely, executing a wireless fund transfer requires careful measures to ensure that the data is correct and reliable, and that all aspects of the transaction complete successfully.
8. Synching Requirements  Some data, such as a contacts file, may be maintained in multiple locations. Ideally, data should be identical at all times, across all locations, but this goal is not always feasible or practical. Synchronization is the method used to match data sources on a periodic basis. The period between synchronizations is determined by the latency of the data being shared and practical considerations for exchanging data. Synchronization may proceed in three ways. Data resident on a wireless device can be periodically delivered to a server. For example, a package delivery person sends collected delivery data to headquarters every few hours as he passes by a wireless access point in his vehicle. Server-resident data can be pushed out to a wireless device, replacing the version of the data kept on the device. For example, an engineering firm could send updated schematics to its field service workers’ devices once a week. Or device-resident and server-resident data can be compared, matched, and merged to create updated versions at both ends, a process requiring a more complex synchronization scheme to deal with data conflicts or inconsistencies.
9. Security  The value and confidentiality of a piece of data determines the level of protection needed. Issues include who has access to that data, how it is transmitted and how and where it is stored. Authorization—access to a given function or piece of data—can be controlled at the information architecture level. For example, a user may be able to access personnel records from his department, but not from other departments. Highly confidential data may need additional security layers such as a secure network and/or encryption when it is transmitted. Given the high rate of theft and loss among wireless devices, a solution may require the encryption of confidential data stored on a device, or it may prohibit storing data on a device altogether.

5.3.4 Wireless Network

Answers to the Where category of questions are the predominate driver of network selection, however, the other categories help set other important network requirements. There are seven major criteria for defining network requirements as shown in Figure 5.9: coverage, bandwidth, latency, reliability, security, interoperability, and cost. Refer to Chapter 11 for more detailed descriptions of each criteria.

FIGURE 5.9
The Network Selection Cheat Sheet

1. Coverage  The level of coverage required to support your desired solution is the major determinant of your network options. Since your final wireless solution may involve more than one network type to gain the desired coverage, be sure to indicate all applicable requirements on the checklist. Where people will use the application in the field and how far they may roam are the determining factors for coverage. For example, if the users are waiters at a restaurant, the coverage area is obviously circumscribed. Sometimes there will be multiple locations of intended use. For salespeople using a wireless application designed to answer customer queries, coverage will be needed wherever customers are located. If salespeople also want to use their devices for e-mail, coverage may be needed at their homes or remote offices as well. If users are repair technicians servicing gas lines or power stations, coverage will be needed wherever these physical assets are located. If a “user” is a piece of equipment, coverage will be needed wherever the equipment may be located or moved. One approach to determining coverage is to create a map of the locations where the application is expected to be used, and compare this map to a potential carrier’s coverage map. The more overlap, the better the coverage. The physical environment where the solution will be used also affects coverage. Environmental conditions influence the working as opposed to theoretical range of the wireless network and pose possible reception problems. For example, the range of an infrared network goes to zero if there are obstructions between communicating devices. The signals transmitted over a short-range network become progressively weaker as the distance between transmitting and receiving devices grows. In-building reception may also be poor with some WANs. Information about the environment can also help uncover interference concerns, and characteristics of the physical environment may also help narrow device choices.
2. Bandwidth  While short- and medium-range wireless networks can approach wired throughput, bandwidth is currently a limiting factor for wireless WANs. Although bandwidth limitations can be overcome to a degree by application design, transfers of large quantities of data over a wide coverage area remains slow and costly, and downloading of some applications, such as video, are not presently feasible over wireless WANs. Consider bandwidth requirements by the primary types of data transfers your solution will need and the user’s tolerance for waiting. Users may be willing to tolerate a longer transfer time for occasional activities, such as downloading a system upgrade, if their routine activities occur at a reasonable speed.
3. Latency  Latency, the timeliness of information exchange, is not really an issue for local, in-building wireless networks, like WLANs or Bluetooth. Their performance depends in large part on the performance of the wired network to which they connect. Latency becomes an issue when wireless WANs are used, and organizations want the ability to push information to users wherever they are, and want mobile users to be able to transmit information back to headquarters from any locale. Data that must be accurate to the second, such as stock price quotes, requires an always on, “zero” latency approach. Less time-sensitive data, such as filing service reports, can be transmitted by storing and forwarding the information when convenient, perhaps through synching. Even when real-time information is desired, remember that coverage and data volume/network bandwidth can impede or prohibit immediate access.
4. Reliability  Reliability assesses the tolerance that a wireless application has for network-related problems. Applications aimed at ensuring personal safety are useless if the networks they run on are available only sporadically. Likewise, wireless applications that depend upon the integrity of transmitted data, such as processing a credit card transaction at a point-of-sale terminal, cannot afford a network that regularly drops data.
5. Security  Although security is ultimately an “end-to-end” issue that includes devices, servers, applications, and other solution components as well as networks, wireless networks differ in their inherent levels of security. WLANs have experienced some well-publicized security flaws, while WANs are generally highly secure.
6. Interoperability  This factor is more of a design “flag” than a network selection criterion. The preponderance of wireless components and platforms, from devices to modems to network equipment to cards, makes interoperability essential. As interoperability declines, costs and support overhead mount, and redundant, overlapping, and conflicting solutions emerge. Interoperability within a class of wireless network solutions, such as Wi-Fi WLANs, may be high, but interoperability between different network types is iffy at best. Interoperability is not an issue for standalone solutions that rely on a single network and limited device types, but can be a significant issue when designing a solution for rollout to a diverse and dispersed audience.
7. Cost  Networks and network services vary by cost of implementation and cost of usage. There may be a range of suitable wireless network options, with a range of features, available at different cost points. Knowing the correct one to choose may hinge on the amount of money budgeted for the solution.

5.4 Moving from Requirements to Design

With solution requirements in hand, you are ready to start your wireless architecture design. In keeping with the book’s “Just Enough” concept, the steps described in this section will help you select the components for an initial high-level design. This design should be sufficient to roughly scope the project and provide a starting point for further research and more detailed discussions with your technical architects and consulting partners. The final, more detailed architecture and design can be a significant project and must be performed by the team that will be charged with its implementation.

The remaining chapters and appendices within this book provide a wealth of information to assist in solution selection. Figure 5.10 shows the relationship of the book’s chapters to the layers and components of the Wireless Decision Process. Additional, up-to-date information can be found on the book’s web site, www.just-enoughwireless.com, and the other web sites listed throughout.

FIGURE 5.10
The Wireless Decision Process with Chapter References

Use the following steps to guide your selections for each of the four wireless architecture component categories. Once choices have been made in these categories, the same process can be used to support an initial design for the Implementation and Support Infrastructure component.

1. Review the Technical Requirements  Make sure you have a good understanding of the technical requirements for the component category that you are selecting. If you have used the forms provided in Appendix A, these requirements will be organized by the same parameters used in the descriptive chapter.
2. Gain an Overview of Component Features and Selection Considerations  Each component chapter contains a wealth of information; however, many details may be outside your areas of interest. To focus your efforts, concentrate on the chapter introduction, considerations, and features and function sections.
3. Identify the Options Best Suited for Your Situation  Using the constraints imposed by your technical requirements, you should be able to identify quickly a narrower range of options. For example, if your desired level of wireless coverage is confined to an office environment, you can focus on short- or medium-range, “Do It Yourself” networks.
4. Read the More Detailed Descriptions on Your Candidate Options  Refer to chapter comparison tables and read the detailed descriptions on the remaining options. This information should further refine your options and may identify the specific one that best suits your needs. Note any issues or constraints that may conflict with choices made in other architectural categories.
5. Perform High-Level Research  When a preferred option or set of options has been identified, perform some additional research to ensure you have the latest available information to guide your decisions. Wireless technology is evolving so quickly that getting current information is essential. Identify the vendors offering the desired solution. Visit industry and vendor web sites, read analyst reports, and contact peer organizations. Check for newly announced standards, evolving features and functions, current pricing, and new, competing options. Again, note any issues or constraints that may cause conflicts.
6. Finalize High-Level Selection  The information from the previous steps should be sufficient to select the candidates for your initial, high-level design and provide cost estimates for cost justification efforts.
7. Conduct Detailed Research  For many wireless solutions more research will be required to support the detailed design and final selection of the components to be implemented. This research can include product and vendor evaluations, technical feasibility pilot projects, and visits to corporate users of the desired technology.

5.5 Working Around Wireless Constraints

As you translate your business requirements into technical specifications, you will undoubtedly discover that the wireless environment is rife with constraints, incompatibilities, and compromises. You may discover that your original solution cannot be deployed as envisioned as limitations in areas such as wireless network bandwidth and device displays reintroduce constraints that have long been eliminated in the world of wired workstations. Don’t let these issues push you into abandoning or unnecessarily delaying your foray into wireless technology. Although wireless technology has yet to reach the levels of maturity, standardization, and support found in other information technologies, corporations such as FedEx and UPS have used wireless solutions productively for years. Current wireless capabilities are sufficient to handle many practical applications, and wireless constraints can often be overcome through creative design. There are two principle categories of wireless constraints.

• Evolving Constraints  Some wireless constraints are temporary. Over time, the rapid evolution of wireless capabilities will reduce constraints in areas such as standards, bandwidth, coverage, security, and support tools. For example, the throughput of short and wide area wireless networks continues to improve, and the arrival of 2.5G and 3G networks will provide high-speed data exchange across a wide geographic area. Similarly, coverage is improving as wireless network operators continue to add infrastructure.
• Inherent Constraints  Other constraints such as device size, display limitations, and data entry capabilities, result from the demand for small, portable devices and are a permanent part of the wireless landscape. A typical mobile device will never support the robust applications found on a desktop. Display size and resolution determine the volume and type of information that can be presented effectively. Keyboard size or handwriting recognition schemes direct the types of interactions possible. Memory and processing power affect the architecture of the application. Size, weight, and useful battery life affect the portability and convenience of the device. These inherent constraints must be overcome by designing around them. For example, applications can use numbered menus or forms to minimize data entry, and intelligent partitioning of functionality between the device and an application server can circumvent processing and memory constraints.

There are many possible paths to take when designing a wireless solution. If the original solution is blocked by limitations, another approach or combination of approaches may give you the capabilities you need.

5.5.1 Rethink Constraints

Is the perceived constraint truly a limitation or is it imposed arbitrarily? A given solution may require sending forms between the user and a corporate system. If the entire form is sent on each transmission, the bandwidth of a wireless wide area network may be insufficient. If the application is designed to transmit only the changed portions, however, current bandwidth may be more than adequate. Does a traveling salesperson really need instant access to account file updates or can files be updated once a day? System architects and designers used to working on unconstrained wired office systems may need to rethink their approach to solution design to work around, or even take advantage of, the differences in wireless capabilities.

5.5.2 Switch Paths

Ask yourself if you can accomplish the same goals with a different set of technology options. For example, if your main goal is to relay sales orders to your corporate office, you may enter the information through a wireless web page, use a custom designed form to transmit data across a digital cellular network, or use e-mail templates through an e-mail device. While the form of the data and the design of the application may be very different, the end result is the same—the sales order is relayed.

5.5.3 Reprioritize Features

While the originally intended, fully featured content-rich solution would have met every need of your target audience, you may be able to gain most of the solution’s benefits using a less ambitious design. As described in the Chapter 3 case study, Atlantic Envelope Company found that a small set of capabilities covered a very large percentage of their sales force automation needs. Focusing on the top ten customer queries, allowed the company to develop, deploy, and gain benefits from their solution now, using currently available and easy to implement technology.

5.5.4 Find Creative Workarounds

Look for creative workarounds if particular aspects or functions of your solution run into roadblocks. As an example, in an originally envisioned medical solution, emergency room doctors would have received an updated version of the emergency room’s patient whiteboard on demand. Experience quickly showed, however, that the busy and highly mobile physicians could not tolerate having to initiate and wait for the updated whiteboard to load on their handheld devices. To overcome this issue, the project’s design team switched to a “push” approach, automatically relaying updates once a minute to the doctors’ devices. By restricting transmissions to only those items that had changed, transmissions were kept short and unobtrusive, enabling the doctors to simply look at their devices periodically to see up-to-date whiteboard contents.

5.5.5 Break the Problem into Smaller Parts

Sometimes a combination of approaches provides a more effective solution than a single approach. Penske Logistics uses wireless technology on its trucks and at its cross docks to keep customers informed about deliveries and manage driver routes and performance. An onboard computer manages and transmits data about arrival and departure times, delays, traffic conditions, and changes in schedules in near real time over a satellite network. More routine data about cargo pickups and drop-offs is captured via handheld devices used by delivery personnel. When a truck returns to a Penske terminal, the routine data on the handheld device is synchronized with the host system via a wired docking cradle. This hybrid approach provides immediate exchange of high-value information, with coverage across Penske’s entire delivery range, with periodic bulk transfer of less time-dependent data at much lower network costs.

5.5.6 Phase Your Solution

If your solution is constrained by limitations in evolving areas, such as coverage or bandwidth, you can use a phased approach to implement a subset of features now and add new features as limitations disappear. For example, you can provide field service workers with a mobile solution for dispatch and work order invoicing with current technology and add capabilities, such as access to on-line repair manuals or videos of repairs in action, as network capacities increase.

5.6 Example Solutions

The best way to illustrate the principles of this chapter is to examine a few actual examples of wireless applications. This section describes four diverse types of applications: e-mail service (Figure 5.11), WLAN (Figure 5.12), data capture (Figure 5.13), and national tracking and location (Figure 5.14), and the considerations that influenced their designs.

FIGURE 5.11
E-mail Service Architecture

FIGURE 5.12
Wireless LAN Architecture

FIGURE 5.13
Data Capture Architecture

5.6.1 Example Architecture: E-mail Service

• Application  Atlantic Envelope Company (AECO) wanted to give its salespeople wireless e-mail access and a custom application that would allow them to answer customer queries and submit changes to orders. AECO chose e-mail as the platform for person-to-person messaging, and as a method to exchange transactional data between client devices and a back-end server. To overcome expected device presentation and network bandwidth limitations, AECO designed its application to focus on customers’ top ten queries and to use forms and templates to ease data entry and minimize data transfer.
• Information  AECO isolated the data needed to support the application to order, customer account, and inventory information. Without a central source of this information, AECO created a program to draw the data from several back-end systems, store it on an application server, and refresh it twice daily, a timeframe sufficient to provide reasonably current information to the field.
• Device  AECO had two important device requirements: the device had to be optimized for e-mail and give sales reps the ability to type freeform e-mail messages using a keyboard rather than a cryptic handwriting scheme. These two requirements led AECO to choose a RIM BlackBerry device equipped with a keyboard.
• Network  Given the locations of its customers and the areas in which salespeople would roam, AECO had one viable network choice: a wireless WAN. Drawing a map of its customer locations, and superimposing this map on various carriers’ coverage maps, led to the selection of Cingular Wireless as the carrier with the best overlap. Although maintaining the integrity of transmissions wasn’t a key concern for AECO, the RIM devices and network allow for storing and forwarding of messages when a sales rep is out of the coverage area.

5.6.2 Example Architecture: Wireless LAN

• Application  Hull Trading wanted to give its derivatives traders access to current pricing information and to capture a record of trades as they occurred. As mobile workers on the floor of an exchange, these traders previously had to rely on hand signals and runners to obtain information from individuals using desktop systems.
• Information  The pricing information that traders needed included real-time bids, offers, and other proprietary information. This information was already available on site through a wired network connection, making it simply a matter of transmitting the data to the floor. As transactions completed on the floor, that data would be transmitted to a local server to be forwarded to a central database.
• Device  Traders needed to look up information and execute trades quickly. With speed as a primary requirement, data entry had to be fast, precluding keyboard-based input. Since traders would be physically standing on the floor, they needed a device they could easily hold in their hands, that wasn’t too weighty, that would remain charged during the course of trading hours, and that allowed them to access information using one hand. A pen-based handheld PC from Fujitsu Personal Systems fulfilled these requirements.
• Network  Traders were located within a main, indoor area, but were mobile within that space. Network choices were narrowed down to short- and medium-range solutions given the local coverage needed. With a lot of movement on the floor, an infrared network was obviously inappropriate—traders could not stay in close, unobstructed proximity to network transceivers. The range limitations of Bluetooth would not work within the exchange. A WLAN solution was selected for its ability to support mobile traders throughout the entire trading area despite physical obstacles.

5.6.3 Example Architecture: Data Capture

• Application  UPS wanted to standardize its systems for tracking packages in its distribution centers. The wireless application had to be able to capture data for each package traveling through a center, to enable the company and its customers to track a shipment in real time. Package sorters would use the application to collect data encapsulated in the bar code affixed to each package.
• Information  The goal of this application was to improve the way that data was transmitted from the point of collection on the sorting line to the back-end databases. Since this data was already being collected and tracked via other means, the existing information architecture would suffice for the new wireless implementation.
• Device  The users for the application were package sorters handling the packages moving on belts through the distribution center. The chosen device had to allow the workers to be mobile at their station, permit hands-free usage so that workers could continue to handle packages, and be free of parts or cables that might snag in the moving equipment. The device also had to support bar code scanning, and contain appropriate integrated wireless communications capabilities.

  To meet these requirements, two devices were chosen. The final selection was inextricably tied to the network options chosen (see below). The first device would perform the bar code scanning function. To free the workers’ hands and avoid cabling, UPS chose a cordless, optical, bar code scanner mounted in a ring and worn on the finger. No commercial device was available that met these specifications, so Symbol Technologies was tapped to develop a custom device. To move the data scanned by the ring device to back-end systems, some type of wireless capability was needed. The size of the ring device precluded using a modem or WLAN adapter, but a small Bluetooth chip could be integrated without any problem. The disadvantage of using Bluetooth was that its range was insufficient to transmit the data straight to an access point located a distance away from the worker. Another device was needed to effectively “stage” the data and forward it via a more powerful network technology such as a WLAN.

  The second device had the same requirements as the first device—it could not impede the workers’ movements and could not have cables—but would necessarily have to be larger than the ring device to accommodate integrated WLAN capabilities. The final choice—a belt-worn terminal that would receive data sent from the ring device and forward it via a WLAN. Again, no commercial device existed with integrated Bluetooth and WLAN capabilities, so Motorola was chosen to develop a custom device. The cost savings anticipated from the wireless solution were deemed sufficient to justify the investment in these custom devices.

• Network  Given that the users of the solution—the package sorters—were located in a relatively contained physical space—a distribution center—short- and medium-range wireless networks were potential solutions. The distance over which data would be transmitted was within the range of a WLAN solution. But as noted above, device considerations (the small size of the ring scanners) precluded the use of a unified WLAN solution. The remaining possibilities, infrared and Bluetooth networks, could handle the size constraints, but faced other issues. Infrared technology was eliminated because the workers’ hands were constantly in motion and obstacles, such as packages and equipment, meant that line-of-sight requirements could not be met. Bluetooth, with its small chips, would work in the ring devices but was not robust enough to transmit data over the distances required in the distribution centers. A dual-network solution was needed to pick up the Bluetooth transmitted data, and then pipe it to the transceivers strategically located through the center. The best candidate for that task was a WLAN.

  Choosing a dual-network solution posed device challenges since an integrated Bluetooth/WLAN device did not exist. Developing a device that could interact with both types of networks took some ingenuity. Since Bluetooth and WLAN networks operate in the same 2.4 GHz radio frequencies, signal conflict was a foreseeable problem. Symbol Technologies came up with a solution that allowed the device to pick up Bluetooth signals, and when the spectrum was quiet on the Bluetooth front, transmit the data over the same frequency to a WLAN access point.

5.6.4 Example Architecture: National Tracking and Location

• Application  Penske Logistics wanted to offer its customers more timely access to performance and logistics data, allowing them to monitor service levels among their supply chain partners. Penske designed three different applications to gather the necessary data: an application to improve communications between dispatcher and driver and transmit time-sensitive information; an application to track incoming and outgoing shipments at its cross docks; and an application to capture detailed data about goods picked up and delivered. The wireless applications needed the following abilities:
• Locate trucks and communicate with drivers to provide route information, pickup and delivery information, and route or schedule changes
• Track events such as arrivals, departures, and downtime, and communicate these events in real time to the internal logistics management system
• Track, locate, and manage inbound and outbound freight at cross docks
• Collect detailed delivery and pickup information for later uploading to the logistics management system
• Capture customer signatures and print receipts, if desired



FIGURE 5.14
National Tracking and Location Architecture

• Information  Several types of data were implicated in the solution, including:
• Bar code and other detailed freight and package information collected in the field and uploaded to internal systems intermittently
• Arrival, departure, and other time-dependent information, originating in the field and transmitted to headquarters in real time
• Alerts, schedule changes, and route information, originating at headquarters and sent to trucks in real time
• Inbound and outbound freight information tracked, collected, and managed at cross docks
• Device  Application requirements indicated that more than one device type was needed. For the truck fleet, two devices were chosen. First, GPS locators were installed on each truck to enable communications between dispatch centers and drivers no matter where the trucks were located. Second, to communicate route information, arrival and departure data, and freeform messages between driver and headquarters, another device was needed, one that would have data input capabilities for the driver. A larger-sized device with a keyboard was acceptable because the device would be mounted in the truck, drawing battery power from the engine. In addition, the device had to support real-time communications via a satellite network. QUALCOMM’s OmniTRACS unit was chosen, a rugged device with integrated satellite communication capabilities. To collect detailed data on pickups and deliveries, a third device was chosen. These devices had to be portable so drivers could easily carry them, and had to be capable of capturing data on labels as well as customer signatures. A handheld PDA from Symbol Technologies was chosen for the task. A fourth device was needed at the cross docks to locate, track, and manage incoming and outgoing freight. This device had to be portable and rugged, and needed WLAN capabilities to transmit the tracking information to an internal system, leading to the selection of an Intermec unit.
• Network  With trucks traveling virtually anywhere in the U.S., relaying real-time information would require a WAN. Because trucks would often travel in remote or rural places where digital cellular coverage was spotty or unreliable, a satellite network with ubiquitous coverage was chosen. To minimize the number (and expense) of satellite transmissions, only certain time-sensitive information (arrival times, departure times, downtime) is sent via satellite. At the cross docks, where incoming and outgoing packages and freight are scanned, tracked and managed, a medium-range WLAN solution was selected since it allowed dock workers and equipment to be mobile without the constraints of cables. Finally, the more detailed pickup and delivery information (number of parts, pieces, etc.) was not needed in real time, and could remain stored in the hand-held unit until a driver finished his route. This information would then be uploaded into internal systems, using a cradle and wired network connection.

This is a sample chapter of Just Enough Wirless Computing
by Ian S. Hayes
ISBN: 0-13-099461-8

For the full text, visit http://www.phptr.com
©2002 Pearson Education. All Rights Reserved.

# # #