—Tim Berners-Lee

How do you organize information when a typical organization contains multitudes of content, ranging from related content to independent, relevant, and active content to historical and horded? This diversity and volume presents a challenge when designing an enterprise content management solution, a challenge you can diminish with your information architecture on hand to support your efforts. In this chapter, I provide guidance on analyzing and designing an information architecture. I share techniques on how to create a data dictionary and how to perform a card sort to analyze and organize information. Finally, I walk you through how to implement an enterprise taxonomy to define the metadata that your organization will use for categorizing and classifying its content.

After reading this chapter, you will know how to

• Describe information architecture and its purpose.
• Analyze your organization’s existing information architecture.
• Create a data dictionary to define data fields and their source.
• Perform a card sort exercise to organize information.
• Build your information architecture.
• Implement your enterprise taxonomy design.
• Design your site structure.
• Design your navigation.

Understanding Information Architecture

Information architecture as a discipline concerns itself with the organization of information. This applies anywhere you want to organize information, not just for enterprise content management within an organization. Nonetheless, information architecture is particularly relevant for an enterprise content management initiative because its core purpose is the process of organizing information for better management throughout the information life cycle.

A typical organization contains a lot of information and its information may be growing at an exponential rate, leading to management challenges and the need for an effective enterprise content management solution. You can organize information by its physical location or by the metadata that you associate with it. Organizing a piece of content by physical location is helpful, but it only provides a limited range of organization, mainly the folder structure’s single dimension of grouping content together in a single directory structure. This is more of an archaic way of organizing content, and it is largely a legacy process carried forward from physical document storage, back when a physical document could only exist in one physical place and so it made sense to use location as the primary organizing method.

Although organizing by location still provides some use, metadata provides a much richer set of capabilities to organize information by abstracting away the single dimension of a folder structure and enabling the multiple facets available to organize information with metadata. Metadata provides the fundamentals of any modern information organization system.

Metadata is information about information; it provides the vehicle for a unit of information to self-describe itself. When you tag a piece of content with metadata, the term also provides a reference pointer to the content, empowering you to associate several different metadata terms with a single piece of content, unlocking the multidimensional power of the potentially multiple reference pointers. You can categorize metadata into the following three general categorizes:

• Descriptive: Metadata describing additional aspects of a unit of information, such as its subject, relevant keywords, and classification.
• Intrinsic: Metadata describing a unit of information’s anatomy and makeup, such as its file type and file size.
• Administrative: Metadata describing how to manage and process a unit of information, such as who created it, whether it is in a draft or published state, and its approval status.

I mention these categories just to help you think about the different types of metadata that you can collect. The categories themselves are not important, and unless you find it useful, you do not have to categorize your metadata with them. As you design your information architecture, you identify a list of metadata that you can use to organize and manage information in your organization. The process of identifying and listing metadata eventually builds out your enterprise taxonomy.

Your enterprise taxonomy creates an index of information within your organization, similar to the index in this book. For example, you might find several different terms in my book’s index that all point to the same page, depending on the topic I am discussing. I call this the multidimensional or multifaceted view for finding content. In contrast, a single-dimensional view is the table of contents and chapter structure: a chapter only points to one specific chapter, and sections within the chapter only point to those specific sections.

The table of contents and the chapter structure is the physical layout, akin to a directory structure on a file system. This provides you with a way to “click through” in a sense (or quite literally, in the case of e-book versions), allowing you to discover things in context. For example, you will find topics related to information architecture in this chapter, but the individual topics differ between sections. Nonetheless, the information is contained within this chapter. Alternatively, if you looked up a term in the index, you will find some topics point to several containers, spread across sections in different chapters, and multiple terms might refer to the same topic or section.

Similarly, your SharePoint site containers provide a single-dimensional view of discovering content, as I discussed in Chapter 2. The container hierarchy enables users to click through and discover information in context. The Managed Metadata Service, like a book index, provides the multidimensional view, enabling users to discover content across multiple containers using multiple terms. Figure 4-1 illustrates the single-dimensional view of a folder structure vs. the multifaceted view of metadata terms.

