Yesterday, SharePoint Pro hosted a virtual event entitled, Managing a Multi-Farm, Multi-Location SharePoint Environment, with sessions focused on architecture (me), governance, mobile access, and more. There were a lot of questions around multi-farm scenarios: when they are necessary, how to architect a service that includes multiple farms, etc. And while I’ve addressed these topics once or twice over the years, I thought it would be helpful to update our readers with some of my current guidance.
Multi-farm scenarios are a complicated and ugly discussion, because they generally involve stretching SharePoint into models that it simply wasn’t really designed to support. Out-of-box tools quickly fail to deliver what any normal set of business requirements would mandate. So you end up having to spend more time and money to implement, support, manage, and present your SharePoint service to your business customers.
Because it’s a complicated topic, I’m not going to be able to cover everything in just one article, so I’ll come back and extend the conversation over coming days.
Let’s approach the issues this way: First, this week, let’s lay out the broad guidance and approach to evaluating business requirements and technical capabilities of SharePoint to determine when a multi-farm scenario is required. Then, let’s talk about what a messed up world it can be when a multi-farm environment is required. Then, over a series of articles, we’ll look at specific, common scenarios, the challenges they present, and the ways you can survive in a multi-farm environment.
Gather Requirements
With any effort, you need to start with the business requirements. As a consultant, the vastmajority of my time is spent helping customers enumerate a rich set of business requirements that address value proposition, functionality, information management, service management and project management (budgets and timelines).
If you don’t identify a full spectrum of requirements, you introduce risk. Overlooked requirements come back later to bite you in the form of, “Oh we assumed…” or “Oh we didn’t know that by doing x that y could happen”, etc.
Align Technical Capabilities of SharePoint with Requirements
I’m keeping this discussion quite simple by assuming that you’ve already identified that SharePoint should even be considered to address the requirements. The next step will be to dig deeper, and to identify just how SharePoint can be architected to support the requirements.
This is the “SharePoint Architecture” step. Conceptually, you should not be asking “how do we support this set of requirements in our existing farm.” Instead, you should be asking “How would we architect SharePoint from the bottom-up to support these requirements.” There’s an important distinction between those two questions, which we’ll come back to in a moment.
Within this step, you must identify controls and scopesfor managing the service to meet the requirements. A control is something you can configure or achieve. You might call a control a switch, a setting, a functionality or a capability. A scope is a logical, resource, or information architecture container that exposes that control.
The real problem is that certain controls are scoped only at the farm level. There are certain configurations, characteristics, settings, functionalities, and capabilities that are applied to the farm as a whole. The farm can either be A or B. It can’t be both A and B. And you can’t “subdivide” the farm—there’s no scope below the farm level (e.g. at the web application or site collection level) that allows you to have both A and B existing within the same farm.
So as you align SharePoint’s technical capabilities with your requirements, you are asking, “How would we architect SharePoint to meet our requirements?” You might decide that to meet a certain requirement, a certain control would need to be “B.”
If your existing SharePoint environment is made up of a farm that is “A”, you now have a tough decision. You either add a farm to your service, so that you have a SharePoint environment that includes a farm with “A” and a farm with “B”, or you go back to the business and tell them that the requirement that led to the need for “B” cannot be met.
There will usually be a difficult discussion that involves the cost and benefit of the additional farm with “B” versus the cost and risk of nothaving the farm with “B”. Sorry, but there’s no easy answer here. The business has to make the decision, and your job is—at a minimum—to equip the business with enough information about options and their costs, benefits, and risks to make that decision.
And here’s why you must have such a rich set of requirements, up front. If you’ve overlooked some requirements, you might have decided that the requirements you dididentify could be supported fully on your farm with “A.” Later on—perhaps too late—you identify a requirement that you had overlooked, and realize that you architected the service incorrectly, which means that there is increased risk and cost—you cannot meet that requirement—or a need to re-architect your service. Neither is a happy place to be.
Now I know I’m being high-level talking about “A” and “B”, and that’s where we’ll need to get into details about various scenarios and typical requirements that lead to multi-farm, “A” and “B” architectures. Those scenarios include:
- Public facing website on SharePoint
- Supporting the development and/or deployment of custom code or third-party extensions (this is pretty much every on-premise SharePoint environment, by the way)
- Disaster recovery
- Extranet
- Business-critical workloads
- Enterprise services (Search, Social, Metadata, BCS…)
- Hosting significant, line-of-business applications on SharePoint
- Hosting functional applications involving custom code (full-trust), or third party tools, on SharePoint
- Remote locations, away from the datacenter, where data availability is required
Each of these scenarios presents significant requirements that would put you in the tough spot of deciding, “do we meet these requirements by adding a farm, or do we assume the risk of not meeting these requirements?” So you need to understand the requirements these scenarios present to allow the business to make that decision.
Again, we’ll come back and address these scenarios individually in the near future.
So, at this point in the discussion of the high-level approach to determining whether a multiple-farm environment is needed, let’s assume you’ve decided it is. Unfortunately, the “fun” is only just beginning, because you’ve introduced a world of new challenges to solve.
To be continued…
