Section 19.1. Information Architecture, Meet the Enterprise

19.1. Information Architecture, Meet the Enterprise

What's enterprise information architecture (EIA)? Quite simply, the practice of information in the enterprise setting.

Sorry, that definition was accurate but not too helpful. Let's back up and make sure we understand what an enterprise is. Most would say that it's a large, physically distributed organizationusually a corporation or a government agency, but we'd also count substantial academic institutions and nonprofits. Enterprises suffer from problems big and complicated enough to merit serious, expensive solutions. (Hence, software marketers have found that prepending the term "enterprise-class" to their products' names is a reasonably reliable path to a condo in Aspen.)

But "large" and "physically distributed" aren't what really defines an enterprise. In fact, the most telling attribute is a place where "one hand doesn't know what the other one's doing." Or, one hand ignores or doesn't care what the other's doing. Or that first hand absolutely despises the second hand, and will do anything to undermine it. Interestingly, these attributes can be found in just about any organization, regardless of size or physical distribution. So while you might not work at ExxonMobil, Thomson, or the UN, it's likely that you're dealing with enterprise-class IA challenges.

Enterprises have been characterized by a constant tug-of-war between forces of centralization and autonomy. A new management regime comes in, finds wasteful duplication of effort and expense, and discovers a lack of coordination and collaboration among business units. The new managers try to reign things in by centralizing as much as they possibly can. Typically this process fails to have its intended impact and even creates some unintended negative consequences, such as choking off local innovation. Then a new regime enters the picture, sees a new set of problems, and in its hurry to leave its mark, swings the pendulum hard the other way: "let a thousand flowers bloom." Staff in far-flung units are empowered to take things into their own hands but may do so in a wasteful, duplicative, uncoordinated manner. And we're back where we started.

This constant tug-of-war impacts an organization's web presence, whether public or internal. In fact, the Web, by dint of its democratizing ways, actually aggravates the naturally innate tension between local and central. The end result is, typically, a web environment consisting of hundreds or even thousands of separate mini-web sites that don't work together in any coherent way, or failed efforts to enforce compliance with common design standards and platforms. Designing a successful information architecture against this insane backdrop is perhaps the biggest challenge we face today. And if it's hard for us as designers, consider the even more horrible experience users face.

19.1.1. Finding Your Way Through an Enterprise Information Architecture

Let's say that you work for a global consulting firm. You just returned from a client trip with a wad of receipts in your wallet or purse. Now you want to get repaid. It's a common task, so it should be feasible to complete using your company's intranet. But where do you begin?

Unfortunately, like many intranets, the company's information architecture mirrors its organization chart and is structured like Figure 19-1. Do you know how your company is organized? (Grab a sheet of paper right now and try jotting it down. Not so easy, is it?) Imagine how confused you'd be if you were a new employee. And considering the "constant revolution" of ongoing reorgs that churn so many enterprises, even long-timers might not have a clue.

Figure 19-1. An intranet that looks like an org chart; common tasks can't be supported because relevant information is buried in departmental "silos"

So you begin to poke around the intranet. The legal department might or might not have some information on how much your client's contract allows you to be compensated for. But HR has various policies and procedures that you'll need to take into account as well. They point to tools, forms, and other materials that might or might not help you get reimbursed.

Of course, if you work for the North American division, there might (or might not) be a similar array of contractual information, policies, tools, and so forth that only pertain to doing business in North American countries.

You'll probably become tired of guessing and hunting. So what happens?

Maybe you give up, making your employer happy because they've just saved the expenses you'll eat. But in the long run, they won't be well served by the according decline in employee loyalty.

Or, more typically, you'll go ask someone who you think can help. Now you've thrown the intranetwhich hasn't been exactly cheap for your company to build and maintainout the window, and you'll go bother an expensive human "expert," who's got other work to do and isn't by any means guaranteed to give you the correct information.

Either way, it's a bad outcome, and it's why we're devoting a chapter to enterprise IA. It may not be the most interesting or exciting of topicsmost of us in the field would probably prefer to spend our time poking around at the intersection of Web 2.0, design patterns, and semantic webs (with a little Ajax thrown in for good measure). But more and more of us find ourselves thrust into the role of balancersnot of budgets, but of centralized and autonomous content, and the motivations, urges, people, and egos behind those conflicting forces. And we have precious little to go on to help us address information architecture challenges in this setting. Our goal in this chapter is to provide you with at least a little practical advice on improving an enterprise's information architecture.