When you associate a taxonomy term with a user’s profile, you create a link between users and the different units of information that a term references. This helps to facilitate users discovering relevant content based on the metadata tags they associate with topics in their profile. It also identifies topics that relate to the users themselves, in a similar way to how a term can point to multiple pieces of relevant content. This concept of a people index can offer a type of organizational yellow pages, where a term references multiple people and you can find people by topic rather than by name.

Your taxonomy is central to your enterprise content management initiative and it is not something you can fake or omit; everything else in the process really depends on first getting at least a good start with your information architecture. The challenge is in identifying the metadata for your enterprise taxonomy, and often this may feel like a daunting task, but if you follow the process and approach I share in this chapter, you should find this undertaking completely achievable. Start by analyzing the information you already have, your organization’s existing information architecture.

Analyzing Your Information Architecture

Back in Chapter 3, I encouraged you to build an inventory of your organization’s content. And as I mentioned then, this inventory serves as the core data you can analyze to understand what type of content your organization uses, how it organizes it, and what systems or general storage locations handle the content. This is the best starting place to analyze your organization’s information architecture.

You can expand your content inventory by also including articles and other web pages on your intranet, if you have not done so already. This will complete the content picture for you with the text-based web content, and it will also uncover additional information about how your organization structures and manages content, along with the types of web content it publishes. It will start to give you a sense for how simple or complex your web content is, allowing you to start envisioning any opportunities for a web content management solution that you can incorporate into your enterprise content management initiative.

In addition to the content itself, you can analyze the folder structures in the content storage locations (or the path structures in the case of web content). Again, this will deepen your understanding of your organization’s content and how your users organize it. This in turn will give you insights into how users group content together as well as the folder names that they use to categorize the content.

You can extend your analysis to move beyond the content and capture details about the metadata your organization uses to categorize information. You can learn a lot strictly from analyzing the content and its context, and now you can build on this by studying different ways to describe and classify content. This information will be useful as it provides the majority of your information architecture, at least initially. The tool I use to analyze the metadata throughout an organization is to create a data dictionary.

Building Your Information Architecture

Building out effective and efficient information architectures is not simply an engineering exercise where you can apply formulas or a crawling agent to calculate and autogenerate your taxonomy. If you have tools of this type, this might give you a start with how different kinds of content relate to each other and your overall organization, but this should merely serve as a guide. You can also purchase some prepackaged taxonomies, particularly industry-specific taxonomies. Again, you should use these to gain a start, where you can take advantage of common patterns and structures, but you will still need to plan for your own analysis and design activities to move beyond the autogenerated or prepackaged taxonomy solutions.

Information architecture is not so clear-cut; it is an art where you make design decisions based on trade-offs and your organization’s priorities. What is true for one organization is not necessary true for another. Any insights will be helpful, such as outputs from automatic tools that crawl your content or from results of a card sorting exercises, but the information architect’s job to take all that information in and translate it into the information architecture.

In my process, I like to drive my information architectures by focusing on how the organization will use a piece of content in the future. Metadata enables a piece of content to self-describe itself, to provide additional details beyond the unit of information’s contents, all of which provides value toward some future usage. I analyze and consider this future value and future usage by asking the following questions for a piece of content:

• What terms will users use to search for the content?
• What metadata will help users determine the relevancy of the content?
• What categorizations will guide users toward proper use and handling of the content?
• What metadata will the system use to process the content?
• What additional information do regulatory agencies require?

One challenge with metadata is its delayed value—the user tagging a piece of content creates future value by associating a richer set of information to the content, providing information that other users can take advantage of when accessing the content in the future. However, that future value comes with a present cost in terms of the time a user spends tagging his or her piece of content as they add it to the system. To complicate this matter further, the user may never realize that future value him or herself, so they are really investing their time today to provide future informational value for their colleagues.

This present cost vs. future value concept is a trade-off between efficiently capturing content and effective discovery and long-term use of content. Users may not want to have an excessive amount of required metadata slow them down and burden them as they create a new piece of content. They may even feel that a records manager or librarian should be responsible for categorizing content rather than burdening the content producers.

If you require too many metadata fields for a piece of content, then users may end up inputting faulty information to satisfy whatever required field constraints you associate with a type of content. Although the idea of capturing and using a range of metadata might sound appealing in theory, if the end result is users entering garbage data just to work around the constraints, then including this metadata does not benefit the information architecture.

