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.

Making SharePoint Information Architecture Work for You

Information architecture shouldn’t be a big scary thing: it’s simply about creating the same elegance you see in the Golden Gate Bridge or the Eiffel Tower, only instead of being built with steel, it is built with information.

What is Information Architecture?

 

Information architecture is the process of creating a structure and tools for information such that it can be stored, retrieved, and managed efficiently and effectively. In other words, information architecture is about making information work for you.

Information architecture is different than physical architecture as there aren’t physical materials to arrange. However, the struggle towards effective and simple elegance, which is at the heart of all architecture, has its place in information architecture as well.

When speaking of architecture, we should mention the architect, the person who is responsible. In Greek, the word architect means the chief builder. However, a building architect doesn’t actually build the building. Carpenters and skilled tradesmen do that. An architect, then, is the person who creates the plans, strategies, and direction for the building.

Going back to our case of information, the primary tool the architect uses is “creating meaningful breakdowns.” That is, the architect creates the ability to find information by categorizing it. The following five steps are a straightforward approach to generating your information architecture.

 

Step #1: Identify Attributes

As humans we use chunking, or treating multiple things like a group, so that we can cope with the sensory and information overload that’s happening all around us. If we want to create groups, we need to create attributes and values to group on. The first step is to identify the sea of available attributes. This in and of itself requires that you develop a way to organize the attributes that you identify, because there will be a few.

Identifying the attributes is typically a process of identifying all of the content in your organization that people want to store and find. This might include invoices, purchase orders, time sheets, et cetera. Each of these has a series of attributes such as the invoice date, customer ID, or vendor ID. These may be valuable for organizing the information for retrieval.

One of the cautions in this exercise is that you’ll try to identify every attribute on every piece of content in the organization. While the exercise is in capturing the attributes and the content types, the assumption is that you’ll never be complete and more importantly, you can come back and extend your inventory of attributes later. Your goal is to get the most important attributes down and allow the others to surface if they’re important.

 

Step #2: Identify Essential Attributes

Once you have an inventory of attributes it’s time to figure out which ones really matter. Attributes of any object or piece of information can be sorted into two categories: essential and accidental. It’s essential that a car has four wheels and that a plane fly: number of wheels and modes of transportation are essential attributes. (No, I don’t count three wheeled vehicles as cars.) The color of the car—say, red—and the construction of the airplane—say carbon fiber—are accidental properties.They just happen to be that way.

Essential attributes are used for top levels in a hierarchy. They are at the top of the hierarchy (or hierarchies) because they’re the ones that are easiest for people to identify with.

 

Step #3: Identify Values

 

Knowing what the attributes are is a good start, but you still have to get to specific values. For instance, what are the colors? Red, blue, or green?
Are you generally referring to color by its rough category, its Pantone number or its marketing name? What are you going to standardize on for the way that you identify colors? This is a game of standardization and specificity.

Specificity is how specific your values are. Red is a generic color. Pantone 1935C is a specific representation of a red color. If your business is printing, you’ll probably need the specificity of Pantone colors, andif you’re in the business of making wagons, red is probably specific enough.

 

Step #4: Create Ranges and Groups

Sometimes you can create groups based on the number of values for an attribute. If you have ten color categories that you’re dealing with, the color categories can be your options.
However, if you’re using Pantone colors, which number over 1000, doesn’t make a good set of options for users to choose from in a single menu. To create an information architecture you’ll need to create a set of meaningful breakdowns.

In the colors you may need to create groups based around the primary colors (red, yellow, and blue) or more likely primary and secondary colors (red, orange, yellow, green, blue, and purple). The fun will be in organizing the colors into these groupings since the boundaries will be somewhat arbitrary.
One solution to this: create a poly hierarchy where each color is placed in more than one of these categories. This reduces the specificity (reduction capabilities) of the choice but maximizes the chance that a user will find the color they’re looking for.

 

Step #5: Design Navigation and Search

 

The final step with building an information architecture is in connecting it to the visual design. This includes the development of navigation solutions that help the user get to the right information.

The convention of a global navigation across the top and local navigation in the left column is pretty set. Utility navigation, the stuff about how to use the site, is less standardized but also less interesting.
Information architects are most likely to focus on content navigation: helping content authors connect one piece of content with other pieces of content.

