logosm.gif (3991 bytes)
Volume 9 No. 2/3 Spring/Summer 1999
Debunking Information Architecture
by Blair Galston

Think of building a house. This is your house and you want to do the job right. After the fantasizing, information gathering, financial planning, and so on, what do you need before you start building? You guessed it. You need an architectural plan.

Now, think of building a web site. No, think bigger! You are going to help the organization you work for build a web-based tool for internal communication — an Intranet. This tool is going to be so cleverly constructed that staff will be able to find the information they need quickly and easily! Revolutionary thinking, indeed, but you want to pull it off because you're committed to your calling as an information professional to make information a resource that can be used and shared efficiently, effectively, and economically. And what do you need before you proceed to build? Three guesses . . .

What Is an Information Architecture?

An information architecture is a logical plan for organizing information. It includes rules which ensure consistency and predictability for users of the information. Its underlying logic enables intuitive use and easy access to information. Just as, in home or restaurant, you'd look for a toilet in the bathroom or a refrigerator in the kitchen, so also should you and your co-workers be able to approach the organization's Intranet and find what you need in an obvious place. And the route you take should require minimal navigation.

An information architecture is not the actual informational content of the Intranet, nor is it the design or layout of the information. It's the two-by-fours, not the furniture or wallpaper.

A good architecture serves as a foundation and framework for future growth. However, it is not simply an idea or concept meant to inspire new ideas. It is a plan that is followed religiously, with a formal process for making adjustments when required.

How Do You Create an Information Architecture?

ICBC has just been through all this, so take note. Like records classification, you will want to conduct a thorough inventory of records and information that are already being shared electronically. You will also need to solicit from stakeholders some ideas or proposals for Intranet sites; group brainstorming sessions are in order. There are also a number of organizations that have already been through several versions of their own Intranets, and a survey of those organizations has proven helpful to ICBC.

Once you've created a mock-up of your architecture, you may choose to facilitate a focus group or two, testing the logic and intuitive quality of your work on fresh and critical minds. Remember, no matter how well the architecture works for you, the Intranet will be a failure if its architecture is a puzzle to everyone else. A word of caution: user validation is important for the success of your undertaking, but it should never compromise the underlying logic of your architecture.

The Case for a Common Architecture

The experience of ICBC in creating an architecture for its Intranet has yielded another important learning. If there are other technologies that serve primarily to support the sharing of information with a broad audience (i.e. general or group space), it may be wise to create a common architecture which can be applied to all these tools.

In ICBC's case, Outlook Public Folders are being used in tandem with the Corporate Intranet. A common architecture will help control duplication of information between the technologies. Although a given document will reside in one place only, it will be accessible on both, thanks to hyperlinks. A common architecture also reinforces a symbiotic relationship between the systems, whereby each supports the other, and a user's movement between systems is facilitated. In other words, if a user is accustomed to working in Outlook, it won't be such a leap to visit the Intranet because information is organized the same way on both systems.

Intranet Governance

So you have your Intranet. You have an architecture that helps staff find what they want easily and efficiently. You think you're finished. Not so! You've got to keep this baby going. What you need is some governance.

Governance is a system of policies and procedures, rules and conventions, standards and guidelines for the management of content. It establishes a framework for defining who is responsible for what and how decisions are made. It is also a key strategy for managing future change and growth.

Why is it important? Like Maxwell Smart and Secret Agent 99, governance combats CHAOS. Records and information managers know all too well what happens when information accumulates unchecked over time—when rules are applied inconsistently—when changes and additions go unmanaged. In the end, chaos impedes access and retrieval of information, wasting a lot of precious time.

Elements of Governance

First you must establish a governance framework. Who will have the power to make decisions? Who will help enforce those decisions? Many organizations have a governance board comprising major stakeholders, FOI, internal communications, and legal representatives, as well as a coordinator or web master who oversees implementation on a daily basis.

Content and design standards are also an essential piece of governance. Good content management can be effectively established only if responsibilities are clearly defined from the outset. Roles such as content owner, author, editor, and contact should be assigned and accountability of those who fill the roles should be formally acknowledged.

From a records management point of view, context management is a crucial part of Intranet governance. Each document posted to the web must include a surrogate description of the creation, status, use, and destiny of the document. A profile of a web page might include such data as who the author is, when the document was last updated, whether or not it is considered the original, what classification and schedule applies, what security precautions are involved, etc. These data, which may or may not be contained in the document itself, serve not only to help manage the document, but also to lend reliability and authenticity—qualities which in turn allow staff to trust and therefore actually use the information.

The Bottom Line

There is a pervasive assumption that information technology (IT) specialists have the required set of skills to set up and manage electronic systems and applications. It's true that IT is an integral and indispensable part of, say, a web development project. However, another integral component of web development—the information architecture—is best suited to records and information professionals. This is classification, folks! You too can be an architect. So, if there's an Intranet barn raising in your neck of the woods, and you're not invited, then for the sake of the greater good, do something about it.

*  *  *

The content of this article was gleaned in the context of project work for ICBC's Records, Archives & Document Management Department and in collaboration with Jayne Bellyk (Corporate Records Officer and Acting Manager).


Back to Table of Contents

© 1999 Archives Association of British Columbia