CHAPTER 10

Growing Your SharePoint Service

Understanding Scalability

Scalability relates to how you can adjust your farm to handle an increasing load or to provide additional capabilities. You achieve scalability when you maintain service performance levels as you increase the load on your SharePoint service. Your system is scalable when you can add resources to it to maintain or improve on the performance levels under an increased load.

One common reason to grow a SharePoint service stems from scaling to meet growing adoption rates and increased demand on the service. You might face the need to scale from increased usage or expanded services, or a combination of the two. As you scale to handle the increased load, you will add resources to the service that provide additional capacity for handling requests. You can scale your service by selecting either or both of the following scaling options:

• Scaling Up
• Scaling Out

Scaling up refers to adding capacity to existing components that the service runs on. When you scale up, you improve performance by replacing a resource in the existing design. For example, if you want to scale up a given SharePoint farm, you can replace the RAM with a larger amount of memory or the CPU with a faster processer. As Figure 10-1 illustrates, you can also scale up by adding additional hard drive storage space. If you had two SharePoint servers and one SQL Server, after scaling up you will still have a farm consisting of those three servers, but they will have the increased power or additional capacity from the resources you added. Scaling up is an effective way to remove bottlenecks based on over utilized resource components.

Scaling out refers to adding components to add capacity. When you scale out, you typically improve performance by adding more servers or farms to grow the existing design. For example, if you want to scale out a given SharePoint farm, you can add more SharePoint web front-end servers and a network load-balancer (NLB) to spread the load across additional servers. Figure 10-2 illustrates an example of scaling out the web front-end servers in a farm. Scaling out is an effective way to remove bottlenecks by allowing for more processing of requests in parallel across additional servers or farms.

Another way you can scale out your SharePoint service is by adding peripheral subordinate farms. You might add a subordinate farm for several reasons, including providing a farm to meet the needs for customizations that you do not want to implement in a shared environment. You might also deploy subordinate farms to meet geographic needs by providing a farm in a remote region for quicker network access. Subordinate farms might help you segregate and organize different services or provide different service levels, although they will also add to the administrative overhead to manage and support your overall SharePoint service.

You might scale out to subordinate farms hosted in the cloud, such as with Office 365, or you might scale out to a subordinate farm hosted on-premises. Although the implementation details differ, I still group these scaling options together and I refer to them both simply as a subordinate farm. Later in this chapter, I return to discuss considerations to help you plan for subordinate farms. For now, I just want to point out that this is one approach to scaling out a service.

In short, I use scalability to relate to your ability to add resources and components to your SharePoint service to increase its capacity. As your user base grows, so can your SharePoint service. As the characteristics of usage evolve, so too can you evolve your SharePoint service. This does not mean that you should start aimlessly throwing servers and additional resources at your SharePoint farms because something feels slow or you suspect you might need something. Instead, base your decisions on performance measurements either from actual production usage or from load testing. You can then use this data to help you make scaling decisions and to help you plan for scalability.

Planning for Growth and Scalability

Microsoft has already done a lot of the scalability planning for you. They designed SharePoint so that you can add components to it in the future without causing a major interruption or rework of the existing service. They also expose many of the product’s capabilities through a service-oriented architecture (SOA), the SharePoint 2013 service applications. This architecture allows you to target how you allocate your server resources for specific services, while SharePoint abstracts away the complexities of balancing the load.

Many of the low-level details to support scalability are already in place for you. However, you can still plan some aspects of the service to prepare for future growth and scalability. The following lists a few of the main areas you may consider as you plan for future growth.

• Budget: As you grow and scale your SharePoint service, you will encounter additional expenses to expand resources to scale up or scale out. When you look at your projected trajectory of growth, consider what that means in cost and how that aligns with your budget. You may need to delay or piecemeal growth until you have available budget to accommodate it, particularly for growth involving capital expenses such as servers and other infrastructure components. You can anticipate this piecemeal approach in your roadmap, as I discussed in Chapter 7.
• Infrastructure Components: With an increasing demand and an expanding range of capabilities, you will eventually require additional hardware to process the load and maintain performance levels. You can plan for hardware acquisitions in your budget, as I mentioned in the previous bullet point. You can also plan for this by setting up the hardware in a manner where you can add additional components at a later date. For example, you can plan for future growth and scale by installing a SQL Server Cluster even if you are only using a single SQL Server node to start. This allows you to add additional database server nodes without much reconfiguration. You can take a similar approach with the web front-end servers by including load balancing hardware or software proxies in your initial architecture design.