Content navigation is built into SharePoint in terms of summary links, but creative use of search can automate some level of the massive task of adding content navigation. For instance, you can add a search web part, which shows all articles authored by the same author, on the same topic, or around the same time.

The design of search itself is mostly about which attributes will be able to be used as facets to refine searches but will include the creation of scopes to create different subsets of the search index in which people can find their answers.

 

Take it Step by Step

Information architecture doesn’t need to be scary. These steps will put you on the right track to creating an information architecture you can be proud of.

SharePoint Business Architecture

Architecture refers to the art of building. The word "architecture" has many meanings. Probably, the most understood meaning is "the art of constructing structures such as homes and buildings." The architect designs the blueprints of the home or building, taking into account factors such as design, space, light, materials, stability, load, and future needs.

Architecture is important because it accounts for the functional and nonfunctional requirements early on. Microsoft Office SharePoint Products and Technologies are powerful tools that increase collaboration and sharing of content. If implemented correctly, SharePoint can store and serve a vast quantity of information very well. However, without proper architecture and governance, a SharePoint deployment can become an unorganized collection of sites, links, users, and documents that hampers productivity and makes it harder to find information.

A good architecture plan and governance plan  lay down guidelines for deploying SharePoint as a solution to common business challenges. The architecture of SharePoint includes designing and allocating the hardware infrastructure needed to support the site, listing out the sites and site hierarchies that will serve the needs of the business, establishing users and roles that will be given permissions to the sites, establishing the relationships between sites, and planning for the needed site features, site customizations, and site and list relationships (which include how data will be rolled up and aggregated from sites and lists to provide an overview of information).

A good governance plan outlines the administration, maintenance, and support of the SharePoint environment. The governance strategy seeks to ensure that SharePoint is used in accordance with the designed goal and that best practices are followed to keep the portal manageable and usable. Best practices include processes for operation in the portal for tasks such as creating sites and lists, assigning permissions to users, using consistent naming conventions, and generally enforcing the guidelines.

When creating a building, architectural concerns include data gathering, planning, and the design of that building. The SharePoint architect must design the SharePoint building to withstand the test of time (meaning the architect must future-proof the implementation by building in robustness and resiliency) and, based on future client requirements, be able to expand easily (in other words, scalability with an eye on future upgradeability of SharePoint installation based on factors such as business need, hardware, software resources, and so on).

For SharePoint, there are three levels of architecture: hardware architecture, software architecture, and information architecture.

Hardware Architecture

To deliver a robust SharePoint 2010 environment, it is necessary to carry out technical design, which looks at all areas of SharePoint 2010 concerning the equipment it will run on or be connected to and systems and processes it will interface with. The following is a list of planning requirements:

• System requirements determining what is required to deploy SharePoint 2010.
• Services architecture determine what service applications are defined and how are they structured.  
• Logical architecture presents the design in terms of isolation. This planning task looks at farms, service applications, Web applications, content databases, site collections, sites, zones, MySites, and so on.
• Authentication examines authentication methods, such as claims-based authentication topologies.
• Server hardening this task focuses on server snapshots, ports, protocols, and the Web Server, Application Server, and Database Server roles.
• Business continuity examines the business decisions, processes, and tools put in place to handle a crisis. A crisis can affect the organization or be part of a local, regional, or national event. Business continuity and disaster recovery are huge areas in SharePoint and planning for them is an important part of ensuring a resilient and robust platform.
• Performance and capacity determines the process of mapping the design for SharePoint 2010 to a farm size and the hardware needed to support the business goals. 
• Virtualization SharePoint 2010 is fully supported when deployed in a Windows Server 2008 Hyper-V environment. This task examines the licensing and topology.

Software Architecture

The software architecture of SharePoint is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. So decisions to be made include determining what components of SharePoint are needed, what will be visible, and the structure of SharePoint. For example, is SharePoint going to be treated as an out-of-the-box solution, slightly modified with internal applications, or will it include third-party additions? Will it simply need just team site components (for example, the free SharePoint Foundation version), or do you need more service application, enterprise content management, or metadata features, such as those provided through SharePoint 2010 Enterprise?

