Architecting SharePoint: Building a Solid Foundation for SharePoint Farms

Designing a SharePoint environment involves much more than deciding how many and what types of farms to implement. If you want your SharePoint farms to effectively and efficiently meet your organization's requirements and goals, the SharePoint architecture team needs to build a foundation that will help ensure a successful design. Building the foundation involves:

It's important for the team members to actively participate in some or all of these steps. Otherwise, they might not buy into the project, and you'll risk getting significant pushback when it comes to signing off on the project. (For more information about SharePoint architecture teams, see "Architecting SharePoint: How to Create a Team to Design SharePoint Farms.")

Identifying and Planning for Risks

The SharePoint architecture team needs to identify and make contingency plans for the possible organizational, financial, resource, compliance, and technical risks associated with the SharePoint deployment.

For example, SharePoint is essentially a multi-function content-sharing repository. Its value to the organization and its compliance risk are directly related to the repository's content, the audience, and level of access the audience has to the content. If your organization plans to leverage SharePoint's document management functionality, there could be records management implications. Specifically, when compliance is added to the equation, there's a risk of negative exposure for your organization if SharePoint doesn't meet the audit criteria.

The level of risk planning depends on your organization's record of project accomplishment. Specifically, were its last five projects successful? Why were those projects successful or unsuccessful? This conversation must occur with multiple team members to be accurate.

The most effective approach to identifying and dealing with risks is to assemble the stakeholders in a meeting room with a whiteboard. Each stakeholder should identify the risks with which he or she is familiar. For each risk, the stakeholder should write the following on a large sticky note:

After the stakeholders have documented the risks, have them place each risk on the whiteboard (or a wall) for everyone to view. Then review each risk to understand the stakeholder's perspective. Afterward, group the risks that are duplicates, asking the stakeholders' permission to do so. Asking for permission is important, as you're not the judge—you're simply a facilitator of the process.

Upon completion, you'll have a list of risks that the team agrees on. From there, you can work with the team members to develop a contingency plan for each risk. Note that if you don't have relationships with some of the team members, I highly suggest you develop them. Make this a high priority, as it will help you better understand business operations and increase your value within the organization.

Building a Lab

You'll need a lab for a variety of reasons, including developing, testing, and demonstrating possible solutions to stakeholders. I recommend that you build a virtual farm consisting of five servers so that you're able to experiment with different configurations (validate design decisions) and understand how the components work together.

For example, performing load testing (baselining performance and capacity) will help determine if two web front-end (WFE) servers provide the necessary performance.

Table 1 shows a good starting point for a lab. You'll need to alter it based on what software versions and devices you're using in your organization. If your lab will use virtual machines (VMs), you should take snapshots of them after they're built as a precaution.

Gathering Data

With the lab built, you're ready to start gathering data to help substantiate architectural decisions that will result in your design. Table 2 shows the key data collection activities, which are iterative in nature. Note that I take the approach of having two plans: Plan A and Plan B. Plan A is the best approach and will generally get the best results. But we live in a world of uncertainties, so having Plan B just makes sense. Plan B specifies the minimal information required and makes some assumptions.

You shouldn't expect to collect all the data at once. It could take months to collect, depending on your organization's size, complexity, and readiness.

I recommend that you store and manage the collected data on a SharePoint Team Site. You should also use this site to manage the team's documents, communications, decisions, issues, and activities. Collaboration aside, it helps manage people's perception of the project's value, your professionalism, and level of success. It also helps surface political problems early in the process.

Documenting Requirements and Other Important Information

After you collect the necessary data, you're ready to begin documenting requirements and other important information. Here are the core items you need to document:

Reaching Consensus

When it comes to architecting solutions, there's a major focus on documenting the facts and building consensus regarding their accuracy. Specifically, depending on your point of view, the facts could be very different. Your job will be to understand the different perspectives and make sure the requirements are presented in a factual manner.

The analogy I use for this is the layers of an onion. As you peel through the layers, you learn more, which means you can discuss and document the requirements in a more detailed manner. This approach is helpful because you'll never have all the information required in the first pass. How many layers of the onion are there? It depends on the information readily available, the skills and knowledge of your team members, and the organization's culture. Typically, there are three layers:

The Next Step

After your SharePoint architecture team has identified the risks, built the lab, gathered the necessary data, and reached consensus about the documented facts, it's ready to proceed to the next step: deciding whether to deploy a single-farm architecture or multi-farm architecture. Because of the importance of this decision, I discuss everything you need to consider in the separate article "Architecting SharePoint: Choosing a Farm Design."