Having worked with a lot of information tools of various genres ranging from content management systems, knowledge management systems, collaboration and personal publishing tools, I think it is safe to say that a feature of each tool is its information architecture (or, its general concepts about how information should be organized and worked with).

I think it is something of a "dirty secret" that these tools tend to fail to offer an up-front way to evaluate their information architectures. And so, consequently, when we get into these tools, we soon find ourselves both working hard to figure out their information architecture and also how we will match up our own information ideas / requirements with those assumed and/or fixed by the tool.

As a simple example, before choosing blojsom as the tool / system for this blog, I tried blogging using three other tools. Each of these tools, for example, in their own ways, had very specific ideas about: 1) the relationship between the blog and other pages I might want to have on my website, and 2) the nature of how old posts would be organized in an archive.

So, it was through trial and error that I learned that these three blog tools: 1) assumed the blog to be the home page and no web page senior to it, and 2) saw all past posts as organized only by their date (i.e., specific day).

(This blog lives within a larger site, and the post archive is organized by month now, and will later also be organized into faceted categories.)

I imagine that I could tweak to my requirements these three blog tools that I chose not to use. But, the main issue for me was that I was having to do a lot of work to figure out these information architectural assumptions.

What I liked about blojsom was that I was able to very quickly figure out these assumptions, and also that they were significantly minimal with regards to the areas where I wanted the most flexibility.

However, in any case, I imagine it would be possible for any of these tools to be expressed in terms of information architecture concepts (e.g., navigation systems, labels, taxonomies, etc.). And, I also see an important feature coming out of this as well: the componentization of a tool along the lines of its information architecture.

So, what I envision is being able to look at a tool / system, without owning it and spending dozens or even hundreds of hours test driving it, and get: 1) a picture of its parts in information architecture terms, and 2) a picture of which parts can be removed and which parts can be easily used as components in other systems—again, in information architecture terms.

A web service-y example would be taking a set of categories from one system, say SharePoint, and being able to use them in another system, say SocialText. That is an OK example, but it makes you think about application services more than information architecture.

I think a better example of what I am getting at is: being able to take the navigation system from MoveableType and use it around SharePoint. And, I don't just mean web services or links between two different web-based interfaces—the issue is that both of these products are significantly coupled to their own navigation systems.

It may not be possible, and it may not even necessarily make sense, to uncouple these things. But, that kind of fact is the kind of information architectural assumption or choice that these products could express up-front. In other words Microsoft could be saying, "we have created a highly integrated information system good for such and such, and so here are the specific parts that always are connected together in our system".

I am very interested in social software and collaboration tools, but I think there are specific information architecture oriented features of these tools that are going to become more and more important. The ability to re-use not only categories and search, but also things like navigation systems and labels, between systems, is going to be a big deal.

I think, eventually, businesses will see information architecture re-use in a similar perspective as data and code re-use. Like, a company now probably would create a RDBMS fronted by an application in some modern programming language, having some sense that they could change vendors and preserve at least the concept of their system.

Right now, when you change information tools, you often have much less portability of information architecture. If you are moving your information from Outlook to your file system to a wiki to a content management system to a portal, each time you will at least re-build your information architecture—and usually, you will need to significantly redesign it to match the constraints of the new system, which you will need to labor-over intensively to understand.

Anyway, one inspiration for the iCite net is that I imagine iCites will work as tools for publishing information architectures in human and machine readable formats (and, no, I am not trying to create a markup language called IAML!). And, I think even more importantly, iCites will allow the componentization of information architectures, and a medium where those "skeletons" can exist autonomously of the interfaces that use them.

So, for example, someday, someone could take parts of the sitemap for this site and parts from another site, plus a little amazon.com search taxonomy, and combine them into the skeleton for a new site. People do this kind of thing already, by hand. But I imagine this being directly puggable into future systems.

(I also imagine this in no way lessening the need for information architects! Just because you yourself can measure the size of a sub-zero refridgerator and roll it into your house doesn't mean you'll never need an architect to design your kitchen!)