Microsoft Windows Server 2003 Unleashed (R2 Edition)
| With the completion of the discovery process and documentation of the results, it should now be very clear what you have to work with in terms of the foundation the new solution will be implemented upon. Essentially, the research is all done, and many decisions will now need to be made and documented. By now, a dozen documents could be written; however, the most important document that needs to be created is the design document. This document is a log of the salient 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 migration document, which provides the roadmap 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). 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 2003 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 2003 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 may 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. 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 environment, 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 technologies 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:
The Executive Summary
The executive summary should set the stage and prepare the audience for what the document 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. 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 level as well, and more details can be provided in the end state section of the design document. 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 may not yet be approved and may 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 2003 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 2003 will play (global controllers, domain controllers, DNS services) are spelled out here, along with the future roles of existing legacy servers. Information on the organizational unit (OU) structure, group structures, and replication sites should be included. Diagrams and tables can help explain the new concepts, and actually show what the solution will look like and 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. 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 document, 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 estimates. Typically, ranges for each phase should be provided. Windows Server 2003 Design Decisions
As the previous section mentioned, the key Windows Server 2003 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 2003 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, it is important to be specific when talking about data availability and discussing the situations 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 requirements, 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 may 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, 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 may require drastic changes to the design document because capabilities in the solution may 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 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. |
Категории