2

Planning for SharePoint

WHAT’S IN THIS CHAPTER?

• Introducing topics that should be considered before and during a SharePoint implementation
• Discussion of some implications of decisions made during the planning phase
• Suggested strategies and methods to prepare for deployment and mitigate challenges

Effectively planning for a SharePoint platform in an organization is critical to the platform’s success in the long term. Similar to the importance of requirement-gathering and design before custom development, SharePoint deployment requires forethought and diligence before rolling out an implementation. And as with development efforts, you can either put the effort in beforehand, or you’ll be forced to do more work catching up later.

Many organizations have experienced SharePoint’s tendency to grow “organically” in an environment when given the chance. Because SharePoint works well with existing client tools and because it enables people to work better together, once users start experiencing the benefits they usually want to use the tool for all kinds of purposes.

The term “governance” has been used and abused over the past few years as an all-encompassing term for planning and operations preparation for SharePoint. Unfortunately, it’s been overused to the point where the word itself has lost value. But whatever name you put on it, planning is required for successful implementation.

Also bear in mind that not all organizations will need answers for every planning topic, but at a minimum the list of topics should be reviewed to find what does need to be addressed in your scenario. This chapter tries to address enough of the preparation topics needed to plan for a SharePoint platform but does not cover everything — that would require a far larger volume. The chapter also does not cover planning topics for specific solutions built on top of SharePoint.

BUSINESS PLANNING

Identifying a business stakeholder or sponsor of a SharePoint project is essential to provide the necessary clarity, direction, funding, and sometimes clout for the project. Without a sponsor high enough in the organization, projects may stall while waiting for the necessary buy-in from different departments, staffing for the platform and supporting technologies, funding for hardware or software, and training for staff and users. Projects driven solely by an IT leader or specific business unit may have challenges in bringing these resources together, and the projects may end in frustration because they overlap with functionality already provided by other systems, they encounter different corporate strategies already in place, or their strategies just aren’t defined enough.

In smaller organizations, defining SharePoint’s role in an organization may be a simple process involving a single IT resource or even a managing service provider. In that case the scenario might be as straightforward as a sponsor’s deciding to use SharePoint and giving the “make it happen” order.

The beneficiaries of the technology solutions also need to be informed and educated. The more users understand both the organization’s intentions as well as how the platform will meet their needs, the happier they will be to assist in the process. The more users understand the capabilities, the more they will be able not only to meet their original requirements, but also to find new ways of using the tool to benefit the organization.

Regardless of the size of the organization, having a vision for the capabilities that SharePoint brings is essential to its success. Sometimes this vision is what drives a SharePoint project. Other times generic organizational needs fit with the technology solution SharePoint brings. In many cases an envisioning session for key business decision-makers that covers both general technology solutions and the specific capabilities of SharePoint goes a long way toward getting a business sponsor interested, or even excited, about the prospects. Many of the items discussed in Chapter 1 could provide content for the vision conversation. Additional decision points for vision and strategy areas that may be covered in an envisioning session are discussed in the next few sections.

Finally, because SharePoint Server 2010 integrates with so many technologies, business stakeholders need to understand at least at a product-to-product level what integration points exist between systems, so that they can effectively make strategy-level decisions. Managers of these areas also need to be involved in the planning. Topics for these areas are discussed later in this chapter.

Web Strategy

At one time web strategy was as simple as deciding what platform would be used for intranet, extranet, and Internet-facing solutions. Now the market has evolved and matured to the point where many products offer web-enabled functionality and access. The SharePoint platform itself offers functionality that extends into numerous other areas where strategy needs to be defined, further complicating matters. Defining a plan with or without SharePoint now requires a bit more diligence to make sure all bases are covered.

SharePoint is a web application. Therefore any organization considering deploying SharePoint needs to define what SharePoint will and will not be used for, and how it will integrate with other web-based solutions. In many cases, the functionality that SharePoint brings crosses paths with other solutions that are already in place. Sometimes SharePoint is brought in explicitly to replace old or more expensive platforms. In cases where solutions don’t have a web component, SharePoint can be used to provide access to content and functionality not otherwise available to users. In other circumstances SharePoint needs to be evaluated alongside other technologies to determine the best technology fit.

As was pointed out in Chapter 1, SharePoint has the capability to be the core solution for many use-cases including the intranet, extranet, and Internet solutions. In fact, one of the benefits of SharePoint is that it can be used for all three scenarios, as well as others. Having a consolidated platform allows for some efficiencies when it comes to skill sets to manage more than one farm, provide custom development across the platform, and even license the environments.

Although functionality is generally the primary decision point (defining whether or not a list of requirements is met), each organization will have its own specific decision points when figuring out where SharePoint fits in the organization. Other frequently used decision points might include:

• Whether or not skilled staff is available for both administration and customization tasks. More details are covered later in this chapter.
• Licensing costs of existing or potential solutions.
• Supportability of platforms. It’s not uncommon to have a solution in place so long that it is no longer supported.

