SharePoint On-Premises and Hybrid Multi-Farm Scenarios, Part 2

Last week we began a discussion of multi-farm environments.  We examined the first two important steps in architecting an effective, reliable, and compliant SharePoint service:

You can check out part 1's mult-farm environment discussion here.

Today we turn our attention to the challenges that occur when requirements can only be supported with an additional farm.

Architect Solutions to the Challenges of a Multi-Farm Environment

If you do, in fact, decide to support the requirements of your scenario with an additional farm, you’re going to be assuming cost and risk as well.  Yup, that’s correct.  By “doing it right” from an architecture approach, you’re introducing new costs and risks.  So these need to be considered, earlier, in the cost-benefit-risk assessment.

The sad reality is that if you have more than one site collection in SharePoint, out-of-box tools and functionalities start to degrade in their ability to support even the most fundamental requirements. 

Take navigation as an obvious example. Have more than one site collection?  Try presenting it to users with an out-of-box capability of SharePoint that dynamically adjusts to your environment.  Doesn’t work.  Should.  Should have for 13 years. Doesn’t. User and group management.  Yuck.  Auditing and insight. Nope.  The list goes on. 

And that’s just for more than one site collection.  When you have more than one farm, particularly a hybrid (e.g. Office 365 + on-premise) service, SharePoint supports very little of what you need. 

So your service architecture needs to address the limitations of the platform.  Service architecture, in my lingo, means the entirety of your technical, logical, information, resource, infrastructural and service delivery architectures.  The service architecture drives how all of the pieces fit and play together, and one component of the service architecture can “make up” for deficiencies, challenges, costs, or risks introduced by another component of the service architecture.

Navigation, again as an example: Your information architecture, and the governance of it, can be architected to provide a universal navigation that is presented to users regardless of how many site collections, web applications, or farms exist.  SharePoint itself won’t help much, but either manual configuration (which I do more regularly than not), scripted management, custom navigation providers, or third party tools can be added to the service to make it work, and work really well.

Administrative deficiencies in multi-farm scenarios can be addressed with process, scripts, or third-party administrative tools which, in my experience, are almost always worth their weight in gold.

So one of the tricks that we must do as SharePoint professionals is to elevate ourselves beyond being simply SharePoint architects, to being business solution architects—to help the business fully identify its requirements—and service architects, who can put together lots of pieces (manual, scripted, custom, third party, and SharePoint itself) to deliver as service that provides the solution.

At this point in the discussion, we’ve addressed the approach to determine whether a multi-farm scenario is prescribed to meet the requirements of a particular workload (last week’s article).  Now we’ve highlighted that by incorporating multiple farms into your logical architecture, you are introducing additional risk and cost. 

You Can't Have It All

That risk and cost has to be balanced against the original requirements that drove to a multi-farm logical architecture and, in the end, you can’t have it all.  Something has to give.  You either accept costs and risks (and work to mitigate those) for an architecture that supports the requirements of the workload, or you opt to stick with a single farm and accept the risk (and potential cost) of doing so.

Generally speaking, it’s not IT’s role to make the decision. IT, business, and compliance (legal, security, HR, etc.) need to make the decision together.  It’s about informed compromise, so that everyone gets on the same page.

In following “episodes,” we’ll dive into specific scenarios that drive to a multi-farm architecture, and the specific challenges and potential solutions for those scenarios.