Ok, I finally got all the notes fixed up in the Clues to the Future presentation. It’s downloadable from here:

http://www.inkblurt.com/media/hinton_iasummit06.pdf (12.8 MB)

If you download it, please leave a “hello” here in the comments? I’m just curious!

And as always, tons of links and references are on the main page about the presentation, here.

Technorati Tags: iasummit2006; andrew_hinton; iasummit

In the age-old struggle to define Information Architecture, many have insisted that it’s important to separate the role from the tasks, or even the role from the “title” of “Information Architect.” I strongly agree.

But as I thought about it more, I realized there was more definition necessary. We need to figure out how these things like methodologies, responsibilities, roles, titles and disciplines all actually relate to one another, so we’re all walking around on the same cognitive map.

So, in the interest of clarity, I’m proposing a model of sorts for the “what we do” part of Information Architecture.

I’ll describe the model, then discuss how it may illustrate what is really going on in our collective yearning to define (or not) IA.

Here’s a figure — please see the description below.

Here I am separating out “Activity” and “Practice” and “Discipline” in the same way that it’s broken down in the “25 Theses“:

23. Information architecture acknowledges that this practice is bigger than any single methodology, tool or perspective.
24. Information architecture is first an act, then a practice, then a discipline.
25. Sharing the practice grows the discipline, and makes it stronger.

Activities

By “act” I refer to the methodologies, tools, whatever. These are all acts, or in this model, they are “activities.”

Activities are agnostic. They aren’t necessarily related to any particular discipline or even any particular practice. Just as a hand saw isn’t only for housebuilding — it can be used for all kinds of other woodwork.

Let’s take a common task used by IAs: Card Sorting. Card sorting was invented at some point by someone so that they could better understand how people organized categories and labels. It’s not an inherently “Information Architecture” activity any more than the screwdriver is an “auto repair” tool.

“But surely,” you may say, “a saw is always a tool for cutting wood! It’s not useful for, say, nailing things.” Absolutely. There is always some boundary around the usefulness of any tool (i.e. activity). Let’s say, then, that in this analogy, the saw is like card sorting, and all of woodwork is equivalent to “design.” Saws get used in all sorts of places within woodwork. It’s very important both to the housebuilder and the shipbuilder, for instance. Someone who does both relates it to whichever one happens to be the current context of need.

Keep this in mind: “Context of Need.” The tool was certainly invented for some context, but it’s often useful in many other contexts. The context of need becomes important for what we mean by “Practice.”

An important point: just because a particular discipline or practice (we’ll define them shortly) happened to *invent* a particular activity, that doesn’t mean that the activity is forever and always inherently defined by that discipline or practice.

Caveat: I’m going to keep running with this saw, carpentry metaphor, and I’m going to do it in a very simplistic parable-like sort of way. Just know that I’m aware I’m probably getting the anthropological history or whatnot completely wrong, and go along with the fun ok?
[Edited to add: I’m not trying to draw an exact analogy between housebuilding and IA — I realize now that it may sound that way. It’s just a simplified example of how tool use and practice and discipline relate to one another. I *do* think that IA and traditional architecture are very similar in abstract … but that’s not the point I was trying to make with this analogy.] Thanks!

Practice

A Practice is essentially a pattern of use. As people coalesce around a shared context of need — shared goals and situational problems to solve — they share ideas and methods and tools.

Long ago when someone wanted to stop living in caves, she decided “hey, that tree over there might make a nice shelter, if I could cut it down and make it into one!” So she figured out a way to do that, and started cutting down trees and shaping the wood, figuring it out as she went. Others who were making their own shelters figured out newer or better tools and methods for cutting the tree down, removing bark, tying them together. They shared these tools and methods, improved them, taught them.

A practice is emerges bottom-up: individuals working as a collective group discover that they have similar contexts of need (a shelter) and, being social organisms, share their expertise and labor.

Community of Practice (CoP) was coined and seminally described by Jean Lave and Etienne Wenger (see Wikipedia article; see historical description). These aren’t created explicitly by any governing body or expert or guru. They just happen, because people want to learn and socially connect based on their particular context of need — their work or hobby or whatever. There is a great deal to learn about the “communities of practice” as an idea in knowledge management, learning studies, etc, but I’m not going to get into that here (but if you haven’t read about it, you should … it’s terrific stuff and I think essential for any IA).