Part of the web strategy now includes where solutions are deployed: whether they are deployed on premise or hosted off-site; whether they are installed on physical hardware or virtualized environments; and whether in-house staff or managed services are managing the infrastructure. These aren’t necessarily SharePoint-specific questions, but they certainly play a part in defining the solution and the requirements needed to support it.

A growing number of hosted SharePoint providers are available with varying levels of support and functionality. Some providers are hosting simple site collections on shared environments; others are building dedicated SharePoint environments that clients still manage, relying only on the hardware and OS to be hosted. Finding an appropriate solution depends on the needs of your organization, but there are obvious benefits in not needing SharePoint IT professional (IT pro) resources in-house and being able to offload some of the infrastructure management.

Cloud-computing solutions using shared infrastructure resources are another option, with Microsoft offering its SharePoint Online solution as part of Office 365. At the time of writing, the 2010 version of SharePoint Online and Office 365 was not yet available but was expected to be closer to on-premises functionality than the 2007 product, though still with a few significant exceptions. These include external data integration and no ability to host publicly accessible sites. Only Internet-facing environments will be able to be hosted. As with the more generic hosted solutions, customers are off-loading the infrastructure management and relying on a remotely managed service.

Other Strategies

Although web strategy is the underlying topic and delivery mechanism, other organizational strategies probably need to be reviewed when determining which pieces of functionality will be delivered via SharePoint.

Collaboration

Collaboration is a sweet spot for SharePoint and can be one of the easier decisions when deciding whether or not SharePoint is the platform of choice. In many cases no other products or solutions are in place, or solutions that are in place are not enterprise-ready, or a smattering of solutions are being used by different teams and departments with no unified strategy.

SharePoint for collaboration can also be an easy sell because so many organizations use Microsoft products for their office productivity tools (MS Word, Excel, Access, and others) and the tight integration between the client and server products provides a good user experience.

When no clear collaboration strategies are identified, users are left using file shares and e-mail. Using file shares has been the default method for organizations for years, but has a number of limitations. File shares don’t allow for check-in/check-out control and are apt to allow one user to overwrite another’s work. No versions are tracked and access must be controlled by IT.

E-mail is certainly part of the collaboration experience, but can be abused when a real collaboration tool isn’t available. Rather than using e-mail only as a communication tool, users lean on MS Outlook or Exchange to store documents and versions. This can lead to higher traffic and storage levels and may also conflict with enterprise retention practices that regularly delete old e-mail.

Document Management

Document and records management strategies are common for organizations of all sizes. Where no specific system is already in place, SharePoint is a capable solution for many organizations; however, its out-of-the-box capabilities may fall short for organizations that have more demanding requirements. If another product is already being used, management may choose to reevaluate the existing document management systems side-by-side with SharePoint. Because of the typically high licensing and support costs for dedicated document management systems, some organizations lean toward SharePoint because of the cost savings alone. When SharePoint features are compared with these products, SharePoint often comes out ahead because of its wider set of functionality and better user interface. Where it is determined that two systems are to coexist, many mainstream document management tools have Web Parts available to work with SharePoint. Users can work in the SharePoint web interface while seamlessly accessing and managing documents in the other systems.

Finally, SharePoint’s ability to extend its capabilities with customizations is also an option because specific features may be requested and can be created for less cost than buying a separate dedicated document system.

Business Process/Workflow

Organizations interested in business process management or workflows should consider SharePoint for its out-of-the-box capabilities, its ability to extend those capabilities, and its ability to integrate with a number of robust third-party workflow platforms. You can find more on this capability in Chapter 15.

Business Intelligence

Business Intelligence (BI) is an area where SharePoint brings a wide range of solutions, from simple lists, views, and graphing to more robust dashboards and KPI (Key Performance Indicator) controls. It’s also able to interact with a diverse set of data from data stored inside SharePoint, to Excel content, to external data, and all the way to fully generated existing cubes.

In organizations where no BI solution is in place, SharePoint brings new capabilities. Where BI solutions do exist, SharePoint is often used as an additional way to surface data stored in BI-specific systems. This can be a cost-efficient way to expose additional users to data typically reserved for a small set of users, a limitation often imposed by the licensing costs for the BI platforms.

Search

Search strategies for organizations today still tend to be hit or miss. Some organizations have specific search tools in place for specific data like company directories, but not as a holistic company approach for all content. Other companies have wider-range search solutions or hardware but still may or may not reach all the content and users they’d like to reach or return the kinds of results users need. Because SharePoint’s search capabilities are so robust, they can be used as little or as much as an organization determines the need to be. SharePoint commonly is introduced as a portal or collaboration tool that initially enables search for its own environment but then quickly adds scopes and Search Result pages for more and more content as users get accustomed to its powerful search engine. As with other functional overlaps, administrators will need to determine if SharePoint’s search functionality infringes on any existing search solutions, and if so how they will interact. The Federated Search capabilities described in Chapter 1 allow for an effective coexistence between new and existing third-party search solutions.

