Enterprise Information Architecture: Don’t Do ECM Without It

Page 2 of 4

May 05, 2004

May 2004 Issue


EIA Offers ROI
Rosenfeld notes that every enterprise information system possesses some notion of information or data architecture—albeit usually an independent one. By investing in EIA, companies can increase the ROI on all information applications by exposing the information across the corporation so users can find things faster and managers can do their jobs better.

Put another way, EIA helps users find the right information, which is the whole point of IT investments in the first place. In the words of Joseph Busch, founder and principal of Taxonomy Strategies, content becomes "actionable." For enterprise customers where that action is "buy things," EIA adds tangible value to the top line.

According to Morville, EIA can also add value to the bottom line by reducing costs. Among his clients, Morville has seen huge duplication of effort as different departments deploy various search engines, each configured differently. He also sees substantial redundancy of effort going into navigational structures, which makes it difficult and costly for enterprises to update Web sites as products and services evolve.

OK, EIA is important, but how do you actually practice it?

EIA as a Discipline
There may be a dearth of EIA textbooks, but a set of common practices is slowly emerging. Some key issues revolve around:

  • Balancing central versus local needs and authority
  • Tactical versus strategic approaches
  • Understanding (and acting on) the different (but related) EIA problem domains

Let's take a look at each issue in turn.

Centralized versus departmental control represents a struggle as old as the first distributed enterprise. In IA today, it appears that departments are winning for the most part. But there are some approaches to restoring balance.

Even in a highly decentralized environment, EIA specialists will, at a minimum, seek some coordination among different information systems, obtaining consistency in content models where possible (i.e. two departments agree to label first names "fname"), and mapping terms where things must have different labels or categories. In other words, information starts to become integrated at the metadata tier, not the content tier. The idea here is that departments don't have to comply with a central standard, but they do have to expose data models, especially if they want access to information in the central directory.

Peter Hallett, VP of marketing at SchemaLogic, likens a standard enterprise content model to having a municipal plan or blueprint. If you want to construct a building, you know where to connect up the sewer, electricity, phone line, and so forth. That sort of standard infrastructure approach sounds nice as a goal, but Hallett is quick to point out that, given its complexity, the typical enterprise supports multiple taxonomies, each covering a broad swath of enterprise content, ranging from audience, to subject, to processes, and so forth.

Rosenfeld counsels a two-step approach to the problem of multiple taxonomies:

1. Build shallow, broad central taxonomy that answers "where will I find the information I need?"
2. Rely on independent departmental taxonomies to answer "where in this area will I find the information I need?"

The much-lauded Microsoft intranet, MSWeb, was an early adopter of a similar approach two years ago. The intranet team catalogued a collection of taxonomies—some enterprise, some domain-specific—and allowed them to coexist. Like many companies, Microsoft's product taxonomy became sacrosanct, but individual departmental navigational taxonomies were also sanctioned, as long as they were registered centrally. Over time, the various intranet navigation schemes were eventually harmonized as well.

Some U.S. federal agencies are also beginning to take a more centralized approach to metatagging standards. In one of his first acts as administrator of the Environmental Protection Agency, Mike Leavitt challenged his organization's departmental Web managers to "reorganize content to serve users, not your programs," and to develop a high-level, agency-wide taxonomy of 30 terms within six months (to be doubled in another six months).

Like all enterprise projects, EIA has both a tactical and strategic dimension. At a tactical level, it encompasses the standard IA design deliverables—ranging from wire frames and design guidelines to taxonomies and controlled vocabularies—but promulgates enterprise-wide. These, in turn, can help drive specifications for content management systems and search engine optimization.

The part about enterprise promulgation, though, requires some real strategy, and here's where information architects often need help. Rosenfeld argues for a formal EIA governance structure centered around an independent team, complete with charter, staff, and budget. In such a model, the group might serve as a self-funded consulting resource to the rest of the enterprise.

Centralized resources are handy, confirms Morville, because "different business units are going to be at different stages at different times and one way to accommodate that is to see those needs as market demand: One business unit might want different things than another."

But at the strategic level, companies must deal with corporate politics. Morville says, "Trying to get major stakeholders on the same page for navigation and search support—given dozens of different business units who control the actual content—requires a skill set that most information architects don't have." He suggests educating and winning over a senior manager who can communicate with peers and connect tactical detail with enterprise objectives.

Assuming that a company creates an EIA group or governance board, it needs a charter, which raises the question of scope. What should fall under its purview?

Rosenfeld has attempted to create a generic EIA roadmap that, while he worked hard to fit it on a single page, is still pretty intimidating. Rosenfeld admits as much. "The roadmap doesn't make sense for all enterprises, and some may be unworkable in your environment," he says, "but you should have an understanding of your options." And, of course, recognize relationships among the choices you make.

Rosenfeld's roadmap does have practical applications. It suggests, for example, that doing a content analysis before conducting a content inventory is premature. "I think the roadmap sums up the challenge," confirms Victor Lombardi, a former IA lead at Razorfish and now an information architect at a major New York City financial services firm. "Taxonomy is here, and search is there, and the roadmap shows all the steps we need to take over the next three years—listed on one page—that's pretty remarkable," says Lombardi.

But as a practical matter, where to begin?

Page 2 of 4