Imagine you are a movie director who is responsible for a major motion picture. You are responsible for everything that must happen, such as set construction, location for film shooting, actors, and scripts. Your job is to produce a quality movie by managing all of the details and ensuring that everyone works together in a common purpose to produce a great movie.
When designing for Microsoft Office SharePoint Server 2007, you are the director! Much like an Office SharePoint Server 2007 installation, many of these activities are happening simultaneously and you must plan for tasks to complete on time and in sync. Your set construction is analogous to your farm and Web applications, actors are your end-users, and the scripts are the policies and training.
SharePoint Server 2007 does require some planning and design, but it doesn’t always need to be rigidly designed and implemented. If you are interested only in getting it installed, you should still review the basics of design processes and the commonly asked SharePoint Server 2007 design questions sections. If your goal is a well-running SharePoint Server 2007 implementation that will grow with your organization and adapt to future challenges, then you should consider using a framework for your design. This chapter isn’t about any one industry framework, but rather an overview of the SharePoint Server 2007 design points and associated processes. You can take this information and incorporate the details into your organization’s design process. If you do not have a framework in place, this chapter will serve to provide a SharePoint Server 2007 design life cycle for your organization. Additionally, it is important to understand this entire chapter is a single best practice and doesn’t necessarily contain granular best practices. This chapter will cover the following topics:
Foundations for a SharePoint Server 2007 design life cycle
Process models
Defining stakeholders
Providing training
Gathering requirements
Designing
Building
Operating
However you choose to proceed with your SharePoint Server 2007 implementation, consistency is crucial. It is usually possible to fix a consistently incorrect installation, but very difficult to fix an inconsistently installed SharePoint Server 2007 server farm. You should consider using a framework to ensure consistency, even if it is very simple.
Design life cycles have been around for quite some time and are based in many verticals such as retail manufacturing, computer software, systems engineering, and academia. Design life cycles are becoming more commonplace in the IT industry and will continue to do so because they lower the overall cost of a service while simultaneously improving its delivery. The following section provides a brief overview of the frameworks and processes that serve as the foundation for this chapter.
The Information Technology Infrastructure Library (ITIL) is a library of over 30 books that provide a foundation for designing, implementing, and management of IT services. The following ITIL books are the most commonly used depending on the size of your implementation.
Service Support. Provides the basics for the daily processes required to maintain IT services.
Service Desk. Can be roughly correlated to the Help Desk function in many organizations, but encompasses much more than answering a phone call.
Incident Management. Outlines the fundamentals of service restoration in the event of a service outage.
Problem Management. Will assist you in detailing a plan to minimize the disruption to valuable IT Services.
Configuration Management. Is a mechanism in which you identify, manage, and maintain versions of configuration items.
Change Management. Helps you to methodically manage configuration changes in your environment.
Release Management. Provides the foundation for releasing new software, whether done manually or automatically, ensuring appropriate control and communication.
Service Delivery. Is widely used in large organizations to manage processes such as Service Level Agreements (SLAs), Service Level Requirements (SLRs), availability management, capacity management, financial management, and service continuity.
More Info
For more information on ITIL, see Chapter 7, or browse to http://itil-officialsite.com.
This section is a brief overview of the Microsoft Solutions Framework as it applies to SharePoint Server 2007. There are entire books on the topic, so the inclusion of more than a brief overview as it applies to SharePoint Server 2007 design isn’t possible. The Microsoft Solutions Framework (MSF) originated to address Microsoft’s need for software design life cycle management. The MSF process model is the basis for developing solutions, while the Microsoft Operations Framework is the framework for managing the solution. Figure 3-1 shows the MSF process model.
As seen in Figure 3-1, the MSF life cycle consists of five phases:
The Envisioning Phase identifies the stakeholders in the project, such as the financier, users, departments, and Information Technology. It is the time where the stakeholders and IT agree on the functional requirements for the project. Be sure to stay with functional requirements such as the need to automate document workflows, and away from technical requirements like implementing SharePoint Server 2007 in conjunction with Microsoft BizTalk Server to enable workflows. The MSF process model addresses technical requirements in a later phase.
The Planning Phase is where you decide what the best technical solutions are to meet the functional requirements. You should do some high-level testing and present your findings to the stakeholders in a project planning review.
The Developing Phase is when you prototype and test the solution, including testing the system dependencies. Example dependencies for SharePoint Server 2007 are SQL Server 2005, Active Directory, firewalls, routers, storage, and Windows Server operating systems. Present the solution in a stakeholder and peer review, and attempt to freeze the project and not allow any new requirements.
The Stabilizing Phase would begin with pilot testing of the solution. A general rule is testing the solution with 5 to 10 percent of your user population. Rarely does everything work as planned, so this phase gives you the opportunity to fix those issues and stabilize the implementation for mass deployment.
The Deploying Phase is where the solution is deployed to the users. Verify that you have provided the proper training to your users, administrators, developers, and Help Desk staff before deployment. You should identify and tweak any required training during the stabilizing phase.
The Microsoft Operations Framework (MOF) compliments the MSF process by providing "operational guidance that enables organizations to achieve mission-critical system reliability, availability, supportability, and manageability of Microsoft products and technologies," as stated in MOF documentation. The Microsoft Operations Framework is divided into four unique quadrants, as shown in Figure 3-2.
While MOF has been developed for Microsoft technologies, much of the framework aligns with ITIL. The four quadrants of MOF are as follows:
The Operating quadrant is more Microsoft-specific and addresses directory services administration, job scheduling, network administration, security administration, service monitoring, storage management, and systems administration.
The Supporting quadrant aligns with ITIL and includes incident management, problem management, and the Service Desk.
The Optimizing quadrant describes eight key service management functions—availability, capacity, financial, infrastructure, service continuity, security, service levels, and workforce management.
The Changing quadrant addresses three key areas as described by ITIL: Change Management, Configuration Management, and Release Management.
More Info
For more information on the Microsoft Solutions Framework, browse to http://www.microsoft.com/msf. For more information on the Microsoft Operations Framework, browse to http://www.microsoft.com/mof.
Before you begin your design, consider your IT governance plan, if it exists. While an IT governance plan obviously isn’t required to implement SharePoint Server 2007, you do need to consider how much freedom you will give your users within the product.
More Info
See Chapter 5, for more Information Technology governance information.
Many times the IT department will exert too much control over the functionality of an application, thus limiting the true capability. SharePoint Server 2007 is definitely one of the products designed for end-users, and built for the end-users to manage their own workspaces. SharePoint Server 2007 was designed to delegate much of the administration to power users and end-users. The more restriction placed on these users, the less functional the product will become. In essence, control and usability are inversely proportional with SharePoint Server 2007.
Note
If you require a rigid structure in place, then you will need to perform a significantly more detailed design. Your requirements planning process must identify most, if not all, possible uses of SharePoint Server 2007. A real-world example of this detailed planning is content type planning. If you will allow your users to leverage only pre-determined content types, then you must completely plan your content types before production deployment. A complete content type planning process is impossible for the majority of organizations because you cannot predict how SharePoint Server 2007 will be used in the future. If you educate and train your users on the proper way to create and use content types, they can create their own content types according to your Information Technology governance plan.
Another common design mistake is attempting to control the site structure within site collections. This is an almost impossible task for all but the smallest SharePoint Server 2007 installations. If you try to control the site structure, you will require a much larger Information Technology staff. A better way is to educate your users and allow them to decide on the best structure for their processes. When using the latter method for site management, you will not need to know all of the processes within your organization because the users can implement the structure themselves. If you exert too much control over the application, users will just find ways around your controls inside or outside SharePoint. Experience has shown that hardworking employees will get their jobs done, whether you provide the technology or not. This non-compliance with your policies results in multiple systems. Because multiple systems providing the same service is difficult and expensive to manage, your goal should be providing a solution employees will use, thus allowing you to effectively control content and automate policies and processes.
While many process models exist for designing solutions, the two basic process models in the Information Technology field are the waterfall process model and spiral process model. It is not important to completely understand the details of each, but you should at least be familiar with them as concepts. You will most likely use a combination of both to effectively design and implement SharePoint Server 2007 in your environment.
The waterfall process model waits for one activity to complete before the next consecutive activity can begin. For example, your requirements analysis must be completed before you start a design. According to the MSF 3.1 overview:
This model uses milestones as transition and assessment points. In the waterfall model, each set of tasks must be completed before the next phase can begin. The waterfall works best for projects where it is feasible to clearly delineate a fixed set of unchanging project requirements at the start. Fixed transition points between phases facilitate schedule tracking and assignment of responsibilities and accountability.
In other words, it works in organizations that have a rigid design process in place and have time to wait for the solution. Many readers of this book will not have those processes in place, and many others needed SharePoint Server 2007 installed yesterday. But one of the primary benefits of a waterfall process model is that there are milestones—both intermediate and major. First, the intermediate milestones help to segment efforts in large SharePoint Server 2007 implementations. Second, major milestones signal time for peer and stakeholder reviews, and for comparing progress against the overall project timeline. Figure 3-3 gives an overview of the waterfall process model.
Figure 3-3. The waterfall process model requires each task to be completed before the next can begin.
In the MSF 3.1 overview, the spiral process model is described as follows:
This model focuses on the continual need to refine the requirements and estimates for a project. The spiral model can be very effective when used for rapid application development on a very small project. This approach stimulates great synergy between the development team and the customer because the customer provides feedback and approval for all stages of the project. However, since the model does not incorporate clear checkpoints, the development process may become chaotic.
Spiral process models are very effective for rapid deployment because you essentially build it quickly, then continually improve and add to your solution, in addition to requirements redefinition. The spiral process model is also useful for small- to medium-sized projects that do not require the great deal of overheard that the waterfall process model dictates. The downside to a spiral process model is the lack of milestones and the difficulty in providing a clear vision of success. An example of a spiral process model is shown in Figure 3-4.
So which process model do you use? An approach taken by many large organizations, including the development of SharePoint Server 2007 itself, is to combine the two process models and take the best traits from each. Deploy the most critical parts immediately, and add secondary and tertiary requirements in a versioned fashion. Figure 3-5 shows how these two models can be combined for a positive outcome.
More Info
If you would like more information regarding process models in solution development, try reading MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures, Exam 70-300 (Microsoft Press, 2003) (http://www.microsoft.com/mspress/books/index/6460.aspx).
A good starting place is a milestone-based approach, borrowed from the waterfall process model, which will allow you to define the points in your implementation where peer and stakeholder reviews should occur. At a minimum, the following reviews should take place:
Requirements review
Design review
Build readiness review
Operational readiness review
While these reviews may be quite complex, they don’t have to be. A small or simple SharePoint Server 2007 implementation might require only a few Office PowerPoint slides and Office Visio diagrams. Your reviews are meant to "get everyone on the same page," so to speak. You should have the stakeholders, Help Desk, Information Technology staff, and any individuals who would like to see your project fail. Why would you want your opposition at the design reviews? It is much like in martial arts, where you use your opponents’ strengths against them. They may not realize that you have a phased implementation and may point out every mistake and weakness in your design and the product itself. Great! They will eventually help you to create a solid solution because they have pointed out the design flaws. It is also important to educate the stakeholders about the design process model you will use.
Major milestones are often used as synchronization points in a project. If you are using Project Server 2007, it is quite easy to publish Office Project 2007 schedules so they are viewable via a Web browser. These major milestones are where your multiple solutions teams synchronize on your project. As an example, your developers might be creating custom Web parts and site definitions. At the same time, your search team has been building test server farms to validate requirements. Your system administrators may also have been building intranet and extranet solutions to test a different set of requirements. The major milestone reviews are a great place to bring all of these teams together and see where there are common solutions, or conflicts in the different teams’ designs.
Minor milestones may prompt for reviews within a team, but rarely will the entire project team meet for a review. Minor milestones in a SharePoint Server 2007 deployment might include the completion of a custom Web part, successful validation of a search topology, or the creation of a server farm. Minor milestones can also be used within teams when a large task is split up into smaller tasks, documenting and tracking the segmentation of efforts.