SharePoint Road Map

SharePoint 2010 is a platform with lots of capabilities and many moving parts. The key to success with SharePoint is to think big and act small. In other words, put some thought into where SharePoint fits in a larger, organizational strategy and then implement that strategy in smaller, more manageable projects. Coordinating those smaller projects into a longer-term plan is your SharePoint road map. It’s not rocket science, nor is the approach unique to SharePoint, but it is still a valid concept that needs to be applied to SharePoint projects and deployment.

Ideally, defining a road map requires stepping back from a technology solution and focusing on business needs. You need to understand what the organization is doing, how work is being done, and who is doing the work. You should also understand what’s working and what the pain points are. You must identify end-user priorities and understand any business improvement initiatives that might be under way. You should ask your end users for this input rather than getting only management’s perspective. The two views are often very different and getting both perspectives is important.

Once gathered, use all this information, along with how these needs align with the SharePoint platform, to determine what to implement and when — where along the road map different features or solutions will be tackled. Aligning the technology solution to the business need will require someone with a solid understanding of the platform capabilities so that the appropriate solutions can be identified and an effort made to deploy those solutions. Working with the IT organization is also critical in aligning their skills and efforts with business needs.

Controlling the scope of a SharePoint project can be so challenging that it becomes a risk to both individual projects and the platform itself. Trying to do too much too quickly has been the downfall of many IT projects, SharePoint included. Fortunately, it’s also true in that many projects have been successful when kept in small enough pieces to control the execution as well as its place in the larger road map.

Typical starting points for SharePoint in an organization are as an intranet or portal solution or as a collaboration tool. Deeper data integration or more robust workflow and business process automation are usually introduced a little later in the process so users can get used to the platform before investing in these more costly solutions.

When some of the more robust features are the reason for deploying SharePoint, they can certainly still be deployed, but in a balanced manner. For example, rather than deploying a whole suite of workflows, a few smaller processes should be identified and deployed first as a proof of concept (POC) before tackling larger or more detailed processes. In this way, users can become accustomed to how the system works and what its capabilities are. Administrators can make sure the environment can handle the workload and any data needs. Developers can ease their way into what is likely a new genre of development. Once these POC examples are successful, the momentum can be carried to the more challenging solutions.

Budgeting

Initial considerations for budgeting of SharePoint usually lean toward SharePoint-specific hardware and licensing costs. Though these are obvious and traditional, broader subjects should also be considered. Each organization is different, so remember to review the particular scenario for your organization so as to not underestimate what’s required. Business stakeholders should work with the IT organization and development staff when appropriate. Some general examples that are detailed later in this chapter include:

• Test/stage/development environments: In addition to the production environment, other SharePoint environments may be necessary to conform to development standards or other standards in the environment.
• Additional staffing: New staff may need to be added to manage the SharePoint environment.
• Multiple locations: If an organization has more than one location, additional architecture, hardware, or software may be necessary to fulfill business needs.
• Disk space: If SharePoint is being used for a storage-intensive solution like document management, records management, or other storage-heavy solutions, be sure that adequate disk space and room for growth are considered.
• Third-party tools: Licensing costs for additional software.
• Contractor costs: If everything can’t be done in-house, be sure to plan for service or consulting costs to round out your internal resources.
• Training, communication, and internal marketing: Just deploying SharePoint isn’t the end of the project. Rolling out a solution to users and empowering them to be successful with the new tool are critical to the success of the project.

When aligning with functionality and specific solutions, the budgeting approach for SharePoint is going to go along with the road map that decision-makers establish. For example, some features, like People Search, are relatively easy to deploy and deploy early for little additional cost. More robust features like advanced process automation or Business Intelligence solutions will likely involve more time and cost and often will be scheduled further down the road.

Staffing

Staffing a SharePoint platform or project requires a range of roles and expertise over the course of the project and product lifecycle. Organizations may choose to use internal resources when available or external resources and services when needed. Depending on the size of the organization, one or more dedicated SharePoint resources may be required to manage SharePoint-specific functionality and support. In diversified IT organizations additional resources from supporting technology teams, such as the database, server, network, and Active Directory teams, may be needed. These teams will need to commit some part of their resources to supporting SharePoint-related activities.

Of the supporting services and technologies, the database team will likely demand the most commitment due to SharePoint’s dependence on SQL as its back end. The server team will need familiarity with the Windows Server 2008 platform, IIS, and any other supporting software used in the environment, such as server management solutions and virus-checking software. This team should also be aware that server OS patches may have unintended consequences for the SharePoint platform.

SharePoint-specific roles don’t necessarily need to be full-time responsibilities of internal or external resources, but they will certainly be the main focus of their attention. The roles of various players in the process are shown in Table 2-1.