• Isolation: Growing and scaling might require you to process an increasing load on the same hardware. To achieve this, you might have to isolate applications that consume heavy amounts of resources and that could degrade the overall service availability. You can achieve this isolation by allocating the application’s services to run on dedicated servers in the farm or you can dedicate subordinate farms specifically to run and isolate these applications. You can plan future growth and scale by planning how you can isolate and constrain certain applications to prevent them from consuming all the available server resources and affecting overall service availability.
• Request Routing: As a quasi mixture of load balancing and isolation, request routing provides another option you may consider to help maximize your resource utilization and prevent one application from negatively affecting the availability of the entire service. SharePoint 2013 contains a Request Management capability that allows you to apply logic to distribute requests based on additional criteria, rather than simply balancing the load across a group of servers. For example, you can throttle requests from certain user agents or to certain applications. You can direct certain requests to specific servers based on static rules you configure or based on dynamic health scores that SharePoint maintains for each server. You can use SharePoint 2013 Request Management to throttle and balance loads across your farm using sophisticated logic, and this can help you plan how you want to grow and scale your service. Figure 10-3 illustrates how the SharePoint 2013 Request Manager handles user requests and then routes them to available SharePoint web front-end servers.

In planning for growth and scalability, you will also need to consider how you will implement customizations and application development so that it does not limit your ability to grow or scale your service. You also want to avoid having the implementation choices you make today cause extensive rework in the future. These are topics I address in Part IV of this book, where I return to discuss planning considerations, actions, and behaviors to guide you for different aspects of customizing your SharePoint service. For this chapter, I focus on the SharePoint platform itself – particularly on the components and services that make up the SharePoint platform. In the next section, I describe the infrastructure components that form a SharePoint farm.

Understanding the Infrastructure Components

You might hear people refer to SharePoint web front-end servers and SharePoint application servers when they describe a SharePoint farm. These are all SharePoint servers with SharePoint software installed and running. Conceptually, the differences between a web tier and an application tier are the services running on the server. A web server runs the “Microsoft SharePoint Foundation Web Application” service, and it responds to HTTP requests for sites and content that the farm provides. You can grow and scale your service on the web tier by adding servers and configuring network load-balancing or SharePoint Request Manager to spread the web requests across these servers. Figure 10-4 provides an architecture diagram to illustrate the different servers in a SharePoint farm as well as other servers the farm may depend on.

Application servers run other services, typically providing the functionality behind an application or a background job. Your farm can include a variety of application servers, ranging from running all the services on the same server (including the web server) to dedicating a server for a particular service. For example, you can dedicate servers to run different components of the search service such as indexing and query components. This architecture allows you to allocate your services in a granular fashion to optimize your server resources. You can grow and scale your service by adding new servers to the farm and then allocating services across your application tier. I return in later sections in this chapter to walk you through how to add servers to a SharePoint farm and how to allocate services on different servers.

The next group of servers in a SharePoint farm involves your SQL Server database servers. The data tier consists of one or more SQL Server nodes running the databases where the SharePoint farm stores its content. Typically, you mirror or cluster these databases to provide redundancy and reduce the risk for outages. As a SharePoint service is data-driven, it relies heavily on the database servers to serve content and for the overall farm’s performance. You can grow and scale your data tier by adding SQL Server nodes to host databases and process requests.

Another important infrastructure component you may include in your SharePoint farm is the Office Web Apps Server 2013. This server product provides functionality to render Microsoft Office documents as a web page within SharePoint libraries and as preview thumbnails in search results. Formerly, SharePoint 2010 included this functionality as a service application, but beginning with SharePoint 2013, Office Web Apps is now its own stand-alone server product. The reason Microsoft separated these products is to make Office Web Apps available for other products such as Exchange 2013 and Lync 2013, which also now use its Office document rendering capabilities, and these other products can use Office Web Apps without also introducing a SharePoint dependency.

