Governance is the cornerstone to any successful SharePoint implementation. Without it, you are doomed to fail eventually—a lesson that many organizations learn the hard way.

Because governance matters so much, there is a lot of information about it, starting with the TechNet SharePoint Server 2010 Governance Resource Center. There is no shortage of governance resources, from SharePoint MVP blogs to SharePoint Pro magazine and beyond.

Many of these resources focus on how to create a governance framework: how to assemble the people, policies, and procedures and how to develop a governance plan. But all too often, such discussions leave out a fourth equally important component of governance: technology.

You must understand the technology that you are trying to govern; you can’t ask it to do something that it cannot do. And you should use the technology to facilitate governance. In this first of a series of articles, I will explore the technical side of governance and thereby answer several vital questions:

  • What does a governable SharePoint implementation actually look like?
  • What is the physical and logical architecture of such an implementation?
  • How many farms, servers, web applications, content databases, site collections, and sites does such an implementation have?

The initial answer to all three questions is, unfortunately, “It depends.” The answer depends not on SharePoint, but on what you are trying to achieve by using SharePoint. The best way to get to the answer that applies to you is to follow my four-step Architecting Governance process. By following this process, not only can you answer the previous question, but you will have a logical, physical, and governable architecture that meets your business requirements.

Given the limitations of space and time, this article will focus on the process itself, which involves four major steps. In future articles, I will explain how you can apply the process to specific scenarios, to gain prescriptive guidance towards successful architectures. And I will show you how to use the technology to automate and enforce your governance policies.


Step 1: Define Your Requirements

Step 1 of Architecting Governance is all about requirements. As a consultant, I spend probably 80 percent of my time helping customers to define requirements and develop discipline around requirements gathering. After all, you must understand the requirements for any solution before you can effectively design that solution. SharePoint is no different.

The problem that I observe is that SharePoint implementations involve a lot of requirements. So I find it helpful to categorize them, and then identify which categories are salient at each step in the Architecting Governance process. I suggest that you group your requirements into these categories:

  • Business requirements—These are the requirements that really matter. They define the business purpose of the solution that the customer is asking you to create. Whenever possible, avoid polluting business requirements with technical requirements. More often than not, technical requirements are artificial. When a business customer says, “I need a sub site that does x,” or “I need a button that does y,” that customer is casting themselves as a technologist—a solutions developer. Encourage them to take a step back and describe the desired result (x or y) without mentioning technology. Let the technical solution be developed by those who know the technology.
  • Technical requirements—Occasionally, technical requirements must be considered. For example, if your mobile sales force is going to use their iPads to access the solution that you are providing, then the ability to access the solution from iPads is a valid technical requirement. Such technical requirements more often relate to architecture—interoperability with other solutions—or infrastructure than to functionality or usability.
  • Project requirements—These requirements relate to the creation of the solution, not to the business purpose of the solution. Budget and deadlines are prime examples of project requirements.
  • Information-architecture requirements—Information architecture, in its most traditional definition, relates to how content is described, organized, and discovered.
  • Information-management requirements—Information-management requirements define how the content is managed over its lifecycle: how is it created, maintained, and archived or deleted. These requirements relate to security, records management, auditing, and compliance.
  • Service-management requirements—Behind the solution, the content, and the information is the service itself. Service-management requirements describe IT assurance expectations: recovery, availability, and performance. These requirements lead to service level objectives (SLOs) or service level agreements (SLAs).

Categorizing requirements is valuable for several reasons. First, you can identify the dependencies between requirements. This ability allows you to proceed through the requirement-gathering process in a logical manner.

Business requirements and technical requirements must be defined carefully and understood clearly before you can effectively elicit other requirements. After you have defined the solution, you can identify the types of information that are associated with it. This exercise drives you to find the information-architecture and information-management requirements.

Business, technical, and information-management requirements determine the service management requirements. All are affected by project requirements such as budget and timelines, and you might need to adjust project requirements to accommodate other categories of requirements.

An important take-away: Discussing information management or service management requirements before you have clearly defined the business and technical requirements makes little sense.

And if the process is undisciplined and additional business or technical requirements are introduced, you will need to revisit the information-architecture, information-management, and service-management requirements.

The second reason why categorizing requirements is valuable is that it allows you to proceed more effectively to the next steps in the Architecting Governance process, in which you will focus on supporting the information-and service-management requirements.

There will continue to be a two-way relationship with those pesky project requirements, but at least you can set aside business and information-architecture requirements, which will have generated the information- and service-management requirements. You’ll return to the information-architecture requirements in the last step of the Architecting Governance process.

After defining requirements, you can begin to design a solution that meets those requirements. This phase involves the evaluation of options for building or buying the solution. You know you’re doing this part correctly when—at least once in a while—it’s determined that SharePoint is not the right solution for a particular requirement.

After all, we can agree that SharePoint is not the silver bullet for every business need, can’t we? If your process is strong enough to overcome loyalty to and enthusiasm for SharePoint when it’s simply not suited for the job at hand, you know you have a good process!

We won’t spend any more time on the evaluation of technical options. Because this is SharePoint Pro magazine, we’ll assume that, for this particular need, SharePoint is the best solution, and we’ll move on to Step 2 of Architecting Governance.


Step 2: Align Management Requirements with Controls and Scopes

In Step 2, we focus on determining how to architect a SharePoint service to support your requirements, specifically those in the service- and information-management categories.

First, you must identify what I will call SharePoint management controls. A management control is a configurable setting that has some effect on SharePoint manageability, and therefore on SharePoint governance. Let’s take a simple example.

One of your service-management requirements should relate to storage of content (i.e., how much storage the content that is associated with the solution will consume). The requirement to support a specified amount of storage is implemented by quotas, of course. Quotas are a management control—a setting that you can configure to support a requirement.

Now that you’ve located the management control that supports your requirement, you must identify the scope of that control. SharePoint farms have a physical and logical architecture. The logical architecture is a hierarchy of farms, web applications, content databases, site collections, sites, lists, and libraries.

Web applications have zones and typically consume one or more services, such as search or metadata. (This logical hierarchy is shown in Figure 1.) The physical architecture relates to the servers in the farm and the distribution of services across those servers. In other words, which servers host web sites, which host services such as search, and which host SharePoint databases?

Figure 1: SharePoint’s logical hierarchy
Figure 1: SharePoint’s logical hierarchy


Management controls are typically scoped to one, and only one, container in the SharePoint logical or physical architecture. Quotas, for example, are scoped to site collections. You can set a quota for a site collection but not for a child site or an entire web application. Nor can you configure a storage limit for an individual user within a team site collection; the out-of-box quota applies to all content in the site collection, regardless of who creates the content.

Scope is an absolutely crucial concept because it determines whether you need more than one of any object in the logical or physical architecture. If the Human Resources (HR) and Engineering teams require distinct quotas (for example, engineers need more storage to support large CAD documents and images), then you have only one option. To support those disparate requirements, you need two scopes—one for HR and one for Engineering—to which you can apply different quotas. And that means that you must have two site collections.

If every solution in your enterprise has identical information- and service-management requirements, then you can get by with a single farm, a single web application, a single content database (subject to a sizing guidance of 4TB) and a single site collection. But you’re highly likely to have solutions that have different information- and service-management requirements, necessitating more than one of many or all of these scopes.

In fact, so many management controls are scoped to site collections that I like to refer to site collections as the administrative container in the SharePoint architecture. Many service- and information management controls, including quotas, ownership (Site Collection Administrators membership), tenancy, user and group management, auditing, locks, sandbox solutions, and search settings, are scoped at the site-collection level.

You also must consider the capabilities of the management control. What is possible, and what is not possible? For example, assume that you have the wild service-management requirement to back up data in a large solution every minute. Assuming that the content is of any size, you simply are not going to be able to meet that requirement by using SharePoint backup APIs.

Another example is sandboxed solutions. If you have a service-management requirement to isolate custom code, then you can configure a sandboxed solution—a management control that scopes to a site collection. After you have enabled sandboxed solutions, a site collection administrator can upload solutions to the sandbox and activate them. There is no out-of-the-box capability to add a workflow whereby another, higher-level administrator can approve the solution before it is activated.

