Corporate Intranet design

how a large enterprise information architecture was improved and How a modular approach and an emphasis on service helped the MSWeb
JohenCorner Profile Pic
JohenCorner,France,Professional
Published Date:02-08-2017
Your Website URL(Optional)
Comment
Chapter 20 MSWeb: An Enterprise Intranet20 What is the Holy Grail for information architects? It’s the secret that will help them develop and maintain a user-centered information architecture for a large, distrib- uted enterprise—the kind made up of all sorts of autonomous, bickering business units that have their own goals, their own sites, their own infrastructures, their own users, and their own ideas of how to go about things (see Chapter 19 for more on enterprise information architecture). It’s nearly impossible to develop a successful information architecture against a back- drop of explosive content growth, content ROT, and the political twists and turns common in any organization. And, we’re sorry to say, no one can claim to own the Grail. But we’ve had the privilege of getting up close to a large number of corporate intranets. And one of the best approaches we’ve seen so far is the one taken by Microsoft’s intranet portal (MSWeb) team. Before you protest, we admit that yes, we understand that you probably don’t have the same resources at your disposal as Microsoft’s team did. But we think everyone can learn from Microsoft’s efforts; what it’s doing today is what most intranets will be doing in three to five years, for two reasons. First, MSWeb’s approach is flexible enough to be customized for many large organizations. And second, knowing Microsoft, it’s a reasonable bet that the good ideas described here will soon enough find their way into Microsoft’s product offerings and into your IT department. So perhaps you’ll own a piece of this approach in the not-too-distant future. Let’s pre- view it here so you’ll be ready. 429Challenges for the User Like Microsoft itself, MSWeb is insanely huge and distributed. Let’s use some num- bers to paint a picture of the situation. MSWeb contains: • 3,100,000+ pages • Content created by and for over 50,000 employees who work in 74 countries • 8,000+ separate intranet sites With apologies to Herbert Hoover, Microsoft has put a web server in practically every employee’s pot. Employees, in turn, have responded by embracing the technol- ogy (as you’d expect from one of the world’s largest technology companies), and by churning out an impossibly huge volume of content. But if you’re a typical Microsoft employee, these numbers also represent a bit of a problem. Microsoft estimates that a typical employee spends 2.31 hours per day engaging with information, and 50 percent of that time is used looking for that infor- mation. Although you already know how ambivalent we are about using such calcu- lations to estimate actual costs to the organization, we think these numbers show that at least some valuable employee time is being wasted flailing about in this huge environment in search of information. Here are just a few examples of how this chaotic environment hurts Microsoft employees. Where to begin? This is your typical case of “silo hell.” With as many as 8,000 possibilities avail- able, employees have a hard time determining where they should begin looking for the information they need. While some starting points are obvious—check the human resources site for information on your medical insurance or 401K plan—other areas, such as technical information, are scattered throughout Microsoft’s intranet environment. Inconsistent navigation systems Navigation systems are quite inconsistent because they employ many different labeling schemes. Therefore, users are confused each time they encounter a new one. Not only does this inhibit navigation, it also muddles the user’s sense of place. Same concept, different labels Because different labels are used for the same concepts, users miss out on impor- tant information when they don’t search or browse for all the possible labels for those concepts. For example, users may search for “Windows 2000” without realizing that they also need to hunt for “Microsoft Windows 2000,” “Windows 2000,” “Win 2000,” “Win2000,” “Win2k,” “Win 2k,” and “w2k.” 430 Chapter 20: MSWeb: An Enterprise IntranetDifferent concepts, same label Conversely, a term doesn’t always mean what you think it does. For example, ASP can mean “active server pages,” “application service providers,” or “actual selling price.” And the term “Merlin” has been used as the code name for three very different products. Ignorance is not bliss Often, users are happy when they get any relevant information. But in a knowl- edge-intensive environment like Microsoft’s, users are much more demanding— their jobs depend on finding the best information possible. In this case, employ- ees often get frustrated because they don’t know when to stop searching. Is the content simply not there? Or is a server down somewhere? Or maybe they didn’t enter a good search query? It’s not hard to see how a typical employee’s 1.155 hours per day might get burned up. In short, Microsoft employees face an expansive and confusing information envi- ronment that’s about as intimidating as the Web itself. Challenges for the Information Architect The flip side of this problem is how these numbers affect the people who are respon- sible for making Microsoft’s content or aggregating that content into portals. Let’s make another comparison to the broader Web. Building and maintaining the Yahoo portal was a huge undertaking, spanning years and a gigantic collection of content— the Web as a whole. MSWeb is a portal, too, and though 8,000 sites is a much more manageable number than what Yahoo faced, consider the varying motives and con- cerns of those who own and maintain those independent sites. And Microsoft can’t charge or compel site owners within the company to register. Instead, the MSWeb team has to create incentives for participation in its model. But the owners of the intranet’s various sites are too distracted by other concerns (such as serving their own constituencies) to consider how their site fits into the bigger picture of Microsoft’s intranet. When a site is brought into the MSWeb fold, it comes with its own information architecture. Its organization, labeling systems, and other tricky information archi- tecture components must be integrated into the broader MSWeb architecture or be replaced altogether. For example, as many as 50 different variants of product vocab- ularies had been created in the Microsoft intranet environment. Fixing such prob- lems is a messy and complicated challenge for any information architect. And it gets even worse: all of those Microsoft intranet sites are backed up by a tech- nical architecture of some sort. Some are designed, built, and maintained by in-house technical staff and are quite advanced and elaborate. At the other extreme are sites maintained by hand or by a simple tool like MS FrontPage. The technology architec- tures that support the Microsoft intranet environment vary widely in complexity, Challenges for the Information Architect 431 and the MSWeb team must determine ways to normalize and simplify the environ- ment to make content management easier and more efficient. Additionally, many of these technology architectures are not designed to support a portal or any other sort of enterprise-wide information architecture, so that’s another crucial factor the MSWeb team must account for. Does your head hurt yet? We Like Taxonomies, Whatever They Are Well, many heads were throbbing at Microsoft. And an odd and often misunder- stood term—“taxonomies”—began to be heard in corridors at Redmond. Although they share a common x, “taxonomies” and “sexy” are two words that aren’t often seen together in public. So when “taxonomies” become a part of everyday conversa- tion, it’s a sure sign that an organization is ready for a deeper look into information architecture. So Microsoft’s MSWeb team heard the word and knew that the time had come for a more ambitious approach to improving MSWeb. The team—fewer than 10 people, but populated by an impressive mix of information scientists, designers, technolo- gists, and politically savvy managers—began to consider what users meant when they called for better (or any) taxonomies. Instead of the traditional biology-inspired definition, Microsoft’s employees thought of taxonomies as constructs that would help them search, browse, and manage intranet content more effectively. In response, the MSWeb team developed a more generalized operating definition of taxonomies that would be more in line with how other employees were using the term. This flexibility—the willingness to speak the language of clients, rather than rigidly clinging to a “correct” but ultimately unpopular meaning—was key. It set the tone for successful communications between the MSWeb team and its clients throughout the organization. Three Flavors of Taxonomies The team defined taxonomies as any set of terms that shared some organizing princi- ple. For example, descriptive vocabularies were seen as controlled vocabularies that described a specific domain (e.g., geography, or products and technologies) and included variant terms for the same concept. Metadata schema were collections of labeled attributes for a document, not unlike a catalog record. Category labels were sets of terms to be used for the options of navigation systems. These three areas com- prised the foundation of the MSWeb approach. Better searching, browsing, and managing of information would be achieved by designing taxonomies that could be shared throughout the enterprise. 432 Chapter 20: MSWeb: An Enterprise IntranetDescriptive vocabularies for indexing Developing terms to manually index important pieces of content seemed a smart proposition for the MSWeb team. It would complement automated indexing by the search engine, which was currently the primary means of making the site’s content available. But creating and applying descriptive vocabularies is an expensive proposi- tion, especially within an information environment as large as Microsoft’s. And there are so many different ways to index content, so half the battle was in selecting which vocabularies would deliver the most value to the organization as a whole. The MSWeb team considered a number of issues when deciding which vocabularies to develop. Not surprisingly, characteristics of the content drove many of the decisions. Search-log analysis Queries from MSWeb’s search-query logs are stored in an SQL database and can therefore be searched and more easily analyzed. Search-log analysis helped the MSWeb team gauge user content needs in users’ own words and determine appropriate vocabulary terms. Studying the search log’s most common queries also helped the team get a good overview of which content areas were generally most valuable to users. Availability The team looked for decent controlled vocabularies that had already been devel- oped in-house or that were available commercially. Vivian Bliss, MSWeb Knowl- edge Management Analyst, puts it simply: “Don’t reinvent the wheel” If there’s a useful vocabulary out there, it’s much cheaper to license and adapt it than to create a new one. Unfortunately, most of the required vocabularies were very specific to Microsoft’s content and had to be custom-built in-house. Other decisions were driven by business context. The MSWeb team considered such issues as: Politics The team was careful to talk with content stakeholders about what they felt was needed to make their content more accessible. In some cases, stakeholders were interested both in information architecture concepts and in committing to work- ing with the MSWeb team. Others were interested in neither. Through such dis- cussions, it became apparent which stakeholders were ready to participate and which weren’t. Applicability Some vocabularies were too specific to have broad value for users across the company. The MSWeb team instead focused on vocabularies with broader appeal and value. We Like Taxonomies, Whatever They Are 433 After taking all of these considerations into account, Microsoft narrowed its vocabu- lary development to the following vocabularies: • Geography • Languages • Proper names • Organization and business unit names • Subjects • Product, standards, and technology names Developing some of these vocabularies was trickier than you might think. Geogra- phy, for example, had to be split into two separate vocabularies: general place names, and locations of Microsoft installations. On the other hand, the subject vocabulary development was simpler than it might have been: its development was constrained primarily to addressing equivalence relationships. The MSWeb team hasn’t added extensive hierarchical and associative relationships; that would require a huge effort and take resources away from developing other vocabularies that could provide broad benefits right away. (In the future, the team does plan to selectively address these other relationships as time and resources permit.) Metadata schema Developed hand-in-hand with controlled vocabularies, metadata schema describe which metadata to use to describe or catalog a content resource. While Microsoft’s descriptive vocabularies were driven by content and context, metadata schema were informed more by issues of users and content. The MSWeb team developed a single schema that has value for both MSWeb and other intranet sites. Borrowing from the Dublin Core Metadata Element Set (see http:// dublincore.org), MSWeb’s schema was intended to be sufficiently “stripped down” so that content owners would use it to describe resources, resulting in more records and therefore a more useful collection of content. The schema’s simplicity was balanced with the goal of providing enough descriptive information to augment searching and browsing by users. The team also had to ensure that records produced using the schema would include fields useful for resource description, display, and integration with other parts of the information architecture (namely by integrating with search results and browsing schemes). The process used to develop this metadata schema was, in the words of one team member, “down and dirty.” Although more polished methodologies exist, sufficient resources were not available at the time for this initial schema develop- ment project. For this reason, it was important to structure the schema to include both a required “core” set of fields and the flexibility to support future extensions of the schema by other business units. To date, seven other major portals are using the metadata schema, and many have extended and customized it for their own context. 434 Chapter 20: MSWeb: An Enterprise IntranetThe schema’s core fields are: URL Title The name of the resource URL Description A brief description of the resource; suitable for display in a search result URL The address of the resource ToolTip Text displayed for a mouseover Comment Administrative information that helps manage a record (not seen by the end user) Contact Alias The name of the person responsible for this resource Review Date The date that the resource should be reviewed next (default setting is six months from when the record was created or last updated) Status The record’s status; e.g., “active” (the default), “deleted,” “inactive,” and “sug- gestion”; used for content management purposes The schema has been commonly extended with these optional fields: Strongly Recommended Flags resources that are especially appropriate Products Terms from the product, standards, and technology names vocabulary that describe the subject matter of the resource Category Label Terms from the vocabulary of category labels; used to ensure that the resource is listed under the appropriate label in the site’s navigation system Keywords Terms from descriptive vocabularies used to describe the resource MSWeb began to use the metadata schema to create resource records in 1999; since then, over 1,000 records have been created. These fuel the immensely useful “Best Bets” search results and hold huge potential for improving areas such as content management. We’ll describe the role of both metadata schema and “Best Bets” at Microsoft in greater detail later in this chapter. We Like Taxonomies, Whatever They Are 435Category labels The third type of taxonomy—labels for the categories in site-wide navigation sys- tems—was geared toward providing users of Microsoft intranet sites with naviga- tional context. Category labels help users know where they are and where they can go. The MSWeb team employed a user-centered process for designing navigation systems, relying upon useful standbys as card sorting and contextual inquiry. In Figure 20-1, the category labels are shown on the lefthand side of the screen. Descriptions of nodes, displayed on the righthand side, help catalogers choose the appropriate category label. Figure 20-1. A subset of MSWeb’s category labels, with some expanded to show subcategories The initial set of category labels was developed solely for the MSWeb portal’s naviga- tion system. But because the portal is so widely used and because the revised naviga- tion represented a major upgrade for many users, the owners of other intranet sites began to approach the MSWeb team for assistance in developing their own naviga- tion systems. The MSWeb team responded by making its user-centered design process and exper- tise into a service that other site owners could utilize. As collaboration with other sites increases, a “standard” intranet navigation system will eventually be created, likely a combination of predetermined intranet-wide options (e.g., another “core”) and a locally determined selection of choices (“extensions”) that would be informed 436 Chapter 20: MSWeb: An Enterprise Intranet by a shared set of guidelines. For now, the transitional stage of raising awareness and providing support to other site owners is considered a great leap forward and a pre- requisite to further navigation standardization. How It Comes Together The impact of all three taxonomies is clear from the MSWeb search results shown in Figure 20-2. Category labels provide contextual navigation at the end of each “Best Bet” result (the first two displayed) and populate the “categories” site-wide naviga- tion system on the lefthand side. Below that, the “terms” area displays two variants of the search term that come directly from the descriptive vocabularies. The “Best Bet” search results themselves are drawn from resource records based on a metadata schema. From category label taxonomy From category label taxonomy Based on metadata schema taxonomy From descriptive vocabulary taxonomy Figure 20-2. All three taxonomies are used to create these search results MSWeb’s “three taxonomies” approach is steeped in traditional library science, which isn’t surprising considering the backgrounds of many of those on the MSWeb team. But it’s important to note how willing the team was to abandon the traditional library science concepts that didn’t make sense in the intranet environment. For example, the team did not try to create “traditional” thesauri for its metadata schema and category label taxonomies. Other standards familiar to the LIS community, such as Dublin Core, weren’t initially adopted for MSWeb’s metadata schema because they were not appropriate at the time (although the Dublin Core schema may be par- tially or completely adopted by MSWeb at some point). We Like Taxonomies, Whatever They Are 437The Technical Architecture: Tools for Taxonomies The MSWeb information architecture is certainly informed by library science ideas. But it’s important to remember that the team (not to mention the company) has its share of technical smarts, too. Out of that combined expertise was born a suite of advanced tools for managing MSWeb’s various taxonomies. And, as mentioned ear- lier, we wouldn’t be shocked to see these tools on the shelves in the near future. Figure 20-3 shows a simplified view of the MSWeb technical architecture. The tools are the Metadata Registry (MDR), which is used for storing, managing, and sharing taxonomies used on the Microsoft intranet; VocabMan, which provides access to the MDR; and the URL Cataloging Service (UCS), which is used for creating records based on the metadata schema, category labels, and descriptive vocabularies. VocabMan UCS MDR VacabMan manages the UCS creates and manages taxonomies stored in the MDR. catalog records based on the metadata schema. Terms from the descriptive vocabularies and category labels are applied to each catalog record. Specialized collections can be Catalog records can be selected and generated from searched and browsed catalog records. by users. Best Bets or Intranet other collection page Catalog records Figure 20-3. A simplified view of the MSWeb technical architecture VocabMan and the MDR feed terms from descriptive and category label vocabular- ies into records generated from the metadata schema stored in UCS. The ultimate goal is the creation of a valuable catalog record that improves search- ing and browsing for users, and makes content management easier. Creating and managing the taxonomies: VocabMan and the Metadata Registry VocabMan and the Metadata Registry (MDR) are separate tools that are used together for taxonomy management. The MDR is simply a SQL-based relational database that uses an associative data model to store MSWeb’s taxonomies. VocabMan is a Visual 438 Chapter 20: MSWeb: An Enterprise Intranet Basic client that provides taxonomy specialists with access to the MDR, allows the creation and editing of taxonomies, and supports the creation of relationships between them. Pictures are definitely worth thousands of words, so we’ll let screenshots tell the story of how VocabMan works. The following sequence shows how a taxonomist might find a specific term to see if it is listed in an existing vocabulary, or simply to understand its context in a particular vocabulary. VocabMan’s initial screen (Figure 20-4) displays available taxonomies for MSWeb and for subsites in the lefthand column. These can be either browsed in “tree” for- mat or searched. The fields in the righthand column support the creation of a new “collection” or taxonomy of vocabulary terms. Figure 20-4. Creating and editing taxonomies in VocabMan Once an existing taxonomy is selected (in Figure 20-5, the descriptive vocabulary “Geography”), it can be searched or modified from this screen. Note that “Relation to Parent,” “Related Terms,” “Entry Terms,” and “Scope Note” are attributes of a specific term drawn directly from traditional thesaurus design. To find a specific term, we can browse the tree on the lefthand side or search on the righthand side (Figure 20-6). Here, “entry terms” are equivalent to variant terms. In Figure 20-7, a search on “Chicago” shows that it is an authorized term in several taxonomies—a test vocabulary, the products vocabulary, and twice in the geo- graphic vocabulary (once as a place in Illinois, and once as a subdistrict in Microsoft’s Midwest Sales District). We Like Taxonomies, Whatever They Are 439 Figure 20-5. Selecting a taxonomy in VocabMan Figure 20-6. Finding a term in VocabMan 440 Chapter 20: MSWeb: An Enterprise Intranet Figure 20-7. Searching for a term in VocabMan retrieves source taxonomies After selecting “Chicago” as a place in Illinois, the term is displayed in the broader context of the geographic descriptive vocabulary (Figure 20-8). The lefthand side shows us that Chicago is a city in Illinois, a Great Lakes state, and a part of the United States. On the righthand side, we see that it is a major city in relation to its parent term (“Illinois”) and is related to the Chicago Sales subdistrict (no entry terms or scope notes are available for this term). Note that the same interface allows the editing of this term’s entry. VocabMan can also be used to create thesaural relationships (i.e., hierarchical, equiv- alence, and associative) between terms within specific taxonomies and between terms in different taxonomies. The screenshot shown in Figure 20-9 has a specific schema (for “Best Bets”) displayed on the lefthand side. Highlighting “Keywords” displays the vocabularies associated with this particular schema tag in the “Related Vocabularies” field on the righthand side. “IS Proper Names,” “Subjects,” and “Organization and Business Unit Names” are the descriptive vocabularies that sup- ply the terms for the “Keywords” tag. (“Pivot vocabulary” is an administrative vocab- ulary that is not used for indexing.) Creating and managing the records: the URL Cataloging Service Drawing from taxonomies stored in the MDR, the URL Cataloging Service (UCS) is a “workbench” for creating, managing, and tagging records; it enables the creation of shared catalog records for useful resources in the Microsoft intranet (such as “Best We Like Taxonomies, Whatever They Are 441 Figure 20-8. VocabMan provides context for a taxonomy term Figure 20-9. Viewing a metadata schema’s tags and associated vocabularies in VocabMan 442 Chapter 20: MSWeb: An Enterprise Intranet Bets”). It’s based on a relational database and uses SQL Server. Like VocabMan and the MDR, UCS was initially designed for use by the MSWeb team, but its value was soon recognized by other groups, and UCS eventually became another service offered by MSWeb to other players in the Microsoft intranet environment. Using UCS, catalogers create quality resource records that directly improve the user’s experience because they can be indexed for searching and browsing. These records are created quite simply: when invoked, UCS displays the metadata schema’s attributes as fields within a form. Record creators fill out the form, selecting from category labels to classify the record and from the various descriptive vocabularies available to index the record. Catalogers have access to all the vocabularies stored in the MDR; however, they don’t have modification privileges for all records, as do the taxonomists who access the MDR via VocabMan. The initial screen of UCS (shown in Figure 20-10) describes an array of services, rang- ing from cataloging resources to link checking. It is accessed from the SAS console, which also provides read access to the MDR. SAS (Search As Service) is the bundle of information architecture and content management services that the MSWeb team offers to other Microsoft business units, and the console is the control panel that MSWeb puts in its clients’ hands. (We’ll describe SAS in greater detail later in this chapter.) Figure 20-10. The initial screen of UCS, accessed from the SAS console In this case, the user can edit or add resource records to any of the three URL sets or collections listed in the lefthand column of Figure 20-10. Catalogers are limited to modifying only those collections that they own and are responsible for; however, the MSWeb team has permissions to modify any collection. This despotism is used benevolently; for example, if a cataloger wishes to create a collection of 60 resources, We Like Taxonomies, Whatever They Are 443 the MSWeb team might find that 28 of these resources are already cataloged. As the cataloger can “subscribe to” (but not modify) these 28 resource records or incorpo- rate them into his collection, a significant amount of duplicated effort can be elimi- nated. Figure 20-11 shows a new record being added to the “Best Bets” Collection. Figure 20-11. Using UCS to add a new resource record UCS automatically checks the URL of the record to be added to see if one has been created already for that resource. In this case, no record exists, so we’ll create a new one, as shown in Figure 20-12. The fields in this form are essentially an interactive version of the metadata schema, and filling them out creates a new record. Note that this process is fairly simple and straightforward, sacrificing a degree of richness and data validation for the ease of creating new records. Figure 20-12. Filling out the fields of the new resource record 444 Chapter 20: MSWeb: An Enterprise Intranet The righthand side of the new form displays the ways it should be indexed, which are encoded in the metadata schema (Figure 20-13). Figure 20-13. The new record is ready for indexing These taxonomies draw from the category labels and descriptive vocabularies man- aged in the MDR. Clicking “Add Terms” brings up a pop-up window for selecting vocabulary terms to be added to the record. These are displayed as hierarchies for easier browsing, as shown in Figure 20-14. Or, if the cataloger prefers, he can search the descriptive vocabularies for terms that match his interest, as shown in Figure 20-15. Search results display a full path—“breadcrumb” style—to provide fuller context for the matching terms. Selecting a term (or “node,” as shown in Figure 20-15) displays its relationships to other terms. These thesaural relationships are all stored in the MDR and managed by taxonomy specialists with access to VocabMan. On the other hand, if the record for a resource already exists, the cataloger can sim- ply modify the record if it’s part of a collection he controls. If it’s part of another col- lection, he can’t modify the original record, but he can “subscribe” to that record and add custom tags to it that are locally used (record subscription is described later in this chapter). In all cases, the cataloger can elect to create a duplicate entry. For example, the cataloger might know from search-log analysis that his site’s users are often looking for product information. The product history information at http:// msw/products would be an excellent “Best Bet” for his site’s users. He enters the URL and learns that two records already exist for this resource (see Figure 20-16). One We Like Taxonomies, Whatever They Are 445 Figure 20-14. The cataloger can browse for a term from a taxonomy associated with this schema... Figure 20-15. ...or the cataloger can search for a taxonomy instead (note the helpful information displayed for this node) 446 Chapter 20: MSWeb: An Enterprise Intranet record is from the MSWeb “Best Bets” collection, and the other is from Microsoft’s Museum “I Need To” collection (another high-value record collection used in MSWeb, similar to “Best Bets”). Note that only the URL is the same; the two records have different titles, descriptions, and other metadata associated with them, and dif- ferent contexts often require different tags. In this case, the cataloger chooses the Museum record for this resource. Figure 20-16. Two records have already been created for this resource Because this record was created as part of a separate collection, its core tags can’t be modified. However, subscribed records can be extended for local use. In this case, the cataloger can apply the metadata schema extensions that are used by his own col- lections (Figure 20-17). These fields—“Keywords” and “Products”—are displayed in the upper-right corner. The cataloger can populate these fields with terms from the descriptive vocabularies that his organization has decided will have the most value for its users and content owners. UCS also provides other useful tools for helping manage resource records, including link checking, broken-link reports (Figure 20-18), and a calendar of tasks for periodi- cally revisiting and checking the quality of a resource record. But perhaps the most important aspect of UCS is how well it balances a core of requirements with a flexi- ble set of extensions. By bringing together taxonomies and other resources in a straightforward interface, UCS makes it easy to create more records. Similarly, because UCS supports the sharing of those records, intellectual effort is not dupli- cated. Sharing is made even more effective by the metadata schema’s extensibility— resource records can be better customized for local use, resulting in more incentive to “borrow” rather than re-create. In other words, UCS supports the investment of We Like Taxonomies, Whatever They Are 447 Figure 20-17. The selected record, created by another cataloger, can be extended with fields from the metadata schema utilized by this editor’s collection human capital in the creation and customization of content rather than the duplica- tion of effort—something all too common in most enterprise environments. This philosophy of flexibility and sharing extends throughout the MSWeb approach and suite of tools. For example, Microsoft’s library doesn’t use UCS at all, opting instead for its own homegrown tool for creating resource records. However, its tool can access the MDR and its taxonomies in much the same way that UCS does. In this case, flexibility through modularity accommodates other business units’ needs (i.e., for a specialized record-creation tool) without forcing them to reject all aspects of MSWeb’s approach (i.e., the taxonomies stored in the MDR). The use of open standards further illustrates this flexible, modular approach. XML is employed in exporting taxonomy terms to tools like UCS and the library’s similar tool; other units’ approaches could easily utilize XML exporting in the same way. Similarly, XML is employed by UCS as the basis for exporting resource record data to be used as search results by numerous Microsoft intranet sites. Beyond Taxonomies: Selling Services The MSWeb team started out with a vision of the very broad but tricky area of tax- onomies, and went to work figuring out how they could be built for use on the MSWeb portal. The team tested and developed tools and vocabularies that improve content management as well as searching and browsing of the MSWeb site. 448 Chapter 20: MSWeb: An Enterprise Intranet