You will also consider other infrastructure components as you plan to grow your service and farms. One notable component may include any virtualization server components that you use to host any virtual servers in your farm. Some network components you may require include the load-balancing servers or other hardware devices, as well as any firewalls and intrusion detection components you require to protect your farms. Other components may include any enterprise backup products you use to capture backups of server states and databases.

Part of growing your SharePoint service may involve scaling out individual farms. Often, scaling out a SharePoint farm involves adding servers to it – either SharePoint servers or database servers. You can scale out your database servers by adding additional SQL Server nodes to a cluster and distributing your databases across the active nodes. You can scale out your SharePoint servers by adding additional servers to the farm. In the next section, I walk you through how to add an additional SharePoint server to the farm.

Adding Servers to a SharePoint Farm

You might recall the SharePoint Configuration Wizard from your initial install of SharePoint. If you only installed SharePoint on a single farm, then you ran this wizard to provision the farm and it configured that server to join the farm. If you installed SharePoint on additional servers, then you ran this wizard on those additional servers and configured them to join the farm. You can add additional servers to the SharePoint farm at a later time by running that same wizard and following those same steps.

The SharePoint team designed SharePoint with this flexibility to add and remove servers from a SharePoint farm with relatively few complications and little complexity. To ease this process of joining a new server to a new farm, I like to go through the following steps:

1. Install the Windows Server 2012 or later operating system.
2. Install any server service packs and Microsoft updates.
3. Install the SharePoint 2013 Prerequisites on the server.
4. Install the SharePoint 2013 software on the server.
5. Install any required language packs, if applicable.
6. Install any SharePoint service packs, if available.
7. Install any other SharePoint updates, if available.
8. Install any add-ons or third-party components, if applicable.
9. Run the SharePoint Products and Technologies Configuration Wizard, selecting the option to join an existing farm.

This approach will help you to avoid any incompatibility issues between the new server and the farm. This is important because once you run configuration wizard, SharePoint will join the server to the farm and it will begin to process requests. Inconsistent version numbers may cause unexpected results in processing a request on the inconsistent server. You can verify the SharePoint versions and patch levels for each server and each content database in the farm on the Manage Patch Status page in SharePoint Central Administration, as shown in Figure 10-5. You can navigate to this page by clicking the “Check product and patch installation status” link under the Upgrade and Migration section on the SharePoint Central Administration homepage.

As you add new servers to the SharePoint farm, you can grow and scale your service. You may have additional steps to configure the server for your farm, depending on your environment and individual situation. Some other tasks you might have to perform on the new server include adding any necessary certificates to the server, configuring system monitoring, and configuring any routing or load-balancing components.

By default, the configuration wizard starts the Microsoft SharePoint Foundation Web Application service on the newly configured server. After you join a server to a farm, you can start and stop the desired services you want on that server. In the next section, I walk through the steps for allocating the desired services on a server.

Allocating Services and Servers

SharePoint exposes management of what services run on what servers through the Services on Server page in the SharePoint Central Administration, as shown in Figure 10-6. On this page, you can select the server and then click to start or stop each of the desired services. This allows a SharePoint administrator the ability to manage background services on a server without having to grant them any administrative access to the server itself.

You can access this page by clicking the “Services on Server” link under the System Settings section on the SharePoint Central Administration homepage. Notice the server name in the top-right table header area of this page. Clicking the link of the server name opens a drop-down menu with the Change Server menu option, as highlighted in Figure 10-7.

If you click this menu option, you will open the Select Server modal window, listing all the SharePoint servers that are available in the farm. Inside this window, you can click the server name to select the server and dismiss the modal window. Notice that the server name in the top-right area of the Services on Server page reflects the newly chosen server. With the desired server selected, you can now allocate which services run on that server, effectively assigning the server’s role.

You can allocate and reallocate services to balance and redistribute the load on the servers in the farm, and you would do this either after adding a new server to the farm or to optimize the distribution of services on existing servers. Through this approach, you can grow your SharePoint service to handle an increasing load on your existing services. By following this approach, you can also expand the service capabilities that your SharePoint service offers. When you expand your service, you start the new services on the desired servers, and you will often create a respective service application to expose the functionality in the expanded capability. In the next section, I discuss some considerations to be mindful of as you approach expanding your SharePoint service with a new capability.

