The Publishing capability consists largely of the features and functionality built into SharePoint Server 2007 from prior versions of Content Management Server. Largely, this is the capability specifically used for the dissemination of information to a targeted, wider audience. Content is often published to these areas through content deployment technologies, such as those built into the SharePoint Server 2007 API or those available from third-party vendor product offerings. See Chapter 13, for more information.

For example, suppose a large project is underway, and many teams are contributing within one or many collaboration spaces. As these various teams author communications materials that provide project updates and information, they can optionally publish the documents which, pending approval, would be deployed to the associated publishing space for consumption by a wider audience. This capability and its associated site types are typified by their higher viewer-to-author ratio and less restrictive information security, although security might be controlled more closely in highly specific or specialty applications.

What do we mean by "audience?" In this case, we are referring to the group of users who visit the site and, even more importantly, have access to the site and its associated content. This should not to be confused with the audience feature of SharePoint Server 2007 used to target content. So, a wide audience would be markedly less discriminating than a member audience or a managed audience, both of which will be reviewed in more detail as we dive deeper into the remaining capabilities.

The Collaboration capability of SharePoint Server 2007 is by far the most popular among users, and it is where most of the real action happens in the majority of information management implementations. This is where users are actively engaged with the creation and update of both document and list item content. Figure 7-1 notes that the audience for collaboration spaces is a member audience, meaning that most, if not all, users who have access to this type of site are actively participating in the contribution or management of content. Returning to the project example used earlier, these sites are where the project subteam members spend most of their time creating, editing, and reviewing document and list item content, such as calendar events, tasks, and so on.

Collaboration sites are often viewed as team spaces, with an average membership between 5 and 50 users. The more emphasis placed on this area from a design perspective, the greater the return for the overall implementation effort as well as the long-term viability of the architecture. In larger organizations where process architectures exist for common activities, such as the management of projects, assets, and checklists, it is often easiest to base the initial content layout and functionality on the available information. If an organization has a well-known process for managing projects, sites created by users for the purpose of performing project work using this process should, by default, provide many of the familiar tools, terms, and elements of the process architecture. This makes both the design and the end-user experience easier to create and accept. It also allows improvements in the process architecture to be easily translated into updates of the associated site types.

The Records Management capability in SharePoint Server 2007 provides a unique set of features that, when viewed together, allow for the identification, retention, and ultimate disposition of high-value document content. This is an often-overlooked aspect of an information architecture because, historically, both the people and the technology used to perform the tasks associated with this capability have not been involved in the selection and implementation of organization-wide collaboration/publishing tools. In an age of unparalleled information risk and with many organizations placing an emphasis on information protection, it is more important than ever to look at this foundation-level function carefully. It is a common mistake for those implementing technology to overlook, or even avoid, records management. The information stored and created by users via the two aforementioned capabilities is at risk of both unintentional deletion and being located in sites that themselves need to be life-cycled over time. Records Management sites have a managed audience in that a controlled group of users, who perform specific roles related to the information life cycle, have tailored access to the site in order to perform the various tasks associated with their role.

A best practice to combat these risks is to place high-value information in a separate, secure storage location, thereby allowing that site and the high- and low-value information it contains to be removed when no longer needed or used. The Records Center site provides these services to other sites by way of the Official File Web Service. This Web service allows a Records Center site to receive content from other publishing and collaboration sites as well as from any Web service–enabled application. Once the file is received, it passes through a filter-like routing table, which contains a set of business rules by which the incoming file is classified and filed, in accordance to a pre-defined Enterprise FilePlan. The Document Center is another storage location for completed documents that do not qualify as official records but still need to be accessible to a wider audience.

Because the file and its associated metadata are stored separately but remain related, it is possible to reclassify the file as needed without disturbing its disposition schedule. The Records Center site also provides additional interfaces and workflows for managing preservation holds on specific information as well as a set of workflows specific to maintaining and disposing information. An additional add-on pack for Records Center is available, which greatly increases this capability and brings the Records Management feature of SharePoint Server 2007 into compliance with the DOD 5015.2 standards (Department of Defense industry standards for records management systems).

For Publishing, Collaboration, and records manager to work together as a seamless system, you must make the movement of content from one site type in a vertical segment to another as transparent as possible. Returning to the project example, when users participating in the Collaboration sites decide they need an item published so that it becomes available within a Publishing site, they will send the document to a location in the appropriate companion site.