Table 2-1: SharePoint Project and Platform Roles

ROLE	DESCRIPTION
Architect	A seasoned veteran of SharePoint implementations big and small with both development and IT professional skills and experience. The architect will oversee the big picture of how SharePoint is used in the business, and how it fits into the larger IT services environment. Architects don’t necessarily need to be the best at everything, but do need to know enough about most topics to understand why one decision is better than another.
Developer	SharePoint developers are specialized .NET application developers. They understand ASP.NET applications, solutions and features, Web Parts, and the underlying SharePoint object model. They understand when to use SharePoint Designer vs. Visual Studio for building solutions.
IT pro	IT pros are the server administrators for SharePoint and understand how to install and configure SharePoint on top of a core Windows Server 2008 and IIS server. They understand how to best design server architectures based on the use-case and business needs.
Creative designer	Creative and design staffers understand both core HTML and web-design concepts and technologies, and know how to apply these branding concepts in the SharePoint platform. Frequently these individuals work with marketing and communications teams or outside design firms to both design a suitable brand as well as apply it effectively to the SharePoint platform.
Project manager	A SharePoint-specific project manager may seem somewhat odd to many people, but there is a lot of benefit to having someone who understands the deployment and customization process and can coordinate initial deployments as well as ongoing customization work.
Analyst	Business analysts with SharePoint experience are essential for understanding the business and its needs and identifying solutions that are appropriate for the SharePoint platform. It is important for the analyst to have a solid understanding of SharePoint’s feature set and the pros and cons of different approaches in order to translate business needs into the correct technical solution.

Other roles at an organization may have SharePoint-specific requirements, but only as part-time focuses. These should not be overlooked, however, because the success of the platform depends heavily on the services that holders of these provide (Table 2-2).

Table 2-2: Others with SharePoint Responsibilities

ROLE	DESCRIPTION
Server team	The server team is responsible for the health and stability of the Windows Server 2008 servers on which SharePoint and SQL are installed. The team members understand IIS (web server) configuration as well as how other server tools like server backups and virus-checking solutions will impact SharePoint.
Database team	The database administrators (DBAs) are responsible for the health, stability, and performance of the database servers and databases. DBAs may also work closely with a SAN (storage area network) team to manage data capacity, duplication, backup, and restoration of data.
Network team	The network team coordinates where SharePoint servers are deployed within the network, and/or how they are connected to the outside word and users while maintaining high performance and security.
Security and Active Directory team	The domain and information security teams work with the SharePoint team to create and manage service accounts as well as define the approach used for security groups.
Trainers	If a training department is available, members will need to add SharePoint content to their curricula and skill sets.

IT PROFESSIONAL PLANNING

Just as a business sponsor is important to delivering the business requirements for SharePoint, a platform sponsor is necessary to consolidate the various technical requirements needed to deploy and maintain SharePoint. This often requires bringing together resources from various teams to ensure the SharePoint platform is built and managed to organizational standards and defined service levels.

Many organizations make the mistake of considering SharePoint as just another application installed on a server rather than as the platform it really is. IT organizations need to understand where SharePoint fits as a part of the larger strategies in an organization to effectively plan for its use. The platform owner coordinates and communicates these strategies and resources.

Server Standards and Builds

SharePoint is a web application that requires Microsoft Windows Server 2008. So before any of the SharePoint-specific tasks are even started there needs to be a server that will host it. Many organizations will have an image or standard for an application server build that should be considered first to see if it will meet all the requirements of SharePoint. The more these standards can be kept in place, the easier it is for the organization to manage the infrastructure across the board. Typically the changes that need to be made can be applied after the core image is installed.

Many organizations may not have 64-bit Windows Server 2008 as a standard yet, which may create additional work to come up to speed before installation of SharePoint. This particular challenge will likely wane as more organizations naturally mature and adopt the server standards required for SharePoint.

Other standard considerations for servers also need attention. Although Microsoft has made general minimum recommendations for RAM and drive sizes, organizations need to ensure that their standards mesh with Microsoft’s recommendations while keeping in mind any additional drive space required for other standard organizational software such as virus-checkers or management agents.

Backup solutions for the underlying infrastructure as well as the SharePoint software itself need to be considered as part of the disaster recovery, business continuity, and backup and restore plans. In many cases organizations are already using a vendor to meet some or all of the required backup options for application servers and database servers. If the vendor also has SharePoint-specific capabilities, it may be a very easy transition to add the remaining modules or agents to attain the coverage desired.

Finally, once the core OS has been built to organizational norms and standards and properly patched up, SharePoint service accounts need to be added to the system. Where other applications may request one or two accounts, SharePoint tends to be on the other end of the spectrum. The final number is defined by which services will be activated, but will typically be more than four or five.

Architecture Considerations