Approaching a New Service Capability

As you approach enabling a new capability for your SharePoint service, the first and most important step is to determine the resource characteristics of the capability. You can start by asking whether the capability consumes resources from the SharePoint servers in the farm, or if it runs elsewhere. For example, a Business Connectivity Services (BCS) application might consume the majority of its required resources on a SQL Server database server where SharePoint queries the data from, and it might require only minimal resources on the SharePoint servers. In contrast, an Excel Calculation Services application might consume the majority of its required processing resources on the SharePoint servers.

Once you know what types of servers that the new capability will affect, you can continue to analyze the resource characteristics by identifying how it will affect the servers. This will help give you an idea about what kind of load the application will put on the server or servers. To get a general sense of how the application will affect server resources, I ask the following questions.

• Is the application heavy on processer (CPU) usage?
• Is the application heavy on memory (RAM) usage?
• Is the application heavy on disk reads or disk writes?  Are the disk reads or writes local to the SharePoint server(s) or do they occur on the SQL server(s)?
• Is the application heavy on network communications?

At this point, you can consider whether your existing servers can handle the expected load, given the expected resource characteristics. In Chapter 6, I discussed different performance metrics that you can measure to determine the health and resource availability on your servers. You can use those same measures now to get a sense about whether your servers are nearing an over-utilized state or whether they have capacity to handle the additional load of the new application. After deploying the new application, you can use these same measures to monitor the new application along side the rest of the SharePoint service.

This is another case where you will want to plan for adequate server resources in a capacity plan. However, similar to your initial deployment of the farm itself, your capacity plan is an estimate. As you estimate the amount of capacity that you need to handle the load of the new application, you will make some assumptions on usage and estimate your initial capacity plan. Once you have your estimates, you can run load tests to increase the level of accuracy in your capacity plan. You can return to validate your estimates as the application runs in production by monitoring the performance metrics, as I mentioned above. This allows you to revisit your assumptions and make any adjustments as needed.

You may need to add additional servers to a farm to support the load of the new application, and you can allocate the services to run on designated servers. I discussed both of these topics earlier. You might dedicate one or more servers on which to run an application’s service, such as potentially dedicating servers on which to run the PerformancePoint services to support a heavily used business intelligence application. Alternatively, you might dedicate an entire farm on which to run an application, such as potentially dedicating a farm to run an enterprise search application that you want to share across many farms. In the next section, I discuss when you might want a subordinate SharePoint farm and how you can plan for one.

Planning for Subordinate Farms

Subordinate farms can help you segregate and address differing needs from your internal customers. They allow you the flexibility to isolate applications or to create a centralized application service that you share with other farms. Deploying multiple farms enables many uses that may be of interest to you, but I do not take this decision lightly because additional farms will have additional operations costs and add support complexity. I generally default to a single enterprise farm, and then analyze and debate why any additional farms would benefit the service.

The benefits of operating a single farm relate to a simplified administrative burden. With a single farm, there is only one farm to maintain. Whereas, multiple farms add a level of complexity, most notably with keeping each farm’s patch levels synchronized and consistent. A single farm also provides a single environment to troubleshoot and maintain. Consolidating in a single farm also reduces the number of required servers for test and staging environments, which you might want to mirror with your production environment for testing and pre-production purposes.

Running one centralized enterprise farm simplifies your ongoing operations and support. For these reasons, I prefer architectures with one centralized farm until there are compelling reasons to add subordinate farms. Through this approach, I find it helps to avoid a potential sprawl of unnecessary farms deployed throughout an organization. I am not opposed to deployments with multiple farms; I just prefer to avoid the added complexity if it does not add sufficient value.

There are many reasons why you might want to have multiple farms. In some cases, trying to fit everything in a single farm would add more complexity than segregating the design into multiple farms. For example, it may add more complexity to work around isolating certain customizations or third-party software products, particularly if they involve installing components or services directly on the server. The following list includes the most common reasons to consider when to add a subordinate farm:

