Information Architecture and Management Controls in WSS 3.0 (Governance 2 of 5)

Preface

With WSS being so flexible as a platform and as a collaboration I often get people asking me how they should architect their deployment.  They ask about what you can do with it.  The possibilities are so open as a platform it's tough to explain.  This paper around the information architecture and building on the managability controls really begins to help you understand what you can do with the base platform.

This paper by Dan Holme will explore four common usage scenarios such as Light Document/Content Management, Collaboration, Meetings/Workspaces and Individual expression. He explains the management/governance controls around each of these scenarios.  I hope you find it insightful.  There's a lot of good guidance based on the experience of MS IT and you'll see some of my recommendations and experience coming out in this paper as well. 

Enjoy.

Joel Oleson
Sr. Technical Product Manager
SharePoint Products and Techologies Team

Supporting Information Architecture with Windows SharePoint Services Manageability Controls 

Date published:

June 2007

Summary:

Microsoft® Windows® SharePoint® Services 3.0 enables individuals, teams, departments, and organizations to rapidly deploy solutions that support the knowledge sharing and collaboration required by information workers in the 21^st century. The value that Windows SharePoint Services delivers often leads to its rapid adoption by organizations with Web sites that host diverse content and collaborative activities. IT organizations can support these activities effectively by implementing and governing Windows SharePoint Services in a way that takes advantage of the manageability features of each component of Windows SharePoint Services 3.0 architecture, and by aligning those features with the organization’s information architecture.

The art and science of planning a manageable implementation of Windows SharePoint Services 3.0 comes down to understanding the following:

·         Which Windows SharePoint Services 3.0 usage scenarios belong together.

·         Why they belong together.

·         How to configure Windows SharePoint Services 3.0 to best support those usage scenarios.

To find the answers to these questions, you must first analyze your organization’s information architecture.

This white paper is the second in a series that guides an organization through designing and implementing a governed, manageable Windows SharePoint Services 3.0 environment. Reading each of these papers in the order listed below is recommended:

