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.
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
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.
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.
Size/Weight/Portability These requirementssize, weight, and portabilityare 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.
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.
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.
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.
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.
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)?
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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 genericproviding wireless e-mail access, for exampleit 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.
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.
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.
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.
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.
Security Security is an important consideration in all four wireless architecture componentsapplications, 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
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.
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.
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.
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.
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.
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.
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.
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.
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. Authorizationaccess to a given function or piece of datacan 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
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.
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.
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.
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.
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.
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.
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.