• You want to provide different levels of service, including dedicated farms
• You want to isolate an unstable or risky application
• You want to segregate customers to reduce the potential of one affecting another
• You want to isolate for security reasons, such as internal versus external farms
• You want to run different versions as part of a gradual upgrade and migration
• You want to provide regional farms to minimize network latency for remote locations
• You want to segregate administration between different groups
• You want to simplify the scope of coordination for maintenance activities

Another reason you might want a separate farm relates to reducing the impact and degree of those affected in the event of a failure or a loss of service. For example, separating applications and groups of customers into multiple farms reduces the surface of potentially affected users during a single farm outage. This can help you reduce the overall risk of lost productivity and the overall severity if a major incident does occur. Figure 10-8 provides an example of a multi-farm architecture.

After you determine that you do need multiple farms in your environment, you can begin to design which farms will be responsible for which applications. You might also identify which farms will serve which regions or which segments of customers. As you identify your farms and their scope, you can begin to identify what services each will need – both the local services they will require and the remote services they can connect to and consume. You do not need to duplicate every service on every farm, and by going through this process, you can minimize and avoid running any unnecessary services. This also helps you to identify what farm trusts you will need to establish.

As I describe these additional farms, I refer to them as subordinate farms because I generally designate one farm as the enterprise farm. Typically, this farm hosts enterprise applications such as the enterprise search, the managed metadata service, MySite profiles, and the main intranet portal. Any additional SharePoint farms can then consume services from the enterprise farm such as consuming the Managed Metadata Service application or redirecting search queries to the enterprise search portal. This allows one farm to provide central services that are global across the enterprise while other farms are conceptually subordinate to the enterprise farm as they consume those global services. Figure 10-9 illustrates an example of an enterprise farm that provides service applications for a subordinate farm to consume.

The following lists the default SharePoint 2013 service applications available to publish for remote farms. For those applicable services, I have made a note where they are best to share with farms on a local LAN rather than geographically distributed farms over a WAN.

• Access Service
• Access Services 2010
• App Management Service
• Business Data Connectivity Service – Microsoft recommends considering the access to the underlying data source in the BCS models, and then use this to determine whether a farm’s availability access across the WAN will have a negative impact on performance.
• Excel Calculation Service
• Lotus Notes Connector
• Managed Metadata Service
• PerformancePoint Service
• Search Service
• Secure Store Service – Microsoft recommends only sharing this service within the same data center or LAN, as sharing the service across a WAN has a negative impact on the service.
• SharePoint Machine Translation Service
• User Profile Service – Microsoft recommends only sharing this service within the same data center or LAN, as this service utilizes direct database access rather than the service application proxy in order to optimize performance.
• Visio Graphics Service
• Work Management Service

Sharing these services can help you to establish a centralized and consistent service for those enterprise applications where consistency adds value. For example, you help optimize your information management policy as you maintain a consistent enterprise taxonomy. With an enterprise taxonomy, your entire organization categorizes their content and information processes using a common controlled vocabulary. I return to discuss the enterprise taxonomy and your information architecture in more detail in Chapter 15.

As you plan a subordinate farm, you also need to decide where to host the databases. SharePoint does not require a one-to-one relationship with a SQL Server database server. Instead, you can host databases from several SharePoint farms on a single database server or a database cluster. Alternatively, you can also spread the databases of a single farm across multiple database servers. The choice you make for the new subordinate farm you are planning depends on the available resources on the database server and whether it can handle the load of the additional farm. Other factors in your decision include whether the database cluster is in the same data center and whether you want a complete segregation between your farms.

Subordinate farms can help you scale out your service, allowing you to improve system performance by segregating and running different applications in parallel. You can also improve performance when you deploy a subordinate farm to a remote region with poor network connectivity back to the enterprise farm. Whatever your reasons are, you need to define the service level of the new farm in the same fashion as you have for any other farm. You can then include this farm’s scope in your service description, as I discussed in Chapter 2.