Planning for SharePoint begins with understanding both the initial intended use as well as what it might be used for in the foreseeable future. With this information in hand, architectures can be designed to meet immediate needs while also being as flexible as possible to keep future re-architecting to a minimum. Luckily, SharePoint 2010 is the most flexible version ever of such software, due primarily to its service-based architecture.

So what is SharePoint being used for? Is it going to be an internal-facing solution like a portal or collaboration environment? Is it going to be external-facing as a publicly accessible Internet site or a restricted client and partner extranet? Do both scenarios need to be supported? What requirements are there for uptime and availability? Does the database need to be clustered or mirrored? Locally or remotely?

Deploying SharePoint as an internal solution generally allows it to fit into an existing networking model, so few network changes are needed to accommodate its servers. SharePoint servers will need to be a part of a domain, have a number of domain service accounts, and be able to talk to the domain server and SQL Server.

Deploying SharePoint as an external solution is a bit more complex. Internet-facing solutions require different licensing than internal-facing solutions. Architecture is dependent on how robust an external-facing environment the organization has and what policies and procedures are already in place. Does the organization have a perimeter network? What belongs in the perimeter network and what doesn’t? What standards are there for configuration across the firewall, and so on? A variety of architectures are available, but SharePoint servers still need to talk to a domain and SQL.

External environments may also involve additional authentication methods that allow non-employees to access the environment without needing to be added to an Active Directory domain (which would require additional licensing costs). Forms-Based Authentication (FBA) is a common replacement when using a model other than the AD model. FBA may use a SQL database that stores credentials; it may leverage Windows Live accounts or may even use AD as a data store. SharePoint 2010 allows for multiple authentication models while still using the same URL — an improvement over previous versions.

Along similar lines as the FBA vs. AD discussion, administrators need to identify whether the system needs to be able to handle Claims or Kerberos authentication. These may be necessary when SharePoint is connected with external systems and they require individualization rather than a single generic connection.

If SharePoint is being used as a search solution for content outside SharePoint, are service accounts created for SharePoint to access the external data? Do any network changes need to be made to allow the SharePoint system to access the other data?

Capacity planning and the use of SAN and hierarchical storage management (HSM) storage should also be considered from a number of angles. In many organizations SAN space needs to be requested with a longer lead time than other resources and should be considered as part of deployment planning and scheduling. The intended use of the platform may influence the capacity plan; if specific document or records management solutions are being planned, they will require more drive space. It ultimately requires more disk space to store a file in SharePoint than on the file server due to the way it is stored, usually in a SQL table itself.

Assuming that a cloud or hosted environment is not being used, it should also be decided whether virtualized or physical servers will be used. SharePoint supports virtualization, so the decision is typically left to the organizational strategy recommendations. In many cases the SQL server is the last server to be virtualized, though performance of the latest generation of software and hardware seem to make a virtualized SQL environment acceptable. It all comes down to whether or not performance standards can be met.

Regardless of the use-case, there will be a test or stage environment that as accurately as possible reflects the production environment. Administrators may want to test anything that can affect the platform’s functionality and stability — anything from DNS settings, load balancers, and IIS settings to software patches, security settings, and custom solutions. The stage environment may be on the same domain or a different one, depending on the types of changes that need to be tested or how strict corporate policies are for isolating production data.

PowerShell

PowerShell is a scripting language built on and tightly integrated with the .NET platform. Microsoft has positioned PowerShell as the primary method for managing SharePoint, as it has for other platforms such as SQL Server and Exchange, by producing a large number of cmdlets (or command-lets) for administrators to use. The basics of PowerShell are a must-have skill set for SharePoint administrators and developers, starting with the 2010 platform.

You can find a detailed list of SharePoint cmdlets by using the following command in the SharePoint 2010 Management Shell:

PowerShell can be used for any number of activities, which can include, but are certainly not limited to:

• Installing and configuring a SharePoint farm: Scripting a production installation allows for a predictable and reproducible environment that can be useful for building consistent environment between stage and production, or be used as part of a disaster recovery process to rebuild servers. It can also be used to rebuild development environments quickly when you need to produce clean environments for testing.
• Installing and deploying solutions and features: Any custom solution should be deployed using a script for consistency and predictability.
• Deploying updates
• Changing service accounts and/or passwords
• Moving, importing, or exporting data

DEVELOPER PLANNING

One of the great features of SharePoint 2010 is its capability to be customized and extended. Although the broad feature set allows for a great deal of functionality out of the box, most every organization eventually wants to extend the platform to meet a requirement that just doesn’t quite work the way the organization would like it to. This section covers some of the topics that should be considered before introducing customizations into the environment.

First of all, there are a lot of ways to customize SharePoint. As best they can, organizations need to provide guidance to their users and development staffs regarding what can and should be customized and how customizations are designed, developed, and deployed in the environment. The “what can and can’t” part is used to set expectations with users so they understand why some things can’t be done.

