Chapter 3: Using Technologies to Meet Requirements

---

Whatever your background, eventually you will manage a project where one or more technologies are unknown to you. The worst-case scenario is to be assigned to a project calling for multiple technologies with some links or dependencies with each other. Your team may be adequately staffed with experts, but it could turn out that only one team member worries about the whole implementation being seamlessly integrated. That person would be you because each expert can be assumed to worry solely about his or her piece to the exclusion of their peers' work efforts, or the whole package for that matter. This chapter's purpose is to illustrate workarounds to this predicament.

3.1 Why Technologies Should be Used

In the last chapter, it was stated that technology should be specified to implement the requirements, which, in turn, are dictated by project scope. Further, it can be assumed that real-world business needs actually drive projects. One of the results of adequately applying the Big Thirteen interrogatory technique introduced in Chapter 1 is to understand these drivers. Always keep these in mind as technology issues arise during the planning and design phases of your project. You must do so because technologies have lives of their own that do not necessarily lend themselves to easy implementation and support. Worse, complex projects can easily become obsessed with the technologies themselves to the detriment of scope, beneficiaries, schedules, and budgets. In other words, if the technology or technologies themselves become scope, I can guarantee you nothing but pain and heartache, not to mention a highly probable state of defeat for you and your team. So, although it is natural and important to worry about technologies working, it is far more important to keep asking whether the technologies are delivering requirements, assuming you and your team know what they are.

The key to doing that is to keep project scope on the front page at all times. Perhaps it is easiest to do that by continuously reminding stakeholders of the answer to Big Thirteen question number two. This is the benefits question (i.e., "Why are we doing this?"). Again, the answer to this question should be some sort of business driver. Drivers that lead to technology implementations are too numerous to fully elaborate; the most common are listed in Exhibit 1.

Exhibit 1: Business Drivers and Their Technology Enablers

Business Driver	Technology
Provide new product or service.	Although the beneficiaries could be internal (i.e., workers) or external (i.e., customers or trading partners), this is likely, today, to be connectivity or "Web-based" products or services.
Consolidate facilities by relocating users to new building.	Latest LAN and WAN connectivity options such as routers, LAN switches and cabling, and multiplexers.
Make business application available "anywhere, anytime."	Convert mainframe or C/S applications to browser-based applications (e.g., HTML/XML or thin client).
Enhance user productivity.	Upgrade hardware, add functionality to legacy software, or replace legacy software with a newer product.
Maintain currency with technical advancements.	Upgrade to latest hardware or software release for operating systems, packaged productivity tools, etc.
Consolidate costs.	Consolidate and downsize computing platforms (e.g., migrate processing to midrange or LAN-based platform from mainframe or midrange). Outsource support or maintenance.
Improve network security.	Upgrade firewalls and proxy servers, or roll out encryption.
Leverage Internet connectivity.	Increase bandwidth (e.g., upgrade T1s to T3s), and incorporate SONET, WDWM, or DSL technologies.
Implement or upgrade DR or business continuity processes.	Build out new disaster recovery or business continuity site. Centralize server management and tape backup infrastructure.

Notice that each technology response to these drivers is pretty generic. For example, the initial response to the "Increase network security" driver is not "Install Vendor X firewalls," or "Add hardware encryption cards to edge routers." Instead, a rather prosaic solution is suggested, based on the general kinds of technology available to accomplish these different kinds of goals. This point is important enough that I want to pursue it. To do so, I will stay with the proposed opportunity to enhance network security.

Firewalls, proxy servers, and encryption increase security, but they do it in different ways:

• Firewalls provide security by controlling, to a certain extent, how people can get into, or go out beyond, the corporate Intranet, based on Internet Protocol (IP) addressing. Obviously, the primary goal is to keep prowlers from hacking into your internal network. Firewalls also perform other traffic access management duties.

• Forward and reverse proxy servers protect access into and out of your intranet as well, employing a totally different strategy and technology from the firewall approach.

• Encryption is yet another security enhancement that scrambles transmissions with the intent that intercepted data is undecipherable.

Therefore, each of these potential technical solutions differs from one another in terms of:

• The kind of protection provided

• Cost

• How it is integrated within the network infrastructure

• Functionality in addition to primary capability

• Potential (negative) impact on throughput, applications, or user satisfaction

• Skill sets required to design, install, operate, and maintain

Although "improve network security" is a reasonable statement of project scope, as a requirement, it is excessively vague. I managed a network security project where enhancing network intrusion safeguards was a key component of scope. The driver was to increase external access for thousands of users to more applications and data, particularly so that the mostly sales-oriented user base could be more mobile. From a technology perspective, this meant that the corporation was migrating the applications from a mainframe to dozens of Web servers. This change would significantly increase the amount of Internet Protocol (IP) traffic flowing in and out of the data center, which, in turn, exposed the company to significantly higher risk of being hacked, due to the nature of the Transmission Control Protocol/Internet Protocol (TCP/IP). The traffic load would increase dramatically as well. This was expected to stress the existing IP infrastructure (e.g., bandwidth, routers, proxy servers, and firewalls), with the resulting risk of frequent network outages. All this information needed to be considered as technology decisions were made.

To some degree, project output will be impacted by available technology. Therefore, part of the design process is reconciling requirements derived from scope with the potential technological solutions. This example is intended to demonstrate how important it is to analyze "Improve network security" very carefully before getting on with the design. Exhibit 2 presents the most common or typical "security improvement" goals.

Exhibit 2: Security Goals Mapped to Technology

Security Improvement	Technical Solution
Keep hackers out of your network.	Use firewalls to reject logins from prohibited external IP addresses.
Keep hackers from stealing internal IP addresses.	Use reverse proxy server to mask internal, originating IP address.
Block internal users from unauthorized Web sites.	Implement forward proxy server with site-blocking software.
Prevent hackers from stealing data transmitted from site to site.	Install hardware or software encryption.

This table could have more rows, but there is no need to get into an extended conversation on network security as long as the point is taken that one must clearly define the requirements in terms that will facilitate the appropriate selection of technology.

---