Enterprise IA
Information Architecture, Meet the Enterprise Web
by Peter Morville and Lou Rosenfeld
05-Feb-2007 --
[Editor's note: this article is reprinted with permission from part of Chapter 19, "Information Architecture for the Enterprise," in Information Architecture for the World Wide Web, the new 3rd edition, published by O'Reilly and Associates.]
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 organization—usually 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.
The Decentralization Problem
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 rein 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: 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.
We haven’t yet encountered an enterprise website that didn’t suffer from problems associated with decentralization. Put another way, it’s the rare site that is too centralized. Now that websites are recognized as a foundational component of doing business in the 21st century, many early sources of resistance to centralization are wearing down. Business units are beginning to understand the benefits of shared resources and coherent user experience, for their sites’ users as much as for their own bottom lines.
Centralization Above All?
So it’s tempting to consider centralization as the ultimate goal of enterprise IA. It does sound like a nice way to deal with the problem: Just design an information architecture that knits together all units’ content silos in a rational, usable way, and then implement across the organization.
The goal of enterprise IA is not to centralize everything you see. In fact, the goal of EIA is no different than any other flavor of IA: identify the few most efficient means of connecting users with the information they need most. That often might involve adopting some centralizing measures, but it could also mean a highly decentralized approach, such as enabling employees to use a social bookmarking tool to tag intranet content. The point, as always, is to apply whatever approach makes the most sense given your organization, its users, content, and context.
Naturally, this is a more thoughtful approach than simply seeking to centralize the information architecture; put another way, it’s more work. But don’t dismay: patterns are emerging to describe common enterprise IA challenges and solutions. Over time certain IA design approaches, when pursued in the appropriate sequence, have emerged as making the most sense in the enterprise setting (c.f., Lou Rosenfeld's Enterprise Information Architecture Roadmap). In this section, we’ve broken the wide range of possible IA design components into several categories, and for each we provide a few nuggets of practical advice on what to do and what not to do.
Top-Down Navigation and EIA
Thanks to improved search engines and the advent of RSS syndication, users are finding more ways to bypass top-down navigation. But top-down navigation isn’t going away any time soon, and top-down elements provide ample opportunities for you to improve EIA.
Bypass the main page
You read it right. Many large IA projects get completely derailed by this one page among the millions that comprise your site. There are an increasing number of other ways to reach your site’s content, such as via a web-wide search engine, an RSS feed, and your advertisements. Still, you know that the main page is the single most important page on your site; the problem is that everyone else in your organization knows that, too. The result: design meetings where senior vice presidents joust over dozens of main-page pixels.
Of course, you could try to shepherd such a meeting to a productive end—a place where the main-page design is conceived with the needs of the enterprise as a whole and the users it serves, rather than the setting where interdepartmental strife plays out. But that might take years, and you’ve got other fish to fry. So we advise you to be prepared to step away from your normal urge to care about the main page. Consider it an unfortunate chunk of real estate that could be so nice if only the warring gangs would cease and desist. You’ll have a chance to rehabilitate it later; for now, move on...
Repurpose your sitemap
...to other pieces of real estate that might be quite useful if only anyone bothered to pay attention to them. For example, your sitemap may already be linked to throughout your site. That makes it a property with considerable value. And yet, it’s often something of an orphan; it may not be clear whose responsibility it is, and few people bother to use it. Can you blame them? Most sitemaps simply mirror the site’s main organization system, and in many enterprise sites, that’s the org chart. Not very useful.
If you want to get things done in the enterprise, it’s often better to ask forgiveness than to beg permission. So you should consider sneaky, Machiavellian means for improving your organization’s information architecture. One trick is to redesign the sitemap so that it stops mirroring what is, and instead suggests what could be. In other words, use the sitemap as a sandbox to try out a new, more user-centered organization system. Chances are, few will complain, and you may be able to monitor traffic to this page to see how well your changes have gone over. This might help you build a case for eventually revising the site’s organization system; or, when your enterprise is ready to seriously consider improving site-wide navigation, you can point to a readily available model for how to do it. This whole messy undertaking may leave you feeling a little impure, but what the heck: life is short, and besides, no lives will be lost or damaged by your noodling around with your enterprise’s sitemap.
Slim down your site index
Another prime piece of real estate is a site index. Like the sitemap, an index ties together content from silos all over your enterprise, thereby making it a great EIA tool. But indices are expensive to develop and maintain. And, in fact, site indices are often superseded by search systems; both support known-item searching, but search is more automated and comprehensive.
Does this mean you should throw out your site’s index? Generally, no. Many search systems aren’t well designed, so users might still need to rely upon an index as a backup. What can you do to make that backup effective while cutting back on its maintenance costs?
Consider a specialized site index. Instead of trying to index everything in your site, focus on one critical type of information. For example, the Centers for Disease Control’s index doesn’t include directions to its campus or biographies of its directors. Instead, it provides an A–Z list of health topics and issues—the primary kind of content that users come to the site for.
A specialized index is far simpler to maintain than a soups-to-nuts version, and because it’s focused on the important content type, it can provide value to a wide array of your enterprise site’s users.
Develop guides
Guides are different from other forms of supplementary navigation. While they can link to content from any silo, guides don’t offer comprehensive coverage of your site’s content like sitemaps and traditional site indices do. Guides are selective—they’re something of an enterprise FAQ—and for that reason they’re ideal “glue” for your enterprise site.
We recommend developing a handful of guides that address users’ top information needs and tasks. What do visitors really want and need from your site? Here’s your opportunity to serve those needs in an especially simple and low-tech way; guides are simply single pages of HTML code, and therefore don’t require specialized technical expertise or applications to implement.
We’re especially enthusiastic about guides in the enterprise context because they scale well. You can develop as many guides as your resources allow. The largest bottleneck typically comes from identifying subject matter experts. But in many cases, the expert—e.g., the poor person besieged by requests for help processing travel expenses—will often be glad to encapsulate his knowledge so he doesn’t have to answer the same question over and over.
Guides are also a good reminder of how you should think about allocating your EIA resources. Let’s face it: you could spend decades trying to develop the ideal information architecture to serve all of your content to all of your users. No one has that luxury—or patience—as far as we know. Prioritization is the only viable alternative, and guides are an ideal tool to aid in efforts to prioritize your EIA development.
Bottom-Up Navigation and EIA
While top-down navigation offers a few quick win opportunities, bottom-up navigation is much trickier. It’s difficult to integrate the upper layers of several separate information architectures, but because there are so many more “moving parts,” it can be far more difficult to integrate the more granular content from the collection of sites that make up an enterprise intranet or public web environment.
Start with single-silo content models
To build momentum toward ambitious content-integration projects, you’ve got to start with baby steps. First among them is building a handful of content models.
Of course, some of your customers' most critical tasks and information needs will require content models that cross departmental silos; set those aside for now and focus on the ones that can be served from within a single business unit’s web site. These will be easier to tackle, because 1) they involve fewer people, and 2) they won’t run into some of the metadata challenges that we’ll describe shortly.
Your goals are to get other people in your enterprise familiar with the idea and execution of content models, which is already a lot to ask of them. So focus on simple tasks and needs that can be addressed by content within a single silo. What useful content model could you build within Human Resources? Marketing? Within your staff directory? Or for each of your products? Your site’s users will benefit from even limited contextual-navigation improvements, and your organization will benefit in the long run from both the experience with content modeling that it gathers, and, ultimately, the ability to connect those content models across silos.
Limit dependence on metadata
As much as we’d like to build interconnected semantic webs throughout the guts of our enterprise’s content, metadata keeps getting in our way. Figure 19-5 below shows a simple illustration, using the BBC content model. Here we want to connect our model with relevant content—let’s say events from a concert calendar and TV listings—from other silos within the BBC.
Figure 19-5. We’d like to connect (along the dotted lines) our content model to other models from other business units; do we have the right metadata to make this happen?
This should work—if we’ve got the same metadata to use to make the connection. Unfortunately, this isn’t always the case. For example, let’s assume that the artist’s name is the metadata that connects “artist descriptions” and “TV listings.” If the people who maintain the TV listings use a different version of an artist’s name—say, an abbreviated or all-caps version, and you list artist names differently, it can be tricky to automate the creation of a link between those two chunks of content.
Usually, software can be taught to understand and deal with simple differences like these. But as metadata becomes more descriptive, even the best artificial intelligence falls flat. Achieving agreement—such as on a standard usage of controlled vocabulary terms—is quite difficult, often for political reasons. And expensive efforts to retrospectively reclassify content might serve as yet another roadblock to relying on shared metadata across the enterprise.
It’s not all gloom and doom, though. Whenever you create a content model, you’re forced to select the most useful metadata attributes to build from a wide variety of possibilities. So efforts to build enterprise-wide content models will yield a useful byproduct: in the process, you’ll identify the few most important varieties of metadata to invest in.
“Telescoped” metadata development
Indeed, in the case of metadata, some varieties are indeed easier than others, though nothing’s ever easy.
Use content model exercises to help you choose which types of metadata to develop or acquire. But also keep in mind that, in general, the less ambiguous the metadata, the cheaper and easier you’ll find it to develop or acquire, and maintain. Table 19-1 orders some common (but by no means comprehensive) types of metadata attributes, from least to most difficult.
Table 19.1. Relative difficulty among metadata attributes; start with the simple ones
| Level of difficulty | Metadata attribute | Comments |
|---|---|---|
| Easy | Business unit names | These are typically already available and standardized |
| Easy to Moderate | Chronology | Variations in formats (e.g., 12/31/07 versus 31/12/07) usually can be addressed by reasonably intelligent software |
| Moderate to Difficult | Place names | Although many standards exist (e.g., state abbreviations and postal codes), many enterprises (and their business units) use custom terms for regions (such as sales territories) |
| Moderate to Difficult | Product names | Product granularity can vary greatly; marketing may think in terms of product families; sales in terms of items with SKU numbers, and support in terms of product parts that can be sold individually |
| Difficult | Audiences | Audiences, such as customers or types of employees, vary widely from unit to unit |
| Difficult | Topics | The most ambiguous type of metadata; difficult for individuals, much less business units, to come to agreement on topical metadata |
Similarly, as we know from examining thesauri, metadata can support a complexity of semantic relationships, ranging from synonyms to broader/narrower terms to related terms (see Table 19-2). Consider beginning your enterprise metadata journey by relying on simpler vocabularies that provide only synonyms, rather than full-blown (and more expensive) thesauri.
Table 19.2. Relative difficulty of developing semantic relationships within metadata; again, start with the simple ones
| Level of difficulty | Type of relationship | Examples |
|---|---|---|
| Hard | Synonymous | Synonym rings and authority lists |
| Harder | Hierarchical | Classification schemes |
| Hardest | Associative | Thesauri |
Simpler vocabularies mean simpler information architectures. You might be able to assemble the metadata you’ll need for the top few layers of a site-wide navigation system before politics and your own lack of expertise with local content get in the way of going deeper.
It’s amazing that, after years of kicking around in the backwaters of corporate consciousness, “metadata” has suddenly emerged as a buzzword. Yet many senior decision-makers now see it as a panacea in much the same way they held out hopes for portals, personalization, and enterprise search in the past. We should all realize that there’s no such thing as a silver bullet, especially when it comes to information architecture; each interesting approach, new or not, comes with many hidden costs. Understanding the varying degrees of difficulty involved with metadata implementation will help you—and your enterprise—scale up its investment in metadata-driven solutions in a reasonable and ultimately successful manner.
[Editor's note: the rest of this chapter deals with the role of search, "guerilla IA," and key operational issues around enterprise information architecture. Well worth the read...]