As discussed in a bit more detail later in this chapter, training for developers is very important. Developers may choose to utilize classroom courses or self-study resources. Many will rely on books (like this one), blogs, and other online resources.

Platform owners from both the business and technical sides need to determine whether they will build internal SharePoint resources or hire partners to do some of the work for them. Bringing in external help also usually means opportunities for the in-house folks to ramp up and use mentoring and knowledge transfer to bring your folks up to speed faster than they could manage by themselves. Whether or not there is local talent available to hire should also be a consideration.

Development Standards

It’s important for developers to define and follow consistent methods of development on the SharePoint platform, just as it is on other platforms. Ideally, project templates and code samples will be created that can be reused as much as possible. Similarly, the packaging of solutions and features should be consistent so that all developers can support each others’ work. Finally, every organization should have a method of source control, in which any SharePoint customizations should also be managed.

Development should be done on an environment other than the production farm. Ideally, there should be separate development machines or environments for each developer. If more than one developer is working on the same effort, they’ll need an environment where they can combine their efforts before promoting it further. There should be an environment where code can be deployed as a test run to production — some call it “test,” while others refer to it as “stage.” Finally, the same process used to deploy the customization to the test environment should then be used to deploy to production. Some organizations like to have a waiting period between when code is deployed to test and when it is rolled out to production, to further safeguard the production environment.

Specific standards get to be a bit trickier to nail down because so many kinds of customizations can be done. For example, aside from being deployed both by a solution and feature, a branding customization is going be very different from a BDC connection to a database customization. Additional examples are highlighted throughout the rest of this chapter.

Tools

The primary tools developers use with SharePoint are SharePoint Designer (SPD), Visual Studio 2010, and possibly a text editor. Each tool has its niche in the development process, with the line between SPD and Visual Studio moving back and forth depending on whom you are talking to. Some developers have found a good balance between the tools, whereas others have biases one way or the other, usually based on their individual skill set and comfort levels with each of the tools. Outside the standard tools, a range of utility applications is available as well, and some developers use these to enhance their workspace.

Other tools fall into something of a gray area for developers — areas where code can certainly be used, but doesn’t need to be. Applications like InfoPath fall into this category where simple digital forms can be created by end users dragging and dropping controls, but more complicated functionality requires development behind the scenes that quickly turns into efforts too complex to justify when better technologies or approaches are also available.

Finally, the reference material and sample code available online is extensive. Even Microsoft has already (early in the SharePoint product cycle) produced more content in MSDN and TechNet than it has in past versions of the product.

INSTALLATION, CONFIGURATION, AND MIGRATION

Many organizations have existing pre-2010 SharePoint installations they want to migrate to the 2010 platform. A number of upgrade paths are available, each with its own pros and cons. This book won’t go into detail on the migration steps, but does review some of the topics that organizations should consider before proceeding with a migration effort.

Migration Options

Two primary methods exist for migrating from SharePoint 2007 to SharePoint 2010: in-place and database-attach migrations. These are the approaches recognized and documented by Microsoft. Other variations and more manual and granular data migrations are possible, but are used in so few cases and in such specialized scenarios that they are not considered relevant methods.

The first step in preparing for an upgrade is choosing the appropriate migration approach. In some cases either approach may work just fine, in others there may be factors that eliminate one method or the other. If considering an in-place upgrade, is the hardware up to the requirements for 2010? In many scenarios this is not the case, which makes the decision easier for some.

Taxonomy, architecture, and farm use-cases are also things that need to be considered when migrating. If a single environment is being migrated to a new single environment, there aren’t too many factors to worry about, but it might be a good opportunity to consider a re-organization of data at the same time.

Where the process gets a little more complicated is when the migration is also part of a consolidation of multiple environments — even more so if they have divergent purposes or core architectures, as an intranet and extranet may have. Even consolidating multiple intranet environments can be dicey because sites and site collections must be determined to have unique URLs, duplicate content may be purged, and site collections may need to conform to a new or altered information architecture and site map.

Finally, it should also be noted that no options exist for direct migration from versions of SharePoint previous to 2007. Data must be migrated from 2003 to 2007, then on to 2010 using the content database-attach method.

Planning and Design

Once an approach has been determined, all the users and providers will need to prepare for the migration. Much like an initial configuration, the communication, support, and training plans discussed later in this chapter are critical to the success of the migration. For existing users, the importance is even higher because these users and the organization have a vested interest in their data coming across successfully.

Everyone will have responsibilities in a migration. Users, power users, and site administrators need to identify and catalog the content and functionality that they have in a current site so that it can all be validated after migration. Farm administrators obviously have very specific tasks ahead of them in determining the method and steps for the whole process. The farm admin or IT pro are generally the ones coordinating the details of the whole migration, sometimes alongside a project manager for larger efforts. Developers need to be informed of any existing customizations in the current environment so they can be reviewed for whether or not they’ll work and can be successfully deployed in the new environment.

