Information architecture provides necessary alignment between the organization, the users, and the arrangement of data in a way that is rigid enough to provide consistency of user experience, yet flexible enough to endure reasonable change over time. A sound foundation-based approach to information architecture includes defining how the building blocks, data, and end-user activities come together to provide a meaningful experience. Additionally, the details of your information architecture provide the manageable back-end administrative and supportable delivery of the technologies used.
Time spent up front defining a comprehensive information architecture provides a basis for controlled, gradual change over time and limits evolution-oriented "learn-as-you-go" change, which can lead to an inconsistent and unpleasant user experience.
When starting down the path toward an initial pass at your information architecture, consider the following basic questions:
Who will be visiting a given site?
What will they be doing within the site?
What level of information security is necessary within the site?
These questions create a paradigm of sorts that can be used as a basis for framing the initial architecture. This paradigm can be viewed as having both horizontal capabilities and vertical segments. Each horizontal capability symbolizes a primary activity that is performed in sites of a given type. Often, each of the identified capabilities are performed by most, if not all, site participants. Vertical segments subdivide or span across capabilities to form groupings of specific capabilities that are related through application. To apply this theory in practice, imagine the common capability of collaboration and its practical vertical application among salespeople who need information about new products or calling scripts, for example. The next section, "Information Architecture Foundations," describes these categories in more detail.
Inside Track: Who Owns Information Architecture in a SharePoint Deployment?
The information architect can be a single person or a group of people, possibly the same group that designed your Active Directory directory services organizational unit (OU) structure. Has that taxonomy worked out? Maybe the group that designed the public folder hierarchy should own information architecture. Is that a touchy subject? Even Distributed File System (DFS) has a namespace with DFS roots and targets, which have limitations and choices with usability considerations. Did you go with product lines, functional, organizational, regional, or simple buckets?
SharePoint consultants stay very busy helping customers figure out this space. Hopefully, you won’t just throw it over the fence and hope someone gets it right. They probably won’t, and a year or two down the road, someone in IT will be researching how to split databases and move site collections to sites or vice versa. They may even need to tell departments that they no longer have their own Web application—it has been consolidated into a single portal through which they have their own site collection, or they have a site on the portal (a tab in the navigation with the powerful inheritance model).
In a world where SharePoint was growing in leaps and bounds and was even exponential in growth the first year, having site creation go through IT added little value. Many chose to allow employees to create sites for projects and teams and, later on for document and meeting workspaces. These types of sites were ad hoc in nature. However, portals, knowledge management, and document management structured sites required an approval process. The business needed to show it was committed by allocating budget and resources for business development, design, and business processes. Once a business commitment has been made, you can begin to talk about how IT can help meet business goals and where you’ll put a portal in the development queue.
At Microsoft, a software development company with nearly 100 percent information workers, it made sense to enable self-service creation (SSC) on a namespace with a defined quota, where ownership, secondary ownership, site descriptions, and other metadata were captured during site creation. Search would later be driven by this list of sites and URLs.
Joel Oleson, Senior Technical Product Manager, Microsoft
3.134.90.44