To bring us back to our saw, then … eventually people who were making stuff with wood developed even more sophisticated tools. They relied, in fact, on whole other communities of practice — such as metal workers. It took a blacksmith to create a workable saw (Hopefully the first carpenter to use a saw for carpentry didn’t suddenly declare blacksmithing “dead.” Because that would have been, of course, absurd.)

At any rate, the saw was a pretty sophisticated tool. But it still wasn’t exclusively a “house building” tool, it was used for ship building and other stuff too. However, the community of practice around house building enabled house builders to teach one another the best ways of using the tool — what sorts of wood could take what sorts of saws, what sort of tooth pattern was best for what grain, etc. Many of these issues are peculiar to house building and required tacit and explicit knowledge to be shared about the nuances of saw use for those very particular contexts — different nuances than are required in making ships and other wooden things. The expertise became important enough that people were willing to pay those who were really good at making houses to make houses for them as customers!

At this point, it became a Profession.

Note that in this situation the Profession did not require a Discipline. Professions can be just as loosey-goosey and bottom-up as communities of practice. They don’t necessarily have to have any authority to define them outside of the collective understanding of a given society that a bunch of people make money for working in a generally similar Context of Need.

Another interesting thing about a Community of Practice is that there is no necessary or completely authoritative role or structure. That isn’t to say that there is *no* authority and *no* structure! Usually some structure is necessary just so people can meet (“Let’s meet at the pub on Tuesdays and talk about housebuilding!” or even “Hey when we meet at the pub what you say we focus on building decks this week?”) In terms of authority, there is typically an informal pecking order, a meritocracy of sorts, where people tend to acknowledge who is an expert in what. Certain people have been at it longer, or have more charisma, or are simply louder. These things may even be written down and talked about explicitly. But at heart, they’re tacit and fluid within the community.

Before I get to the “Discipline” portion, let me go ahead and say: I think that we — meaning those who call themselves “people who do a lot of stuff we collectively refer to as information architecture” –are (as a whole) hovering in the blue “Practice” area, or even just below it. That is, we have found one another, and we’re sharing tools and methods for very similar purposes and contexts of need. Some of us are more focused on the Activities (seeing IA as “expert saw usage” as opposed to housebuilding) than on the larger Practice, but most of our leadership seems to understand that there is *some* common and shared Context of Need which drives us, making the sum of all our Activities larger than its the parts.

And for us, it’s especially tricky, partly due to the nature of digital information and the incredible rapidity of change, our contexts are shifting and evolving quickly under our feet. Whereas the carpenters of old had solid wood to deal with that didn’t change from one generation to the next, we’re dealing with stuff that isn’t physical, that’s full of semantic quirkiness, in a technological context that has new inventions and innovations every day. It’s making it especially hard for us to even *describe* where the boundaries are for our community of practice, much less *define* any boundaries. (This distinction between description and definition is important for the next layer — the Discipline.)

Discipline

A Discipline is not bottom-up but top-down. Whereas a community of practice is very horizontal and peer-to-peer, with some informally acknowledged variations in authority and structure, a discipline’s very purpose is to create centralized authority of some kind.

Why make a discipline? I’d say it’s mainly for things like legitimacy and authority in the larger world.

Eventually our housebuilders (saws and other tools in hand!) realized that some housebuilders were competing with them who weren’t qualified, and were making their profession look bad. Or for that matter, when they’d try to collaborate on projects, they were making things so differently that they couldn’t fit walls and joists together well. To keep their profession from losing its integrity, they decided they should figure out who the responsible and capable housebuilders were and tell everybody “here’s the list of housebuilders whom you can trust.” That’s licensing. They also figured out some standards for how to make stuff so it would work together better.

But to do this, they had to agree to a top-down structure of explicit rules and regulations. The trade-off was significant, though. It helped business, and it helped their community of practice by establishing norms and standards, which developed into best practices and “standard stuff you should know,” i.e. curricula for training.

Therefore, the Discipline does not merely *describe* what the Practice is doing. It *defines* what the Practice *should* be doing. (As denoted in the visual model by the brackets around the Practice.)

