Section 19.3. Designing an Enterprise Information Architecture

19.3. Designing an Enterprise Information Architecture

As with any other flavor of information architecture, there's no "right way" to design an enterprise information architecture. However, over time certain IA design approaches, when pursued in the appropriate sequence, have emerged as making the most sense in the enterprise setting.^[*] In this section, we've broken the wide range of possible IA design components into four categories, and for each we provide a few nuggets of practical advice on what to do and what not to do. We could fill up an entire book on enterprise IA design, but we hope you'll find this tip of the iceberg to be useful.

^[*] Lou Rosenfeld's Enterprise Information Architecture Roadmap represents an effort to capture what makes sense to do and when; you can download the latest version (in PDF) from http://louisrosenfeld.com/publications/index.html#enterpriseia.

19.3.1. 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.

19.3.1.1. 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. Granted, 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 enda 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...

19.3.1.2. 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 (aka table of contents, as discussed in Chapter 7) 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.

Normally, your attention would be focused on improving the organization system, weaning your enterprise from an org-chart-driven self-view. But that's quite difficult to pull off in an enterprise setting, and requires considerable agreement and coordination.

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.

19.3.1.3. Slim down your site index

Another prime piece of real estate is the site index (also covered in Chapter 7). 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.^[]

^[] Our former company, Argus Associates, was once hired by a Fortune 500 company to develop a custom AZ index for its public site. Wed recommended investing in search improvements, but the search engine was off-limits at the time, so we began work on the index. Many months and $250,000 later, a comprehensive index was built and launched, and a team of indexers trained to maintain it. And two years later, it was thrown away, as the IT department acceded to improvements to the search system. So it goes in the enterprise environment.

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, shown in Figure 19-2, doesn't include directions to its campus or biographies of its directors. Instead, it provides an AZ list of health topics and issuesthe primary kind of content that users come to the site for.

Figure 19-2. The Centers for Disease Control's specialized index on health topics

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.

As an alternative, you might consider another variety of less-than-comprehensive site index. Michigan State University builds its site index, shown in Figure 19-3, automatically, using the same common keywords derived from search-log analysis that have been assigned Best Bet results. Essentially, if the query is good (common) enough to merit a Best Bet, it's good enough to be included in the site index. Note that each entry links directly to its Best Bet result:

Figure 19-3. MSU's index is automatically generated from common search keywords; the index is uneven but useful nonetheless

19.3.1.4. Develop guides

Guides, also covered in Chapter 7, 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, like the one in Figure 19-4, are selectivethey're something of an enterprise FAQand 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 users 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. And you can use a variety of methods to determine common needs, such as search-log analysis (discussed in Chapters 6 and 10), persona development, and even talking to your organization's switchboard operators.

Figure 19-4. Vanguard introduces its guides front and center on the main page (in the "I want to " section)

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 expertin the example above, the poor person besieged by requests for help processing travel expenseswill 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 luxuryor patienceas 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. Build a few guides to address common tasks and information needs, and you'll see how a little effort can go a very long way.

19.3.2. 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.