To ease the data-entry burden of metadata, I investigate each individual metadata field that I want to include for a type of content and I look for opportunities to reduce or avoid the user’s involvement with categorizing and classifying the content they are capturing. I use the following questions to analyze ways to simplify the process of capturing metadata:

• Can the system infer the metadata field’s value rather than require user input?
• Can the system delay or defer collecting the field’s value?
• Can the system autopopulate a field’s value during a workflow process?
• Can the system capture a field’s value inline within the document, such as through a document field in the body of the document?

This chapter focuses primarily on the types of metadata that you can use to categorize and classify content, ultimately organizing your organization’s content. However, you will also capture metadata to self-describe content, to support managing its life cycle, and even to meet regulatory compliance, none of which may relate to how users interact with the content. Where possible, I prefer to autogenerate those metadata fields as well, using the same process and questions as the categorization and classification metadata.

You can look for opportunities to autopopulate metadata in a few different ways. The content type itself can have some logic to infer certain fields based on things such as who creates the content, what location the user creates the content in, what values he or she sets for other metadata settings, and the like. You could even analyze body copy of the content itself and attempt to infer metadata values from it. This takes some upfront planning and design, and often it will require a third-party component or some custom development to implement, but its value balances the cost of capturing content with the value of later retrieval and consumption.

A couple of ways that you might approach autopopulating metadata include developing a custom component with the logic. You can hook the custom component’s logic into the process with an event on the list or library, or through a workflow that you associate with the content type. Whatever creativity and effort you invest now will add to the effectiveness of your enterprise content management solution by reducing the burden on users having to enter a lot of metadata as they capture content. Alternatively, you can also look for ways to delay capturing metadata until later in the process, such as after content edits or when a content retention workflow initiates.

With your list of metadata you wish to capture, your next step is to organize it into a structure. Some metadata categories or classifications will be simple lists, a single level deep, often implemented in what I refer to as a closed list—a list of finite items that users can select an option from to apply to a piece of content, but which a user cannot append items to the list. Some lists may be open lists, where users can append items with whatever term they find relevant, such as the “Keywords” term set that users can use to tag content with any term they wish.

The card sorting exercises will give you some indication for organizing and structuring the metadata terms you identified. Some groups of terms will naturally go together and form a term set, while others take some analyzing and reflecting on your design options. I usually experiment with different groupings and structures as I build out taxonomy schemas, some of which I revise later (even after a production deployment), while others turn out to work well.

For those terms that I do not yet have an idea for how to group them, and there are always some, I usually just add them to a generic list, one similar to the Keywords term set. This gives me the opportunity to implement these terms and to make them available for users to tag their content with, even if I do not fully understand the term’s purpose yet, since I can return later to analyze how users use those terms. At that point, I can refine my taxonomy schema and place the term in a more appropriate term set.

My point is that you can change your mind and adjust things later; you do not have to get your taxonomy perfect before you can make progress. One beautiful thing about metadata in SharePoint is its ability for you to change and adapt it as you evolve and refine your requirements. You can move or merge terms, depreciate terms, and even rename terms, all without causing major ripple effects throughout the system and without demanding any major rework efforts. Do not get stuck in endless cycles of analyzing and revising your taxonomy, cycles where you try to design the perfect schema—things change too quickly and your organization will always reveal new information. Try out your taxonomy designs and move forward with the confidence that you can make adjustments and fine-tune your schema as you discover what works and what is less effective.

Once you have a design that you are satisfied with, or at least when you have a slice of your overall information architecture ready, your next step is to implement that design in your environment. In SharePoint 2013, you implement your information architecture through your enterprise taxonomy, through the site structure, and through reference links or navigation menus in the user interface. To implement your enterprise taxonomy in a SharePoint environment, you add it as term sets and terms to the Managed Metadata Service, which I walk you through next.

Implementing Your Enterprise Taxonomy Design

SharePoint 2013 provides a service application to centralize metadata management. You can provision an instance of the Managed Metadata Service to store, manage, and provide metadata to SharePoint sites throughout your farm, and you can even share this service across farms, further centralizing your enterprise taxonomy. Metadata is a paramount service in SharePoint as other services depend on it to provide their own service, such as the User Profile Service and the Search Service. As such, implementing your information architecture as managed metadata has a ripple effect throughout your SharePoint deployment as other aspects of the service take advantage of and utilize the metadata.

