—Confucius

How does SharePoint implement and support enterprise content management (ECM)? In this chapter, I provide an overview of SharePoint 2013 and its ECM-related features. I also discuss how each of the main capability areas within SharePoint relate to or complement each other, particularly as they relate to the information life cycle within your organization.

After reading this chapter, you will know how to

• Describe SharePoint 2013 and its purpose.
• Describe how SharePoint capability areas relate to and complement each other.
• Explain the SharePoint site and content container architecture.
• List SharePoint list and library types and their uses.
• List SharePoint site types and describe their uses.
• List and describe the SharePoint 2013 ECM features.

Overview of SharePoint 2013

SharePoint, at its simplest core, is a platform that an organization uses to manage and work with information—knowledge that an organization produces or acquires, and then uses as part of its operations. This is a very abstract description, but SharePoint has grown into its current version as a vast array of different features and functions that make up a set of diverse yet interrelated capability areas. Still, at its core, it provides a way for knowledge workers to interact with information, the enterprise content.

Enterprise content within SharePoint ranges from documents and web pages to electronic forms and social feeds. The platform provides containers to capture, manage, and interact with these different types of content at granular degrees and across the network. In its first version, SharePoint 2001, it began as a document management and collaboration system, providing users with a centralized document repository and richer document management features than a simple network file share.

As SharePoint matured over the years, Microsoft continued to invest in the collaboration experience for users in an organization. The product team built out SharePoint to serve as a platform to host and collaborate on different types of information in an enterprise, and they refined the user experience to encompass more of the information life cycle—from content creation to content discovery to content retention and disposition.

With the product evolving its capabilities to manage more of the content and life cycle, it has also grown in size and complexity. Now, rather than just providing document repositories and enabling collaboration, SharePoint 2013 offers a range of other features for information workers to capture knowledge and work with information. I like to group these other features into what I refer to its seven core capability areas, which are:

• Collaboration
• Social computing
• Portals
• Search
• Records management
• Business intelligence
• Composite applications

Within the collaboration capability, I bundle the different aspects of creating and collaborating on content, as in team or project workspaces. In this book, I refer to the type of content within the collaboration capability as transitory content. Knowledge workers collaborate by creating drafts and working with different pieces of content within a workspace container such as a SharePoint site. This interaction may involve content such as Word documents or wiki web pages, but collaboration is less characteristic of the type of content and more with the nature of how people create and share information collaboratively.

Social computing relates to collaboration, and the two have some overlap—particularly with functional aspects such as wiki pages or blogs. For my purposes in this book, I classify social computing as those features that enable people to discover information and their peers through other people. Whether a knowledge worker creates a collaborative piece of content as a Word document or as a wiki page, the social aspect includes things such as his or her tagging the content with metadata so other users interested in that tag will discover the content. For example, in Figure 2-1 a user can discover the new document based on the #Marketing tag he or she follows.

Portals also overlap and relate with the other capabilities, such as a user’s personal portal or their My Site. At their essence, portals provide a means to communicate information to a particular audience and provide a gateway to access other web properties and processes on the network, such as other more specific portals and workflow applications. A portal’s audience can be internal users, as with an intranet, or it can target external users, as with an organization’s public web site.

Search relates and complements the other SharePoint capabilities by providing the functionality for a knowledge worker to search and find information of interest. Users can use keywords or more advanced query criteria and find relevant documents or web pages within SharePoint or any other content source you have configured for the SharePoint search service to index. Users can also search for and discover other people based on metadata associated with user profiles. This enterprise search capability provides users with a means to discover content based on its relevance to the search terms, and it offers an entry point to the other capability areas.

Records management extends the information life cycle to manage content retention and disposition once content progresses beyond the transitory phase. This capability provides a repository and the functionality associated with capturing an official unit of information that the organization can or has used to base decisions on. The content captured provides a historical record of decisions or information at a particular point in time, which can serve to meet legal or regulatory requirements in the future.

Business intelligence includes features that aggregate and report on data, such as Key Performance Indicators (KPI), scorecards, dashboards, and other types of analytical reports. This capability provides a means to analyze data, and then report on statuses, relationships, and trends. A knowledge worker or organizational leader can use this information to base their decisions.

Composite applications cover a range of features. It is the capability that I group those aspects where you extend and customize SharePoint. Here, I include custom applications built on SharePoint as well integration with other enterprise systems. Specifically as it relates to enterprise content management, this is where I include electronic forms such as InfoPath forms to capture business process information. This is also the capability where I include workflows to manage and automate business processes ranging from approval workflows to automated content retention and disposition workflows.

I already alluded to how each of these capability areas relate to each other, but in the next section, I look more closely at the different ways that these capability areas complement and build on each other by sharing functionality and services.

Relating SharePoint Capability Areas to Each Other

I often describe the relationship between different capability areas as one similar to puzzle pieces fitting together—each complements each other as they add on and build out a larger overall picture, as I illustrate in Figure 2-2. Microsoft designed the product in a modular and service-oriented fashion so that you can reuse common functionality across different capabilities. Ultimately, at the component level, this leads to a more efficient system; but at the capability level, this allows you to continuously add on and grow your SharePoint environment as you need to and as you are ready for new capabilities, all without requiring you to over-architect a complicated deployment up front.