1.        Windows SharePoint Services Manageability Controls (http://go.microsoft.com/fwlink/?LinkId=92895&clcid=0x409)

2.        Supporting Information Architecture with Windows SharePoint Services Manageability Controls (http://go.microsoft.com/fwlink/?LinkId=92896&clcid=0x409)

3.        Implementing Windows SharePoint Services Governance (http://go.microsoft.com/fwlink/?LinkId=92897&clcid=0x409)

The three white papers, as well as other resources related to the governance of SharePoint Products and Technologies, can be found at the Governance Information for SharePoint Server 2007 landing page (http://go.microsoft.com/fwlink/?LinkID=90916&clcid=0x409) on Microsoft TechNet.

To get the most from these white papers, you can familiarize yourself with Windows SharePoint Services 3.0 by using product documentation contained in the Microsoft TechNet Windows SharePoint Services 3.0 Technical Library (http://go.microsoft.com/fwlink/?LinkID=73952&clcid=0x405).

Examining Your Information Architecture

Microsoft® Windows® SharePoint® Services 3.0 is designed to host content and applications that support such business needs as communication, collaboration, analysis, process, and knowledge management. Across those diverse functions, not all content is created equal. Imagining a spectrum of content characteristics, as suggested by the following figure, is a useful first step in examining your information architecture.

These content characteristics are interrelated. Content with a long-term lifespan is typically more structured and process-driven, and is not meant to support collaboration. An example of such content would be a departmental Web site. Ad hoc content is typically placed online to support collaboration and, because of its dynamic nature, is not intended to remain available indefinitely. The documents on which a team collaborates fall into this category. Content might migrate between these two broad categories: When a project is completed, its final documentation might consist of information that the organization wants to maintain for the long term.

Where the content that your organization hosts in Windows SharePoint Services 3.0 falls in this spectrum depends primarily on characteristics unique to your business or industry. For example, content related to a project for improving service at an airline might be informal and highly collaborative. Content related to delivering service to a patient at a health care organization might be much more process-driven in order to comply with regulations and privacy guidelines.

Information Architecture and Content Management

Your information architecture provides guidance as to how each type of content should be managed in a Windows SharePoint Services environment. Examine the following content management considerations in the context of your own information architecture:

·         Content creation: To what extent will the process be managed to create high-level content, such as a new Web application, site, or site collection? It is likely that there will be scenarios for both the tightly and loosely managed creation of the following high-level components:

o        Web sites that represent a business unit, division, group, or department, which are typically well-managed and will be carefully provisioned, designed, and consumed by a broad audience.

o        Sites for individual users, such as blogs, which will be provisioned by request of an authorized user.

o        Sites for teams and meetings, which will be more informal to allow users to create sites with minimal change management.

·         Content management: How closely will the organization manage lower-level content, such as libraries, lists, items, pages, and documents? Content that is meant for broader consumption or permanence will often be added, removed, and modified in such a way that ensures the content is accurate, compliant, and belongs where it is placed. The content typically is reviewed before it is made visible in higher levels of the intranet and will be subject to content approval workflows. Generally, content that is useful to smaller groups, or is of a more temporary nature, will be less closely managed.

·         Relevance to search: How do various types of content in your organization relate to each other in the context of search? Remember that Windows SharePoint Services 3.0 supports search from the top-level site in a site collection to all sites within that collection. You cannot search across site collections without implementing Microsoft Office SharePoint Server 2007. Therefore, you should group content that should be accessible as the result of a single search. For example, you might decide to place departmental sites in a single site collection, so that users can search for content across all departments.

·         Content structure: How highly structured and described is the content? Effective knowledge management, which leads to effective search and content analysis, relies on content being structured and described by metadata. Large organizations have knowledge management functions that help the organization understand and describe its content, so that the content can be discovered, reused, and leveraged in the future. Smaller organizations should invest effort to attain an understanding of their business so that information can begin to be described by metadata. Certain types of content, particularly more informal content, might not require the level of detail or structure required by higher-level, organizational content.

·         Content lifespan: How long, in general, will the content be useful and available? Are there liability and compliance issues that drive how long content is maintained? Content that is valuable to an organization in the long term will be maintained differently from content related to a short-lived project or meeting.

·         User control: What level of access and ownership do users have regarding content? Enterprise, divisional, and departmental content will be maintained by a small group of individuals who understand and can support content management requirements, but typically, all users will be able to read such high-level content. As content becomes more directly relevant to the day-to-day job tasks of teams and employees, users will have more ability to contribute to, or even own, Windows SharePoint Services content such as lists, libraries, or sites. However, content that is specific to a team or meeting might be more restricted as to its general visibility across the organization.

Categorizing Content and Aligning Content with Windows SharePoint Services Manageability Controls

Based on the content characteristics and content management considerations discussed above, you can begin to categorize the content that will be hosted in your Windows SharePoint Services infrastructure into logical groups that can be supported by the manageability controls offered by Windows SharePoint Services. If you are not familiar with Windows SharePoint Services manageability controls or the structure of Windows SharePoint Services components (server farms, Web applications, site collections, and sites), reading the Windows SharePoint Services Manageability Controls (http://go.microsoft.com/fwlink/?LinkId=92895&clcid=0x409) white paper before proceeding with this paper is recommended.

The following will provide an example of how an organization might categorize its content in order to align its information architecture with Windows SharePoint Services manageability controls. However, as suggested earlier, your categorization will depend upon your business and industry.

Organizational and Divisional Content

Organizational and divisional content is business content related to the enterprise as a whole and to permanent organizational divisions such as business units, regions, departments, groups, or functions. It is the type of content that Chief Knowledge Officers and knowledge management professionals are most concerned with, as it will have value over the long term, and should be available for reference as a repository of corporate knowledge. Therefore, content in this category will be structured, managed, and process-driven. Not every user will be able to create or edit content. The types of information that will fall into this category typically include:

·        Divisional, departmental, or functional sites that are used to communicate within and across organizational containers. For example, a human resources site with information about benefits or a site with guidance about the organization’s Six Sigma projects would fall within this category.

·        Divisional, departmental, or functional wikis that can be leveraged by a team to capture knowledge in a less structured manner, but with a goal of mid- to long-term knowledge retention.

·        Document libraries used for long-term document management. For example, a document library of marketing communications or proposals and contracts would have long-term value to the business.

·        Content that must be retained because of business needs or legal requirements. Management of information within this category is controlled by both automated and human processes. Users must check out documents and pages in order to make changes, and the number of users capable of making changes is limited. Modifications to content on these sites are typically subject to workflow and content approval by an editorial or publication staff. Also, content is removed manually—it is not automatically purged based on an arbitrary expiration timeframe. As a method of encouraging proper use of organizational and divisional knowledge sites, quotas can be set to limit addition of content to sites.

To support organizational and divisional content, therefore, you might structure Windows SharePoint Services components as follows:

·         Server farm: It is likely that content related to an organization and its divisions will be centralized and hosted on a single server, at least before taking geography into account. Content for business units located in different geographical locations might be better supported by server farms specific to their location, particularly if network connectivity between locations is limited.

·         Web application: The decision of how many Web applications to implement will be driven by several considerations. First, do you want to enable or disable anonymous access? Second, will you need to make some features available to one division that should not be available to another division? Typically, one Web application will be sufficient, but you might choose to have one Web application for the organization and separate Web applications for each division. The Web application’s recommended name and URL should match your organization’s intranet name (for example, http://intranet.contoso.com). We will refer to this Web application by a generic URL, http://Company.

·         Site collections: By hosting all divisions within a single site collection (which thus mandates a single Web application), you are able to provide a unified search experience for content across those divisions. In a small business, a single site collection might work well, but several factors might compel you to use separate site collections, even though doing so will prevent a unified search.

First, separate site collections enable the assignment of unique site collection administrators, users, and groups. In a larger or more decentralized enterprise, you might have too many divergent access requirements for content in this category.

Additionally, the use of a single site collection results in all content sharing a common content database, quota, and settings for site use confirmation and deletion. Therefore, storage management and cleanup could be a problem. In larger enterprises, unless very little content is stored, data management from a back-end perspective and content management from an end-user perspective could be hampered by having all data in a common content database. Therefore, a single site collection is unlikely to support the broader scope of business requirements for organizational and divisional content.

·         Sites: Within the site collection, create a top-level site for the topmost division hosted by the site collection and, below that, one site per logical organizational division. Your site structure might end up reflecting your corporate or organization chart.

Within that structure, the following prescriptive guidance will illuminate how you can leverage Windows SharePoint Services 3.0 manageability controls to support organizational and divisional content:

·         Self-service site creation: Disabled. Creation of highly structured content, such as departmental sites, should not be permitted without a process-driven workflow.

·         Permissions, authentication, and anonymous access: A limited number of users are given the ability to create, modify, and delete content. Other users have read permission. A Web application hosting departmental sites might allow anonymous access for intranet visitors. Alternatively, departmental sites might include the Authenticated Users identity in their Visitors group to allow any user with an Active Directory (AD) account to access the content, but to block anonymous access. Certain types of organizational and divisional content, such as a document library that contains contracts with customers and vendors, will be restricted as required to support business needs.

·         Document check-out and content approval: Required. In order to ensure that content is reviewed prior to release, a workflow or content approval process should be implemented.

·         Content types: Defined. Because content types ensure the consistent management of content, which itself facilitates analysis, search, and maintenance, content at this level needs to be highly structured, with well-defined metadata and process.

·         Quotas: Configure an initial quota of 15 GB for the site collection and dedicate the division or department to its own content database. This quota is based on the amount of time it takes to back up a site collection, and the performance impact of such long-running processes. If the quota is met, perform an audit of the site collection to determine whether the sites within the site collection should be split across site collections in separate content databases.

Site collections that need to more than 15 GB should be in their own dedicated database, and care should be taken to reduce long running operations that could cause performance issues, such as large site collection deletions and site collection backups.

·         Content expiration: None. Content in this category is, by definition, long term. The best-practice recommendation is to directly manage content expiration by examining which sites have outdated information and manually deleting that content.

·         Content databases: Initially one per Web application if you start with a single site collection. If you anticipate more than 100 site collections, you should look at load balancing the creation of the site collections across multiple content databases. There is no hard limit to the number of databases you can have for a Web application; however, the recommended maximum from a connection perspective is 100. When you account for flexibility in database mirroring and for log shipping failover strategies, the recommended limit is 29.

A typical requirement for organizational and divisional content is an effective search capability. Because Windows SharePoint Services 3.0 provides search only within a site collection—from the top-level site and recursively through its child sites—and not across site collections, you will not be able to support search across divisions if they are hosted in unique site collections, Web applications, or server farms. In those situations, the best you can do is to provide a directory that facilitates navigation across divisional sites. Such a directory is discussed in the white paper Windows SharePoint Services Governance. Office SharePoint Server 2007 provides significant added value for this specific scenario, as it enables search across site collections.

Information Worker Collaboration

Projects and informal teams of information workers benefit from the ability to collaborate online. Governance of SharePoint Products and Technologies should support such needs as appropriate for the organization, but should ensure that collaborative content is created and managed efficiently. The number and size of team sites in an organization can grow, sometimes rather quickly. As projects are completed, team sites might be abandoned. As teams reorganize, they might create new team sites or expand old team sites to include additional users and content.

The key characteristic of content in this category is the content’s limited lifetime. A project or informal team might require the ability to collaborate for days, weeks, months, or years, but at some point, the collaboration will stop.

Team sites are the most obvious example of sites that fall into the information worker collaboration category. These sites should be easy to create and should provide easy access to functionality required by site owners, who will range from power users to non-technical users. Quotas should create a balance between providing sufficient room for teams to store documents related to their projects and the practical limits of supporting a large number of such sites on the organization’s SQL Server storage infrastructure. Most important, to encourage proper use of sites in this category, you should manage the site lifecycle to ensure that site owners archive or remove content, or promote the content to a more long-term category, such as organizational and divisional content.

To support information worker collaboration, consider the following structural recommendations:

·        Server farm: Collaborative content such as team sites should be hosted on a server farm that is proximal to the team from a network topology perspective. A team in Singapore should not be accessing its team site from a data center in Berlin over an expensive frame relay connection unless WAN acceleration and optimization considerations have been made. A centralized farm is possible, but additional appliance or client solution costs are involved.

·        Web applications: Host team sites in one or more Web applications dedicated to team sites (for example, http://teams). Do not host team sites in the same Web application as organizational and divisional information.

The number of Web applications you implement to support collaborative content such as team sites will be based on the number of server farms hosting team sites. Additionally, you configure many manageability controls—including content expiration, Recycle Bin settings, and security policies—at the Web application level, so any management that leverages those controls will mandate unique Web applications.

For example, an organization might want to ensure that the intellectual property discussed by the Research and Development team is not accessible by contract employees, even if those employees are on the team. By configuring a Web application, security policies can be enforced to support that requirement.

Security policies can also be leveraged by investment banking and equities research companies that, in order to comply with the regulations of the U. S. Securities and Exchange Commission, must keep sites for the investment banking division and equities research division completely separate.

Web applications also support authentication provider configuration. Therefore, a team site that requires access by both users with Active Directory accounts and extranet users logging on with forms-based authentication should be hosted in a Web application separate from sites that require only one authentication provider.

Another manageability control supported by Web applications is content expiration. Whereas Office SharePoint Server 2007 provides rich functionality for managing content expiration, Windows SharePoint Services 3.0 supports only site-level use confirmation and deletion. The Web application configuration determines whether and when sites within the application are deleted. If different teams require different expiration policies, their content will need to be hosted in different Web applications.

·        Site collections: The definition of users and groups is managed at the site collection level. In addition, a quota template that is applied to a site collection will determine the quota across all sites and content within the site collection. Therefore, the best-practice recommendation is to create one site collection for each division, department, function, or team so that site collection administrators and user or group management can be specific to the site collection. The quota for the site collection can be increased if necessary, but the fact that Windows SharePoint Services 3.0 does not support search across site collections might drive you to implement a single site collection for teams, particularly in a server farm that supports a smaller number of users or teams.

·        Content databases: Content databases provide support for service level agreements (SLAs), as restoring the backup of a single content database is possible. Determine how many content databases are required based on the number of teams you plan to support, the projected size of each content database, and the time required to restore such a database given your recovery hardware and processes.

Manageability settings that are appropriate to configure for team sites include:

·        Quotas: Enabled. To determine the appropriate storage quota size, project the number and sizes of team sites you will support. Then, determine the number of requests for quota expansion to which you want to respond. For example, if you anticipate that 90 percent of your team site collections will use less than 400 MB of storage and the remaining 10 percent will use up to 500 MB, and you are willing to receive support calls from 10 percent of the teams, then you can set your quota at 400 MB. As 10 percent of the teams reach that limit, they will require attention, either in the form of an expanded quota or notification site administrators reducing the size of their site collections. Ultimately, you determine how much storage you want to allow per site collection, but you also might want to consider the cost of the support call versus the cost of the storage. Do not set the storage limit so low that the support call costs more than the storage itself. Hard quotas that are well-communicated can mitigate these types of calls.

·        Self-service site creation: Enabled. To reduce the burden on the team that supports Windows SharePoint Services, enable teams to create sites without administrative intervention or enable a support desk to provision sites and set up initial permissions. Alternatively, a survey or list with a workflow and e-mail notification can be developed to allow users to request sites and gather up-front data about the site request.

·        Content expiration: Enabled. The best-practice recommendation is to configure notification of site owners after a timeframe appropriate for the team (for example, 6 to 12 months). Configuring automatic site deletion is not recommended, because you might delete valuable content. You can migrate content that should be preserved to an application that supports organizational and divisional content.

Meetings and Very Short-Term Collaboration

Organizations can create SharePoint sites to provide rich collaboration for very short-term needs, such as to support meetings, surveys, and short-term collaboration on a document. Examples include sites based on the Meeting Workspace or Document Workspace templates, and custom sites that host surveys. As with the Information Worker Collaboration category, sites that host content in this category are often owned by non-technical users, should be easy to create, and should have quotas that restrict the site collections from growing out of control.

The structural implementation to support such content might follow these guidelines:

·        Server farm: Host content on a server farm that is proximal to the team from a network topology perspective.

·        Web applications: Host meeting and document sites in one Web application dedicated to such sites (for example, http://meetings and http://documents), unless there are differing security policy, authentication provider, or other requirements that would require multiple Web applications to support. Do not host these sites in the same Web application as organizational and divisional information.

·        Site collections: Within a Web application, you likely will not need to manage content in this category with settings applied to site collections. Therefore, you can host meeting, document, survey, and other short-term content sites in a single site collection.

Manageability settings that are appropriate to configure for sites in this category include:

·        Quotas: Configure a quota that prevents site collections in this category from becoming a place for users to share documents that have longer-term value. Remember to balance the need to restrict storage with the number of support calls you want to receive as users approach the configured limit.

·        Self-service site creation: Enabled. Sites in this category are generally informal and should be, wherever possible, as automated and responsive as possible to user need.

·        Content expiration: Content lifetime should reflect what “very short-term” means in your organization, and should be most closely aligned with the lifecycle of recurring meetings. If, for example, your organizational policies suggest scheduling recurring meetings for a maximum of 9 months, then that would be the site deletion window for sites with content in this category. Remember that you can move content to sites in other categories as its value or relevance changes. For example, meeting notes from old meetings might be promoted to a team collaboration site as a history of team activity, or to a long-term team library in a divisional site.

Individual Knowledge and Expression

Individuals are also the source of certain types of business information that has long-term value. An easily understood example of this information is a user blog. Organizations can use blogs as an effective, unstructured, easily adopted method of capturing knowledge. Employees can use blogs to record procedures they carry out, experiences they have worked through, and perspectives about the organization and its constituencies. Blogs can be a way for employees to share ideas about non-work-related topics that can unleash creativity and value in the workplace. A user’s My Site—a personalized portal provided by Microsoft Office SharePoint Server 2007—takes this concept to the next level with social networking and other enhanced functionality.

In organizations and industries where this content is appropriate to support, blogs and other such forums for capturing individual knowledge and expression are generally less managed than team or divisional content, as users should be encouraged to manage their own sites. Quotas are restrictive to encourage correct use of the service. The site’s lifecycle is not managed, so sites are not automatically expired, but the organization might choose to manually delete or archive an employee’s site after the employee leaves the organization.

The structure to support sites that provide for individual knowledge and expression is:

·        Server farm: Host content on a server farm that is proximal to the user from a network topology perspective.

·        Web applications: Host content in a single Web application separate from the other categories of content discussed above.

·        Site collections: If you are supporting sites of limited functionality, such as simple blog sites, you can host them in a single Web application. For more sophisticated individual sites, you might consider the structure used by Office SharePoint Server 2007 My Sites, where each user’s My Site is a unique site collection. This approach enables granular control of quotas and provides the possibility for each user to define users and groups and to provide access to their site collection.

Windows SharePoint Services manageability controls for sites that support individual knowledge and expression include:

·        Quotas: Configure a quota that prevents site collections in this category from becoming a team site or from becoming a place for users to share documents that have long-term value. Remember to balance the need to restrict storage with the number of support calls you want to receive as users approach the configured limit. You can also reduce support calls by communicating that quotas are hard limits that will not be increased.

·        Self-service site creation: Dependent on business process. You might want to provision user sites when an employee is hired and restrict that user from creating sites. Conversely, you might provision the top-level site for a user in a unique site collection and give that user Design permissions, enabling the user to create sites.

·        Content expiration: None. Organizations should maintain user sites according to the established information policy, not by time limits enforced on the site collection. An organization typically will manage content in user sites when the user departs the organization—archiving the site, relocating content with long-term value to other locations, and then removing the site.

Information Architecture and you

This white paper has presented guidance for examining your organization’s information architecture, categorizing content based on common content management requirements, and identifying how you can support categories of content by using Windows SharePoint Services manageability controls. The four categories of content outlined above—Organizational and Divisional, Team, Meetings, and Individual—are typical for many environments. However, you need to analyze Windows SharePoint Services manageability in light of the information architecture of your organization. Your business, industry, employees, vendors, and customers will affect the types of controls you implement.