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:
- Identifying and planning for risks
- Building a lab
- Gathering data
- Documenting requirements and other important information
- Reaching consensus
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:
- The name or description of the risk
- The name of the person who identified the risk
- Probability of occurrence (high or low)
- Impact (high or low)
- How the risk will present itself
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.
| Components | Running | Notes |
|---|---|---|
| Two workstations |
Windows 7 Microsoft Office 2013 Microsoft Internet Explorer 8.0 or later Google Chrome (latest version) Mozilla Firefox (latest version) Apple Safari (latest version) Microsoft Visual Studio 2012 |
Time share access |
| Mobile devices, such as smartphones and tablets |
Windows Phone 7.5 or later Apple iOS 5.0 or later Google Android 4.0 or later |
Have a few handy |
| Two WFE servers |
Windows Server 2012 SharePoint Server 2013 |
Load balanced |
| One Office Online server |
Windows Server 2012 SharePoint Server 2013 |
Web versions of Microsoft Word, Excel, PowerPoint, and OneNote |
| One applications server |
Windows Server 2012 SharePoint Server 2013 |
Deploy applications and services you want to demonstrate, such as Microsoft Visio and Business Connectivity Services |
| One relational database server |
Windows Server 2012 SQL Server 2012 |
Establishing a cluster is optional |
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.
| Data | Data Sources | Plan A | Plan B |
|---|---|---|---|
| Service levels |
Business analyst SharePoint product manager |
Obtain documented service levels that provide metrics for RTO, RPO, number of users, transaction performance (e.g., page load, search results), and provisioning (e.g., number of servers, site collections, and new sites added). | Estimate the service levels, using the metrics provided in the MSDN blog "SharePoint - Sample Service Level Agreement (SLA)" as a baseline. |
| Service provider contracts |
Contracts or purchasing department SharePoint service manager SharePoint product manager |
Obtain details regarding all contracted services (support or business process), including the recipients of those services, the SLAs, and the process for making changes to the contracted services. | Contact the contracts department and obtain as much information as possible. |
| Features |
Business analyst SharePoint product manager |
Obtain a business requirements document that maps business requirements to SharePoint features. | If there's an existing SharePoint deployment, open the Central Administration website and document the site collections, services enabled, and any custom Windows Solution Package (WSP) deployed. |
| Customizations (existing SharePoint environments only) |
Business analyst Development manager |
Obtain documentation that describes the customizations deployed in the SharePoint farm and the subject matter experts to contact for more information. | Use the Central Administration website to get a list of installed WSPs and speak with the developers for more information. |
| Capacity | Operations manager | Obtain reports detailing the number of users, servers, and databases (and their sizes). If there's an existing SharePoint environment, obtain reports detailing the number of site collections and sites. Also obtain trending forecasts from the SharePoint, SQL Server, SAN, and network administrators. | If there's an existing SharePoint deployment, use the Central Administration website to obtain the number of database and their sizes. Otherwise, use Windows PowerShell commands to collect this information. |
| Records management policy | Records manager | Obtain the definition of a record, the file plan, the policy regarding usage of SharePoint, and the disposition schedule. | Assume that SharePoint won't be used for records management. If it is, watch the videos in the free Microsoft training course "Introduction to Records Management and Compliance." |
| Security policy | Security manager | Obtain the security policy, control plan, and any information regarding past audits. | Utilize the documents provided on the SharePoint Governance Policies, Plans, and Documents Listing web page. |
| Server standards | Infrastructure manager | Obtain commercially available server models. Join the committee that helps select the standards if possible. What's important regarding server standards are the build specifications. What are the standards when building each server or VM, and can you measure and validate them in production when auditing and troubleshooting. | Speak with the person in charge of purchasing to understand who you need to deal with and how to order what is required. |
| Network |
Infrastructure manager Network vendor |
Obtain information about the network capacity and trending, and the bandwidth consumed with trending. Also obtain a network diagram and provisioning information. | Use Performance Monitor to collect statistics regarding the NICs. Also look for critical events that might suggest network congestion. |
| Storage |
Infrastructure manager Storage vendor |
Obtain information about storage capacity and trending, and IOPS and storage consumed with trending. Also obtain storage provisioning information. | If there's an existing SharePoint deployment, use the Central Administration website to obtain information about the size of the content, databases, and search index. If there isn't an existing SharePoint deployment, see TechNet's Capacity planning for SharePoint Server 2013 web page. For IOPS, assume 2 IOPS per gigabyte. |
| Operations | Operations manager | Obtain information about the operational jobs (e.g., search crawl, backups, virus scans). Also obtain a list of key operational problems related to the platform (e.g., problems with large lists and site reporting). | Document the timer jobs and speak with the person who runs the backup system. Assume there are problems with large lists and site reporting. |
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:
- Risk plan. You need to document the risks, the probability that they'll occur, and their potential impact. In addition, for each risk, you need to specify the person to contact if the risk turns into reality and describe how the problem should be addressed.
- Business requirements. You need to document the business areas and their specific requirements, the context and priorities of those requirements, and the expected outcomes if those requirements are met.
- Functional requirements. You need to translate the business requirements to product-related functions. (The product can be SharePoint or any other product that's part of the solution.) Where gaps exist, you need to detail the functionality needed (e.g., use cases). This level of abstraction focuses solely on how SharePoint will be utilized.
- Logical design. You need to document the logical components in the SharePoint architecture, explaining their key functions and the interrelationships between them. This level of abstraction focuses solely on how the logical components interact to support the functions.
- Physical design. You need to document the physical components in the SharePoint architecture at the toolset, server, network, and storage levels, explaining their key functions and the interrelationships between them. This level of abstraction focuses solely on how the physical components interact to support the functions.
-
Operational impacts. You need to document the solution's specific impacts to operational staff, processes, policies, toolsets, and third-party agreements. This document is focused on ensuring your organization can successfully operate the end solution.
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:
- First layer (exterior). During the first layer, or pass, you're documenting what you and the other team members know. The resulting first draft of the document usually doesn't include enough detail. In addition, it often exposes gaps in the organizational knowledge as well as exposes people's lack of knowledge.
- Second layer. During the second pass, you'll likely need to dig for (or create) the information required to fill the gaps. You might expose facts that team members or other stakeholders have been trying to hide. The resulting second draft includes the new information, but it's not uncommon to find a few more gaps. Reviewing the second draft as a team helps build consensus regarding the facts' accuracy.
-
Third layer. During the third pass, the remaining gaps are filled and the facts are presented from multiple points of view. In this draft, all the facts are on the table in plain sight (although how they're interpreted depends on your company's culture). If all goes well, the team members will sign off on this version of the document.
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."