So, does that mean that once you have a Discipline, the Practice isn’t necessary? Does one destroy the other? Absolutely not. While they may have different, even opposite, qualities, they can often work to be very complementary to one another. In fact, disciplines that really thrive and grow are highly responsive to their communities of practice.

Medicine was a Practice before it was a Discipline. But it was a Discipline for a very long time — its standards have been defined for long stretches of time without being fundamentally changed. It was a Discipline even before germ theory hit the scene, and it resisted germ theory at first! But that discovery changed everything in medical science, and radically shifted what medicine was about. Some say genetic science may do the same thing again.

There is certainly tension. Even the healthiest Discipline/Practice relationships have friction, because by definition a standard is static and resists change long enough to be useful, and agreed upon over time. Communities of practice thrive on the fluidity and collective tacit intelligence of their members, while Disciplines refer to explicit, documented “known truths.” This is an oversimplification, but it describes where they are on the continuum.

This part is important: The Activities are agnostic — they don’t care about context as long as they’re useful in whatever context they’re employed in.

The Practice, however, is *very* concerned with context. It doesn’t exist because of the Activities (the tools and methods), but because of the Context of Need.

Therefore, to describe any Practice, one must articulate the Context of Need that brought it into being, that made it necessary enough for people to coalesce and share their expertise.

For housebuilders, they can point to shelters and say “we needed shelters, so we made these things called houses, and we started getting really good at it by working together and sharing our expertise.”

The Discipline is another layer that doesn’t merely *describe* what has already come into shape — it *defines* what is authoritative, what is standard, what is legitimate.

So what does this mean for Information Architecture?

I think we’re currently in the awkward growing pains of a Community of Practice that yearns for more legitimacy, more resources, more authority and definition. As individuals, we want these things in widely varying degrees. But collectively, it’s impossible to deny that this Community of Practice wants more.

At the same time, we’re a prickly bunch. We didn’t get into what we do because we like other people to label things *for us!* We like to do it ourselves, and make lots of tidy semantic sense out of it.

We aren’t going to get anywhere further unless we can separate the Activities from the Practice. That means coming to some agreed description of our Practice. And that means *agreeing on a shared Context of Need.*

Here’s another very important point: We cannot agree on a DEFINITION until we at least have some agreement on a DESCRIPTION.

And we cannot have a Discipline unless we can agree on definition (which, as just stated, depends on having a description to begin with.)

In addition: We need to stop getting confused between Profession, Discipline, Practice and Activity. Just because we’re getting paid to do something doesn’t mean that defines the Practice or a Discipline. For that matter, just because there are some University majors and courses with “Information Architecture” listed in their titles, it doesn’t mean that we’re any closer to having a real, defined Discipline. It just means that our Community of Practice is becoming more “professional.”

So why can’t we just do that?

Several reasons I can think of (and there are certainly more):

1. We can’t seem to agree on our Context of Need. (I’ll get to this one in a bit.)

2. Unlike our friendly housebuilders, we can’t point at a shelter and say “we make that!” We don’t make things with walls, we make things with relevance. If we do our job well, it’s invisible. It’s very hard to prove a negative, or describe a Discipline with one. This is a serious challenge that we have to tackle. We have to figure out how to point at what we’ve done and say “We made that” — because right now when we do that, interaction designers and usability folks say “um, hey, you’re pointing at an interface.”

3. There are tensions, mostly healthy ones I think, between the bottom-upness of our Practice and the top-downness of the Definition/Discipline that we’re collectively looking for. These should improve with time … conventions and shared understanding will eventually happen. These things cannot be rushed or forced artificially. They can be helped along, though, I would imagine.

As I said, there are probably other reasons.

I’m not saying that all Communities of Practice *have* to eventually become Disciplines. Hip Hop artists are doing quite well, thank you, without getting an MFA in hip-hop. Though I’m sure that’s not far off.

But I am saying that it will be hard for our Community of Practice to evolve further without being able to agree on our description — which hinges on our Context of Need.

And it will be *impossible* to have a Discipline without it.

So what is our Context of Need then?

It may seem obvious, but evidently there’s a lot of disagreement.

Until this point, the model I’ve proposed is pretty neutral. The model, I think, works pretty well regardless of the Practice referenced.

