Once you have gathered your base requirements, communicated them among the stakeholders, and defined the process for your design, you enter the design phase. The design phase should be very flexible so you can adapt to additional requirements that you must include, as well as changing requirements based on the iterative learning process. As you begin your design and modeling, things don’t always work the way you thought. So be ready to change your design to meet these challenges. As you proceed with your design, remember that SharePoint Server 2007 isn’t a stand-alone system; rather it is part of a "system of systems" (SoS). As such, you should include the people responsible for those dependencies such as SQL Server administrators, network administrators, security teams, the Active Directory team, and the Help Desk. In many circumstances, these roles are shared throughout the Information Technology department and will make this process easier.
While creating functional requirements may sound very technical at first glance, real work cannot begin until you map those requirements to SharePoint Server 2007 design features. We also call the mapping of functional requirements to design features technical requirements. Technical requirements should map directly to SharePoint Server 2007 features, and the system dependencies such as Active Directory and SQL Server. For example, a functional requirement for SharePoint Server 2007 could be to automatically collect and archive e-mail for your current discussion lists. The technical requirement in SharePoint Server 2007 would be enabling incoming e-mail, and the supporting requirements such as Windows Server 2003 SMTP service and Active Directory.
Note
When creating your first design, include the functional requirement label, such as F3.1, on the SharePoint Server 2007 object itself. An example would be creating a portal named Portal_F3.1, if creating a portal was a functional requirement labeled F3.1 in your design document.
In order to understand what functional requirements you’ll have for your SharePoint deployment, you may need to ask some specific questions of the right people to fill out that information.
When communicating with the stakeholders, try to keep the communication streams high-level. The following functional design questions are examples to assist you in communicating with the stakeholders. From these functional design questions, you can extrapolate technical requirements. Here are some example questions you might ask the stakeholders:
Will you move file share content to SharePoint Server 2007?
What content is being migrated from file shares to SharePoint Server 2007?
Do you understand that large files should probably remain on file shares?
How will this content be organized?
Who is responsible for the data?
Will you create an enterprise portal?
What do you consider to be a portal?
Who will manage it?
What type of aggregation do you want?
What should be in the portal?
How will you implement a search solution?
What is your expectation?
Who is on the search team?
What do you want searched?
What are the desired search scopes?
Will you allow secure access to intranet content from the Internet?
Is SSL sufficient for external access?
Can we have two URLs for the same content?
How will you reduce content sprawl?
What are the current information management policies?
If there are no current policies, how will we determine the length of time to keep files?
How many versions should we keep?
Must you adhere to corporate Information Management Policies?
Must we abide by regulations (HIPPA, SOX)?
Do we need a records center?
What would a desirable outcome be?
Without defining a successful outcome, it is very difficult to measure the growth and success of your SharePoint Server 2007 installation. Some examples of metrics for success might include turning off legacy collaborative file shares, using SharePoint Server 2007 as your Web platform in addition to collaborative platform, turning off legacy Web servers, automating a business process, or integrating with a Line-of-Business (LOB) system.
Is the project being driven by Information Technology or the business principals?
You need to quickly know if the project is IT driven or business driven. An IT-driven project rarely gains as much traction as a business-driven project, and is usually less supported. If you are not implementing for business stakeholders, it is even more important to educate the executives and departments about the advantages of implementing SharePoint Server 2007.
Is your Information Technology management centralized or decentralized?
Early in your design, you should map out administrative delegation. If you have a centralized IT department, you can manage your SharePoint Server 2007 implementation with a single team. But if you are geographically dispersed or very large, you may have many SharePoint Server 2007 administrators. If this is the case, you should create a systems management plan so you have a consistent architecture in place.
Will you integrate SharePoint Server 2007 with third-party systems?
If you need to connect to LOB systems, it is best to do so after the initial version. But, you may need to integrate with these systems in the very beginning to meet fundamental project requirements or to gain stakeholder buy-in. Try to clearly define what systems you are connecting to, and what level of integration is expected. For example, simply crawling an LOB system is of no use unless the end-user can connect to the content source returned in a search result.
How important is SharePoint Server 2007 compared to other Information Technology projects?
Let’s be honest: If SharePoint Server 2007 isn’t high on the priority list in your organization, it will be difficult to get support from management. SharePoint Server 2007 isn’t the type of product that does well when low on the implementation priority list. Either try to move SharePoint Server 2007 towards the top of the list using methods within this book, or consider implementing only in small increments.
Who will be on your search team?
If search is important to your organization, and it usually is, you need to involve many people in your search design. Ask your stakeholders who is responsible for making decisions such as gaining access to content sources for search authentication, security audits of content sources before crawling, permission to crawl corporate Web servers and file servers, and how federated indexing will be performed in your environment. You also need end-user feedback to create search scopes and customize the end-user experience in the Search Center and site collections.
Will you brand/customize team sites?
You must also make the decision if you will brand team sites. It should be obvious that not branding SharePoint Server 2007 will make your life easier as an administrator. But if you must customize and brand, you need to plan for this and apply branding and customization best practices as outlined in Chapter 11.
What content will you crawl?
Early on, you must decide what content to initially crawl. Because a stable search service is very important, consider crawling only SharePoint Server 2007 content in the beginning. As your understanding of search and the impact on other services increases, add content sources gradually. This will help your users trust your search implementation and give you time to grow with the product.
Once you have defined the functional requirements, you must map them to technical requirements. Carefully plan what technical requirements you actually need, and don’t hurry your implementation without planning.
When installing SharePoint Server 2007, be aware that there are many interwoven dependencies. Many times, tweaking one portion of SharePoint Server 2007 can affect a seemingly unrelated function. An example is the content database change logs. A customer struggled to understand why search always full-crawled his SharePoint Server 2007 content, even though incremental crawls were scheduled. What was the reason? He had set the change log database settings to 3 Days in Central Administration Web application general settings. Because it was taking longer than three days to crawl their environment, and search uses the content database change logs for incremental crawling of SharePoint Products and Technologies content, an incremental crawl couldn’t be performed. This is an example of many of the intricacies covered through the book and how changing one part of SharePoint Server 2007 can affect one or many other parts. Because of these interdependencies within SharePoint Server 2007 and other systems integrated with SharePoint Server 2007, you must continually refine your design through an iterative process. Figure 3-7 shows a possible design process that will change with your design.
Microsoft provides planning, architecture, deployment, design, security, and operational guides at http://technet2.microsoft.com/Office/en-us/library/3e3b8737-c6a3-4e2c-a35f-f0095d952b781033.mspx. Real-world experience in conjunction with the thousands of pages in the preceding TechNet location were used to derive the following common technical questions that you can use to begin your design.
The following section is not meant to be all-inclusive. It simply provides an overview of design questions that are commonly asked and points you in the right direction for finding the answers specific for your environment. Because it is impossible to list every design variable for every SharePoint Server 2007 installation, we will explain how to answer the question. You will be provided with a foundation to research each of these design questions for your environment.
Should you migrate all content to SharePoint Server 2007? A common mistake is moving lots of file share content, from tens or hundreds of file shares and systems, to tens or hundreds of SharePoint Server 2007 sites, without a plan. If you move disorganized content to SharePoint Server 2007 without a plan, you will simply have disorganized content in SharePoint Server 2007! Part of your content migration plan should be an information architecture design. More importantly, you must educate your users on the correct way to store and retrieve content, or your well-laid plans can quickly erode.
How large can your content databases be? That is a very common question that is directly related to your service level agreements (SLAs). An SLA defines, among other things, the maximum time to return your application to service. If you do not have an SLA, you should ask the stakeholders how long your system can be down in the event of failure. You must take the maximum amount of time you can be down and calculate how long it will take you to restore a database in the event of a problem. For example, if your SLA defined four hours as the maximum down time, you would need content databases no larger than about 150-GB with the average tape system on the market today. You should test your backup and restore speeds to a SQL Server instance to benchmark performance for your system. Once you have calculated the maximum size your content databases can grow to, divide that size by the site quotas used in the Web application associated with those content databases. Table 3-1 shows an example of calculating content database sizes using two different site quotas and 2nd stage Recycle Bin settings. You must estimate your backup throughput, populate content databases with information, and test in your environment. Nobody can tell you exactly what your numbers should be.
Table 3-1. Content Database Size Planning
Site Quota
Number of Sites per Database
Total Database Size
Add % of Recycle Bin 2nd Stage
Actual Database Size
30 GB
4
120 GB
50%
180 GB
50 GB
4
200 GB
20%
240 GB
As you can see in Figure 3-8, the default settings of 9,000 sites before a warning and 15,000 sites maximum are unlikely to be accurate in your environment. If you thoughtfully set these, you will assuredly have multiple content databases per Web application. Details on content database size and planning are covered in Chapter 23.
How many Web applications do you need? This will be very different for every installation, but there are some general guidelines to follow. A good rule of thumb is that fewer are better. Keep it simple and create new Web applications only when necessary. Chapter 20, will help you understand when to create multiple Web applications. In the beginning, most organizations will have at least the following:
Portal A Web application is usually created for your intranet, regardless if it is actually called a portal. It is a centralized, governed Web application where content is aggregated. Unless you have specific requirements to do otherwise, this is also a good place for your collaborative site collections.
Shared Services Provider Administration Web Application While it is not required that you have another Shared Services Web application to host Shared Services Administration, it is useful for the purposes of backup and restore, inter-farm shared services, and application isolation.
My Sites Web Application It is also not required that you create a dedicated Web application to host My Sites. But doing so eases administration of My Sites in that you can leverage Web application permission levels, policies, and authentication for the hosting Web application. If you choose to host My Sites in another Web application, be sure to install the My Site Host template in the same Web application. This specialized site collection is used for default settings and for the crawler to index profile settings for people search functionality.
Central Administration The best practice is to always have Central Administration in its own Web application. This is the default setting. You should not use Central Administration to host any other services.
Unfortunately, additional Web applications are often created due to politics within an organization. While a managed path is usually sufficient to meet a requirement, customers and executives sometimes drive designs that are needlessly complex. For example, you might have a Human Resources executive who demands a Web application named http://HR, when a sub-site or embedded managed path site collection in the corporate portal named http://portal/HR would work just as well. Another Web application usually means more resources, additional content databases, and additional IIS Server configuration. But even after explaining the benefits of not creating another Web application, you may still be forced to create the http://HR Web application. That’s okay; just try to keep them to a minimum.
How do you enable intranet/extranet access to content? A major question from many is, "How can I securely access my content from either the intranet or Internet?" This is such an important topic that it is included in Chapter 20, but the general concepts are discussed here. You can extend an existing Web application, http://portal.contoso.msft, for example, to use another IIS Web application and additional URL portal-ext.contoso.msft. Using Web application policies and zones, you can restrict access based on the URL. There are other options as well, such as legacy virtual private network (VPN) access and, more recently, SSL VPN access.
Important
We often work with customers who want to leverage the native functionality of extended zones and Web application policies to extend collaborative information to the Internet. But when you get to the meat of the problem, many times this cannot be done securely. For example, if you were to serve up http://portal.contoso.msft externally as https://portal.contoso.msft you are only slightly minimizing the risk of being hacked. In fact, organizations that must comply with NIST guidelines or HIPAA regulations probably cannot implement zones and Web application policies to enable Internet access to their content. The most likely solution is either classic IPSEC virtual private network (VPN) connections or SSL VPN connections. Another option is creating a second farm in its entirety, including SQL Server. Why? Because if any Internet-facing Web application in the farm is compromised, the risk of compromising all other applications in the farm is very high. If a hacker has gained access to your SharePoint Server 2007 server farm, you must assume the SQL Server has also been compromised. Therefore, carefully plan your intranet/extranet access.
What level of content type planning must you do? Content types are a very important part of SharePoint Server 2007. In fact, every Web page, document, task item, and meeting request—virtually everything stored in the database—is a content type. You can use the default content types in the beginning and methodically expand your usage, but depending on your organization’s policies, judicial use of content types from the beginning may be needed. An example of this would be requiring metadata collection as part of a content type. You may need to know if an item is confidential, secure, belongs to a division, or has a project identification code. You can always go back and tag items later with metadata values, but defining them in the beginning can make your content management easier down the road. Experience has shown that you are better to use the defaults than to set them up incorrectly. Details of content types are in Chapter 8, and Chapter 9.
Do you need an information architecture plan? The short answer is YES. Without some planning of the Web application, managed paths, and site collection structure, you could easily end up with a mess that cannot easily be fixed. Information architecture is a lengthy topic, and is covered later in this book in Chapter 7. For the sake of designing in this chapter, you simply need to gather input from the stakeholders on how your Web application, managed path, and top-level site structure will be. Try to help your stakeholders understand the importance of getting it right from the very beginning. A mistake with your information architecture in the beginning can make corrections later very difficult.
Do you need records management? If your stakeholders require records management for legal or regulatory compliance, then you should consider implementing a records center. Otherwise, you should attempt to manage your document life cycle in-place. Most organizations will be fine using information management (IM) policies via content types and lists. IM policies include auditing, labeling, expiration, programmatic workflows, time-based approvals, and barcodes. Creating a records center usually complicates your administration more than it resolves issues. If you do require a records center for compliance, plan for the additional Web application and Shared Services Provider needed for proper isolation.
Do you need search? You needn’t have a robust search topology and plan before implementing SharePoint Server 2007. Search will benefit you greatly, but don’t let the fear of planning search stymie your plans for SharePoint Server 2007. In the beginning, just use the native search functionality, and expand as your knowledge and requirements increase. One word of caution—because your users have been trained by Internet search engines to find what they need via search, you do need a reliable search center in the very beginning. You want your users to trust SharePoint Server 2007 search early because otherwise it is very hard to gain back their trust.
Will you configure version pruning policies? You should decide what the official policy is on version pruning. If you leave it completely up to your users, they could turn on versioning with no limits. This action leaves you in the same state as SharePoint Portal Server 2003 and means there is no limit to the number of versions in document libraries. This is generally bad practice because it can dramatically increase your disk space usage. You should decide how many major versions to maintain, how many major versions you will keep minor versions for, and what the security will be on each. These decisions will vary greatly depending on your requirements, but at least one major version is recommended for content recovery due to user error and data corruption.
Will you allow users to modify sites with SharePoint Designer? With proper training, your users can modify sites with SharePoint Designer 2007 and produce very elegant, customized SharePoint Server 2007 sites. Without proper training, your users can break sites and pages, customize pages that should not be customized, and affect overall server performance. A best practice is to provide the SharePoint Designer tool only after users have received the proper training.
Will you leverage the publishing infrastructure? Chapter 13, details why and how to use publishing sites. But, you need to decide when to use publishing sites. Because of the increased overhead associated with the publishing infrastructure, you don’t want to turn it on unless there is a requirement to do so.
What content will you crawl? From a technical perspective, you should define what content sources you will crawl. You should always crawl your local SharePoint Server 2007 content including My Sites. But you may need to crawl additional sites from the very beginning, such as file shares and Web servers. Be sure to apply search best practices when doing so and plan for crawler authentication. Also, be careful when crawling file shares because you may expose information that was previously secured through obscurity.
How many Shared Services Providers will you have? You should plan for the number of Shared Services Providers you will have. Most installations should have only one. Leveraging Shared Services Providers is discussed in Chapter 16. You can safely assume the best practice is a single Shared Services Provider. If you are not sure or don’t know why to create more than one, don’t.
Who will create new site collections? SharePoint Server 2007 was really designed to allow users to manage their own destiny in regard to workspaces. Your goal should be to train users and allow them to create their own site collections. If you choose to do otherwise, you should seriously consider training a set of site collection administrators to perform the creation and management. Otherwise, the IT department usually does a poor job of managing site collections, including the creation thereof.
Note
Thousands of laws govern how highway systems are built, the chemistry of the concrete, how signage is used, how automobiles are built, how motors are maintained, how emissions are controlled, and when to stop for oncoming traffic. If you had to know and understand every single rule of highway systems before you could drive, nobody would! Instead, you only need to know the basic rules of the road, take a test, and you are issued a license to drive. SharePoint Server 2007 is much the same way. If you levy complex governance rules on your site collection administrators, they will feel overwhelmed and find another way to do their jobs. Instead, analogize site collection administrator training with a driver’s license. Train them on the basics of site collection management within your implementation and encourage them to adhere to your governance policy through education.
Will you enable incoming e-mail for lists? Enabling incoming e-mail for lists and libraries isn’t as simple as selecting the option in Central Administration and the target list. You must install an SMTP server, configure DNS, and allow the proper security in your network and e-mail server. You should work with the respective teams and explain the functionality and requirements of incoming e-mail.
Will you mail-enable SharePoint groups? Mail-enabling SharePoint Server 2007 groups has the same requirements as incoming e-mail for lists, but also provides a method for approval. Unfortunately, this approval can be done only in Central Administration, so you must plan for approval rights, if necessary. You don’t have to approve groups, but you lose control over the naming convention otherwise. Once again, training your end-users is very important.
Do you have workflows that should be created organization-wide? If you have workflows that are needed in all or many sites, consider creating the workflows in Visual Studio and deploying them as features. A best practice is to create workflows as needed, and only deploy globally after verifying their need and functionality in a prototyped site.
Who will manage your code access security? Code access security (CAS) is widely regarded as a developer responsibility and not an administrator responsibility. But the best practice has been proven to be the opposite. Developers often create code in a "full control" environment to ease application development. But writing code with no security boundaries can be a vulnerability when deployed. You need to decide who will manage code access security and how it will be audited.
What logging and auditing policies do you need? As outlined in the Microsoft SharePoint Products and Technologies Administrator’s Pocket Consultant (Microsoft Press, 2007), defining and setting logging and auditing policies is an important exercise when implementing SharePoint Server 2007. If you don’t set your policies, the defaults are rarely enough to help when a problem arises, yet impact server performance. Don’t simply set your logging levels to Verbose; you should make informed decisions about logging and auditing settings. Many SharePoint Server 2007 administrators set logging levels only to report errors, and increase the level of auditing when troubleshooting an error. This has proven to be a good starting point.
How will you monitor your solution? You should decide what to monitor, and to what level you will monitor services in your SharePoint Server 2007 server farm. Too much system monitoring, and you could miss important facts because of too much information. Too little monitoring or using wrong performance counters will have the same result. Chapter 23, will assist you with monitoring best practices.
How will you back up and restore your content? Disaster Recovery, to include backup and restore, should be paramount in your SharePoint Server 2007 design. Chapter 21, will assist you in disaster recovery best practices.
Should we migrate My Documents to My Sites? Many of you want to replace My Documents with SharePoint Server 2007 personal portals, also called My Sites. This isn’t altogether a bad idea, but you need to carefully plan what content will be migrated. Remember that SharePoint Server 2007 has limitations on file upload size and file types, and drastically changing these can have negative repercussions. But My Sites are often a good starting place for an enterprise SharePoint Server 2007 deployment because of the immediate value stakeholders can see in work efficiency and collaboration. Large organizations have seen the value in Exchange Server installations, and My Sites are a natural extension to that in the minds of many executives. If your users currently store music, video, ISO, and other large file types, you should consider some type of file storage other than My Sites.
What should my farm topology be? Many administrators are concerned with the farm topology in the very beginning of their design. The truth is, your farm topology is almost always the last design consideration. You should start with the end-user’s experience with the product (it is, after all, an end-user product) and design toward the farm topology. Figure 3-9 shows the logical architecture of SharePoint Server 2007 containment.
You should first decide your information architecture, Web application design, search requirements, security, governance stance, and user requirements. If you must buy hardware immediately, plan for a medium server farm topology. A medium farm topology consists of two Web front-end servers, one application server, and one SQL Server. Alternatively, you can continue developing on your prototype system and scale outwards as needed. Either way, your farm topology is changed with relative ease later.
Will you enable integration with third-party systems? If you need to integrate SharePoint Server 2007 with third-party systems, such as a Line-of-Business system, be sure to include the administrators from that system, and know what information your stakeholders expect you to surface from that system. You may need to connect to many third-party systems, but experience has shown that you should build out the native functionality first, then connect to these systems in a systematic fashion.
What are your security controls? Early in your design, you should decide what security authentication and authorization you will use. You essentially have two choices for authentication—Windows Authentication and Forms Based Authentication (FBA)—although other pluggable choices exist. Windows Authentication has the deepest functionality in SharePoint Server 2007, but support for FBA is rapidly gaining. If you can use Windows Authentication with SharePoint Server 2007, it is easier to install and easier to maintain. There are two types of Windows Authentication—NTLM and Kerberos. One isn’t necessarily better than the other from a design perspective, but Kerberos is generally a better choice from a performance point of view, while NTLM is easier to configure and install. There are instances, however, where FBA is preferable. An example is a partner extranet where you want to authenticate users against a Line-of-Business system. Carefully test your SharePoint Server 2007 functionality when using FBA.
As you progress through your SharePoint Server 2007 design, it is imperative that you include the system dependencies. System dependencies are any software and hardware services that are required for your SharePoint Server 2007 installation to run properly. You require a building to host your servers, utilities such as A/C to power them, battery backups, lights, monitors, network switches, hubs, cables, routers, firewalls, and software to manage these. The following list should be considered the minimum dependencies you should plan for. If you are not the administrator for the following dependencies, be sure to include the respective system administrator.
Active Directory. Not required for SharePoint Server 2007, but most installations will be built using Active Directory as the identity manager. The service accounts and Web application pool identities should be domain accounts, when possible, but should not be domain administrators or local administrators. You can enable the farm account as a local administrator during the installation process and the permissions will be set automatically. Then move the farm/installer account into the local users group afterwards.
SQL Server. A common bottleneck in SharePoint Server 2007 installations. Because your valuable user content is stored in SQL Server along with your farm configuration database, it is critical that your SQL Server configuration be capable of the load, and stable enough to meet your SLA requirements. You should research methods of fault tolerance for your SQL Server instances including clustering, mirroring, log shipping, and third-party solutions. SQL Server transaction log shipping and database mirroring for SharePoint Server 2007 is covered in Chapter 21.
Storage. For the most part managed by your SQL Server instance. But don’t forget to plan for file system storage of items such as event logging, trace logging, indexes, temporary storage for content deployment jobs, and usage analysis processing files. Remember to include planning for your Shared Services Provider database, search database, content databases, and configuration databases. If leveraging SQL Reporting Services, you may also need to plan for related databases.
Network. Configuration would include switches, routers, firewalls, hardware load balancers, storage area network (SAN), and proxy servers. It is critically important that you include each of these administrators if you do not manage these systems. You should ask questions like: What is my required network speed? What firewall rules do I need? Do I need hardware or software load balancing for my WFE Servers? Do I need source-based routing? How will I manage remote access? Do we need to use inbound and outbound proxy servers? What capacity and speed do I need in my SAN solution? Will SharePoint Server 2007 change the capacity requirements for these hardware and software dependencies? Are all tiers of dependencies sufficiently engineered to support fault tolerance to meet SharePoint Server 2007 SLAs? For example, if you require four-hour return to service for SharePoint Server 2007, then all supporting tiers must support a four-hour return to service or less. Remember, SQL Server must be restored before you can begin your SharePoint Server 2007 database restoration.
You should plan for performance and capacity from the very beginning. Usually, the medium server farm requirement for fault tolerance is sufficient for several thousand users. Performance and capacity come into play with extreme customizations or very large implementations. As was discussed in process models, you should plan for an iterative deployment when servicing large user populations. Another advantage to an iterative design and implementation process is the ability to monitor your server farm for performance as you add users and custom code.
As you progress with your design, you need to plan for contingency factors. Contingency factors are anything that may affect your implementation for the worse, but are not certain to occur. You must balance the risks with the costs of mitigation. Since we live in the real world, your design may not always progress or function like you planned. There could be technical limitations, political obstructions, and many unforeseen risks and issues encountered along your design path. You should understand the differences between risks and issues, and design accordingly.
Risks are a part of life, and your SharePoint Server 2007 implementation is no different. Risks aren’t necessarily a problem, as long as you notice them and plan for them. Risks usually have a negative outcome if allowed to fruition, but sometimes have a positive outcome. Some examples of SharePoint Server 2007 design risks might be Active Directory migrations, SQL Server versions and upgrades, hardware instability, lack of training by technical staff, lack of executive support, and no IT governance plan. All known risks should be documented and a mitigation plan presented at your design reviews. Even if you know it will not be mitigated, at least you have performed due diligence by documenting the risk and bringing it to the team’s attention. Risks should be stated in simple terms such as If X happens, then issue Z will exist.
For example, a non-clustered SQL Server instance would provide a risk as follows: If the SQL instance hosting SharePoint Server 2007 fails, user content and search will be unavailable until the content is restored. All user content could be lost since the last backup occurred. Mitigation for this risk might be: By using SQL Mirroring and SQL Clustering, we can decrease the downtime and user content loss in the event of a SQL Server outage.
When the risk becomes fact, then it is an issue. It is quite possible that a design dependency, such as your network, may already be an issue. An issue should not be overlooked because they often happen again. Yes, a current issue might become a future risk. If you have an issue, you should thoroughly document the issue and redesign or involve someone to fix the problem. Examples of issues are slow throughput on WAN links, service provider instability, contractor non-performance, slow storage speeds, and lack of load balancing capability. Issues should be documented in simple terms like: X happened and can be prevented by Y. For example, an issue might be documented as follows: A network outage occurred because of insufficient network bandwidth. You should plan for increasing the bandwidth, or you risk the reoccurrence of the issue.
Once you have designed your prototype environment and installed according to your technical requirements, you should test it against the functional requirements. In other words, will it do what your stakeholders want it to do? Look at the functional requirements you started with in the beginning and see if all are met in your design. Conversely, look at implemented technical features that don’t align with functional requirements, and consider removing them. Extraneous functionality often causes unneeded problems in the future. Don’t forget to ask the stakeholder’s opinion, and realize you may need to tweak requirements and re-prototype before moving to the build readiness phase. Problems are much easier to fix now, rather than after you have implemented in full-scale.
Last, but definitely not least, is the approval process. Depending on the complexity of your design, the approval could range from an e-mail containing some design PowerPoint and Visio diagrams, to a multiple-day design review with the stakeholders. The best practice is to get written approval from the stakeholders. While this isn’t always possible, you should have correspondence from the stakeholders approving your design before moving into the build readiness phase. Be clear about the design in your reviews, and point out any risks or issues more than once.
On the Companion Media
On the companion CD, you will find examples of design review PowerPoint and Visio files (Design and Planning.ppt, Acme Phase 1.vsd, Acme Phase 2.vsd, and Acme Phase 3.vsd). If you do not currently have a design process in place, you can use these as starting points for your design reviews.