OPERATIONS AND ADMINISTRATION

The ongoing operation of the SharePoint platform is just as important as all the effort that is put into preparation for deployment. After deployment, it’s all about execution. If plans have been made, but not followed through with, users will lose confidence in the platform and any solutions built on it. So it’s important not only to plan, but to execute the communication, training support, and maintenance plans while continuing to keep users informed regarding the status of the platform.

Most concepts described here aren’t necessarily specific to SharePoint, but can be applied to a number of platforms and solutions.

Communication Planning

Regardless of what your SharePoint environment has been built for, it has users and it will require maintenance. To meet or exceed user expectations, there should be a communication plan in place to both communicate effectively to users as well as collect feedback from them. At its core, the communication needs to identify:

• Who needs to be communicated to
• What needs to be communicated
• When the communications need to go out
• Who will generate the communication

Ideally, the initial parts of the communication plan will be implemented before deployment of the platform or new solutions to let the user community know what solutions are in development. If the core platform is already in place, there may be an ongoing list of planned improvements and projects. Strategically, this allows users to plan for the new solutions while also preventing any duplication of effort to solve the same issues.

If the SharePoint solution is being brought in as a replacement to an existing system, or if it will in any way be a significant change in how users do business, the communication plan may also take on some aspects of a marketing campaign designed to win over the users to the new way of doing business.

One of the easier perspectives of a communication plan is that in most organizations the methods and media for communication with the users are already established. Tapping these existing methods is both efficient and comfortable for the users. There may be a portal in place where announcements are distributed. There may be RSS feeds that users follow to stay informed, and there likely are e-mail distribution channels that users are accustomed to using. If these aren’t already in place, the deployment of SharePoint may introduce some of them with its implementation.

Plenty of options are available for how to communicate with users. Whoever is creating the communications plan should understand that a variety of methods should be used to meet the needs of a larger percentage of the users. It should also be recognized that regardless of how well communication is done, it will not meet every user’s needs.

Examples of what and when to communicate:

• When the project is first starting, communicate what the goals of the project are and who is on the team.
• As soon as milestone dates have been established these should be displayed somewhere.
• As deployments are getting close, users and implementers should be informed of their roles and expected outcomes.

Training Planning

Education and empowering of the user base is critical to the success of SharePoint projects as it is with any tool or system that users are expected to use and rely on. It’s important to meet the needs of the different user roles and to accommodate the different ways users learn. It’s also important to continue training beyond the initial phase that leads up to deployment because new employees will continue to come on board, and people who went through training will need refresher information from time to time. Table 2-3 describes who should be trained and the curriculum for each.

Table 2-3: Roles Targeted in Training

GROUP	CURRICULUM
Business users and management	These people need to understand the capabilities and business value as delivered by using an overview and examples, preferably specific to the organization. Generally these are delivered by an external resource, unless the organization is large and has developed internal resources with the breadth of experience needed.
Developers	Development training generally takes .NET developers and introduces them to the SharePoint object model, types of customization projects, and best practices regarding tools and processes like deployment. Usually delivered via classroom or knowledge transfer sessions.
IT pros/farm administrators	Information needed to build and manage a SharePoint environment. Usually delivered via classroom training and if possible bolstered with mentoring.
Site administrators	Site administrators have mastered end-user training and have a deep understanding of the SharePoint site-security model, so that they can properly manage security of the site.
Power users	Power users have mastered end-user training and extend their capabilities by understanding more about SharePoint features, Web Parts, and creating and customizing lists. They may also be introduced to SharePoint Designer.
End users	There are usually too many end users to send everyone to external classroom training within a budget. Organizations generally rely on internal training and “train the trainer” approaches to get this basic day-to-day operational content to everyone.

Staffers responsible for User Interface (UI) and creative design don’t typically attend classes or formal SharePoint branding training because the majority of their workloads deal with non-SharePoint specific tasks. They can apply much of their knowledge and experience to the SharePoint platform because of the way content management has been implemented in SharePoint. Many of the same CSS and layout concepts are the same. There is value, however, in acquiring knowledge on methods and best practices for how to apply designs to the SharePoint platform as there are some challenges. Finally, in many cases the design team is needed only early in the process or for a specific migration rather than for ongoing branding work. This one-time use doesn’t generally justify the cost of training for the creative staff members.

Training Content

Training for SharePoint development usually assumes that developers are at least experienced with .NET. Training curriculums are pretty consistent at covering the different types of customization projects that are available to SharePoint developers and telling when to choose one method over another. They also cover toolsets and best practices.

IT pro training is similar to developer training in that it is usually a very consistent curriculum, walking through the installation and configuration and then onto all the details in the Configuration Manager. PowerShell will likely be covered during the session as well.