For me, each of the SharePoint capabilities build on or complements the others, offering specialized individual functionality while also leveraging or enhancing features in the other capabilities. In a general sense, you can extend your SharePoint service by adding additional capabilities, and this will add new features and functionality for your end users. This could be a drastically new capability area, such as adding business intelligence dashboards to an intranet portal, or it could be a related capability area, such as adding an enterprise search portal to an intranet portal.

Whatever the extension, the capabilities will still loosely relate to each other, and Microsoft designed the SharePoint platform such that the different capabilities will all work together to create a better or more feature-rich end-user experience. This design allows you to take and enable the capabilities you need, and leave the rest disabled. From an architectural perspective, the product team implemented a module pattern to design the infrastructure for capabilities, features, and any general product add-ons. Essentially, a module component provides loose coupling with high cohesion; it is an independent and self-contained component that you can include or not, and if included, it will work well with the other components.

The ability for capabilities to work together in a well-coordinated fashion is especially important for planning and designing enterprise content solutions, precisely because of the information life cycle I discussed in the previous chapter. Information in an organization is fluid and in flux as it flows through an organization and as it progresses through its life cycle. Whatever system you use to capture and manage information within your organization will resemble a kaleidoscopic of enterprise content that users interact with for different purposes and at different points in the cycle.

Such a complex relationship among enterprise content within an organization requires a flexible enterprise content management system, and this is particularly true as the complexity and the types of information will vary from organization to organization. For example, a legal firm may track contracts with precise security and retention requirements, while an advertisement firm may collaborate on copy and visuals for an advertisement campaign. Their needs are similar, as the information life cycle is similar for each; however, they expand or contract at different stages with different levels of formality. With the module design in SharePoint, they can each enable the capabilities they need and configure them to serve their distinct purposes.

Enterprise content management is a concept that spans all of the SharePoint capabilities that you have deployed. And as I just mentioned, the mix of capabilities you enable will vary depending on your organization’s needs and the type of information it creates and consumes. Nevertheless, each of the SharePoint capabilities you have deployed will play a part in your information life cycle strategy, and you can continue to build on and evolve your strategy over time as you enable additional capabilities and as your enterprise content management requirements mature or change.

From a general enterprise content management perspective, the capabilities relate together as information progresses through different uses and through different stages in its life cycle. As your users generate and create content in a collaboration environment, other users might want to discover it using search or social capabilities, or a content manager might include a link on a portal page. Meanwhile, your records managers might want to use workflows to capture the content and apply policies, and they can report on compliance using a business intelligence dashboard.

In a simplified and quick synopsis of enterprise content management, you can see how all the main SharePoint capabilities can come together at different points in the information life cycle. This example presents a user story of how the different capabilities relate to each other from the perspective of the business value and usage. The relationship between capabilities also runs deeper than the flow of information participating in the information life cycle. Capabilities can also provide services to other capabilities, which enables a SharePoint capability to leverage the features in a component hosted in another capability while providing its own functionality.

Capabilities such as search include underlying components that other capabilities can leverage. For example, a portal can provide a dynamic navigation by using search refiners, a social computing site can provide recommendations based on similar content search crawled, a portal site can provide usage analytic reports based on crawling data from search, and an eDiscovery case manager can discover content by querying the search index.

As a result, some capabilities will depend on other capabilities to provide their features and functionality. They also may share the same underlying service application in SharePoint—an application that exposes its features through a Windows Communication Foundation (WCF) web service hosted in Internet Information Services (IIS). A service application extends SharePoint with additional functionality by providing sets of features that can make up an entire application, and it can include its own data sources or external system integration points.

You associate a service application with one or more web applications, and then the sites within these web applications can consume and interact with the services that the service application provides. You can share the same service application instance across many web applications, which centralizes and reuses its services, or you can create several instances of a service application and isolate each from other instances, either providing each web application with a dedicated and isolated service application or providing multiple service application instances to a single web application. Figure 2-3 provides a conceptual example of SharePoint farms that share some service applications but not others.

A service application can also provide services to one or more of SharePoint’s capabilities. For example, the Managed Metadata Service provides metadata and taxonomy services to tag content in every capability. The User Profile Service, which provides core social computing features, depends on the Managed Metadata Service to provide profiles and to link relevant content in a user’s newsfeed. The Search Service also depends on the Managed Metadata Service to store the dictionaries of custom spellings, synonyms, or terms to ignore.

I use the concept of SharePoint capabilities as a logical way to group core functional areas to simplify and abstract the vastness of SharePoint; in contrast, service applications are more granular and their actual implementation details map specific feature sets to one or more capability area. I loosely relate SharePoint capabilities to underlying features and service applications in the product, but this is only one logical way to divide the product and plan its different aspects. This division and simplification of the product is what I found works well for me when I plan and design a SharePoint solution, but you are welcome to adapt it to whatever model works best for you.

