Many audiences will ask for documentation to help them understand how the various pieces of the SharePoint ECM solution will fit together. We have found that the best way to illustrate this is to create a kind of configuration blueprint in the format of tables and lists that are easily understood by a wide audience. The key to this is to see the interrelationship of items so that, for example, you can understand how the IA and content types relate to each other.

Governance is a widely used term that is often misunderstood or interpreted in various ways, depending on the subject. For purposes of your documentation, we define it as a nontechnical section that connects the features of SharePoint with their proper usage and company policy—in essence, a rulebook. Governance in this context refers to the usage and control of content in SharePoint. This covers how to use the platform, such as how to properly upload a document with proper metadata, and proper types of content per a retention schedule or other organizational policy.

Some organizations will also have an IT governance plan that includes security considerations. This document is very often owned by IT and is separate from the ECM governance document. The section on ECM governance can include references to the overall IT governance plan where appropriate, but we recommend that organizations keep them as separate documents.

The danger of documentation is that it can be a resource vacuum and become never ending. To help mitigate this problem, we recommend as few authors as necessary to complete the effort. By limiting the number of people involved in the documentation process, you will have a better understanding of the boundaries that they have used to prevent unneeded detail on certain subjects. This also creates a more focused effort on where the information came from and why it was written and organized in a particular way—that is, a singular source of truth.

Obviously, a peer review of the documentation is necessary for accuracy and to get joint ownership, but multiple authors sometimes cause unneeded focus in some areas and too little on others. The other danger is the belief that the documentation has to be 100 percent accurate. We are not advocating glossing over mistakes, especially the technical ones, but sections like governance and records management are very often a moving target and can change over time. It’s better to publish a 90 percent accurate document and move forward with modifications than to never publish anything. The document should be a foundation of future growth and extension of the platform; this requires an end point to its creation.

In the rest of this chapter, we are going to focus on the areas that you should include from this planning guide that will be critical for your ECM solution. This is meant as a resource for you to select the elements that work for your project. This is not a one size fits all. Every situation is unique, and we recommend that you exercise your own judgment to apply as many of these elements as you see fit for your organization and project.

The two primary ways to document the IA are either in a diagram or in table form. We recommend that organizations do both because the added effort of one over the other is nominal when one is already created. This also helps various audiences digest the documentation in the format that is most familiar to them. The site and library architecture should go from the site collection level, down through sites, to document libraries. In the IA section of Chapter 5, we mentioned that organizations planning for growth would create a site collection per business unit, whereas other organizations will do an individual site per business unit. The difference in the documentation is simply the depth. They will essentially look the same. Let’s review in detail a real-world example of each documentation type.

The benefit of a diagram is that it puts all components and their relationships in one place. This is usually very easy for most people to digest. The only downside of diagrams is that they can get very large and hard to print. As shown in Figure 7-1, the center of the diagram is the farm. Typically, the configuration at the farm or platform level is up to the IT department, and that is not included in the diagram. For purposes of this section of your ECM documentation, you do not need to provide technical details at the farm level.

Figure 7-1. IA diagram.

Toward the right of the diagram, notice that we included three applications that will be used for other purposes outside of our ECM solution. These are listed as separate web application sites called Members, Applications, and Intranet. We list them here, even though they are separate uses of the SharePoint 2013 platform, because it’s nice to have a full listing of root web applications for navigational purposes, and we might have a need to relate them to one another. For example, there might be a line-of-business application such as an employee or customer survey submission that creates a record in ECM, and we can easily document that relationship when they are all listed in one place. For purposes of this planning guide, we will not go into any deeper detail on these additional web applications.

Our focus is the ECM web application. In this diagram, we have taken the site collection approach per function. This could have been done for scaling or due to the size of content. Normally, if you take this approach, it means that you are also using more than one content database. If this is true, you should add the level at which content databases are chosen. For example, if you have a content database per site collection, note this as a parent of the site collection and the name of the content database used. This is important for IT support functions, such as planning backup configurations and disaster recovery procedures.

In this case, we are using a single content database per site collection. We are also using the root site of each site collection as the landing page of each function. As we mentioned in the IA section in Chapter 4, the trend is to have flatter architectures and leverage the power of metadata to improve browsing and search. This is a perfect example of that implementation trend and how to structure your IA.

Each site collection has a listing of libraries and features used. For every site collection, you can see that there are documents, media, and confidential libraries. The documents library is the largest in each site collection and will contain a listing of all content items such as documents, presentations, and text files for that business unit. The media library is used for rich media files, such as photos and videos, for each business unit. And finally, the confidential library is a location where managers of a business unit can store documents that are not visible to all the staff in that unit. For example, employee reviews can be stored here or in the HR library, depending on your organization’s records plan.