I mentioned earlier that the primary factor why I might want to avoid multiple production farms is the complexity they add to operations. However, you can plan for this and mitigate the complexity. I approach this by considering how consistent I can make the farms, and especially how consistent I can keep the SharePoint version and any add-ons that I deploy in the organization. The following questions will help you consider how consistent the farms will be.

• Do you need to keep the patch levels synchronized with the enterprise farm?
• Are there custom or other third-party components you want to keep consistent across the farms?
• Are the other operational tools, such as any backup or administrative software, consistent across the farms?
• Can you configure the farms with the same configuration settings?
• Can you build the farms using the same server image or virtual server template?

Generally, you will want to keep the farms as consistent as you can. By consistent, I am referring to consistent patches and service packs, consistent components, and consistent configurations. The more your farms are alike, the less you risk operational issues from developing in the future. For example, when the patch levels are the same and each farm has the same add-ons installed, you can migrate sites from one farm to another with more ease and compatibility. When the configuration settings are similar, administrators can switch between administering environments more smoothly and they will be less likely to introduce an error due to differing configuration settings. Finally, the more alike the environments are, the more you can script and automate the operational tasks. In the long run, consistency reduces operational costs and overhead.

Consultant Comrade

Planning to accommodate future growth is one roadblock I often face with clients on an engagement to plan a new SharePoint deployment. This type of roadblock can stall progress, and this can be especially true when it comes to accepting an infrastructure architecture plan that I will move forward with deploying. Clients might be nervous about painting themselves into a corner, and the nervousness might come from a fear of the unknown of what the actual adoption and load will be like.

This nervousness seems to almost paralyze some with a worry that they might limit the infrastructure in the farm and they cannot handle the load. Alternatively, they may worry about whether they are limiting their options in the future, such as if the requirements change. As far as I have been able to tell, this type of worry that stalls commitment to moving forward with a plan typically stems from a lack of knowledge about SharePoint and the implications of any decisions. The product might feel like a black box to them, and the unknown can cause anxiety.

The best way that I have found to work through this issue involves holding a SharePoint architecture overview session. I usually make this a general overview of the main components in SharePoint and how they come together. Typically for me, this session lasts about 45 minutes or more, depending on how many questions that they may have and how large the group is. I have a basic PowerPoint slide deck that I use to walk through the following topics during the architecture overview session:

• A high-level product overview and how to set an initial scope (see Chapter 2)
• An overview of each of the core capability areas (see Chapter 3)
• The typical roles and responsibilities involved in the service (see Chapter 4)
• An overview of the types of performance metrics and reporting available (see Chapter 6)
• The concept of a roadmap to break down deployments into small phases (see Chapter 7)
• An overview of the infrastructure components in a SharePoint farm (see this chapter)
• An overview on how to allocate services to servers
• A discussion on how to install and join new servers to a farm

With the understanding from this SharePoint architecture overview session, clients usually feel more at ease. By the end of the session, they should have a sense about the level of flexibility that SharePoint offers so that they can make adjustments in the future as their needs change. They should also have an idea about how SharePoint works and what are the main components involved in a SharePoint farm. This session also helps give their team a sense of the scale of SharePoint and all the capabilities involved. I find this helps with expectation management, as it tables all these issues during this session rather than having team members run with private worries that affect their decisions or their commitment to scope.

My ideal engagement starts with a meeting where the entire team comes together to kick-off the project. During this meeting, I like to present the scope and success criteria to ensure the entire team shares a common vision for what I am there to do and what I am saving for later. I then like to collect a list of risks from the team members and other stakeholders, and I can use this to start a risk registry right away. From there, I move into a SharePoint architecture overview session to provide the entire team with a good understanding of what SharePoint is, its capabilities, and how they can build a roadmap to grow it over time as it evolves.

As a consultant, you can build yourself a PowerPoint slide deck and schedule this type of session to help set your client’s expectations early in your next engagement. I bet you will find, as I have found, that this helps get everyone on the same page and it removes some of the mystery about SharePoint that can cause anxiety for team members. You might build on to this session as well by deploying a pilot – another expectation management tool that is a favorite of mine on almost any project. You could even provide team members with a quick reference guide similar to what I discussed in Chapter 5, and they can use this to explore the pilot environment on their own.

The combination of these techniques can help set your client’s expectations early. And the closer the expectations of the team members and other stakeholders align with your expectations, the greater the likelihood is that your project can be successful.

Inside Story: Notes from the Field

A few years ago, I engaged with a major construction company to help them build a vision and strategy for where they wanted to take SharePoint. They rank as one of my favorite clients for several reasons, starting with how great they are to work with through to their passion for technology. They have technology at the forefront of their operations, delivering business value, anticipating new opportunities, and aligning it with how their users need technology to support their jobs. What I love the most about them is how the business drives technology, and so they always align technology decisions with business value.

They also did a great job growing their SharePoint service to provide functionality to the business. Their challenge in deciding where to grow and extend SharePoint arises from the diversity of their business. They range from major industrial construction projects such as arenas and oil refineries to residential construction projects such as houses. On the surface, it may not seem as if technology would play a large role beyond managing blueprint files and tracking tasks, but it does, and their technology decisions largely focus on helping them achieve competitive advantages.

I, of course, do not want to reveal details about their competitive advantage, but I do want to tell the story about how I helped them progressively expand and grow their SharePoint service to provide additional capabilities that could work to their advantage. For starters, I had to stabilize the platform – they were a couple service packs behind, due mostly to some of the customizations they made that broke when they tested applying the patches. They were using SharePoint as a large document repository and document collaboration workspace, and they customized many aspects of SharePoint to address custom security requirements or to implement custom document control processes.

My next order of business was to get different development groups communicating with each other, sharing ideas and best practices. I could not have one group developing components that would prevent operations from patching or upgrading the farm or that would interrupt the performance levels for other groups. Some of their developers suggested that we segregate the farms to make their job easier, but I resisted because I knew through experience that this would only provide short-term gains at the expense of long-term sustainability and maintenance. Instead, I worked on developer processes and involving architecture reviews of custom applications early in their design and development stages.

With a stable platform and several groups working on different yet compatible custom applications, they were trending well toward growing and expanding the service beyond document management and collaboration. One of the projects was to replace the intranet by deploying the web content management (WCM) capability within SharePoint. The business driver for this initiative was to take advantage of modern web technologies to enhance the communication experience, while also aligning the intranet and document collaboration on a common platform. This allowed for rolling up content across the intranet and it simplified the mobile browsing experience.

Mobile was the next area of expansion. They already had a mobile experience, but they were working on expanding it to expose additional functionality beyond accessing content, such as interacting with a workflow to support business processes on different job sites. This required infrastructure to provide external access and handle the extra load from the mobile requests. It also required resources to process things such as InfoPath forms and workflow logic. They had to plan for this growth, both for the budget and for the operational capacity to physically do the work.

From there, they also had a work stream focusing on SharePoint MySites. They wanted to expand into this area, not based on some social computing platitude, but based on actual business requirements to provide everyone with a personal portal. The business needed a single gateway for managing business processes such as vacation requests and training bookings, and the SharePoint MySite capability provided the base portal functionality that they could use to develop and host the rest of the application.

I like this construction company example of how they grew their SharePoint service because it illustrates a steady progression of growing and expanding a SharePoint service into many areas. However, what I like the most is that a business need or opportunity drove every decision to grow the service. They did not simply enable capabilities just to make a popular feature available; they planned their growth based on business drivers. The operations team started with a basic SharePoint deployment consisting of a small farm that hosted collaboration sites. They did not need to over-architect that farm to plan for anything and everything; instead, they continuously added on and expanded that farm as additional needs arose.

Wrapping Up

In this chapter, I discussed how to plan for growing your SharePoint service, including considerations to scale for availability, general infrastructure components, and the server roles in a SharePoint farm. I looked at how you can evolve and grow your SharePoint service over time as the usage pattern changes, and how this eliminates the need to feel constrained or to over-architect your farm upfront.

Enhancement requests can involve more than growing your existing SharePoint service, as some might include deploying service and feature packs or even upgrading to a newer version. In the next chapter, I discuss how to plan and prepare for upgrades and patches. I pay extra attention to techniques to take advantage of structures within SharePoint that you can use to lower your risk against interfering with cumulative updates, service packs, or version upgrades.