3.6 Review Validation Plan

< Day Day Up >

Just to recap, you now have a proposal that Requirement X will be implemented using Technologies A, B, and C. The obvious question is: "Can we build it in our environment in such a way that the requirement shall be met in an acceptable manner?" You are likely to hear "Of course," but unless you are also told, "We do this all the time," your retort should be, "Show me." That should probably be put more tactfully (i.e., "How do we validate the strategy?"). I have illustrated one approach with IP Telephone, which included a competitive analysis, a pilot, and a Plan B provision to fall back on proven private branch exchange (PBX) technology if our efforts to make IP Telephone work proved inadequate to match our success metrics.

Earlier in this chapter, I recounted the near-disastrous load-balancing escapade and acknowledged that some details had been omitted. I want to recycle the story, this time baring all, and what the approach should have been. This was a case begging for the validation of the proposed technical solution prior to the investment in time and money that was made. By the way, the application's high-profile user was exposed to significant risk because the output was subject to regulatory oversight with punitive sanctions for missed deadlines. First, let us look at the project's high-level tasks:

Build a dozen servers in the new data center to replace the nearly obsolete ones at the legacy site. Production data shall be ported from legacy servers to the new farm for testing and refreshed immediately prior to cutover, with no loss of data.
Migrate the multigigabyte database from a proprietary repository to the corporate standard for LAN-based database servers.
Re-architect the application to add "thin computing" as a front end, so this pseudo-client/server (C/S) application can be launched at the user desktop anywhere in the world using common browsers.
Replicate the load-balanced, Web browser architecture for global, casual users on new servers, too.

It is also important to look at this from a more anecdotal form, a process to be described in Chapter 4 as an implementation strategy. In this case, the story looks something like this:

The processing site will be moved to a new environment.
The application will be re-architected.
The database technology will be changed.
This would be done on new servers in a new environment.
At nearly the same time, the key users will be moving into a new building as well.
Their old personal computers would be replaced with faster ones using a more current operating system that also used a different strategy for launching applications.
Their network logins, which this application used for authentication, would be moved to a new domain with new user IDs and passwords.

In other words, you would be hard-pressed to introduce more risk than what was already on the table. We were brought into the server side of this project at the last hour. Had I arrived during the planning phase, I would have urged the team lead to come up with a plan like this.

Validate that the new user LAN/desktop environment performed acceptably with the legacy application infrastructure at the legacy site.
Move users to the new site and new LAN/desktop platform and reconnect them to the legacy application platform.
Build out and test the new architecture, in the new site, in a carefully phased test to ensure that each possible risk point was isolated to facilitate troubleshooting, repair, and performance evaluation.
Test the new architecture from the new site with the new LAN/desktop platform.
Validate data refresh and data recovery.
Execute production cutover with the back-out "Plan B" of reconnecting to legacy site/infrastructure.
Sunset equipment at the legacy site.

Quite naturally, you would look for a lot of more testing detail, end user roles and responsibilities, and so forth, but this would be the skeleton to which that muscle and flesh would be affixed.

< Day Day Up >