There are a number of ways this can happen. The easiest, but most user-intensive, option is to train users to utilize the Auto-Copy feature of SharePoint Server 2007, which is exposed via the Edit Control Block of a document library as Send To > Other Location. This allows a user to specify the URL of the destination library, after which a linked copy of the document will be sent to that library. The user will have an option to have future updates to the source document automatically update the destination document. It is also possible to set up a default Custom Send To location setting for each document library, which might specify a predefined companion library. Additional options also exist, such as content deployment paths, third-party content replication and deployment tools, and document library event handlers.

You can move content to secure Records Management sites by using many of the methods described earlier. However, it is a generally accepted best practice to use the Official File Web Service, which is the Records Center’s cross-application in-basket. This Web service accepts the document itself, along with any metadata, audit details, and actions performed on the document. Specific, pre-configured content types that have been identified as high-value information are configured and made available to end-users through the settings of individual document libraries. There are two primary methods of automating this one-way push of content to the records repository that don’t require user interaction.

The first option is to configure high-value record content types with a custom workflow, which includes a final step that calls the SendToOfficialFile method. This workflow could be triggered by a document event, such as when a document reaches a major version. The second method involves event handlers on the document library list that detects specific conditions, such as a major version, check-in action, or publishing action, after which the workflow fires to process the document. The URL of the records repository can be set at the farm level through Central Administration. However, it is often preferable to store this URL at the Web application, site collection, or site level using a Property Bag property or list item so that the management of the preferred records repository is more specific to the areas served. The SharePoint Server 2007 Software Development Kit (SDK) and ECM Starter Kit include samples and code to get you on the way to creating these solutions for your implementation. You can find more information on the SharePoint Server 2007 SDK samples at http://go.microsoft.com/?linkid=6162309.

SharePoint Server 2007 ships with ready-made templates for Publishing, Collaboration, and Records Management. These templates provide a feel for the functional expression of the underlying system capability that is available without modifications or heavy configuration. To identify the opportunities that will produce the greatest return for the business, you will need to engage the business stakeholders with the goal of collecting quality feedback, which can then be used to align the technology capabilities with well-identified business needs. It is important that these business stakeholders be individuals with a high level of operational understanding and experience.

One of the most critical aspects of collecting quality feedback from these individuals is the creation and distribution of clear, concise, and effective communications. If financially feasible, it is a best practice to have a dedicated individual or team that is specifically tasked with the collection of this feedback to ensure that proper care is given to both the communications and the collection methods.

The most frequently used methods for collecting business stakeholder feedback include surveys, interviews, and joint sessions. Best practice is to employ a mixture of these methods. For example, you could start with a series of brief interviews with pre-identified stakeholders, followed by a medium-length survey that summarizes the findings common among interview responses, after which a series of joint sessions would be scheduled to explore each of the well-identified opportunities. Expect these sessions to be highly interactive, as each representative of the business holds a somewhat different view of what is important and what kind of system benefits would be most useful to them and their constituents. The final result of these exercises should yield a short list of immediate targets or vertical segments. These vertical segments intersect with the horizontal capability layers described earlier in the chapter.

While most general implementation opportunities identified will span all three capabilities of the platform, niche or process-specific implementation opportunities might intersect only one or two platform capabilities. For example, a common vertical segment is projects. The project site vertical segment crosses all three of the categories, so a specific business customer might elect to use one, two, or all of the available feature/functionality mixtures provided by each category. A given project may require only the ability to collaborate on project tasks and documents. A different project might require Collaboration capabilities, but also need Publishing and Records Management capability.

By providing a consistent and measurable set of capabilities for a specific vertical segment, both initial adoption as well as return service usage will benefit. Assuming that you implement these products using Site Definitions as opposed to Site Templates, users might even share their own versions or enhancements to the provided base product with other users, which in turn will help improve the product over time. Figure 7-2 illustrates how a few example segments might overlay the categories shown in Figure 7-1.

Figure 7-2. Base architecture categories with example segments shown

Core services, such as Regional Shared Services Providers, My Sites, Search, and Application Servers, might also be offered in a product/services model to create ubiquity in organizations that are spread out managerially or geographically. When doing so, pay special attention to the limitations of using Shared Services Providers in distributed environments, and avoid consumption of Shared Services across WAN links. Some implementations even include the provisioning of My Site for every user in the organization as part of their user setup routine. While this certainly is not required, it may prove helpful in fostering adoption of the technology within your environment, as many users see their personal site as a place where they can safely learn to use the technology prior to contributing content to shared collaboration sites.