This section is simply a long way to say that SharePoint offers an array of features and capabilities, and the product team designed the core architecture so that you can enable the functionality you need and leave the rest disabled, all in a coordinated and complementary fashion. As a result, SharePoint is flexible enough to adapt to a variety of situations, allowing you to tailor it to suit your enterprise content management needs, whether they are complex and rigid or they are straightforward and open.

As I discuss different phases of the information life cycle in different chapters of this book, I provide you with guidance on planning and implementing the different SharePoint capabilities and their underlying features. For now, I just wanted to point out how they all work together and build on each other. You can build out and mature your SharePoint service by enabling additional capabilities like fitting puzzle pieces together to form a richer and fuller picture of your information life cycle strategy.

With service applications and major feature sets making up the conceptual capabilities at the product level, your SharePoint service exposes these capabilities at the site level. A SharePoint site provides a granular container that contains functionality and content for users to interact with their content. As SharePoint sites provide the most significant container for interaction and information in any SharePoint deployment, I discuss them in depth in the following sections, starting with a look at the site architecture.

Understanding the SharePoint Site Architecture

Every architecture decision in a SharePoint deployment either directly or indirectly revolves around SharePoint sites. This is because SharePoint sites are at the essence of SharePoint and its capabilities. You can choose not to deploy certain aspects of SharePoint, but if you omit deploying any sites, then your SharePoint deployment will not be useful to users. However, even though you might deploy a SharePoint farm strictly to host services such as search, somewhere along the way you will need to create a SharePoint site to provide a user interface for this service, whether in that particular SharePoint farm or in another.

SharePoint sites are the entry point for users to create and interact with enterprise content. They are an essential piece of your SharePoint deployment and your information life cycle strategy. They intertwine so deeply with the product that you will find them throughout your SharePoint service, even if you have not previously given them any conscious thought. So, what makes a SharePoint site so essential and paramount in a SharePoint deployment and with enterprise content management? The answer lies in the site architecture and the hierarchy of containers in SharePoint.

The following lists the main containers in the SharePoint hierarchy, which I also illustrate in Figure 2-4:

• SharePoint farm
• Web application
• Site collection
• Site
• Lists and libraries
• List items

At its most macro level, a SharePoint farm is the highest container—or at least it is the most encompassing container for the farm itself for my purposes to simplify this discussion, even though an organization can deploy multiple farms and spread services and content across these farms. Service applications branch off and provide another container for the functionality and data the service provides, and depending on the service application, it can share its services across web applications and even farms in some cases.

The next major container in a SharePoint farm is the web application. Web applications consume service applications and they manage settings such as security providers and other policies. A web application will have one or more content databases that associate with it and that provide the storage for sites within the web application. A site collection can only belong to a single content database within a web application, but different site collections can belong to different content databases or the same one, depending on how you want to segregate and spread the data out within a web application.

Site collections make up the next container in the SharePoint container hierarchy. A site collection is what its name implies: a collection of one or more sites. In addition to its storage boundaries, it also serves as a security boundary where a site collection administrator can manage security groups and permissions for all of the sites within the collection. It is a self-contained unit that you can delegate its ownership and management to regular users.

A site collection will contain one or more sites—a root site with optional child sites. A site can optionally contain other child sites or other types of content containers, such as document libraries or lists. A site serves as the main unit in SharePoint that users interact with because it hosts the user interface and any content containers.

Content containers within SharePoint provide places for users to store and collaborate on content. They consist of a specialized type of list or library to store content items, depending on the type of content you are working with. For example, to capture and work with announcements, you would use an announcement list; for PowerPoint slides, you would use a slide library; and for web pages, you would use a pages library.

Each specialized type of list or library manages the settings for the content stored within its container, except when you are using content types. Content types provide a means to identify a type of content, and then associate policies with it. For example, you can create a Press Release content type and associate a default Word template with it, as well as approval and retention workflows, and any relevant metadata fields you want to capture with this type of content. If you do not wish to manage this policy, workflow, and metadata information through content types, then you can manage it directly in the list or library.

Optionally, a library can contain folders to organize files within the library, further nesting the container hierarchy. A library can also contain document sets, which are a special type of library item that can contain a group of other items and treat them all as a single unit. You would use a document set when you need to group items together to apply the same retention policy and workflows to them all. For example, in a procurement process, you might want to capture supporting information such as the original quote, your purchase order, the vendor’s invoice, and any other related documents to the purchase. You could capture those together in a document set to enforce the same information life cycle to the document set package.

At the lowest level in the hierarchy are the individual items within a list or library. These can be the announcements within the announcement list or the PowerPoint slides within the slide library. They could be pages within a page library or documents within a regular document library. Their essence is the same: they are a list item contained within a list or library. They may or may not have multiple versions and extra columns of metadata associated with them, along with other potential settings available. But at their core, they are a unit of information contained within SharePoint.

These units of information within lists and libraries are going to be my focus throughout this book. There are other places for units of information, both inside SharePoint and not, and I will discuss some of those as they come up. However, my primary focus is on those units of information you create and work with in a SharePoint list or library, because those items usually make up the majority of the content in one's information life cycle, at least from the perspective of a SharePoint environment. As such, they are a crucial piece of your information life cycle strategy and they are the key pieces around which to build your enterprise content management solution.