19.3.2.1. Build 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 (which we've introduced in Chapter 12).

Think back to the common information needs and tasks that we discussed earlier. Each might require navigating deep into the guts of your site; strong contextual navigation requires strong content models. Of course, some of the 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.

19.3.2.2. 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 shows a simple illustration, using the BBC content model. Here we want to connect our model with relevant contentlet's say events from a concert calendar and TV listingsfrom 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 workif 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 namesay, 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. For example, if one unit at the BBC classifies Johnny Cash's music as "country," while another unit deems it "Americana," genre metadata wouldn't be very useful or usable for automating connections between content models. Achieving agreementsuch as on a standard usage of controlled vocabulary termsis 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. The same is true when you connect content models across silo boundariesthis exercise reveals the few types of metadata that you should focus your efforts on across the enterprise. So efforts to build enterprise-wide content models will have a useful byproduct: in the process, you'll identify the few most important varieties of metadata to invest in.

19.3.2.3. "Telescoped" metadata development

In the above example from the BBC, you can see that some metadata types are easier to standardize than others. Because EIA is an expensive, long-term undertaking, you've got to prioritize whenever possible, taking on the easy wins first while building momentum toward tougher challenges. 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 in Chapter 9, 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. And your architecture almost certainly won't be able to take advantage of "see alsos" and other related terms in any substantial way until your organization achieves some measure of "EIA maturity."

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 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 youand your enterprisescale up its investment in metadata-driven solutions in a reasonable and ultimately successful manner.

19.3.3. Search Systems and EIA

As pessimistic as we are about instituting descriptive metadata across the enterprise, we see great potential for enterprise search systems. They're the closest thing to a killer application for enterprise information architectures. Search systems can provide access to most or all of your enterprise content, regardless of silo. The query logs they create generate valuable data that can help you diagnose and fix your information architecture's biggest problems. And because, typically, the same retrieval algorithm is applied to all of your enterprise's content, search is as apolitical as things can get in the enterprise environment. Put another way, you might have a product manager scream at you about your design of your site's navigation, organization, and labeling systems, but we'd be surprised that she'd come after you for reasons related to search.

That said, we don't advise purchasing the latest and best enterprise search engine, installing it, and simply walking away. Small modifications can go a long way toward improving the interface. We've already covered many search system improvements in Chapter 8, but we'll reiterate a few here, recast for enterprise consumption.

19.3.3.1. Simple consistent interface

If it's important anywhere, it's especially important in the enterprise: a simple search interface"The Box"should behave consistently and be consistently located on each page, like the one shown in Figure 19-6, regardless of who owns that page. Thankfully, this is becoming a convention, partly due to the advent of content management systems and their use of standard templates, which can be customized to include a simple search interface.

Figure 19-6. If IBM can pull off a simple search interface on each of its pages, so can you!

Perhaps your enterprise isn't able or willing to provide a standard interface. Don't let that stop you; simple search is a good cause around which you can build a campaign for some measure of enterprise centralization. Not only is it everywhere (you don't have to look far to see how it's emerged as a convention), but you can find good supporting data; for example, you can always cite a guru like Jakob Nielsen, who makes the point^[] that roughly 50 percent of all users begin their sessions on any given site by searching. Very few people can muster a strong case against ubiquitous simple search interfaces, and once you succeed with this particular battle, youll have momentum to take on bigger challenges that require some measure of coordination across the enterprise.

^[] Jakob Nielsen, "Search and You May Find." AlertBox, July 15, 1997. http://www.useit.com/alertbox/9707b.html.

19.3.3.2. Analyze those logs

If search systems are the killer app for enterprise sites, then search-log analysis is the killer enterprise diagnostic tool. You don't need to spend months analyzing your query data to reveal some critical problems with your search system and content. Common examples: users' preponderance to misspell and mistype queries (fix it by implementing a spell-checker to your search system), frequent entry of acronyms and jargon (address with a glossary), searches for product codes (make sure your product pages include those codes!), and so on.

19.3.3.3. Prioritize your queries

Additionally, search-log analysis is a means for revealing which are the most commonly searched queries on your site. You can use this data to prioritize your efforts at developing Best Bet search results (covered in Chapter 8) and in a similar vein, guides, which could be considered Best Bets for main pages.

The numbers are really in your favor here: let's say you create Best Bet results for the 200 most common queries. These 200 queries account for 25 percent of your all queries executed on your site. If, as Jakob Nielsen suggests, 50 percent of your site's users start by searching, multiply that 50 percent by 25 percent; the result is an improvement in the user experience for 12.5 percent of all users. These numbers, like all IA-related numbers, can be easily challenged, but the message behind the numbersimproved performancestill rings loud and true.

While you're at it, look over those top queries, identify which have zero results, and plug those content gaps. Might that bring you another three to five percent improvement in the user experience? Not bad. Add in some percentage for users who'd previously been defeated by spelling errors and typos, and the numbers start to add up.

19.3.3.4. Reverse-engineering content and metadata

No matter what you do to improve your enterprise search system, poor content and metadata can conspire to derail your efforts. Garbage in, garbage out. And in a distributed environment, it's hard to even find authors, much less to convince them to do a better job preparing their content for consumption via the web site or intranet.

When you do have the opportunity to bend an author's ear, you'll need a good tool to help convince him to do a better job authoring content, applying metadata tags to it, and titling documents. Whether this comes up in the context of an enterprise style guide or a face-to-face meeting, come prepared with an example of poor search resultswhich include some of his own documentsto demonstrate just how much his work impacts users down the line.

For example, a search for "financing" on the DaimlerChrysler site returns poorly formatted, poorly titled results, as shown in Figure 19-7.

Figure 19-7. Wouldn't you be a bit embarrassed if you were the author of one of these documents? (Or, for that matter, responsible for the search system?)

You now have the opportunity to show authors of these documents the importance of well-considered document titles. Conversely, you could show content authors how their documents don't show up as highly as they should in search results, and explain to them how they might improve their rankings by following the enterprise's guidelines on writing titles and good copy, and assigning metadata.

Poor search results are an effective way to communicate to authors just what happens when they fail to see their content, and their work, as part of something much largernamely, an enterprise web site or intranet that serves thousands of users. "Reverse-engineering" search results uncovers opportunities for authors to do better, makes the case for doing so quite clear, and provides you with a way to accomplish "organizational change" in a small but important way: author by author.

19.3.4. "Guerrilla" EIA

The three tracks described so far all have to do with overlaying existing content from different silos with user-oriented ways to navigate and search. Increasingly, these approaches are being complemented with newer, often emergent methods of connecting users and content in the enterprise setting. One " guerrilla" approach is predicated on enabling the creation of content that is, by definition, cross-departmental (mostly through the use of blogs and wikis). Another is the growing use of folksonomic tagging to provide access to content. Both guerrilla approaches make sense primarily on intranets.

19.3.4.1. Klogs for internal experts

Remember the person who knew so much about filing expense reports at our fictional consulting firm? She's an SME (Subject Matter Expert) whose expertise spans multiple business units' content. It serves the goal of EIA to enable her knowledge to be captured and shared more broadly within the enterprise. To that end, many companies are providing simple blog tools to their SMEssometimes describing them as "klogs," or knowledge blogs^[§]to help them share what they know.

^[§] It should be noted that many public-facing web sites increasingly feature blogs from their employees as a way to positively influence customers. This is especially the case in technical areas where it is beneficial to showcase in-house technical expertise.

Implementing klogs internally is technically fairly simple; however, identifying SMEsespecially ones with valuable cross-departmental knowledgemay be a bit difficult. Even more challenging, your enterprise's culture may not support its employees sharing their knowledge. It's an unfortunate fact that many organizations encourage its opposite: knowledge hoarding. Additionally, many SMEs aren't willing to share what they know simply to protect their job security. So klogs aren't a slam dunk, especially in settings where there is little incentive to share information. But their technical barrier to entry is low, and they at least merit consideration. Many individuals already do share their knowledge, especially if it raises their personal visibility as an expert within the enterprise (and if it helps them to avoid answering the same questions over and over again).

19.3.4.2. Wikis for groups

Just as klogs enable individuals to capture and share their cross-departmental knowledge, wikis and other shared-authoring tools have similar potential for groups. Every enterprise has projects that require collaboration from multiple business units; these are typically tackled by temporarily constituted committees and working groups.

Wikis can make it relatively easy for these committees to capture their workwhich, by definition, has cross-departmental value. In many cases, the content these groups develop will eventually receive official blessing and be published in a more traditional format, perhaps as a Word document or a PDF. But even in its relatively fluid and unfinished state, such content can have significant value to enterprise users. Additionally, wiki-based content is more likely to be accessible via search systems than Word or PDF files.

19.3.4.3. Accessing internal expertise through the staff directory

In so many cases, we search intranets for people rather than content. As cross-departmental information systems, staff directories are already excellent demonstrations of the value of EIA. We can extend their value by linking directory entries to corresponding klog and wiki content. The result: users can find out more about coworkers than their email addresses; they can learn about colleagues' expertise, what projects they've served on, and who they served with. Users can also search a topic and ultimately find a person.

Traditional directories can also be expanded to include more relationships between coworkers, such as reporting relationships. For example, it can be useful to know what to expect from the new boss by grilling a few of his past supervisees. Look to social-network services like LinkedIn (shown in Figure 19-8) and Ryze for models of how staff directories can be expanded and enhanced.

Figure 19-8. An entry from LinkedIn; is this your staff directory's future?

19.3.4.4. Aggregating staff expertise...and everything else

If your enterprise does begin investing in blogs and other means for capturing cross-departmental content, the good news is that most of these new publishing tools generate RSS or Atom feeds for recently posted content (blogs especially, of course). The better news is that there are many tools, both web-based^[||] and standalone, that allow users to aggregate the feeds they've subscribed to. Imagine in-house researchers relying on aggregators to easily monitor the findings of their colleagues from research centers throughout the enterprise as soon as they're published.

^[||] If you're not familiar with aggregators, we recommend kicking the tires of the excellent and free web-based service Bloglines (http://www.bloglines.com).

The even better news is that, as feeds become common for just about any type of web site, your enterprise's users could subscribe to feeds from a variety of departmental subsites. The aggregator becomes the means for accessing an enterprise's new contentregardless of originating siloin one window. Imagine aggregating news releases from their many sources within your enterprise so you can keep up with what your own employer is actually doingor enabling a public site's users to do the same.

19.3.4.5. Social bookmarking in the enterprise

Social bookmarking applications like del.icio.us have succeeded at helping users tag and return to visited content from across the Web. And by seeing what others have tagged with the same tags, del.icio.us subscribers also benefit from the wisdom of the hive, learning about other relevant documents (and who shares a similar interest).

Could the same approach work in the enterprise? Although it's too soon to say, large enterprises like IBM are hoping to find out.^[#] Enterprise environments are obviously smaller than the Web as a whole, but they certainly exhibit web-like characteristics, such as overwhelming growth, frustrating organization, and swirling change. Bookmarking tools could help enterprise users benefit from one another's tagging efforts, and as an additional benefit, find like-minded colleagues. Collectively, tags also provide excellent fodder for helping improve traditional controlled vocabularies and bring them up-to-date.

^[#] David Millen, Jonathan Feinberg, and Bernard Kerr, "Social Bookmarking in the Enterprise" in ACM Queue, vol. 3, no. 9. Nov. 2005 (http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=344&page=1).