Windows Server 2008 R2 Unleashed (21 page)

points of the discussions that have taken place to date; it should make very clear why the

project is being invested in, describe what the scope of the project is, and provide details

of what the results will look like. A second document that needs to be created is the migra-

tion document, which provides the road map showing how this end state will be reached.

Often, companies strive for an all-in-one document, but as explained in the next section,

there are specific advantages to breaking up this information into two key components. A

simple analogy is that you want to agree on what the floor plan for a house will look like

(the design) and what the function of each room will be before deciding on how to build

it (the migration/implementation).

ptg

Collaboration Sessions: Making the Design Decisions

The design team is most likely not ready to make all the decisions yet, even though quite

a bit of homework has already been done. A more formal collaborative and educational

process should follow to ensure that the end state of the project is defined in detail and

that the design team members fully understand the new technologies to be introduced.

The collaborative process involves interactive brainstorming and knowledge-sharing

sessions, in which the stakeholders work with facilitators who have expertise with the

technologies in question.

Ideally, a consultant with hands-on experience designing and implementing Windows

Server 2008 R2 will provide leadership through this process. Well-thought-out agendas can

lead the design team through a logical process that educates them about the key decisions

to be made and helps with the decisions.

Whiteboards can be used to illustrate the new physical layout of the Windows Server 2008

R2 environment, as well as to explain how the data will be managed and protected on the

network. Notes should be taken on the decisions that are made in these sessions. If the

sessions are effectively planned and executed, a relatively small number of collaboration

sessions will provide the key decisions required for the implementation.

With effective leadership, these sessions can also help establish positive team dynamics

and excitement for the project itself. Employees might feel negative about a major

upgrade for a wide variety of reasons, but through contributing to the design, learning

about the technologies to be implemented, and better understanding their own roles in

the process, attitudes can change.

64

CHAPTER 2

Planning, Prototyping, Migrating, and Deploying Windows Server 2008

R2 Best Practices

Through these sessions, the details of the end state should become crystal clear. Specifics

can be discussed, such as how many servers are needed in which locations, which

specific functions they will perform (file and print or application servers, firewalls, and so

on), and which key software applications will be managed. Other design decisions and

logistical concerns will come up and should be discussed, such as whether to use existing

server and network infrastructure hardware or to buy new equipment. Decisions also

need to be made concerning secondary applications to support the upgraded environ-

ment, such as tape backup software, antivirus solutions, firewall protection, and network

management software.

Ideally, some of the details of the actual migration process will start to become clear. For

instance, the members of the testing and deployment teams, the training they will

require, and the level of involvement from outside resources can be discussed.

Organizing Information for a Structured Design Document

The complexity of the project will affect the size of the document and the effort required

to create it. As mentioned previously, this document summarizes the goals and objectives

that were gathered in the initial discovery phase and describes how the project’s result will

meet them. It should represent a detailed picture of the end state when the new technolo-

ptg

gies and devices have been implemented. The amount of detail can vary, but it should

include key design decisions made in the discovery process and collaboration sessions.

The following is a sample table of contents and brief description of the design document:

.
Executive Summary—
Provides a brief discussion of the scope of the Windows

Server 2008 R2 implementation (what are the pieces of the puzzle).

.
Goals and Objectives—
Includes the “50,000-foot view” business objectives, down

to the “1,000-foot view” staff level tasks that will be met by the project.

.
Background—
Provides a high-level summary of the current state of the network,

focusing on problem areas, as clarified in the discovery process, as well as summary

decisions made in the collaboration sessions.

.
Approach—
Outlines the high-level phases and tasks required to implement the

solution (the details of each task will be determined in the migration document).

.
End State—
Defines the details of the new technology configurations. For example,

this section describes the number, placement, and functions of Windows Server

2008 R2.

.
Budget Estimate—
Provides an estimate of basic costs involved in the project.

Whereas a detailed cost estimate requires the creation of the migration document,

experienced estimators can provide order of magnitude numbers at this point. Also,

it should be clear what software and hardware are needed, so budgetary numbers can

be provided.

The Design Phase: Documenting the Vision and the Plan

65

The Executive Summary

The executive summary should set the stage and prepare the audience for what the docu-

ment will contain, and it should be concise. It should outline, at the highest level, what

the scope of the work is. Ideally, the executive summary also positions the document in

the decision-making process and clarifies that approvals of the design are required to

move forward.

2

The Goals and Objectives

The goals and objectives section should cover the high-level goals of the project and

include the pertinent departmental goals. It’s easy to go too far in the goals and objectives

sections and get down to the “1,000-foot view” level, but this can end up becoming very

confusing, so this information might better be recorded in the migration document and

the detailed project plan for the project.

The Background

