Sunday, May 5, 2013

Information Architecture

What information architecture (IA) is.  To be more precise, we need to explain a handful of topics around the subject:

  1. What is information architecture?
  2. Why is information architecture important?
  3. What is information architecture, specific to SharePoint?
  4. What is the difference between information architecture and information management (IM)?
  5. When should information architecture be addressed?






I will attempt to answer these questions with two goals in mind:
  • For those new to the concept of IA, provide an introduction to core concepts. 
  • For the more initiated, provide a framework (a checklist?) or at least a starting point to make sure the main points are being addressed in their own projects.
This isn't meant to be fully inclusive but will, I hope, get readers thinking about their own requirements to make sure they've addressed all the areas they need to.

What is Information Architecture?

 

For an "official" definition a good place to start is provided by the Information Architecture Institute.  They describe IA as "the art and science of organizing and labeling websites, intranets, online communities and software to support usability."
I quite like this definition.  It truly is a little art and a little science.  But it's a tad narrow.
Another definition I'm fond of is one I've heard Randy Williams use, which is "your company’s way of describing, organizing and discovering your content."  This is a lot more high level, which I like as it leaves room to include all of the things that make sense in your project.
More specifically, IA tends to include the following aspects of a website:
  • site taxonomy/structure
  • metadata
  • search schema
  • navigation
These are all interrelated.  In fact in many cases, one drives or informs the other. For example, if you're employing navigation that is automatically driven by the site's structure, your site taxonomy will impact the usability of your navigation.
Further, though I won't focus on it in this blog, a key driver of your IA may be another topic of interest (and confusion): SharePoint governance.
As an example, imagine a company has created a governance plan, which states that SharePoint sites containing customer data must have auditing and content expiration policies applied to them.  Because these sites represent a small subset of the overall application, it may be wise to segregate them in their own site collection where the policies can be applied, while other sites can reside outside of this "special" site collection without the overhead of these policies.
For more on governance, I recommend reading A Definitive Guide To SharePoint Governance: Whitepaper by SharePoint MVP Jeremy Thake, Randy Williams, and Richard Harbridge. But for now, this should illustrate the point that governance may impact IA.

 

Why is Information Architecture Important?

 

This is a good question.  Why should you care about IA?  Is it just an abstract exercise or does it have an impact on your site's users?  The answer is that it is absolutely crucial, and in many ways.  To name a few:
  1. Usability - Sites that lack a well-thought out IA tend to be less usable.  It's more difficult to find information and site navigation tends to be substandard or confusing.
  2. Adherence to Governance Plan - As alluded to earlier, your IA may be one piece of how a governance plan is executed or adhered to.
  3. Compliance - Policies that allow us to adhere to compliance regulations are quite often driven by metadata.  If the metadata design is lacking, it may be difficult or impossible to stay in compliance, which can have tremendous legal and financial repercussions.
  4. Site Management/Administration - A strong IA will help prevent site sprawl and may help address storage requirements or goals.
Simply put, without an IA in place, your site will be inconsistently tagged, poorly organized, and difficult to use.  And depending on the criticality of your site, this could be either a small annoyance or have much more grave significance.


What is Information Architecture, Specific to SharePoint?

 

In general, SharePoint IA requires attention to the same topics that any other website does.  But SharePoint does warrant a specific discussion because there are SharePoint-specific mechanisms and structures that must be addressed and because SharePoint's nature is to empower users to create sites and content on their own.

If the IA is not well thought out (as well as executed and adhered to), site sprawl and other undesired results are sure to emerge.  Some of the SharePoint-specific topics that must be addressed are these:

Content containers - By this I mean, deciding whether content or sites will reside in a specific farm, web application, site collection, or subweb.  Decisions about where to provision a specific site will include, among other things, configuration requirements, compliance/data segregation/encryption, specific SLAs, and navigation.

Metadata Structure - This includes defining Managed Metadata term sets, site columns, content types, content type hubs, and more.

Search Schema - SharePoint Search managed properties and crawled properties (and their mappings) must be well thought out to ensure quality search results as well as setting the system up to create search-based applications.

Now, I mentioned this isn't a full list, but even so, you might have noticed there are some obvious things missing.  Which leads me to the next topic.


What is the Difference Between Information Architecture and Information Management?

 

At a high level, I think of IA as the design and planning of your application whereas IM is the implementation, application and execution of that design.

So as an example, your IA may define a metadata taxonomy for tagging content and a content type hub to manage those terms centrally.  The IM part of this would be, perhaps, configuring auto-tagging on this library to make sure that the tags are actually applied.

Another way to look at this is that IA describes where and how content is organized, while IM is an application of tools and configuration that describe how this information behaves.
Some of the areas of IM that need to be addressed follow:

Permissions/Security - Who has access to the content?  What different permission levels are available to apply?

Content Lifecycle - When does an item become a record?  When and how is old content archived?  Is content ever expunged from the site?

Policies - What type of auditing and reporting is required for the content?  Can the information be printed or emailed?

Provisioning Process - How are sites provisioned?  Which site templates are made available?  Where can sites be created?

Again, there's more to consider here, but this should get you thinking about the types of things to plan for and configure in your implementations.

When Should Information Architecture be Addressed?

 

There's an easy answer to this question.  You should address IA early and often.  If there's one thing to take away from this blog it is that last sentence.
IA should be planned for very early in the project.  In my opinion, it should follow the initial governance planning.  This is because the governance plan will in some way or another define then IA.

IA should be revisited often.  Requirements change over time, sites change over time.  Your SharePoint application is a living breathing thing and your IA (as well as many other aspects of your SharePoint solution) should be reviewed and updated on a frequent basis to make improvements and address the current needs of the business.

Wrap Up

I hope this has been a good intro or refresher on the basic tenets of SharePoint information architecture.  The key takeaways I hope you'll get are as follows:
  1. IA describes where and how content is organized, while IM is an application of tools and configuration that describe how this information behaves.
  2. IA should be addressed early and often.
  3. IA and IM are two major components used to apply and execute your governance plan.
  4. A strong information architecture will result in a highly usable site that adheres to compliance regulation, is easy to manage, and where it's easy to find data.