These consistencies allow users to understand the navigation and structure of your ECM solution no matter what business unit or functional role they have in your organization. In the case of the HR and the Legal departments, there are some exceptions to this rule where some special libraries are called for. For Legal, there is a library for content holds. This will be used in any litigation scenario and is the location where content will be held during eDiscovery for legal review when preparing to respond to requests for production of documents during litigation. Because not all held content is visible to everyone, it’s placed here for exclusive use by the Legal department.

In the HR department, you see special libraries for employee files and resources. Employee files also come with the special feature of “document sets.” This library has legal implications due to the regulation around employee files and must be kept separate with appropriate security. However, the resources library is a location where the HR department might store content that they regularly provide to employees related to their employment.

You will also see site collections named Search and ECM Hub. These are special site collections with specific functions. Search will be the ECM-wide search application, and the ECM Hub will be the location that contains some testing for specific ECM functionality before and after it’s deployed to the organization, as well as the official location for all content types that are published to all other site collections. These site collections don’t have functional libraries. However, the ECM Hub might have libraries not for general consumption, to test out various features such as views and column setup.

Each site collection also has a listing of features that will be enabled. This is simply a listing rather than a detailed explanation of how each feature would be used. This should be included in the detailed screen shots we discussed in the documentation section of this chapter. This listing of each feature is a guide that lays out from a user perspective what features they will have access to.

As we recommended earlier, it might be helpful to organize this same documentation in the table format illustrated in Table 7-1.

Most organizations’ configuration will span, on average, 15 business units and be much larger than the four configurations shown in the preceding table. Table 7-2 outlines another format for a small city’s IA. This structure uses a site per business unit instead of library.

For simplicity, we have removed the Configuration column shown in Table 7-1, and we have added a Content Database column to Table 7-2. Because of added security requirements and larger amounts of content stored in SharePoint, the city needed to expand its deployment to many site collections and content databases. In contrast to the structure shown in Table 7-1, the small city has two layers of business units, which is still a very flat IA, where each business unit still has the standard library configuration of a documents library and a media library, with the exception of Legal. The other big difference is that you see the Projects web application where cross-functional projects are set up. Under Projects, there is a new site collection per project. You will also notice the email web application. As we mentioned before, email archival is a large project on its own. The city decided to implement an email retention policy that required all email older than 90 days to be deleted from their inbox and moved to the email web application for archive. The web application is visible only to the City Attorney’s Office. Under the email web application is a content database for each year of archives.

For example, if this system were set up in 2008, there would be EMAILDB_2008, EMAILDB_2009, EMAILDB_2010, and so on up to the current year. The content database will store one site collection per year, with each site collection named per year. Within the site collection will be a site for each business unit, and under each business unit, there will be a site and a library per user in that business unit. This is the final resting place for all those users’ emails. This configuration was required for the sheer volume of email, and for ease of browsing either in legal cases or to facilitate Public Disclosure and Freedom of Information Act requests.

When completed, both the diagram and the table could be used during training to help users get a high level overview of the farm and its configuration. During adoption, this is helpful because it allows users to see the big picture. In any case, each diagram and table should be preceded by an introductory paragraph that includes the assumptions made so that it is very clear to the organization why the IA was organized in such a way. In the beginning section of the IA document, you should include the following three elements:

A good example to include in your explanations would be around scaling the ECM solution. List how much content you have now, what percent will go to SharePoint, and the growth rate. This is important in the decision of whether to do business units per site or per site collection. Include how the functions were determined and how the library names were selected. Anyplace you can anticipate inquiry, you should proactively describe the rationale behind the decisions that led to your IA.

When completed, the IA documentation should be a clear guide for how to navigate the entire ECM application in the SharePoint farm. But the logical storage of content does not stop there. Content types are not only part of where content is stored, but what is stored with it.

Earlier, we described the content type as the container for the content and its metadata. By the time most organizations reach the configuration of content types, they become weary and fail to go into much detail. They might elect to use out-of-the-box content types, which provide nominal value, or they might allow users to create their own content types, which results in content type sprawl similar to the issues surrounding a shared network drive.

The reason content types are so important is that they are the only way to embrace the future of flatter IA designs and a minimalist approach to document libraries. By using content types, you can leverage the power of documents-associated metadata to slice and dice information in numerous combinations. This allows users to browse more precisely, search faster, and make better decisions about the content in views.

The first part of documenting content types is providing a detailed summary of how content types are created, the thought process behind how they are used, and what policies were followed when creating them. The following four key areas need to be included when documenting your content types:

After you have given the high-level description of the methods used to create the organization’s content type, you need to define what the final sets of content types are and how they are used. One of the big benefits, as shown in Figure 7-3, of the content type hub is that, at minimum, you can use screen shots of the content type hub and content type configuration page for this portion of your documentation.

Figure 7-3. Content type hub.

As you can see, all content types are listed in one place. For the custom content type group, we recommend that you place all content types where they will be visible. The content type hub is a very nice tool for listing all content types in one place. In a pinch, this will suffice, but we recommend that you also create a separate table that includes more detailed information about content types, as shown in Table 7-3.

In this example, we detail two documents of content types: Medical Leave and Policy. Both are created in the content type hub, and for this organization, both are derived from a base content type that is the retention schedule year.

Medical Leave is derived from the root content CYE+7, which is derived from the content type Document, which means that this document will be deleted 7 years after the year it was created. It has the columns Created Date, Modified Date, Title, Author, Department and Leave Date. Department and Leave Date are unique content types.

Department is based on a managed metadata column that lists all departments, and Leave Date is simply a date field indicating the employees’ last day of work prior to medical leave. Most of the columns in both content types are required. The organization should already have a predefined description of how they determine mandatory fields.

The Medical Leave content type is available in only one library, the documents library of the HR site or site collection, while the Policy content type is available in four sites or site collections: Operations, HR, Legal, and Executive.

When documenting these content types as outlined in Table 7-3, it’s often easier to list only the columns that are unique to a content type. For example, in this case, the Leave Date column for the Medical Leave content type is unique across the board, whereas Created Date and Modified Date will be present in all content types.

One of the most common custom types of columns that we talk about in this book is managed metadata. This column links to the managed metadata service (MMS), where it pulls from a specific term set or from a subset of a term set. Frequently, content types will have more than one of these types of columns, and this is the location for all taxonomies, which is another piece of your IA that should be documented.

The purpose of documenting your taxonomies is slightly different than for content types and the SharePoint farms IA down to the library level. Because of how taxonomies are implemented in SharePoint 2013, change control can be difficult. Properly designed taxonomies should not be updated frequently and should not be updated by the user because this is a quick path to sprawl and a return to the shared drive paradigm that quickly creates a digital dump of content and terms.

The individual taxonomies will be initially created in comma-separated value (CSV) files. We recommend that you have one file for each taxonomy that should be set up as shown in Table 7-4, in a strict format with no deviation.

These values are defined to support the following purposes:

When the taxonomy is completed, it will be uploaded to the MMS service application. While it is not available to be set up in a specific content type and used in the farm, it should be considered as read-only at this point. If you were to make edits to the taxonomy inside of the MMS service application, you would have no record of the change. When this happens once or twice, it’s not a big deal, but over time, the collective amount of changes causes a problem for migration and understanding of setup. This is because you are unable to export taxonomies or merge them with the original CSV file in SharePoint.

This is why we recommend that all changes to taxonomy happen in the CSV file directly. To do this in an effective way, you need to track those changes. This is the primary purpose of documenting taxonomies, in addition to documenting the policies and principles that defined them.

In your taxonomy documentation, as with content types and IA, you should start with a description of why taxonomies are being used, how they will benefit the organization, and the high-level rationale that drove their creation.

It is very important to follow the rules that we outlined in the Chapter 4 examples:

When creating your terms you want to follow the nine step process we have outlined:

After you have documented how taxonomies were derived, you can list the taxonomies, their location, their last modification date, and history of changes, as shown in Table 7-5.

There are a few key elements to this table. First, we list the type of taxonomy. We explained earlier that there are limited numbers of types of taxonomy: functional, period, and regional. In this list, you will also see Folksonomy and Listing. Folksonomy is the flexible form of Taxonomy that is created and driven by the users. Therefore, it might not be something you track, but in any case, it is still something that we recommend against. Listing is a way to avoid using drop-down type menus to pick from a flat list of items. In this case, it’s simply a list of the departments, as opposed to a standard taxonomy, which would normally indicate a term used to define the content’s use in the organization. Some organizations might elect to continue to use the drop-down style column. The benefit of putting it in an MMS term store is having one place to manage all listings of content.

The other key element to this Table 7-5 is the location. As you can see, we are recommending that even your created and published taxonomies should be stored inside a library in SharePoint. This can be either the ECM Hub or a site collection or site belonging to the content managers and records managers. This gives the added benefit of tracking changes for you so that you do not have to include them in this tracking table.

Table 7-5 gives a minimal picture of where and when taxonomies were updated. The process of the update when updates are not frequent is to update both in the CSV file and in the MMS Service application term store. For frequent updates, we recommend that you consider third-party tools for synchronizing CSV files with SharePoint MMS.

Now that we have documented all components of the IA by creating a map of the entire SharePoint farm, we need to define how this configuration aligns with the content stored in SharePoint and the people who use the platform.