SharePoint Governance Architecture

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.

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, you spend probably 80 percent of your 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.