The background section should summarize the results of the discovery process and the

collaboration sessions, and can list specific design decisions that were made during the

collaboration sessions. Additionally, decisions made about what technologies or features

not to include can be summarized here. This information should stay at a relatively high

ptg

level as well, and more details can be provided in the end state section of the design docu-

ment. This information is extremely useful to have as a reference to come back to later in

the project when the infamous question “Who made that decision?” comes up.

The Approach

The approach section should document the implementation strategy agreed upon to this

point, and will also serve to record decisions made in the discovery and design process

about the timeline (end to end, and for each phase) and the team members participating

in the different phases. This section should avoid going into too much detail because in

many cases the end design might not yet be approved and might change after review. Also,

the migration document should provide the details of the process that will be followed.

The End State

In the end state section, the specifics of the Windows Server 2008 R2 implementation

should be spelled out in detail and the high-level decisions that were summarized in the

background section should be fleshed out here. Essentially, the software to be installed on

each server and the roles that Windows Server 2008 R2 will play (global catalog servers,

domain controllers, DNS services) are spelled out here, along with the future roles of exist-

ing legacy servers. Information on the organizational unit (OU) structure, group struc-

tures, and replication sites should be included. Diagrams and tables can help explain the

new concepts, and actually show what the solution will look like, where the key network

devices will be located, and how the overall topology of the network will change. Often,

besides a standard physical diagram of “what goes where,” a logical diagram illustrating

how devices communicate is needed.

66

CHAPTER 2

Planning, Prototyping, Migrating, and Deploying Windows Server 2008

R2 Best Practices

The Budget Estimate

The budget section will not be exact but should provide order of magnitude prices for the

different phases of the project. If an outside consulting firm is assisting with this docu-

ment, it can draw from experience with similar projects with like-sized companies.

Because no two projects are ever the same, there needs to be some flexibility in these esti-

mates. Typically, ranges for each phase should be provided.

Windows Server 2008 R2 Design Decisions

As the previous section mentioned, the key Windows Server 2008 R2 design decisions

should be recorded in the design document. This is perhaps the most important section of

the document because it will define how Windows Server 2008 R2 will be configured and

how it will interact with the network infrastructure.

Decisions should have been made about the hardware and software needed for the

migration. They should take into account whether the existing hardware will be used in

the migration, upgraded, left in place, or retired. This decision, in turn, will determine

how many server software licenses will be required, which will directly affect the costs of

the project.

The level of redundancy and security the solution will provide should be detailed. Again,

ptg

it is important to be specific when talking about data availability and discussing the situa-

tions that have been planned for in the design.

The server and other infrastructure hardware and software should be defined in this

section. If upgrades are needed for existing hardware (more processors, RAM, hard drives,

tape drives, and so on) or the existing software (upgrades from the existing NOS, server

applications, and vertical market applications), they should be detailed here.

Other key technologies such as messaging applications or industry-specific applications

will be included here, in as much detail as appropriate.

Agreeing on the Design

The final step in the design document process actually takes place after the document has

been created. When the document is considered complete, it should be presented to the

project stakeholders and reviewed to make sure that it does, in fact, meet their require-

ments, that they understand the contents, and to see whether any additional concerns

come up that weren’t addressed in the document.

Although it is unlikely that every goal of every stakeholder will be met (because some

might conflict), this process will clarify which goals are the most important and can be

met by the technologies to be implemented.

Specific decisions made in the design document that should be reviewed include any

disparities between the wish lists the stakeholders had and what the final results of the

project will be. Also, the timeline and high-level budget should be discussed and

confirmed. If the design document outlines a budget of $500K for hardware and software,

The Migration Planning Phase: Documenting the Process for Migration

67

but the stakeholders won’t be able to allocate more than $250K, the changes should be

made at this point, rather than after the migration document is created. A smaller budget

might require drastic changes to the design document because capabilities in the solution

might need to be removed, which will have ripple effects throughout the project.

If the time frame outlined in the design document needs to be modified to meet the

requirements of the stakeholders, this should be identified prior to expending the effort of

2

creating the detailed implementation plan as well.

Bear in mind as well that the design document can be used for different purposes. Some

companies want the design document to serve as an educational document to inform not

only what the end state will look like, but why it should be that way. Others simply need

to document the decisions made and come up with budgetary information.

Having this level of detail will also make it easier to get competitive bids on the costs to

implement. Many organizations make the mistake of seeking bids for solutions before they

even know what the solution will consist of.

The Migration Planning Phase: Documenting the

ptg

Process for Migration

Before the migration document is created, the end state of the project has been docu-

mented in detail and agreed upon by the key stakeholders in the organization. There

should not be any question as to exactly what the next evolution of the network will be