Architecting SharePoint: How to Create a Team to Design SharePoint Farms

Architecting SharePoint farms is a complex task. For this reason, it's best to assemble a SharePoint architecture team. Doing so will greatly increase the likelihood that the project will succeed. I'll discuss who needs to be on this team and why, as well as tell you about the approach the team needs to follow. However, I first need to tell you about the various SharePoint architect roles.

SharePoint Architect Roles

One person typically doesn't possess all the disciplines required for architecting SharePoint projects, so SharePoint architects usually specialize in one or more disciplines. For example, enterprise architects might specialize in aligning business goals with technology and leading the SharePoint team. Information architects might concentrate on how the information architecture (e.g., metadata, logical model) will be applied or extended to include SharePoint. Technical architects might specialize in deploying SharePoint and its related technologies.

As an architect (no matter your discipline), you'll be tasked with obtaining requirements and collecting supporting materials that will enable you to design a SharePoint environment. You shouldn't expect to easily obtain all the information you require. Most likely, you'll need to work with process stakeholders to document information that isn't currently available or known.

To be a successful architect, you need good communication skills (both verbal and written) and good interpersonal skills (e.g., the ability to deal with conflict and office politics). In addition, you need good negotiation skills. You often need to reason and negotiate with people regarding the work they need to perform and how to bridge an identified gap to a mutually beneficial outcome. Finally, you need to be skilled in working within your organization's culture. Every culture is slightly different, but there are many common themes in them. For example, technology companies tend to be more forgiving if you push out solutions that aren't fully baked, whereas financial cultures aren't as forgiving in this respect.

In addition to these core skills, it's good to have experience in five areas: enterprise architecture, operations, information architecture, SharePoint Server, and SQL Server. Before I provide information about these areas, it's important to point out that, practically speaking, it's doubtful that a single person would be experienced in all five areas. Furthermore, organizations might not have anyone with experience in some of the more specialized areas. Therefore, the responsibility for these areas, or roles, typically is divided across multiple people, and some of these roles might even need to be outsourced.

The five roles are:

• Enterprise architecture. The person in this role needs to assess business requirements (e.g., service-management, product-management, and financial requirements) from an enterprise point of view. This role might need to be outsourced, with the outsourced enterprise architect working alongside an architect within the organization.
• Operations. The person in this role needs to be knowledgeable about the organization's operational processes, procedures, policies, toolsets, and third parties (e.g., outsourced functions).
• Information architecture. The person in this role needs understand both the terminology and data used by the organization's business operations so that he or she can effectively articulate metadata requirements, content types, workflows, and more. This role is often outsourced. For more information about the information architecture role, see the Information Architecture Institute website, the book Information Architecture for the World Wide Web by Louis Rosenfeld and Peter Morville (O'Reilly Media, 2002), or the book The Elements of User Experience by Jesse James Garrett (2003).
• SharePoint Server. The person in this role needs to have several years' experience in deploying, supporting, and providing training for recent SharePoint Server versions (e.g., SharePoint Server 2013). Not having solid SharePoint Server experience is a risk to you and the organization. You need in-depth product knowledge to be able to manage user expectations (what the product can and can't do off the shelf), install and configure SharePoint Server, and administer it. (Every product has its quirks.) In addition, the person needs to know how to establish baselines for normal performance and manage capacity growth using predefined measures (i.e., use performance and capacity monitoring so you know when to add additional hardware and tune the farm accordingly to remain within expected service levels).
• SQL Server. The person in this role needs to have experience in deploying, supporting, and providing training for recent SQL Server versions (e.g., SQL Server 2012). Not having solid SQL Server experience is a risk to you and the organization because SQL Server is the heart of SharePoint. Specifically, the design for SQL Server must be able to support the required capacity in the form of disk space and I/O operations per second (IOPS) over the lifespan of the solution. These requirements must be clearly articulated to SAN architects. In addition, operational procedures must be put in place for monitoring and proactive maintenance.

Finally, successfully architecting a SharePoint farm requires an open mind, patience, a politically savvy approach, and willingness to learn. My advice has always been to make sure your mind is open to learning, leverage your strengths, address your weaknesses with the help of team members, and understanding people's styles and their agendas. This is the difference between someone who can get things done and someone who needs to be told what to do.

The SharePoint Architecture Team

Just about every successful person in history has a solid team behind him or her, and the architect who successfully designs a SharePoint environment is no different. Table 1 lists the members of a SharePoint architecture team, their expected roles, and their key deliverables. (Note that some projects might involve roles not listed in Table 1.)

Table 1: SharePoint Architecture Team Members

Team Member	Role	Key Outcomes
Executive sponsor	Has the authority and political savvy to be the champion of change and provide budgetary support	Budget, organizational, and strategic alignment
Evangelist	Has the business, technical, and marketing savvy to sell to the vision and pave the way for SharePoint	Demand created for SharePoint and users' expectations managed
Service or product manager	Is accountable for SharePoint as a service offering within the organization	Service offering aligned with business insight
Project manager	Manages all aspects of the SharePoint project	Project-related activities, documents, reports, and controls
Purchasing manager	Handles all commercial aspects, such as procurement and licensing negotiations	Commercial contracts for products and services
Enterprise architect	Provides technical and organizational acumen specific to SharePoint and its related technologies	End-to-end technical solution
Technical architect	Handles the hands-on installation and configuration of SharePoint	SharePoint installation and testing
Infrastructure architect	Is responsible for the server, storage, and network infrastructure	Infrastructure provisioning and management plan
Operations architect	Is responsible for SharePoint operations, including administration, quality assurance, monitoring, reporting, and problem solving	Operational plan and transition-to-production plan
Security manager	Manages the security policy and control plan for SharePoint, including auditing policies	Security policy and control plan
Records manager	Manages records and other documents and helps develop the auditing policy	Records management policy, file plan, and disposition and training schedules
Third-party representative	Is responsible for the areas the third party is contractually obligated to support	Activities related to the areas the third party is contractually obligated to support

Not every project will utilize every role listed in Table 1. For example, whether you have a third-party representative depends on whether you're outsourcing any of the roles. Generally, the more outsourcing, the more critical it is to have third-party representatives on your team. Otherwise, you might face roadblocks or unforeseen problems later in the project. 

In general, the larger the organization, the larger the team because the economies of scale are well suited to single-purpose roles. When you have a large team, each team member will bring a lot of experience to his or her role. However, there will be more personalities and schedules to deal with.

In smaller organizations, you typically see people taking on multiple roles. Although this can simplify the team in terms of personalities and schedules, it means that the team members will have less experience specific to the some of their roles.

It's important to note that you need all the stakeholders represented on the team. They also need to buy into the project. Otherwise, you risk significant pushback when it comes to signing off on the project.

The Approach

Thinking back when I first started in the IT business, I would start at the server and design outward. This works in small organizations with minimal complexity, but as you deal with larger and more complex organizations, this approach is almost certain to fail.

Did I just admit to failure? Yes, I have failed and learned many life lessons from these experiences. At the time, these life lessons seemed negative, but now as I look back, they were very positive experiences that I'll share with you.

The first lesson I'll share is that one of the biggest mistakes you can make in your SharePoint deployment is to treat it like a technology solution and deploy it without input from the business.

Here are some other lessons learned that you should keep in mind when designing your SharePoint architecture:

Get facts on paper. As you meet with stakeholders and other team members, you need to document and distribute information. Similarly, as you go through the artifact collection and creation process (which I'll discuss next), you need to document the specifics under each to make sure there's measurable traceability.

This will be important because projects sometimes take a long time to complete and people forget what was agreed to and by whom. In addition, you should use a SharePoint site to house, distribute, and track content. Finally, you should create a communication plan that details what communications are needed, to whom, how often, and the format.

Establish measurable traceability. All the meetings, presentations, and data collection operations must result in artifacts. The artifacts can be meeting notes regarding problems, actions to be taken, decisions to be made, assigned ownership, due dates, and expected outcomes. They can also be documents sent to you, acknowledgements of agreements, or acknowledgements of requirements.

Organizing and tracking artifacts is referred to as establishing measurable traceability. It can help you link factual requirements to stakeholders, refresh people's memory, and establish effective communication. For guidance on how to set up measurable traceability, go to the Project Management Institute website and search on the phrase "project management body of knowledge" or just "PMBOK".

Leverage governance. Governance is an interesting but complex topic, as it's focused on people and technology. Generally, people are the greatest risk because of personalities. You've probably worked with a "Captain Control" or "Debbie Downer" or other people with poison personalities who run their own fiefdom.

This is where having an executive sponsor comes into the picture. Your sponsor will have the organizational insight and political might to deal with these sorts of problems before they derail the project. So, governance is really about managing people first and technology second, because if you don't manage the people (grease the wheels), you won't be able to manage the technology.

So what are the specifics of governance? The free webinar Real-World SharePoint Governance discusses how to build, launch, and manage your SharePoint governance program.

Aside from this webinar, there are many other resources containing governance-related advice but I've yet to find one resource that covers governance end to end. Instead, you'll need to check out several resources to get the big picture, such as:

• The TechNet articles on governance planning, which are listed on the Governance planning in SharePoint 2013 web page
• The book IT Governance: How Top Performers Manage IT Decision Rights for Superior Results by Peter Weill and Jeanne W. Ross (Harvard Business Review Press, 2004)
• White papers and other resources on the AvePoint website 

Map the political landscape. Using governance and relying on your executive sponsor, you must carefully map out the political landscape of your organization. You need to look for fiefdoms and other landmines that could derail your project.

Generally, the larger and more dispersed the organization, the greater the chance of political islands. You need to work with your sponsor and use governance to deal with conflicting views and people who simply won't cooperate. You need to determine which battles you can win and which you must steer clear of.

Set achievable metrics for success. Utilizing governance, you must establish achievable metrics for your architecture. They can take different forms:

• Financial. An example of a financial metric is that the SharePoint farm must cost no more than $4 million to plan, design, and deploy, and $2.5 million a year to operate.
• Business process. Examples of business process metrics include reducing form approval process times and simplifying business reporting.
• Technical. Examples of technical metrics include page loads must take no longer than 10 seconds, search queries must return results within the first 3 pages, and search results must be displayed within 10 seconds.
• Operational. An example of an operational metric is that a specified service level must be met for provisioning sites.
• Organizational. An example of an organizational metric is that industry-specific compliance must be achieved. 

Set service level agreements (SLAs). The SLAs should focus on SharePoint as a service offering and build on the metrics for success. Here are some examples of service-focused metrics:

• Availability. The availability metrics might include recovery time objectives (RTOs), recovery point objectives (RPOs), service availability, and how quickly you can recover a farm, server, site collection, site, list, library, or item (e.g., document) when there's a service failure.
• Performance. The performance metrics might include page loads (e.g., a page will load within 5 seconds), search results, and document uploads and downloads (e.g., a 10MB document will download within 10 seconds).
• Provisioning. The provisioning metrics might include timeframes for providing additional capacity (e.g., adding servers, web applications, site collections, or sites). 

For each SLA, you need to specify the responsibilities of each party involved.

Take time for proof of concept (POC) and pilot testing. Make sure that you utilize POC and pilot testing. It's beneficial in many ways, including getting feedback about problems sooner rather than later, introducing users to the new technology, helping the IT staff learn more about SharePoint, and providing the business leaders with some tangible examples of what's possible with SharePoint.

The Next Steps

Keeping these lessons learned in mind, here are the steps that the SharePoint architecture team should follow to design a successful SharePoint environment:

1. Identify and plan for risks.
2. Build a lab.
3. Gather data.
4. Document requirements and other important information.
5. Review, refine, and build consensus.
6. Decide whether to use a single-farm architecture or multi-farm architecture.
7. Decide whether to virtualize SharePoint.
8. Decide whether to use a hosted environment.
9. Prove the architecture.

Because this is a lot of information to cover, I discuss these steps in several articles. Specifically, I discuss step 1 through step 5 in the "Architecting a SharePoint Environment: Building a Solid Foundation for SharePoint Farms." Step 6 is covered in "Architecting a SharePoint Environment: Choosing a Farm Design." Finally, I discuss step 7 through step 9 in "Architecting a SharePoint Environment: Virtualization and Cloud Decisions."