If you want to successfully implement SharePoint in your organization, then you need to clearly define and manage your information architecture (IA). There are a number of things you need to do to define your SharePoint IA and here are five critical steps to ensure you are on the right track.

Information Architecture in SharePoint

The best way to think about information architecture is that it’s a blueprint, a way to organize your information so it’s easy to find by the right people. And while SharePoint isn’t the only platform that is in need of a well defined IA, it is one, that if badly defined, can cause more information silos and frustrated employees than you can even imagine.

The key to getting it right, is to plan it right, from the start. Now we hear some of you smirking because you know that what you have now is in such a state that it seems impossible to fix. Rest assured, it can be done.

Planning your IA

Information architecture is a key element of your governance strategy. Governance is a huge topic for SharePoint, everyone talks about it, everyone has their own ideas on how to implement and manage a SharePoint governance strategy and the associated IA, and you know what? It’s all really good advice. But there’s just so much of it out there, how do you get focused and started?

We told you that there are a number of elements that make up your SharePoint IA, including:

  • Sites and Site Collection Structures
  • Content Modeling and Content Type Definitions
  • Metadata Schemas and Taxonomy Management
  • Search Integration
  • Managed Administration

You say, that’s great. I get it, but now what? Where do I start? There are five critical steps that you need to do/ask yourself and your organization to get you on the right track.

Step 1: Understand Where You are Coming From

A clean slate is great place to start, But it’s typically unrealistic. Maybe you are a new company and have the opportunity to plan your information architecture from scratch. Or maybe you have a pretty well defined IA with your current system, it’s just lacking some functionality that SharePoint can provide, so you’ve decided it’s time to move on. You are probably one of the lucky few.

Others come from a range of crazy fileshares, desktop folders, outdated intranets and multiple business apps. It’s like trying to find a needle in a haystack, unless you are the knowledge worker who has been with the company for many years and have developed your own little system of playing “where’s Waldo?”

For many, SharePoint 2007 was implemented in their organization in an ad hoc, sometimes grassroots manner. Which means that no one had central management of the platform. Divisions/departments and often groups within those divisions/departments were going along doing their own thing, building SharePoint sites, defining their own metadata, assigning their own permissions. Multiple copies of documents scattered across folders and sites, search severely lacking, but oddly enough, many people happy in their little worlds, because they could do what they wanted, and they could usually do it quickly.

What’s the point here? Know what you have now. Have it well documented and have a clear understanding of how the users of that current system(s) feel about it. Don’t assume everyone wants a change, regardless of how good it would be for the organization overall. If you don’t really understand where you are coming from, you won’t be able to properly figure out how to get where you need to be.

Step 2: Know What Players Need to be Involved

Is it obvious to you who should be involved in defining your new SharePoint information architecture?

  • The business users/information workers who use the current system(s) and will use the new SharePoint implementation. These are your advocates (including your devil’s advocates). If you don’t have some naysayers on your team, you’re missing the opportunity to convert a potentially large group of unhappy users -- these people can become your strongest advocates.
  • Compliance / record managers who know the rules and regulations that your content must adhere to.
  • Your current information architect, assuming you have one. Maybe this person hasn’t managed a central IA yet, but it’s likely they have been involved in one or more projects that involved knowing what content is out there, how the business works and what the business objectives are.
  • Your SharePoint 2010 Information Architect. You are going to need someone on your team that understands how SharePoint 2010 works. This is the platform you have chosen to work with, that means you need someone who knows how your information can be best implemented within it. You can define your IA without considering how SharePoint works, but we wouldn’t want to be the IT team trying to implement it.

Those are the key roles. There are others, including other members of IT and business leaders. The key is that you need to find all the right players that will help bring everything out into the open, get it all laid out on the table and help define the best approach to move forward.

Step 3: Understand How Content Flows across the Organization

As we indicated earlier, in many situations content is created and managed at the department level, and sometimes lower. But that doesn’t mean that something developed within one department isn’t useful to another. It’s quite the opposite actually.

We solve problems by bringing the right people to them at the right time....The idea that a team is not defined by a specific organizational structure is finally so accepted a truth that it hardly stands mentioning now. We know that differing perspectives, give and take, mutual analysis and common understanding leads to better, faster learning -- which means better, faster outcomes.”

Today’s successful organizations are not tied down by a top down hierarchy, each department living in its own little world. Instead we are seeing many more cross functional teams and the need to share information across the organization.

So what does that mean for you? Understand how content is used across the organization -- who owns what, who should have access to it, who can change it. SharePoint 2010 is vastly different from its predecessor in how you can manage content types and metadata. It has also improved how you can organize your information across sites and collections (and even SharePoint farms) and still make it available to all the right people regardless of where they are in the organization.

Step 4: Your Plan to get Started

So now you know what you have, who should be involved and how your content is shared across the organization. What’s next? Think about the best way to proceed.

If you are a small organization, going into full strategy, design and implementation is probably a good choice. If you are starting from a clean slate, same thing. Get your IA implemented and up and running, so you can move on to the maintenance aspects.

But, if it’s a mess you are coming from, and/or your organization is large and complex, going into a full implementation and migration is a scary prospect, one that even your toughest business executive would likely shudder at doing. In this situation, consider piloting your new information architecture. Get your practices in place and then incrementally move people over. Note that we aren’t saying migrate by department necessarily, because if you have a number of those cross-functional groups we just talked about, then you are defeating the purpose of a well defined IA.

Be prepared to adjust both your IA and your practices as you test them out. Having the right tools to help make changes quickly will be important at this stage.

Step 5: Plan for Change

A new SharePoint 2010 implementation is not going to happen overnight. You have to build awareness of what you are attempting to do and show the importance of this new information architecture (a pilot is a great way to this). People are also going to have to be trained -- out of the old ways and into the new ones.

All the while this is happening, the business continues on. It won’t stand still while you define and implement your new IA and migrate to SharePoint 2010. Which means you need a plan to deal with the changes that will arise. A plan that will continue to evolve as your implementation matures.

Benefits of a Proper Information Architecture

We said that the three key tasks that need to be completed when you define an information architecture were to understand:

  1. the Business/Context
  2. the Content
  3. the Users

This is why the five steps discussed above are so important to do before you even sit down and start wrapping your head around SharePoint sites/collections, content types/metadata, permissions, etc....

Doing these five steps will:

  • Ensure you provide central access to your information
  • Reduce the duplicate content in your organization and ensure there is “one version of the truth”
  • Allow you to develop content standards that support cross-organizational sharing
  • Foster an environment of sharing and collaboration.

Final Thoughts

Often the hardest part of defining a SharePoint information architecture is really understanding what you have now and how to change that. That understanding is a mix of knowing what and where the information is, along with who needs access to it, but also understanding the everyday knowledge worker who is using that information and will be using your new environment. Making management happy should be a by-product of making your key workforce more efficient and productive. A well-defined SharePoint Information Architecture will get you on your way.

Editor's Note: You may also be interested in reading: