Vivian: The larger group I belong to, the Knowledge Network Group (KNG), formerly known as Information Services, began establishing an information architecture almost three years ago with the first targeted use being the corporate intranet's general portal, MSWeb.

We recognized the level of pain caused by increased use of the corporate intranet as the information system by both content creators and users. We went from 128 pages in 1995 to 2.3 million pages in 1998. A change in the user interface would not suffice. The entire portal needed evaluation from the back end technology through the middle (content and metadata) out to the user interface coupled with a clear understanding of our users and our culture. We also recognized that other portals in the company were in pain and would be looking for solutions for their information systems very soon. We wanted to create an architecture that could be leveraged by other portals.

Lou: Let me interrupt here--when you mention "pain," what do you mean?

Vivian: Information seekers experience pain when they cannot find what they are searching for, become totally lost in an information system or lost between multiple information systems. With the enormous increase in content on the corporate intranet and the growing number of portals, the pain was increasing across the company. There is also a specific type of pain felt by portal owners when someone at the executive level cannot find what he or she is seeking and voices their dismay.

So, after making MSWeb a more usable and useful portal, we made it possible to extend the new architecture to other portals by packaging into components, consolidating and using XML.

Lou: Could you talk a little more about this three-headed approach?

Vivian: We made components out of pieces of the architecture such as the enterprise-wide search, the taxonomies and the different content collections used. We consolidated access to our two main databases driving the system to a single web interface for use by our group and the groups leveraging our architecture. We deliver the search and taxonomy services to other portals and tools using XML. This creates an abstraction layer that allows the other groups to create any look and feel they want on their side or to use any tool of their choice, and allows our group to make updates and changes on our side without breaking any of our customers' information systems.

For example, to crawl and index the corporate intranet we recently changed from MS Site Server search technology to the search technology included in MS SharePoint Portal Server. We did this exchange on our side without breaking any of the portals run by our customers because although we changed underlying technologies we delivered search results in the same XML.

By componentizing, consolidating and using XML we drastically simplified access to these architecture pieces. Now other portals can leverage the enterprise-wide search and taxonomies with much less hassle. Borrowing from economics, we lowered the barriers to entry. As a result, many other portals now leverage our architecture as a service from our group, currently known as Search as a Service.

Lou: What's "Search as a Service"?

Vivian: It includes search services, taxonomy services and consulting. More than twelve other portals in the company use part or all of our architecture. The portals report positive improvement in their systems and positive anecdotal comments from their own users. In addition, metrics are showing an increase in the use of the enterprise-wide search, improved click-through on individual portals, etc. We are currently working on a customer satisfaction plan to better measure our success.

Lou: How are you following up on your success?

Vivian: We are now working on the next generation that is to not just share the information architecture we created but to work in cooperation with other groups to build on what we have established to create an even better architecture to share across the company.

I realize how much our team has learned and accomplished when we work with other portals in the company. The questions and concerns voiced are the same ones we began tackling almost three years ago. This puts us in a great position to lead the next generation. As for having it all figured out, not yet, but we know a lot more than when we started. We have an interesting and growing collection of garlands and scars. Plus, we have some great ideas for the future.

Lou: Let's get to today's $64,000 question: I'm sure Microsoft has its share of both cowboys, who want complete control of every aspect of their sites, and Borg-like centralizers who are fans of standards and shared resources. How does your approach accommodate both? And is it designed to scale toward one or the other end of the spectrum (i.e., autonomy versus centralization) over time?

Vivian: One of the best things about this company is the level of creativity and independence. From the beginning we knew that our solutions would need to accommodate many different groups' current and future information problems and management styles without compromising the creative spirit. In our view, sharing an information architecture across the company is not about creating dependence or destroying independence, rather creating interdependence and freeing up creative energy that can be focused elsewhere.

There are two very important things about our vision of a shared architecture that makes it attractive to both cowboys and Borg. First, the pieces created are extensible to fit a group's needs. We achieved this with our current architecture and it will be a requirement of the next generation. Second, in the next version other groups, not just KNG, will be providing pieces of the architecture. For example, one group will be working on the technology to support personalization while KNG and others will work on personalization taxonomies. Another example is a project currently underway in which we are working with another group inside the company to build a taxonomy tool and processes that will scale globally. The new tool and processes are based on what we have already built and put in place but evolving it to the next level.

We believe that over time it is even more important to centralize what makes sense to centralize while leaving room for customization that reflects context. Centralizing can create efficiencies of time and money for the users and managers of information systems. Then each group can customize where needed, as they should be the best authorities on their users, content and context.

Lou: It sounds like your approach is as much content management as information architecture. True? If so, what's the difference anyway?

Vivian: I do not believe you can create a durable information architecture without knowing and understanding the content, the users' interaction with the content as both creators and seekers and the context(s) in which the content is used. At this level of understanding it becomes clear that managing content is vital to creating a useful and usable information system.

Stated another way-the three basic elements that need to be understood are users, content and context. If you approach the system from the content side you begin to see everything needed to provide quality content for the targeted users and context. In the corporate intranet space you also begin to see that the system must work as a content aggregator pulling content from many different sources, both internal and external, each with its own access points, restrictions, value and intended publishing venue. Content management is an incredible undertaking that relies heavily on high quality, consistent metadata, and possibly mapped metadata. A shared information architecture that includes common taxonomies, common processes and best practices can provide such metadata.

Getting back to your question: right now there is a lot of conversation about content management in the IA world. I predict that the focus will soon shift to "context".

Lou: Developing enterprise-wide metadata schemes is ambitious. How long will it take to roll it out throughout a company as huge as Microsoft? Can you hurry the evolution along?

Vivian: I cannot predict how long it will take for a shared information architecture to reach every nook and cranny of the organization. I do know, however, that there is direct correlation between the level of pain felt by the owners of a portal and the pace of evolution. No one looks for a solution until they are in pain. Once they look up, we can hasten the evolution by providing an extensible information architecture they can quickly leverage and customize.

Lou: Pain again, eh? It's becoming clear that pain is the information architect's greatest friend. Anyway, your approach seems very focused on process and workflow; how much of the solution is dependent on specific technologies? Or is technology somewhat de-emphasized (and why)?

Vivian: My preference is to first discuss the problems and possible solutions without mentioning specific technologies. Once the problems and potential solutions are named possible technologies can be evaluated. I believe this approach leads to even more interesting use of technologies in the final solution.

The architecture solutions we built are tool-agnostic. We used Microsoft technologies because it is a great opportunity to showcase our own products, but the ideas our architecture represents can also be built using other technologies.

Another reason we are tool-agnostic is that each group can create or purchase their own tools to address their pain. Our taxonomy services include delivering a metadata schema or a controlled vocabulary in XML. A group can use any tool they desire and leverage our taxonomies. The only requirement is that the tool be XML-compatible; we rely on XML because it provides the layer of abstraction that is key to sharing and customizing.

Lou: As far as incentives for getting business units to work with you, what is the ideal mix of carrots and sticks? Or have you found a way to do away with the sticks altogether?

Vivian: We rely heavily on carrots-using the web properties we create and manage, such as MSWeb, to showcase what can be achieved; making it as easy as possible for a group to plug into our search and taxonomy services no matter what tool they are using, etc. I believe there is a greater chance of long-term success if people join a shared solution because of the carrots rather than the sticks. We leave the sticks to the individual groups to wield internally when necessary. Besides carrots and sticks, I personally believe in power baking. A lot has been accomplished with a dozen fabulous homemade cookies.

Lou: The baked-goods approach to IA is vastly underrated; thanks Vivian!