January 27, 2021
Hot Topics:

Defining a Wireless Solution

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

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.

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.

Page 3 of 10

This article was originally published on October 16, 2002

Enterprise Development Update

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

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