Think of the information hierarchy like words in a book: you have different containers, such as the book itself, chapters, and sections within chapters. Then you have the sentences, the units of information. Within a sentence, you have words, which make up the contents, but that individually do not contain information on their own. The sentences form a unit of information because they contain one or more propositions. There is a structure that then all comes together (hopefully) into a cohesive whole. Likewise, your enterprise content also consists of a structure, managing which is the heart of enterprise content management.

Now, you will not get far or you will quickly become over-consumed if you try to manage each individual unit of information yourself. Most organizations generate too much information for one person to track and manage at each individual item level. Quite simply, you will not scale by focusing on each individual item, even though those units of information are the critical component around which to build your enterprise content management solution. This is why understanding the content hierarchy in SharePoint is crucial, because unlike sentences in a book, you can automate a lot of the management of items by managing aspects at one of the container levels.

Containers in the hierarchy contain and manage other containers or the actual units of information. The site collection provides the main security and content boundary to isolate content and processes from other sites. As a container, they are largely generic and standard—a site collection is a site collection and does not vary much as a container beyond its configuration settings. Similarly, a web application is a standard container that does not vary from its default a great deal. You can set policies and settings at these container levels and they will apply to the items that they contain.

Once you move down the hierarchy to one of the lower containers, the site or list and library containers, you can specify a specific type of container. Types that are more specialized include predefined settings and functionality to specifically manage and interact with the particular type of information stored in the container. Using specific types of containers can help ease your enterprise content management implementation details.

In the next section, I look at some of the different types of sites you can choose from—more commonly referred to as the different site templates. I also share some considerations for deciding between different site types and their appropriate purposes. Following my discussion on the site types, I shift to look at some of the different lists and library types available in a default SharePoint deployment.

SharePoint Site Types

As I mentioned previously, a site collection will have one or more sites, beginning with a single site at the root of the site collection. Sites can then contain one or more child sites, and those sites can contain other sites, and so on. You can choose the site type for each of those sites independently from each other—meaning you are free to choose whichever site template is available when creating a new site, regardless of what any containing or peer site template you previously choose. (Although not every template will always be available, as some may only be available for root sites and some parent sites may suppress certain site templates).

You can create a new site collection from SharePoint Central Administration by clicking the Create Site Collections link found under the Application Management section. On the Create Site Collection page, you will also see a Template Selection section, as shown in Figure 2-5, where you can select a site template for the initial site in the site collection—the site collection’s root site.

The following lists and describes the main site templates on the Create Site page you can use to base a new site on:

• Team Site: This template creates a basic SharePoint site with only a document library provisioned within it. It provides the fundamentals that all other site templates include and build upon. Users can activate additional features or provision additional SharePoint apps to tailor the site to their needs. You can use team sites to host and facilitate team collaboration on content such as documentation and reports. Figure 2-6 shows the default homepage for a team site.

• Blog: This template creates a site designed around blog posts where one or more users can create blog posts, tag and categorize their posts, and even schedule their posts. It also provides functionality for users to comment and rate different posts. You can use blog sites to host and publish blogs, either for individuals or for groups of individuals, such as in a personal My Site or a shared group blog site.
• Wiki: This template creates a site that uses wiki pages for its welcome page and any subsequent pages. It facilitates creating additional wiki pages in a wiki fashion: by adding a link to a new page, and then clicking the link to generate the new page. You can use wiki sites to capture and collaborate on information such as documentation that you generate across pages in the wiki. Figure 2-7 shows the default wiki site welcome page.

• Publishing Portal: This template creates a site with the publishing features activated and organized with a portal welcome page. It also facilitates publishing portal content such as different types of articles or product catalogues. You can use the publishing portal sites to create a public web site or an internal intranet portal.
• Search Portal: This template creates a site with a default search landing page and an advanced search page. It also includes a search results page with preconfigured search refiners. You can use a search site for search-related requirements, such as for your enterprise search portal or for a departmental search application.
• My Site Host: This template creates a site to host the shared My Site pages and features, such as the newsfeed, sites listing page, and the main people profile page. It also provides the functionality for users to update their profile, add a profile picture, and manage their newsfeed and social tags. You can use a My Site host site as a starting point for your My Site and User Profile Service implementation.
• Community Site: This template creates a site for a community of practice to ask questions and discuss topics on a forum within the site. It also keeps track of the reputation for community members and contributors, scoring ratings based on the number and community-voted value of contributions. You can use a community site for a knowledge management portal, a frequently asked questions site, or a community of practice site. Figure 2-8 shows the default welcome page for a community site.

You can find the different site templates available by clicking the different tabs in the Site Template section. This is not a fixed list, because Microsoft or other vendors can add additional site templates along with their custom applications or SharePoint extensions. Your developers can also add to the list of site templates with any templates they create in a SharePoint feature, and then deploy in a SharePoint solution package. Finally, site collection administrators can add custom site templates by saving a site as a template or by uploading a site template package to the site template library in a site collection.