But for Information Architecture, there’s talk that our Context of Need is “wherever some information needs to be organized” and I think that’s dangerous, if we want to have a Discipline, and earn consistent legitimacy and authority in the wider world.

My Contention on the IA Context of Need

Information Architecture happened because of something extraordinary — the Web. I know lots of people say “oh we’ve been doing IA for a long time before the Web,” but my contention is NO. We have not.

What people were doing before the Web was a set of Activities that were applied in other Contexts of Need, as represented by Disciplines and Practices that were already around: Library Science, Architecture, Interior Design, Anthropology, HCI, Graphic Design, Brand Management, Copywriting, etc.

But then the Web happened. Hyperlinks became no longer a specialized concept in computer labs and musty research networks. They became available to everyone who had access to the Web, and access exploded.* Soon after, anybody on the Web was able to not only find and read things there, they were able to create things there themselves. (see Sidebar below on the importance of write-access)

The Web is the ultimate “shared information environment” — and I don’t mean a shared environment *of* information. I mean a shared environment *made of* information — the bricks and mortar are semantics and relevance. This is a key distinction.

Why weren’t people getting together for the stuff we now call IA before the Web? Yeah there were LIS people and the rest, but they already had organizations and practices and context of need of their own.

Something about the Web created a Context of Need that was new. Designers, scientists, writers … bunches of them realized there was something *else* going on that their previous activities and contexts hadn’t quite prepared them for. They realized they would have to adapt their expertise to meet this new context. Probably most people who now call themselves IAs (or their work IA-related work) had this epiphany at some point — they started out doing other things, but felt a need to adapt and evolve their work to meet a new context. That’s why they sought each other out and came up with mailing lists and discussion boards to begin with.

It just so happens that the book that appropriated the term Information Architecture for this new Practice (to deal with the new Context of Need) was written by LIS folks. And so, of course, it is written from that perspective. If the first major book to attend to the new Context of Need had been written by programmers or graphic designers, it would’ve been heavily slanted toward *their* tools and activities.

Over time, though, we’ve realized that, partly because the Web is so all-encompassing and mashes up so many parts of human experience, many other Disciplines and Practices have elements that can be appropriated and adapted for the Web Context of Need as well as LIS.

In fact, we need all those Disciplines and Practices to keep right on being experts in what they do, because their innovations are often helpful for us.

But guess what? It turns out they need the IA Practice to do the same thing.

At some point I want to write further about why I think it’s important that we not confuse Information Architecture with non-digital environment design, but I won’t belabor it right now.

I just want to make this clear: we need to focus our description of what we do, and the value we bring. We need to come to some shared understanding on what Context of Need we *primarily* address. Without that focus, we allow Information Architecture to continue to be viewed by many people as just a fancy name for stuff that other Disciplines and Practices already do. We don’t do ourselves any favors by trying to define ourselves with contexts of need that other practices and disciplines already cover quite nicely on their own (even if they don’t always do it well). Just because another Context of Need can be helped by some excellent taxonomy and card sorting work, it doesn’t necessarily mean IA is the best Practice for the job.

I hope this model, and my ruminations, can maybe help build toward a little more clarity. Or at least a language we can use to move things along a little more.

* Sidebar: The importance of write-access: All Web 2.0 really is, in my opinion, is the rise of write-access. For the first chunk of time, even though the Web was growing fast, it was mainly useful as a place for information retrieval because most people couldn’t *write* to it, only read from it. And even where they could write to it, most people hadn’t had it around long enough to mentally switch from a broadcast mindset to a peer-to-peer mindset… we were all trained to be broadcast to, or to find and read and use things other people made.

While information retrieval is still exceedingly important, the infrastructure has blown the doors off of write-access, turning the Web into the Peer to Peer network that it was invented to be. The scientists who wanted to use it to begin with all had write access. It just took a number of years for the infrastructure to mature enough that non-experts could write to it as well, and a few years more for it to sink in that “holy crap I can make stuff here too!”

Web 2.0 is just a rediscovery of what the Web was about to begin with: social, peer to peer communication. Whether it’s about science or comic books or sex or buying stuff — it’s all conversation. It’s all social interaction. Information retrieval and search are just tools we use as part of the whole.