The Managed Metadata Service also manages the enterprise content type hub, a site collection containing the site columns and content types to synchronize with other site collections across a SharePoint deployment. This allows you to standardize and centralize content types for your organization, including the types of metadata you want to capture along with the types of content.

You will implement your enterprise taxonomy as term sets and terms in the Managed Metadata Service. To start, navigate to the Term Store Management Tool page by clicking the Managed Metadata Service instance on the Manage Service Applications page in SharePoint Central Administration.

1. Create a new term group by expanding the context menu on the Managed Metadata Service root node, and then clicking New Group. For this example, name the new group Enterprise Taxonomy.
2. On the context menu for the Enterprise Taxonomy group, click New Term Set. For this example, name the new term set Departments.
3. On the content menu for the Departments term set, click Create Term. Enter a department name, and then press enter to create a new term for another department.
4. After creating terms for several departments, create a term for the Information Technology department. On the context menu for the Information Technology term, click Create Term. Create a Service Desk and System Administration child term for the Information Technology term, as Figure 4-2 illustrates.

Metadata and your enterprise taxonomy serve as the essence of your information architecture. If you do this well, anything else you do related to information architecture merely enhances this core. I come back to the topic of metadata and your enterprise taxonomy repeatedly throughout this book as I discuss many different aspects of enterprise content management. It is important to make a start with a taxonomy and continue to move forward rather than to be stuck in over analyzing and trying to perfect a hierarchy of terms, but at the same time, recognize that this is a foundational piece, central to everything else you do with your enterprise content management initiative. Make a valiant effort on your first pass to design a metadata solution, and then be prepared to come back and continue evolving it.

With the crucial metadata piece started, the next aspect of information architecture relates to the site structure. There was a time when your physical structure was the most important aspect, because that was traditionally the primary way to organize information, but now that metadata should act as your dominant means to organize your content, the site structure details are not as pertinent. In fact, to add precedence and further enhance my metadata strategies, I take an almost anti-structure approach to my site structure designs, as I describe next.

Designing Your Site Structure

I spent some time so far in this chapter steering you away from focusing on the physical structure of your information architecture, instead highlighting the role of metadata and virtual structures that you can implement by using reference links or filtered views. However, at some point, you do need to implement the physical storage structure for the actual content containers. As I discussed in Chapter 2, the site architecture does involve a hierarchy of content containers, yet in this chapter I tried to steer you away from building a deep hierarchy.

Having a deep hierarchy of child sites is not horrible, and it certainly does come with some end-user convenience-related benefits, most notably the ability to inherit site settings such as security groups and navigation. This can be attractive, but I prefer to avoid a deep nesting of sites within a fewer number of site collections, and instead I lean toward a flat structure consisting of many site collections, each with a shallow hierarchy of child sites.

I find that the benefits from having many independent site collections loosely coupled together using reference links far outweighs any short-term conveniences with a tightly coupled hierarchy of sites and child sites. For me, the site collection’s boundary provides the greatest long-term benefits and flexibility. One major aspect of a site collection’s boundary is the ability to move it to a new content database to distribute and level the storage load in your SharePoint farm, offering you an isolated and granular scope of content to move without any complex dependencies or ripple effects throughout the system.

Another operational benefit with a site collection’s boundary is the ability to apply a quota to a site collection in a targeted and manageable manner. If you have a massive site collection with a variety of user groups storing their content in it to collaborate, then you will probably find that site quotas will be largely ineffective. I have frequently come across site collections as large as 70 GB or 100 GB with hundreds of users collaborating in different sites within the collection, and the bottom line is that a site quote just will not be effective in these sites for helping to manage system resources. What’s the point of even enabling the quota at that point?

Sure, there are valid reasons for site collections of this size, particularly for archival sites or sites that contain a heavy amount of rich media, but I find these are not the rule but that they are exceptions to the rule. If I take the average collaboration-related 100 GB site collection and break it up into at least 10 or 20 or more separate site collections, then I can track the content growth more effectively with site quotas. Best of all, I can spread that content across multiple content databases, thus enabling me with more operational options, such as to target and maximize database system resources to the busiest site collections.