Each site template has a specific purpose and provides a specific user experience. Which one you choose will depend on the aspect it will fill for your enterprise content management implementation. You do not have to create a site for each, but you may, depending on your requirements.

For some site types, you might only create a single site based on the template. For example, you might only create a single enterprise search portal based on the search template. For other site types, you might create many instances of sites based on those templates. For example, you might create many collaboration sites based on the Team Site template. The choice of site type and site structure makes up your information architecture. Figure 2-9 provides a sample of a simple information architecture consisting of different site types.

Some of these sites in the sample information architecture exist in separate site collections. For simplicity sake, I used a single web application, but you can also spread these sites across different web applications as well. SharePoint has an important concept for how and where you create sites, referred to as a managed path. A managed path is what SharePoint uses to organize the URL for where you can create a site collection in a web application, and it comes in two flavors:

• Explicit managed path: Specifies an explicit URL path where you can create a single site collection. For example, if you create a search explicit managed path on the www.contoso.com web application, you can then create a single site collection at www.contoso.com/search to host the search portal.
• Wildcard managed path: Specifies a path under which you can create multiple site collections. For example, if you create a sites wildcard managed path on the www.contoso.com web application, you can then create multiple site collections under that path, such as www.contoso.com/sites/hr to host an HR team site and www.contoso.com/sites/it to host an IT team site.

Once you create your site, the template you used ceases to remain relevant. At its essence, a site is just a site, and as I mentioned, the team site provides the fundamentals of any site. Anything beyond the team site simply consists of activating different features, adding different SharePoint apps, or provisioning different types of content. In most cases, you can activate these features or add these apps when you need them, evolving the site beyond its original site template to adapt it to new site needs.

A site can and probably will evolve over time, transforming into other purposes or expanding to meet new requirements. The site template simply defines a site’s initial functionality and layout, and then the template ceases to contribute anything to the site. You also cannot make changes to the original template to cascade changes down to sites. Site templates are limiting from a maintenance perspective, and they do not offer a lot of value beyond automating the initial site configuration and providing a friendly name for this automation on the Create Site page. For this reason, I try to minimize any extra templates and avoid what I call template bloating, as I describe in the sidebar.

SharePoint List and Library Types

In much the same way that you can use templates to create different types of sites, you can do the same to create different types of lists and libraries. Unlike a site, however, lists and libraries are specialized with particular functionality to work with certain types of content, remaining specialized throughout their continuation.

You cannot, for example, easily transform or evolve a document library into a picture library with all its picture-related functionality, although you can add pictures and other content types to a document library. Lists and libraries are specialized by design to manage specific types of content through the information life cycle.

Lists and libraries provide the primary and most significant container for enterprise content in your SharePoint environment, establishing and sorting the variety of content in different containers. The lists and libraries also provide a container for other aspects to manage your information life cycle, such as associating metadata with content, hosting workflows to process and manage the content, and applying retention and disposition policies to the content.

I am stressing the importance of SharePoint lists and libraries because they are a critical component to any enterprise content management design and implementation. Indeed, this is where the majority of your configuration and policy settings will apply, allowing those details to cascade down to the individual units of information stored within the container, thus enabling you to scale. Instances of the policies and workflows apply to individual units of information, but you define and apply them at the content’s container, either directly implementing them through lists and libraries, or through a content type.

You can add new lists and libraries to your site by adding new SharePoint apps, the site component through which SharePoint adds new functionality and containers to a site. Apps can be a little confusing at first because they include a variety of options to add to and enhance a site. For example, you can add an app to provision a new document library in your site for storing content, and you can add another app to add a web part with functionality for user interaction rather than content storage.

Apps also come from a few different sources, adding to the potential confusion when one initially tries to understand their purpose and what they do. SharePoint organizes apps in different catalogs, which are simply different sources of finding apps, some built into SharePoint itself, others developed by your internal developers, and still others licensed through third-party vendors. The following lists and describes the different app catalogs:

• Site Catalog: This catalog exposes all of the apps built in or installed directly on the SharePoint farm. It includes apps such as the core lists and libraries as well as the product’s core web parts.
• Organization Catalog: This catalog exposes your organization’s internal apps, built either by your internal development teams or outside consulting service firms. You use this catalog to host your custom developed apps, providing a well-known and centralized location for users to discover relevant apps for their sites. This catalog also manages your organization’s app licenses and user requests for apps from the SharePoint Store.
• SharePoint Store: This catalog exposes Microsoft’s marketplace where Microsoft and third-party vendors list their apps—some for sale, some for free. You can use this catalog to acquire new apps rather than develop them yourself. This provides a centralized and trusted location to add new functionality, leveraging the global community for site-specific extensions while standardizing the procurement process.

At their most basic sense, SharePoint apps package instructions to configure or add functionality to a site, including adding a list or library definition, creating an instance of a content container to capture and manage units of information, as well as adding other site aspects such as web parts. SharePoint contains apps within a site collection, isolating them from other sites and the system itself. It also prevents any custom code from executing on the servers in the SharePoint farm, instead requiring the app to execute any custom code directly on the client, typically using JavaScript, or on a vendor-hosted server using a web service.