Software architecture examines SharePoint from a site and solution planning perspective, taking into consideration site components, security, governance, enterprise content management, Web content management, managed metadata, business intelligence, data and processes, access services, quota management, and social computing.

As an example, suppose that you’re going to implement SharePoint in an organization that already has SharePoint but needs to expand. They have a third-party tool providing some functionality that the client finds useful. From scoping the information architecture, you found how much usage it gets, how the data is used, how it flows, and so on. From further investigation of the software architecture, you find that the relevant tool cannot grow with the service. This means revisiting the functionality in terms of the information architecture and finding an alternative, which then drives the software architecture.


Information Architecture

Information architecture involves studying the type and amount of information used within an organization, organizational structure, information flow, process flow, and more. This is an extremely important aspect of the Plan phase. Without it, SharePoint is not defined to meet the client requirements, because information architecture leads to SharePoint user strategy in terms of content management. Identifying the organizational information and management information goals combines the work of information analysts and business analysts, coordinated by the project Manager and feeding back to the SharePoint architect.

Large organizations have documentation plans and methods of managing their data across the organization (for example, retention plans and archive plans), and some use information analysts to manage, coordinate, and categorize how members in the organization deal with information. Additionally, organization face legal and regulatory compliance requirements that directly influence how data is retained long term. In the United States, for example, the Sarbanes-Oxley (SOX) Act established record-retention rules in July 2002. It is highly recommended any company have a records-retention policy that complies with regional and national laws.

Another benefit of a good records-retention policy is a decrease in storage costs.The information analyst details from the ground level the organizational data concerning information standards and policies set out by the business. Information architecture establishes information control and compliance policies so that accumulating information is done in a well-managed way and does not create data chaos.

SharePoint 2010 provides enterprise content management tools that can help lower costs associated with the control and storage of information, decrease complexity, and increase user participation relating to content control. Combining SharePoint 2010 with Office 2010 takes information management to a higher level by extending information control from the desktop environment to SharePoint 2010 sites and content.

The aim of information architecture in SharePoint is to reduce the manual end user actions related to metadata, to scale policies and processes across all types of content in an organization, and to increase compliance and transparency. To meet this goal, there must be an examination leading to the creation of an organizational taxonomy. During the Design phase of the SharePoint project, the information analyst (working with the SharePoint architect) creates a taxonomy for the organization by examining metadata and information policies.

The business analyst can provide, through the collection of user requirements, an understanding of what the typical content life cycle is in the business. This shows how end user content becomes managed content. Typically, managed content begins its life as temporary information created by the individuals in the organization, leading to work in progress (and this means multiple individuals working on the same content) and in the backdrop of retention and disposition (business teams or individuals deciding on whether documents should be archived and what their state is, either approved, published, or other). SharePoint 2010 provides tools to ensure the content life cycle can be designed and adhered to. Enterprise content types, document sets, information management policies, metadata, term sets, and content organizers can be established using SharePoint 2010 document management features. 

Here are some basic procedures for setting the information architecture for SharePoint 2010:

• Carry out an investigation and inventory of existing content.
• Classify the content by performing the following tasks: Look for definitions of structure, policy, and defaults; Identify organizational-level content by enterprise, department, and team; Define what “general use” content is.
• Organize content into enterprise content types and document sets, keeping the following factors in mind: Content types are where there are definitions of structure, policy, and defaults; Content types can inherit from other content types; Document sets are where the work spans multiple documents.
• Decide where information management policies apply. When doing this, be sure to consider access permissions, auditing, user restrictions (for example, no printing), retention, and deletion.
• Decide on applicable metadata by performing the following tasks: Define customized columns, and associate them with documents and lists; Define any cases where the system or user might take different actions based on the characteristics of an item. Note that the characteristics of the item are metadata; Find out what common things users will want to sort or filter items on; Find out what words or phrases users are likely to tag items with; Use Choice or Lookup columns in SharePoint 2010 sites; Use the existing taxonomy if the organization has one.
• Map the physical flow of the document, including the sites, lists, and libraries where the content will be physically located throughout the document’s life cycle.