As you can probably tell, I generally default to a new site collection unless I have a valid reason to go with a child site instead. It is not a golden or blanket rule, but I do tend to encourage more site collections with shallower hierarchies to maximize flexibility in the future. This feels similar to normalizing tables in a database, and perhaps it is my background in database design underlying my philosophy for site structure design. With a normalized database, you have less coupling of tables, as each table serves its own distinct and focused purpose, all using relationships to work together and act as a cohesive unit. This low coupling liberates you because it makes the database less fragile with respect to changes. In the same way, a low coupling of site collections, all independent and self-contained, liberates you because it makes your SharePoint environment less fragile when it comes to future changes and general maintenance.

In addition to the flexibility with allocating site collections in content databases and applying more granular quotas, your future self will also thank you for the more focused and concise sites. These sites are potentially easier to retire or archive as a unit, and this minimizing the need to manually identify a subset to retire deep within a site hierarchy, a deep hierarchy that likely results in users skipping the manual process to retire their content and instead allowing those areas to persist. You can detect dormant sites easier when they are distinct, as opposed to those that intertwine with a bunch of other child sites, and this detection can reduce the need for manual processes to manage the content life cycle.

One challenge I find with a flat site design that uses multiple site collections is the site provisioning process—once users have a site, they can provision child sites to build out a site hierarchy as they please, a hierarchy that feels natural to them for organizing their content. Users have been conditioned for too long to organize their content using a single-dimensional folder structure, and so this is what will feel natural and make sense to them.

The reality is that content needs a container, so some aspect of a content hierarchy is necessary. On top of that, I do not want to confuse or stress out my users by limiting the content hierarchies they want to work in. Instead, I try to design the solution so that it is easy to create new site collections, and then I promote this process with users through things such as training materials. Inside the site collection, I do not fret too much about the structures and hierarchies that users wish to work with. By designing the site creation process around the main site collections and managed path groupings, for the most part, future sites tend to follow the same pattern.

A good managed path strategy logically organizes common sites under common URL paths. Most users will then notice this pattern and try to follow it for their own site structures. I start with the following managed paths for almost any SharePoint deployment:

• Sites: I use the default sites managed path that SharePoint adds to web applications, and I plan for the collaboration-related sites under this managed path. These sites types can range from team sites and wikis to community sites and team blogs. You can divide the sites up further under additional managed paths if you think another term will provide a good logical grouping of site types.
• People: I change the default personal managed path that SharePoint uses for My Sites because I find people reads better in the URL to me. If I share the My Site web application with other types of site collections, then I set the My Site managed path as people. However, I prefer to dedicate a web application to host My Sites because it enables limiting the scope of settings on the web application, such as the self-service site creation permissions. In this case, I usually have a web application URL with the My Site host at http://people and the managed path for personal My Sites set as sites.

You might also add other paths to this list with paths for department-related sites. You can also consider paths for specific types of sites, such as a Projects path for project sites. I generally keep my list of wildcard managed paths short and simple, but occasionally I do come across requirements to add to the list. For example, with my education clients, I usually add a classes path under which to create class sites.

You can add a managed path to a web application by navigating to the Manage web applications page in SharePoint Central Administration, selecting a web application, and then clicking Managed Paths in the ribbon. This will open a Define Managed Paths modal window similar to the one in Figure 4-3.

Publishing portal sites are often at the root or close to the root of a web application. Rather than use a wildcard managed path as I would for a collaboration site, I use an explicit managed path for portal sites to keep the site paths close to the root. For example, with a portal homepage at http://portal and the need for a human resources portal site close to the root, I would create an explicit managed path at http://portal/hr to create the human resources site there.

For the most part, your site design is a flat structure, consisting of a lot of site collections that you can logically organize under managed paths. Because there are no hierarchies to physically structure your site collections, they do not take a significant portion of your information architecture design efforts. Instead, you can invest that time into designing your navigation strategy, which I discuss next.

Designing Your Navigation

Web site navigation has remained fairly consistent for years now, in SharePoint sites or any other web application. Effective navigation incorporates basic elements such as a global navigation menu and a current navigation menu to simplify the web site layout and user interaction. The navigation serves to guide a user through relevant areas of the site, to provide the user with some context of where they are in the site, and to provide a means to navigate back the way he or she came.

