Implementing and governing information architecture
Updated: February 26, 2009
Applies To: Office SharePoint Server 2007
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2016-11-14
By planning and governing your enterprise’s information architecture, you help ensure that your solution that is based on Microsoft Office SharePoint Server 2007 will meet your organizational needs. Effective information architecture makes it easy for users of your solution to find and store information and improves the quality of that information. This article:
Introduces the concept of information architecture
Points to available resources to help your organization’s information architects plan and implement your information architecture in Office SharePoint Server 2007
Recommends how to govern your Office SharePoint Server information architecture
Presents a case study that illustrates the benefit of effective information architecture to promote collaboration across an enterprise
In this article:
Information architecture in Office SharePoint Server is the organization of information in an enterprise — its documents, lists, Web sites, and Web pages — to maximize the information’s usability and manageability. Factors that contribute to the successful implementation of information architecture include:
How easy it is to find information
How information is stored and retrieved
How users navigate to information
How redundant or overlapping information is
What metadata is available for each type of information
What templates are used for creating information
How well the information architecture is governed
The goals and implementation of information architecture will vary depending on the type of solution you are creating. For example:
If you are designing the information architecture of an enterprise’s intranet portal site, you might focus on how metadata will be used to characterize the site’s content, the organization of the content in sites and document libraries, the availability of that content in portal sites, and the templates to use for creating content.
When you design the information architecture of an Internet presence Web site, you might focus on how the site is organized into a hierarchy of sub-sites and Web pages, how that hierarchy is exposed in the site’s navigation features, and how easy it is to search for content on the site.
Information architecture decisions may also affect the flow of information. For example, in an intranet portal site, information may initially be drafted in sites that are not available to most members of the organization. To make that information useful and actionable across the organization, the information architecture design could include methods and guidelines for promoting information to locations that are available to all users.
Depending on the size of your organization, you should consider including an information architect on your team who is responsible for designing and implementing your solution based on Office SharePoint Server. Information architects have expertise in structuring information in large Web environments such as intranet portal sites.
The following table presents resources that are available to help information architects plan the information architecture of your Office SharePoint Server solution:
Information architecture resources
|To plan …||See …|
The structure of sites and subsites
Standardization across sites
Information management policies
Information architecture in an enterprise should be governed. When you govern the architecture of information, you ensure the following conditions:
Information in the organization is manageable by the organization's information technology (IT) team by specifying how that information architecture is implemented and maintained.
Information architecture meets the regulatory requirements, privacy needs, and security goals of the enterprise.
Information architecture meets the organization’s business goals. Remember that poorly designed and governed information architecture can subtract from an organization’s effectiveness. Well designed and governed information architecture can multiply that organization’s effectiveness.
Governance of information architecture requires the participation of all groups that have a stake in its success. Because the ultimate purpose of information architecture is to meet the needs of the business, it is essential that representatives of the enterprise’s business units have a primary role in this governance group. If possible, include a professional information architect in your planning team and have that person participate in the governing group. Along with these primary stakeholders, representatives of the IT and legal organizations should be included. Depending on the type of enterprise, you may decide to include other participants. One key participant is the executive sponsor of the governing group. Although this person may not attend all sessions of the governing group, inclusion of this role is essential so that the governing group is kept accountable to its mission. Furthermore, the executive sponsor helps to ensure that benchmarks are used that help mark the progress of the ongoing effort of governing information architecture.
The best way to run the information architecture governing group will be based on the culture and methodologies of your enterprise. However, here are some general guidelines:
Meet regularly and allow enough time, especially in early sessions, to consider all the issues.
Exemplify good information architecture practices in your own deliberations, such as by using a well designed collaboration site to record your deliberations and maintain its artifacts.
Report to the wider organization (and gather requirements across the organization) by using a Web site and online surveys.
Maintain a set of milestones and a shared calendar.
Consider piloting information architecture practices in some divisions of the organization and using that experience to incrementally improve the information architecture practices across the wider organization.
Fabrikam, Inc. is a world-wide manufacturer and exporter of automobile parts, including fuel and water pumps, shock absorbers, brake pads, and various engine parts. The company has 13,000 employees world-wide and more than fifty manufacturing plants across multiple geographical divisions. Fabrikam’s IT organization owns deployment, operations, and support of information technologies such as e-mail, file management, and Internet technology, along with development of information technology solutions, such as the corporate Web site.
Content at Fabrikam had historically been stored in shared file directories which were distributed across local file servers at the various locations of the company. This contributed to a chaotic content situation. Mass duplication of key content made it difficult to determine the “official” version of a file. Content metadata taxonomy was very limited, based on what the file system could support. Because divisions of the corporation created unique, custom templates for common documents such as work orders, sales proposals, or human resource documents, it was difficult to compare documents side by side across divisions.
As the inadequacies of their information architecture that was based on file shares became more evident, managers at Fabrikam mandated adoption of new, portal-based technologies. They did this to accomplish several goals:
Modernize their information architecture
Move content from file shares to libraries in portal sites
Provide central access to content and applications such as expense report submissions
Provide a home page for central communications to Fabrikam employees
The next step in the evolution of Fabrikam’s information architecture had begun.
The following diagram illustrates the initial architecture of the Fabrikam portal. A corporate portal at the top of the architecture provided a central location from which to broadcast general corporate information. At the next level, a few sites provided shared resources to the organization, such as human resources, legal services, and financial services.
Below the shared resources level in the Fabrikam architecture were divisional portals for the various regional offices of Fabrikam. Initially, North America, Europe, and East Asia were piloted. Gradually other divisional portals were added: Australia, Africa, and South America. Each divisional portal contained repositories for its policies, product designs, research and development, and customer data.
The result of the change from collaboration that is based on file shares to collaboration that is based on portals was disappointing to the sponsors of the portal effort and to the Fabrikam work force. “Content chaos” had not been alleviated. It had just moved from file shares to portal sites.
Because key functions at Fabrikam, such as materials purchasing, customer relationships, parts design and specification, and even some human resources processes, occurred at the divisional level, each division had developed local content to support these functions. Policy statements, parts blueprints and specifications, personnel documents, documents related to customer relationships, and similar content was created and managed locally. Templates and metadata schema for these documents diverged across divisional portals. As metadata became more specific to each division it became more difficult to search for content from one division to another. When a document was found across divisions, it was often copied to another division’s portal to make it more accessible. This process made it increasingly difficult to find the “official” version of a document as duplicates proliferated. Also, some documents in divisional portals were secured in such a way that employees of other divisions could not view them. Although this was appropriate when a document was being drafted, there was no guideline for when and how a document should be made viewable across the enterprise.
To address the growing discontent with the portal, a strategy team was formed, comprising managers across the various Fabrikam divisions along with core IT team members and portal architects. The team had the following tasks:
Evaluate the current state of the Office SharePoint Server portal deployment.
Recommend necessary changes to the portal.
Determine how to measure improvement over time.
The team that developed the portal strategy concluded that the current portal taxonomy’s “divisional” organization was the root to the problem. Each division was duplicating processes and hoarding content without taking advantage of the expertise and best practices developed in peer divisions. This contributed to poor collaboration, wasted resources, and content chaos. Their insight was to move towards a more “operational” organization for the enterprise portal. Shared resources such as information technology and finance were currently exposed in the portal taxonomy above (and visible to) all divisions. The team that developed the portal strategy concluded that other operational disciplines, such as customer relationships, vendor relationships, plant configuration, and research and design should be moved from divisional silos to the same level as the shared resources in the site’s hierarchy. Metadata instead of the content’s location would associate information with the various divisions.
The following illustration is the revised architecture of the Fabrikam portal:
Reorganizing the Fabrikam portal in this way had the additional benefit of forcing collaboration across parts of the enterprise that had similar responsibilities but were not accustomed to working together on standards and processes. For example, storing design files in a central repository forced the various divisions to standardize on a tool for designing automobile parts. This change saved money and reduced training time. Also, best practices in design were made available for engineers to view across the enterprise and to use as a basis for new design projects.
Here is a summary of the benefits of the redesigned portal architecture:
Provides central access to information.
Reduces duplication of content.
Makes the official version of each item of content evident.
Fosters collaboration and sharing of best practices.
The redesign and reimplementation of the portal was just the start. The team that developed the portal strategy received executive sponsorship to become a governing group of the portal. As a result, the group represented the needs of portal users by developing policies and standards. This helped ensure accountability across the organization and provided a forum for evaluating and evolving the portal — both to improve portal features but also to help maximize the return on the enterprise’s investment in the Office SharePoint Server technology. The governance body oversaw the following elements:
Guidelines for when information needed to be made available across the enterprise
Compliance with corporate and governmental regulations
Branding standards for content
Fabrikam started seeing a large return on their portal investment. A year into the project, the strategy team did an inventory of content and found that out of 500,000 documents, only 230 were duplicates. They identified millions of dollars in savings due to the centralization of efforts. And a survey of their employees showed a large increase in satisfaction with the portal. Collaboration was healthy at Fabrikam.
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable content for Office SharePoint Server 2007.