Most, if not all, of the training content discussed up until this point has been for out-of-the-box functionality. In many SharePoint implementations, organizations create custom solutions. Users need to be trained on these as well, and due to the nature of the content the training generally needs to be driven from in-house resources because it is so specific and sometimes confidential.

Training Approach

Several training methods were suggested earlier, starting with traditional classroom instruction and mentoring. Any number of methods can and should be used as long as the user needs are being met effectively. One key challenge that you should mitigate is that different people learn differently; you have to offer up a variety of tools and methods to assist your clients, partners, and co-workers.

The first thing to consider in training is the timing. Training needs to happen before many of the people will need it because administrators/IT pros need to design and build a platform. Developers likely need to build a few customizations even for initial launch iteration, so their training should start early. User training can also begin before a launch, but it would be hampered somewhat by not having an environment to see and touch.

The typical tripping point for an organization is that training and resources should continue to be available after the launch of the platform. Not only will new employees come on board and need to be trained, but existing users will get smarter and more experienced and want new materials to allow them to use the SharePoint platform fully.

A variety of options are available for delivering the training materials. Some companies may choose to use training partners who come with their own classroom, trainers, and curriculums. Other organizations may send a select group of people to training and then use those people to train the next batch of users, repeating the process internally until all users have been trained. A few of the trainers then offer the course work from time to time to new employees.

Training Resources

A full range of materials should also be made available to users to support the coursework, what was learned, and what users will continue to learn as they use the tool. Some examples:

• Center of excellence sites: Not just for the SharePoint platform but also for other platforms in the environment, center of excellence sites can be used as one-stop shopping for users to find information about a particular tool. Administrators and management can use the site as a communication center for the tools. Tools, resources, and other information can also be made available — anything that can make the user experience better.
• Brown bag sessions and internal user groups: These are good ways to meet periodically with users and share new or interesting information with them about or for the platform, such as new third-party tools that have been installed and solutions that have been built by other teams.
• Handouts and desk drops: A number of products are available such as SharePoint quick guides or cheat sheets. These make great desk drops for everyone, giving them core information they might need about getting started with SharePoint.
• Online resources: The center of excellence site should include a list of links to online resources within and beyond the organization. New articles, videos, and how-to resources are being added every day.
• Productivity hub: Microsoft has a free site collection that can be used to store educational materials, track who is using them, and provide a platform for adding additional material as needed. It doesn’t have to be a SharePoint-only set of data. It’s more about being a framework to build on.

Finally, as specific solutions are built on the SharePoint platform, be sure to set aside time to train the users and administrators of these new systems as well as time to create reference materials for them.

Support Planning

Support planning is an activity in which the IT department defines how it will run the platform on a day-to-day basis as well as how it will meet any service-level agreements (SLAs) that have been negotiated with the business owners. Defining the plan and delivering on it consistently is necessary to build confidence with the users and in the platform.

SLAs act as the requirements document for a support plan. They should define roles and responsibilities so that users know whom to call for questions. They should define how the support team is reached and for what services. Support plans should clearly identify when the system should be up and running and when service windows will be. The support team should be able to effectively communicate when those service windows are being used, what is being done, and how it may affect users.

Backup and restore options are another area that falls under support planning. Though restores have taken a bit of a back seat with the introduction of the SharePoint recycle bin, instances still exist where content needs to be restored. The recycle bin allows users and site administrators to restore most content. When circumstances require additional support, administrators will need to rely on third-party solutions or restoring from backup.

From the IT side of things, defined processes are needed for rolling out service packs and other deployable changes. Ideally, this will include deploying changes in a stage or test environment with sufficient time for testing and validation before using a repeatable process to deploy the same change to production, followed by the same validation and testing scripts. Third-party tools are available to assist with deployment activities as well.

The more traditional support topic of disaster recovery also needs to be addressed and can vary from simple to complex. Organizations with high availability demands may have a second instance of a production farm with database mirroring in place, whereas a simpler environment may have expected downtime with tools or scripts in place to restore or rebuild from backup.

Support plans should also work in concert with the communication plan to effectively communicate expectations and schedules with users and the rest of the IT organization.

SUMMARY

This chapter covered a lot of the potential topics that should be reviewed as part of readying an organization for SharePoint. Even though the market is starting to see more commoditization of both developer and IT pro resources, stakeholders need to understand enough of the general concepts to coordinate internal and external resources effectively. So many roles and responsibilities can be confusing, but everyone has a part to play in a successful SharePoint implementation.

Stakeholders from the business side need to work with the technical implementers to prioritize their needs based on a strategic vision and road map. Administrators need to plan for and build a stable platform for the organization as well as execute a successful support and maintenance plan. Developers need not only to deliver quality solutions but to identify standard development practices for both internal and external resources. Everyone needs to be trained and empowered to do his or her part effectively.

Although there is a lot to do, no one part is overwhelming. When each phase is complete, all the contributors can be confident that added value has been brought to the organization.