Where I see navigation fail tends to be where designers tried to get too fancy, such as adding some nifty elements to the interface resembling more of an artistic expression manner than a functional and intuitive design. In my experience, these creative navigation attempts rarely succeed nor do they add any value to the user’s site experience. My advice is to focus on the basics, make sure you get the fundamentals of navigation right, and look at how you can make the navigation almost transparent.

SharePoint includes a few key navigation areas. First, there is the top bar that includes links to the Newsfeed, Sky Drive, and Sites directory. You can create a custom control to add links to this navigation menu, which I recommend, and this will provide your users with a consistent navigation across the top of every site page in the SharePoint farm. You can add your custom ASP.NET user control to override the SuiteLinksDelegate delegate control and implement your own navigation menu on the top bar. I like to add a link to the organization’s portal homepage and one to the enterprise search portal. This fills in what I feel is a gap in the navigation architecture in SharePoint 2013, namely the ability for a user to get to these key intranet web properties intuitively, from anywhere, and within a single click.

For portals, you can design the site’s global navigation grounded in the results from the card sorting exercise I mentioned previously, thereby organizing the site navigation stemming from what is intuitive for its users. SharePoint manages the current navigation (also commonly referred to as the Quick Launch list) based on the structure of content containers within the site, but you can modify this navigation menu and align it with the results from the card sorting exercise as well.

In collaboration team sites, users will manage their own navigation structures, or more likely, just accept the autogenerated navigation that SharePoint provides. I have had some clients who wanted to control the navigation even at this level, but for the most part, I find this only complicates things and does not seem to provide much added navigational value. Of course, there are exceptions to this rule, particularly for those team sites that more resemble department portal sites, but generally, I focus my efforts on the bigger navigation picture.

The next major navigational area for me is the site directory, accessed by clicking the Sites link on the top navigation bar. This page contains a list of recommended sites for a user based on his or her interests, as well as sites that the user follows. In addition, you can add what SharePoint terms as promoted sites—sites you want to promote and display on the site directory page, displaying them as a tile with an icon and title linking to the site. The following steps walk you through how to add a promoted site link.

To add a new promoted site, first navigate to the User Profile Service settings page and then click the Manage Promoted Sites link under the My Site Settings section. This will open the Promoted Sites page, as shown in Figure 4-4. On the Promoted Sites page, click the New Link button and enter the details for the site you wish to promote.

Once you create a promoted site, SharePoint displays it on the site directory page that you can access by clicking the Sites link in the top navigation bar. Figure 4-5 shows an example of a promoted site on the site directory page.

By taking care of these big picture navigation areas, you address the biggest navigation needs for your SharePoint deployment by guiding users to the key web properties and allowing them to discover the rest organically, or even socially. You can continue to build on your navigation strategy, spending more time on designing your site navigation at a more granular level, but these key areas will provide you with a start and they offer the biggest impact for your navigation strategy.

Wrapping Up

You manage information as part of your enterprise content management solution through your information architecture, which identifies a way of organizing content and its life cycle. You can analyze and design your organization’s information architecture by conducting a content inventory, creating a data dictionary, and performing a card sorting exercise with users. As I described, this leads toward the design of your enterprise taxonomy, your site structure, and your site navigation strategy. Your enterprise taxonomy establishes a schema for the hierarchy of metadata that you make available for users to classify and describe their content. You can implement your enterprise taxonomy in SharePoint through the Managed Metadata Service as term sets and terms. I encouraged you to implement a relatively flat site structure, consisting predominantly of site collections, and to focus your navigation design primarily on establishing a consistent top navigation bar and a site directory, both linking to key web properties on your intranet.

This marks a pivotal moment in your enterprise content management solution, because the information analysis and design you do in this chapter establishes the central pieces around which you will build the rest of your solution. An information architecture applies to each aspect of an enterprise content management initiative, from transitory content to official records, and to content discovery in between. In the next part, I shift to focus first on transitory content and the role it plays in your enterprise content management solution, beginning with the next chapter, where I discuss collaboration content and where it fits in the content life cycle model, preparing you with how to plan for and enable collaboration-related content.