The next major phase of your SharePoint Server 2007 implementation is build readiness. This phase begins with preparing to implement SharePoint Server 2007 for production use. Because of space constraints in this book, you should reference the MSF documentation for a complete overview of the build readiness phase. Only critical points are referenced in the following section.
While it is possible to simply proceed with your prototype system, you should leave it in place when possible to support question-and-answer sessions with the stakeholders. By this point, your prototype should have been approved by the stakeholders via e-mail, or preferably a formal design review. This is the point in your project where you will need real funding and support to move forward. You will need to build out at least one SharePoint Server 2007 server farm and supporting infrastructure services such as SQL Server, Exchange Server, Active Directory, Windows Server systems, and the supporting hardware to proceed. If these do not already exist, you need to procure these dependencies along with the software licensing required for SharePoint Server 2007.
Design constraints may be based on your risks and issues, change in technology, or unforeseen usability limitations in SharePoint Server 2007 itself. Examples of SharePoint Server 2007 design constraints might be:
Incompatibility of customizations with legacy Office applications
Inability to upgrade clients from Office 2003 to Office 2007 for reasons not associated with your SharePoint Server 2007 deployment
Inability to upgrade your clients to the latest version of Internet Explorer due to legacy custom Web application requirements
Regulatory limitations on upgrading the Windows Server operating systems or Exchange Servers
Delayed training of administrators, developers, designers, and end-users
You should document your design constraints and communicate these constraints to the stakeholders. Be sure to clearly explain the impact these constraints have on the functionality and deployment schedule of SharePoint Server 2007. It is possible that some constraints can be resolved when the impact of not fixing the constraints is greater than the impact to your SharePoint Server 2007 implementation.
When your team and the stakeholders have agreed with the requirements, approved the prototype, and have funded your project, you are ready to proceed with building the production system. When building your system, be sure to refer to the many articles on TechNet and MSDN, along with the materials from your training sessions, to properly build-out for production use. This section is not a technical reference for building SharePoint Server 2007; that is covered in many other books and on http://www.microsoft.com/sharepoint. Instead, this section is a brief overview of the activities that should take place as you build for production.
You must first prepare the SharePoint Server 2007 dependencies such as SQL Server, Active Directory, and Windows Server. If you have defined your requirements at a granular level, this should simply be a process of following your design documents. If you have not granularly defined the requirements, you may have some trial and error while configuring these dependencies.
You should document absolutely everything you do when installing SharePoint Server 2007, but especially if you didn’t granularly define your technical requirements. If you have only a few servers and do not have a complex design, you can create a Microsoft Office Word document with the installation requirements and installation walk-through. When you begin installation, you are also beginning your disaster recovery plan. In a worst-case scenario, you must rely on your documentation to bring your system back to the state it was in previously. Without a carefully documented installation, this is almost impossible.
Once you have your SharePoint Server 2007 server farm ready for production, you should always complete comprehensive testing, no matter the size or complexity of your implementation. At a minimum, the following items should be tested before moving to the pilot phase of your deployment:
Functional Requirements. You should always test your production system for the functional requirements defined by your stakeholders. This should be fairly straight-forward. For example, if your stakeholders asked for mail-enabled lists and libraries, then you should test this functionality with all of the possible list and library settings for e-mails and attachments. Don’t forget to test fault tolerance of functional requirements, such as the example with incoming e-mail.
Performance. Performance can be a difficult metric to define and measure. Chapter 23, discusses many techniques for measuring performance, but perceived performance is what your SharePoint Server 2007 installation is measured by. This can vary greatly if you have customized code because the developer must understand how to build code that paints the screen, even if a background process must run. Ask a few of your stakeholders to test the functionality of the new system and gauge their perception of system performance. This is often more important than the actual system performance.
Capacity. You should start with 5 to 10 percent of your expected user population and incrementally increase the user base. Using performance counters defined in Chapter 23, continually measure the system’s capacity as you add users.
Integration Testing. If you added integration to third-party systems, test for the functional requirements defined by your stakeholders.
Custom Development Testing. Always completely test third-party code for any variance you can imagine. Custom code, especially poorly written Web parts, can crash an entire Web application. When deploying custom code, it is a best practice to mimic your entire user base accessing the custom code using Visual Studio Team System 2008.
As you deploy your project and continue to refine the system’s functionality and performance, you need to communicate with the stakeholders and verify that your refinements are not impacting the original functional requirements. An initial system deployment should always begin with a set of pilot users. These pilot users can help refine the system and identify where these refinements may impact functional requirements. An example of a SharePoint Server 2007 refinement might be integration with client authentication. Many times, client computers do not have your SharePoint Server 2007 Web applications included in the appropriate Internet Explorer security zone, like Trusted Sites, and therefore do not automatically authenticate. This is easily missed in an initial design but probably cannot wait until version n of your SharePoint Server 2007 implementation. But this could possibly impact other areas of your design that require clients to be in a different zone, perhaps Local Intranet. This is merely an example and your refinements could be much different.
We have talked about pilot users occasionally, but here we will more clearly define how to choose and classify pilot users. Many use personas to identify and validate a design during pilot testing. Personas correlate to a type of user in your environment, like an executive, Help Desk employee, average user, developer, or power user. If you are in a complex environment and your organization is very large, you should consider using several personas in your pilot. Try to identity the four or five largest groups of users by function, and map the most commonly used SharePoint Server 2007 features. Evenly spread 5 to 10 percent of your target production user base across these defined personas. As you progress with your operational pilot, survey these users against the persona requirements to see if your design works as expected. Remember, you will also be gathering requirements for the next version of your SharePoint Server 2007 deployment.
If you deployed more than a basic SharePoint Server 2007 installation, you will no doubt find bugs in the deployed software, dependent systems, or custom code. You need a method to document these bugs and get them fixed. Always verify that bug fixes do not affect the functionality and performance of your deployment. SharePoint Server 2007 lists and library functionality can be leveraged to collect bugs and bug fixes. Don’t forget to deploy your bug fixes to all affected areas of your design.