A key concept here is out-of-the-box. Although SharePoint management controls might have certain limited scopes and capabilities, sometimes you can build or buy tools that extend those scopes and capabilities.

So if you run into a situation in which your information- or service management requirements drive you towards an unacceptable architecture, you can choose to work around the limitation, build or buy code that overcomes the limitation, or return to the question, “Is SharePoint the right technical solution to address the requirements?”

Step 2 is the nitty-gritty part of Architecting Governance. You must determine how SharePoint can support your information- and service-management requirements through out-of-box or extended manageability controls, and which logical and physical architecture is necessary to scope the settings that you require.

I will dive into numerous examples of how to succeed with this step—and how to fail miserably—in future articles.


Step 3: Align Business Requirements with Controls, Features, and Scopes

After you put a set of requirements through Step 2, you typically will have an architecture that defines farms, servers, web applications, content databases, and site collections. Occasionally, your architecture will dive deeper into sites, lists, and libraries. The resulting architecture will support your information- and service-management requirements.

You can then further refine that architecture to support business requirements—specifically those functionality requirements that are implemented as a feature, template, list, library, or site definition.

For example, suppose that a business requirement can be supported by providing the leader of a team site with a blog. SharePoint implements blogs as a site definition (or template), so your logical architecture must include a site for the blog—typically, one that will be distinct from other collaborative content on a team site.

Step 3 is similar to Step 2, but you’re using a different set of requirements at this point, to drive the lower levels of your logical architecture. You did not consider business requirements in Step 2, although these requirements informed the information- and service-management requirements that you did consider.

When you complete this step, you will generally find that you have added some child sites, lists, and libraries to the logical architecture that you produced in Step 2. Step 3 typically does not involve modifying the farms, servers, web applications, content databases, or site collections in the architecture.


Step 4: Overlay Information Architecture and Manageability

As you can imagine, even a simple SharePoint implementation is likely to have more than one site collection, web application, and farm. And as soon as content is distributed across more than one site collection, web application, or farm, or across more than one content database or server, working with SharePoint becomes more difficult.

First, navigation becomes a challenge. When you create content within a single site collection—a child site, for example—you can add links to the parent container so that users can navigate easily. However, when you create a second site collection, no such navigation links are created. You must either manually manage navigation or build or buy a tool that manages and presents a navigation structure.

Administration also becomes more difficult. If a user needs access to content in each of the two site collections, then the user must be added to each site collection individually; identity management is scoped at the site collection. If you need to pull an audit report of content, you must pull reports from both site collections; auditing is configured and reported at the site collection scope.

Because site collections are, in my words, the administrative container of SharePoint, your administrative burden increases as soon as you have more than one.

To address administration and management of a SharePoint implementation with more than one farm, web application, content database, or site collection, Windows PowerShell is your best friend. PowerShell can iterate (i.e., loop) through your architectural elements and can perform repetitive tasks quickly and easily. Several third-party tools also give you a single-pane-of-glass view of your SharePoint service, regardless of how complicated its logical and physical architecture might be.

When you architect a governable SharePoint implementation, you will almost certainly end up with one that is more difficult than you’d actually prefer to manage on a day-to-day basis. A disconnect exists between governance and ease of use, and that disconnect is an unfortunate side effect of using a platform with limited but rich features to support an unlimited number of business requirements.

Workarounds, PowerShell, and extensions to SharePoint become crucial. Luckily for us all, SharePoint has an extraordinary community of consultants, developers, project managers, IT pros, MVPs, and ISVs to help us succeed.

In this article, I’ve outlined the process through which you can get from requirements to a governable SharePoint architecture. Half the story is what SharePoint can and can’t do, and how it was designed. The other half is what you’re asking SharePoint to do.

There are myriad examples to illustrate that those two things don’t always align as neatly or easily as you would hope. I’m not saying the process is easy, but it is necessary. In an upcoming article, I’ll show you several common examples of real-world scenarios and how they affect your logical and physical architecture.