You can add a new SharePoint app to you site from the Site Content page, easily accessed by clicking the Site Content link in the quick launch navigation menu, usually located in the left area of a site page. Alternatively, you can use the site Settings menu found in the top-right area on a site page and represented by a gear icon. On the Site Content page, click the Add An App link to open the Add An App page, similar to the one in Figure 2-10. You can select a desired SharePoint app from one of the categories by clicking it.

For my purposes in this book, I primarily focus on the apps for content containers, and for simplicity sake, I refer to those containers directly as the lists and libraries in general, or the specific type of list or library. The other apps are valuable and I encourage you to explore them and experiment with what they can offer to your site, but except where they relate directly to designing your enterprise content management strategy, I do not discuss them further in this book.

As I mentioned, content containers divide between two main flavors: lists and libraries. The following lists and describes the main libraries available in SharePoint 2013, accessed through the Add An App function and by selecting the library filter:

• Document library: This library is the core content container and one of the most popular libraries your SharePoint deployment will probably use. Users can upload any type of file, not just Microsoft Office files, as long as its extension is not on the exclusion list for file extensions.
• Pages library: This library stores and manages SharePoint pages—ASP.NET pages as well as basic HTML web pages. When combined with the publishing features in a SharePoint site, it can merge page content with layouts pages, rendering consistent and efficient content pages for site visitors. Wikis also use a page library to store wiki pages.
• Picture library: This library is a specialized library for storing and managing pictures and their associated metadata. It also provides functionality to preview pictures at different sizes or view a slideshow of selected pictures. You can use this library to share pictures and host picture galleries with the site visitors.
• Form library: This library stores and manages InfoPath forms. It also provides the ability to link a column in the library with a field in the InfoPath form. You can use this library to capture electronic forms, execute their related workflow processes, and track or audit their history.
• Asset library: This library stores and manages different types of media assets, including video, audio, and pictures, as well as their associated metadata. It also provides functionality to preview media assets. You can use this library to organize your rich media content.
• Slide library: This library is a specialized library for storing and managing PowerPoint slides. User can upload PowerPoint files and then interact with individual slides from those presentations. You can use this library to share presentations with teammates, allowing them to mix and match slides when they need to make a presentation of their own.

Where libraries mostly entail files, lists mostly involve strings of text directly as the unit of information. (Both lists and libraries further include metadata as part of the unit information, self-describing an item along with the item’s content). The following lists and describes the main lists available in SharePoint 2013, accessed through the Add An App function and by selecting one of the list filters:

• Announcements: This list allows you to post and schedule announcements for site visitors and teammates, keeping everyone updated and aware of developments. It also exposes enhanced formatting capabilities to embed images and hyperlinks with rich formatted text. You can add a web part to a site page to display recent announcements.
• Calendar: This list essentially serves as a shared calendar, allowing site members to post event details and schedules. It also exposes functionality for users to open the calendar in Outlook, optionally layering it over their personal calendar, providing a global view of their commitments and availability.
• Tasks: This list provides task management capabilities, including task details and task assignments. SharePoint can aggregate tasks from tasks lists on different sites, as well as other task repositories such as Project sites or Exchange mailboxes, displaying an aggregated list of tasks on each user’s My Site.
• Project Tasks: This list captures task information in a similar fashion to the task list, extending that list to provide a visual or Gantt view with progress bars consistent with common project management formats. It also exposes functionality to open and interact with a project task list in Microsoft Project 2013. You can use this list for more consistency with traditional task tracking in project management.
• Issues: This list captures issue details and manages open issues, tracking their progress and status. It also exposes functionality to assign issues to site members, categorize issues, and relate issue items to other issues. You can use this list to track bugs, risks, or other types of issues you want to capture and monitor through until the issue’s resolution.
• Contacts: This list stores contact information such as names, phone numbers, e-mail addresses, and postal addresses for individual contacts. You can use this list for different types of contacts, depending on the site’s purpose, including customers for a service or stakeholders on a project.
• Discussions: This list stores discussion topics and their replies in a similar format to forums or newsgroups. It also exposes functionality to receive threaded e-mail discussions, set by configuring the list to receive and post inbound e-mail messages. You can use this list to brainstorm ideas or capture discussion topics for future reference.
• Links: This list stores link information such as a URL and title for a web link. You can use this list to display links to relevant web resources for site members and site visitors to reference.
• Surveys: This list allows you to define survey questions and capture survey responses. It also provides reports on survey results, both aggregating and reporting on individual responses. You can use surveys to gather information from users based on a series of questions.

As you can see, there are many different containers to capture and manage enterprise content in. They provide the entry point to capture knowledge and information, then transforming themselves into a storage role to provide ongoing access, consumption, and management of a unit of information. Some are specialized to manage particular kinds of content, whereas other containers are more generic. They all combine in your enterprise content management implementation, working together to provide the storage and item handling.

