Understanding the Design Life Cycle

Some administrators and architects might use their own organization's specific life-cycle guidelines. If you are one of them, you will still find useful information in this section. If you have not been exposed to design life cycles, you should consider using them in your SharePoint Server 2007 implementation. Most major published design life cycles are similar, but they do not always mesh well with deploying collaboration solutions. This section gives you an example of a design life cycle you can use when deploying SharePoint Server 2007 solutions. Figure 3-1 is an overview of the design life cycle.

Figure 3-1: SharePoint Server 2007 design life cycle

Defining the Stakeholders

The term stakeholder in the information technology (IT) realm has come to mean those who have the final decision, fund projects, or are in a position to benefit from implementing a new system. One of the most difficult tasks as an IT professional is convincing management to spend time and money to effectively architect solutions. Many solutions are hastily designed and then later fail because a solid, scalable foundation wasn't laid. A well-designed SharePoint Server 2007 solution takes investment of both time and money from the stakeholders.

Ask yourself how your implementation will help your stakeholders, and then educate them on the increased profit and productivity they will receive. Stakeholder involvement will be essential in building a solid SharePoint Server 2007 platform that can grow with your business. Take the time to think through your design, and don't rush to install or upgrade. Time spent asking questions, testing applications, and using test groups will save you substantial administration effort down the road. Always get written approval from senior management before embarking on a new project.

Creating a Problem Statement

You cannot perfectly execute an SharePoint Server 2007 implementation without a clear definition and understanding of the business reasons for implementing SharePoint Server 2007 in the first place. Work closely with the stakeholders to define a problem statement and objectives to solving that problem. The following are examples of business, functional, and security problems.

• Business problems Helpdesk trouble ticketing and disposition, workflow issues, inventory control, document management, records management, portability and accessibility of data, duplication of effort, content management

• Functional problems Overworked IT staff, dispersed geographical management of servers and data, organizational boundaries, multiple subsidiaries, multiple contractors

• Security problems Legal issues, regional laws and regulations, federal mandates and regulatory guidelines, protection of intellectual property, integrity of data, disaster recovery, continuity of operations

Security Alert 

It is important to consider security in each phase of your design. Study how your objectives, requirements, and implementation plan affect the safekeeping of your data. This effort will save you significant time and energy in the future. Include your IT Security staff in all phases of your design.

After consulting with your stakeholders and other interested parties, you develop the problem statement, which will look similar to the following statement:

• Data is scattered throughout the enterprise on personal computers, e-mail folders, Web servers, thumb drives, compact discs, content management solutions, databases, and file servers. It is very difficult and time consuming to locate previously authored documents, and employees waste time and money finding the correct resources. Frequently, the IT department must get involved to locate, copy, or authorize access to data. There have been issues with hardware failures preventing access to data. Management would also like data owners to authorize user access to content, ensuring that users access content on a need-to-know basis.

Defining Objectives

Objectives should show value specific to solving your business, functional, and security problems, but they should not include details for development and implementation. From your problem statement, you clearly define the objectives:

• Objective 1 Consolidate as much information as possible to a central location and lower the total cost of ownership.

• Objective 2 Install an indexing capability for searching all content that is centrally and remotely located.

• Objective 3 Create a way to share ideas and information within a team while allowing and promoting interaction between teams. This information should be indexed, searched, and consumed by an audience defined by the data owner.

• Objective 4 Implement a highly available solution.

This section outlines a few of the design considerations you need to take into account early in the design life cycle so that you can accurately define your objectives and requirements.

Establishing an Administrative Model

As you work through your design, keep in mind how you will administer all the different pieces. Many organizations are geographically dispersed or departmentally separated, and a well-thought-out administrative model is important to success. If you are planning a multifarm SharePoint Server 2007 topology, it can be difficult maintaining a secure and consistent implementation.

Enterprise Administrators

Multifarm installations should have an enterprise administrator with administrative access and control over all farms. An enterprise administrator is responsible for the overall architecture including security, deployment, and customization of all SharePoint installations. In this model, day-to-day administration is carried out by administrators dedicated to their individual SharePoint Server 2007 server farm.

If your organization has a centralized IT department, you might need to plan for remote server administration. For example, you may need to open certain firewall ports in order to be able to access Central Administration from anywhere on your network.

If you have distributed IT support for your infrastructure, you might want to create groups by division or geographic location, following your Active Directory organizational unit (OU) design, to manage your SharePoint Server 2007 server farms.

Identifying Hardware and Software Costs

When designing your SharePoint Server 2007 installation or upgrade, create a detailed spreadsheet defining what your costs will be. Here are a few items to get you started:

• Legacy hardware Will your current hardware support the additional load placed on it during and after the upgrade? SharePoint Server 2007 will inevitably increase the hardware usage of existing servers.

• New hardware Plan for sharply increased usage of the system once users see the advantages of SharePoint Server 2007. Enterprise implementations of My Sites have a rapid adoption rate, and large enterprise-class solutions will do well to have dedicated hardware.

  More Info 

  For more information on hardware requirements, visit http://www.microsoft.com/sharepoint/default.mspx.

• Software Contact your Microsoft sales representative for licensing costs for SharePoint Server 2007, Windows Server 2003 R2, Windows Server Code Name "Longhorn," and Microsoft SQL Server 2000 or 2005. Remember that each person accessing your SharePoint Server 2007 servers must have a client access license (CAL).

Defining Service Level Agreements

In the modern IT world, you have no doubt been exposed to service-level agreements (SLAs). SLAs are agreements between two or more parties that describe the deliverables, support, and communication that will be provided by each party to the agreement. You might be asked to define the SLA for your SharePoint Server 2007 implementation. Draft these documents carefully, and request the appropriate funding for your scenario. If you do not directly manage all components of your installation, consider having SLAs with owners of your particular installation components-SQL Server, server hardware, switches, routers, firewalls, and so on.

Planning 

If you are asked to provide high availability, many variables must be considered. These variables will be covered later in this chapter and in Chapter 30, "Microsoft Office SharePoint Server 2007 Disaster Recovery."

Defining Requirements

Objectives are commonly formed by IT staff in conjunction with the stakeholders, while requirements are usually formed with little assistance from the stakeholders. Requirements derived from your example objectives might look like this:

• Requirement 1 Implement a small, three-server SharePoint Server 2007 server farm to consolidate corporate data, and allow remote access using Secure Sockets Layer (SSL) to discourage the use of thumb drives and local personal computer storage.

• Requirement 2 Customize the search and indexing functions in SharePoint Server 2007 to search current data in Microsoft Exchange servers, file servers, Web servers, third-party content management systems, and previous versions of Microsoft SharePoint Server.

• Requirement 3 Implement self-service site creation and administration to reduce the overhead of the IT department. This will allow faster service for customers, as well as lower the total cost of ownership of the service.

• Requirement 4 Implement a multiserver, load-balanced solution that will ensure availability of data in the event of hardware failure.

Although your problem statement, objectives, and requirements will vary greatly, always research and test before implementation. Be sure to take into consideration multiple time zones, languages, customs, and legal and security issues before you begin.

Obtaining Approvals and Implementing the Solution

After you have defined a solid set of requirements, you need to present these requirements to the stakeholders, and your peers, in a design review. Design reviews offer an excellent opportunity for all involved parties to recommend changes and approve of your design. Provide an implementation plan at your design review, and begin scheduling any technical resources you will need.