Information Architecture: Defined

By Steven Pogrebivsky posted 12-04-2012 13:31


Consider this. Microsoft has sold over 125 million licenses of SharePoint. It is a multi-billion dollar business. SharePoint is a platform that everyone seems to have, many actually use and most don’t understand how to implement and manage properly. There is no platform more in need of a proper information architecture than SharePoint. But what exactly does that mean?

What is an Information Architecture?

Before we dive into the ins and outs of information architecture for SharePoint specifically, it might be a good idea to define what an information architecture is. One of the simplest definitions I’ve read is:

“Information architecture is the term used to describe the structure of a system, i.e the way information is grouped, the navigation methods and terminology used within the system.” (source -

To paint a better picture, think about starting a new job. You get assigned a desk and before you even get to drink your coffee, someone from IT pops by to get your computer set up. He makes sure you have access to the Intranet, to SharePoint for working on projects and to all the file shares your department has access to. You’re all set.

So when your new boss gives you your first assignment to create a new project site and pull together a list of documents as well as create several new ones, you think you’ll be fine, all the information you need is at your fingertips. Unfortunately, there’s no rhyme or reason to the file share, you have no idea how to set up your project site because every project you have access to has done something completely different and all your searches are coming up empty.

Think of an information architecture as a blueprint, a way to organize your information so that it’s easy to find. The example above? That is what happens when an organization falls to properly plan and implement an information architecture. Unfortunately, it’s not so easy to do.

3 Elements of an Effective of Information Architecture

According to Lou Rosenfeld and Peter Morville, there are three key tasks that need to be completed when you are defining an information architecture: understand the business/context, the content and the users.

  1. Business/Context-- You need to understand the business objectives and the organizational structure. Any constraints on time and budget will also have to be considered.
  2. Content -- You must have a clear understanding of all the content that is to be stored in the system. Think of this like a content audit where you document where all the information is now, who has access to it, who needs to have access to it, what it’s used for, etc..
  3. Users -- Understand the users of the content, their behaviors, tasks and their expectations. 

All three things, clearly defined and understood will help you identify the most appropriate information architecture for your system.

Information Architecture & SharePoint

Maybe you are thinking at this point that having a great information architecture is critical for any content management system you implement, this is not a problem unique to SharePoint. And you are correct. No matter what system you choose to implement, it is critical to get your IA right or your information is simply taking up space and your users will be frustrated.

The fact is though, that every day we hear one more horror story about a SharePoint implementation gone wrong. SharePoint is a platform that offers so much capability and is so easy to get started with, that many organizations have allowed their departments and/or employees to simply jump in and get things started. They haven’t taken the time to consider what they really need to do to get their information managed right and available to the right people.

What many have ended up with is simply another file share to match the confusing, disorganized one they already had. They have so many people administrating their own little SharePoint sites, managing their own content (content that is often similar across groups/departments/divisions), and no one understanding how it all works.

And it gets worse. For those who adopted SharePoint 2007 and found themselves in this situation, the idea of moving to SharePoint 2010 is scary. They don’t want another series of mini-silos of information, another giant file share and a potential compliance and archiving nightmare.

Which is why a well-defined information architecture for SharePoint is necessary.

The Basic Elements of a SharePoint Information Architecture

To get started down the right path, you need to understand some of the elements that make up your SharePoint information architecture:

Sites and Site Collection Structures

Your SharePoint implementation is made up of one or Site Collections within which you can have one or more Sites. A Site Collection allows you to group together a number of sites to manage. Sites within a collection share common features such as shared permissions, content types, and in some cases, a common navigation. These are the places where your employees spend their time.

Content Modeling and Content Type Definitions

Content Modeling is the process of organizing your content into logical groups, called Content Types. Content Types have a number of attributes, called metadata, information management policies (who can view/edit the content, auditing levels, retention requirements, etc..) and usually one or more workflow processes that define how the content type should be managed.

Metadata Schemas and Taxonomy Development

Metadata schemas and taxonomies allow you to control how information is defined in your system. This ensures consistent tagging of information using predefined terms as much as possible. It also ensures that information is more easily found within search queries.

In SharePoint 2010 you can create what’s called Managed Metadata. This is a centralized approach to defining a hierarchical set terms and enterprise keywords that can be used with the content types in your SharePoint environment.

Terms and term sets are basically a word or phrase (or group of words/phrases) that can be associated with a content type column (property), enabling you to restrict the values entered into that column. You can create terms and terms sets within the boundaries of a Site Collection or globally across your SharePoint environment.

Enterprise keywords are basically words or phrases (or tags) you can add to a content type in a single column. Unlike Terms, they are not hierarchical, and although they can be predefined, you can allow users to enter their own keywords -- creating a folksonomy of sorts. 

Integration with Search

Making information findable by the people who need it is critical and search is a common tool that users go to to find things quickly. Which means you have to really think about how your information is managed to make it more findable via SharePoint search.

In SharePoint, you have your standard search that works against all crawled attributes (or properties) defined for your content. But if you want to offer users a more advanced, refined search capability, you have to define ‘managed properties’ which are essentially crawled properties you define as key search properties.

To understand what properties you want to make available as managed properties, it’s critical to have a solid information architecture defined.

Managed Administration

Another important element of defining your Information Architecture focuses on who has access to your information and what that access is. Many users will not work in a single SharePoint site, but will instead need access to a number of different sites and site collections. It’s important to outline the roles and responsibilities of the users of your information, so that you can best define the security schema for your SharePoint environment.

And people don’t stay forever, or at least not always in the same part of the organization. So you need to define the policies that will support changes like hires, moves and fires across your SharePoint environment.

Information Architecture is Not a One Time Activity

Probably one of the most concerning aspects of defining an information architecture is the belief that it’s a one-time deal. It isn’t. Yes there is a lot of work to be done up front to get the IA defined and in place, but IA is not static. Because business is not static.

At a time when innovation is critical to success, organizations constantly adapt and try new things. People come and go, companies are bought and sold. That means your information architecture is a living, breathing plan that needs to be constantly monitored and adapted as necessary. Now that’s not as scary as it may seem, because in most cases you aren’t starting from scratch to develop a new IA, but simply evolving the existing one. But it’s not always simple either.

Final Thoughts

The role of a SharePoint Information Architect can be a tough one, especially if you are moving from out of control file shares or a poorly managed SharePoint 2007 implementation. But the rewards if you do it right are happy users. The truth is most people don’t notice a good IA, but they sure notice a bad one, because it means they can’t find what they are looking for. Wouldn’t you prefer to be anonymous than the one who gets the evil eye when you approach the water cooler?

Now that you understand what an information architecture is, what elements it is comprised of in a SharePoint implementation and why it’s so important to monitor and adapt on an on-going basis.

#informationarchitecture #sharepoint #SharePoint #ContentManagement #Taxonomies