All of these content containers share some underlying core functionality and settings, such as access control, retention policies, and workflows, among others—all vital features to facilitate a productive and automated content life cycle. These content containers establish the foundation for an ECM solution, capturing and managing the individual content items, providing a means for enterprise-wide ECM features to interact with and manage your content. In the next section, I summarize the different ECM features in SharePoint, looking at how they provide tools to manage the content life cycle across all lists and libraries, among other content repositories.

SharePoint 2013 ECM-Specific Features

SharePoint offers a compelling range of enterprise content management features for your deployment, establishing a platform with rich feature sets for each stage of the information life cycle, allowing you to deploy a single platform, growing and adapting it over time as your enterprise content management matures. You do not have to stick with a single platform, as SharePoint can integrate and coordinate with other platforms. But for now, let’s just focus on SharePoint as your ECM platform.

I already noted some low-level, particularly crucial components for managing your enterprise content: the SharePoint lists and libraries. These are where your ECM solution design begins, because this is where the content lives. I like to build out from there. I touched on another useful, and somewhat related, aspect at the list or library level when I mentioned content types—every item in a list or library belongs to a content type, whether a more generic content type or a specialized one for certain kinds of content.

Where SharePoint lists and libraries handle the capture and storage of content, content types offer a granular method to apply policies to a specific type of content wherever it resides, rather than applying policies to everything in a content container. It also offers a means to define the metadata. Defining the content and its policies through a content type empowers you to organize the content by what makes sense for the information and how users want to work with it, instead of having to organize it by how you want the system to manage the content.

At its essence, a content type is really just another piece of metadata that categorizes content as a specific type. SharePoint uses this metadata category to group and marry other content-related aspects to the unit of information, such as retention policies, workflows, and other metadata columns, as illustrated in Figure 2-11. The product simplifies these underlying details and exposes the implementation details relating to a unit of information as a content type.

Content types enable you to manage different kinds of content in the same list or library, but that is just the start of their value. You can reuse content type definitions across different content containers, facilitating consistency and standardization for your units of information, no matter where users create particular kinds of content and no matter where users move the content items. Indeed, one other feature of content types is that you can standardize and share them across your enterprise, a feature known as the content type hub.

When you create a content type hub, you specify a site collection to host content types that SharePoint will then replicate to the other site collections across your organization (or at least replicating to those site collections in a web application that consumes the same Managed Metadata Service managing the content type hub). This manages units of information as users move them to new locations, progressing through stages of the content’s life cycle.

For example, a user can create a document in his or her My Site, associating it with a particular content type, and then later he or she can move it to a shared team site for group collaboration, before finally moving it once again to a records repository to designate it as an official record. In each location, the SharePoint site is aware of the content type and any policies or metadata associated with it, regardless of the site or document library. Furthermore, as I discuss in Part IV on records management, a records repository can automatically route and apply the applicable retention policies for content based on its content type.

So far, I have discussed granular aspects relating to enterprise content management in SharePoint. Lists and libraries, along with content types, set the basic building blocks for everything else in your information life cycle to interact with, extend, and depend on. Working out from here, the different kinds of SharePoint sites are the next major aspect for managing units of information, depending on the type of site, as I discussed previously.

A major component of a content type includes the metadata to tag and classify content. Metadata itself plays an integral part of any enterprise content management solution, because this organizes content and it establishes the criteria for most of your policy rules to apply to the content. SharePoint implements metadata through its Managed Metadata Service (MMS)—a service application that hosts your enterprise taxonomies and other term-based structures and lists.

Workflows establish another major ECM feature exposed in SharePoint. The Windows Workflow Foundation in the .NET framework provides the underlying workflow engine and framework for SharePoint, enabling sophisticated workflows to manage and orchestrate activities and automate processes. SharePoint leverages these workflow capabilities in the .NET framework, extending them with its own workflow implementation, hosting workflow instances, managing workflow state, and providing an integrated workflow user experience consistent with the rest of the SharePoint user experience.

You can apply and associate workflows at any stage of your information life cycle. For example, you can create an approval workflow for documents or portal pages as a team collaborates on them, defining a system-managed process for documents or portal pages to move from a draft status into a published state, as illustrated in Figure 2-12. This both formalizes and enforces the process to progress from draft to published content.

With users constantly producing new units of information, your corpus of enterprise content continuously grows, some portions valuable, others not at all or only temporarily. This presents the need to retain some content and dispose of other content when it no longer provides value and is no longer required for historical purposes. SharePoint solves this scenario through retention policies, and these are especially effective when you combine them with custom workflows and associate them with content types, enabling you to manage major categories of content in an efficient and effective manner.

Electronic discovery (also referred to as eDiscovery in SharePoint 2013) provides a means to discover relevant content based on a range of query parameters. This allows an organization to respond to compliance, regulatory, and legal cases by discovering any relevant units of information within the corpus of enterprise content. An eDiscovery manager can create and manage a discovery case, discover content related to the case, and place a snapshot of the content items on hold to preserve and protect their integrity for the case. You can use eDiscovery in response to an incident or external obligations, or for a proactive internal content audit.

Managing the process to capture, store, and control units of information make up the majority of an enterprise content management solution, but you also need to manage how users can find and discover information, whether managing eDiscovery cases or generally searching for relevant content. The SharePoint search service is the underlying component and the essential functionality to query for content, from users executing a search query to aggregated rollups displaying related content suggestions.

I discuss these features and others in more depth throughout the rest of this book. For now, I just wanted to give you an overview of some key functionality, a taste of what SharePoint brings to the table, to whet your appetite for the rest of the book, where I lead you through how to plan and design solutions around these functions, and then how to implement them in your SharePoint environment.

Although this is not a deployment book on how to set up and configure SharePoint itself, as my limited space for topics constrains me from including detailed SharePoint deployment guidance, I think it is important to ensure a general understanding of what a SharePoint farm entails. As such, I shift now to give you a succinct overview of the infrastructure that makes up a SharePoint farm.

Overview of the SharePoint Infrastructure

Any SharePoint farm will consist of at least a SharePoint server and a SQL Server database server—these may coexist on the same Windows server instance, but in all but the smallest and most basic deployments, you will generally install them on separate servers. As I indicated, you install the SharePoint and SQL Server application software on a Windows Server (either 2008 R2 or 2012), building your servers on virtual or physical servers, depending on your preference.

These servers make up the essence of a SharePoint farm, ranging from small farms with just those two servers, to larger farms consisting of multiple servers to process a greater load in parallel. The number of servers your SharePoint farm requires depends on the number of users you support, their usage characteristics, and how powerful the servers are.

One of the great things about SharePoint is its flexibility to change over time. Indeed, Microsoft designed SharePoint to maximize its adaptability to future requirements and the inevitable changes as the future reveals itself. As your users grow in numbers or their usage characteristics change, you can join additional servers to the farm to handle the increasing load. This is as simple as the following steps:

• Install the SharePoint software and any applicable language packs.
• Apply the latest service pack, security updates, and patches.
• Run the SharePoint configuration wizard.

A SharePoint server is a server on which you install the SharePoint software. SharePoint servers run services, and each of those services process some aspect of the farm's workload. You can allocate a server to different conceptual roles in a SharePoint farm by starting the relevant services on that server and stopping other services. For example, you can designate a web server by starting the Microsoft SharePoint Foundation Web Application service; or you can designate different application roles by starting the application’s respective services on the server. A server can run all or some services, and multiple servers run the same service, in which case SharePoint will manage the load balancing for the service.

Basically, I want to show you that your SharePoint farm is not fixed or limiting, and this is because you can adapt the number of servers and the distribution of services on the servers with ease. I like to highlight this because it is important: you do not have to worry about thinking of every possible future scenario ahead of time, alleviating the need to over-architect an implementation up front. You can grow and adapt your farm as the load warrants, and you can discover your farm loads by monitoring the performance levels of servers in the farm.

Now you know the main infrastructure components involved in a SharePoint farm; but SharePoint farms rarely operate in isolation. In fact, I like to think of SharePoint as the application that integrates or interacts with almost every other enterprise application, and this can quickly add to the complexity with understanding the infrastructure that surrounds a SharePoint farm.

Some of these enterprise systems are natural and almost seamless for SharePoint to integrate with and consume data or services. For example, a SharePoint farm probably uses an identity management system such as Active Directory to authenticate its users. A SharePoint farm may send e-mail alerts and even receive inbound messages to discussion boards or document libraries, interacting with an e-mail system such as Exchange. SharePoint can interact with other enterprise systems through custom integration points as well, such as through Business Connectivity Services (a service application that provides external data connectivity and integration services to the SharePoint farm).

Figure 2-13 illustrates the different servers making up a sample SharePoint farm, as well as servers from other enterprise systems that the SharePoint farm integrates with.

As you can see, a SharePoint farm can interact with some critical enterprise systems, and in some cases, these are some of the most critical enterprise systems in an organization—take Active Directory or Exchange, for example, since these are among the most critical systems for many organizations. But even more than simply interacting with critical enterprise systems, I find that SharePoint is itself frequently a critical enterprise system as well.

With SharePoint reaching the status of a critical enterprise system, you can take comfort in how capable the product is to hold this status. For one, it is generally stable and built well. However, for my money, I think its service-oriented design and overall scalability are what make it particularly capable for you to treat it as enterprise critical.

Wrapping Up

SharePoint offers a range of ECM features to implement and support your ECM solution, from collaboration sites and content types to eDiscovery and content retention workflows. In this chapter, I provided an overview of SharePoint 2013 and its core capability areas—namely, collaboration, social computing, portals, search, records management, business intelligence, and composite applications. From there, I described the site architecture in SharePoint, paying particular attention to the hierarchy of content containers as well as the types of sites, lists, and libraries. I stressed understanding how SharePoint captures and manages content will help you with your information life cycle strategy, and then I highlighted some of the main enterprise content management features in SharePoint.

Knowing how SharePoint manages content is critical for implementing your enterprise content management solution, but before you get to that stage, you have to design a solution that fits your organization’s needs. The first major step in designing your enterprise content management solution is to analyze and understand your information life cycle. In the next chapter, I return to the content life cycle model I introduced in Chapter 1, and I show you how to apply it to your organization and how to use this to analyze its information life cycle.