This section provides a brief overview of the basic building blocks available for use when designing and building an information architecture. This is not an exhaustive review of each, but rather a simplified review of how each type of object fits into the overall architecture. This prerequisite knowledge is necessary in order to understand how these types of objects can be used to build an information architecture that is usable and sustainable over time. After you have reviewed these basic building blocks, you will review a few permutations of how a simple information architecture might be assembled at both the micro and macro levels. With these examples as a backdrop, you will examine how you might add new sites to an implementation employing this architecture. The following list presents these building blocks and describes each block at a high level by listing a few defining properties and/or constraints.
Defined within a farm
Topmost object within the hierarchy and the native container of the topmost site collection
Representative of a specific Microsoft Internet Information Services (IIS) Web site and defines a specific IIS application scope
Has no visual presentation within the user interface and is in no way visually apparent to the end-user
Can be extended into multiple zones
Zone
Defined within a Web application
Allows users to access the same Web site through separate and independent URLs
Has its own load-balanced URL (protocol, host header, and port)
Allows for many configurations (multiple authentication stores, caching scenarios, content databases, or custom HTTP modules)
Managed Path
Defined within a Web application
Used to incorporate a second tier of top-level site collections
Implements either an explicit inclusion (allows you to assign an explicit URL that is appended to the path, e.g., http://fabrikam.com/dept) or a wildcard inclusion (automatically assigns a path name, e.g., http://fabrikam.com/depts/)
Site Collections
Defined within a managed path
Are the native containers of Office SharePoint Server 2007 sites
Contain a single top-level site that in turn may contain any number of child sites
Enforce specific feature and security boundaries that cannot be inherited or discovered by a parent or child site collection
The top-level site collection in a Web application may contain site collections through the use of managed paths
Features that are bound within a site collection and cannot be shared include global navigation, branding, security groups, content types, content sharing Web parts, site aggregation Web parts, usage reports, alert management, and workflows
Subsites
In addition to the higher-level objects that are used to create the macro architecture, a small, yet equally important set of lower-level objects are used to create and construct the list, libraries, and classification mechanisms within individual sites. A portion of these lower-level elements will be configured by the end-user on an as-needed basis. The goal of the architecture should be to provide end-user workgroups with as many of the feedback-derived elements as possible without creating unnecessary elements.
The item-level storage of individual documents and list entries in SharePoint Server 2007 is made possible through the configuration arrangement of the following four building blocks:
Content Types (defined within a site collection or subsite)
Represent a unique data type
May be extended as needed over time
May be inherited so as to create new derived data types, allowing for both specificity and simplified management
Site Columns or Fields (defined within a site collection, subsite, or list configuration)
Represent a property of a unique data type
May be added/altered over time
Provide granular selection and optional required entry of metadata
Lists (defined within a site)
Represent a collection of individual items (data) that are stored by users of the system
Provide further requirement-specific configuration capabilities
May contain heterogeneous data—items of different content types, with their associated Site Column specifications
Can provide additional enhanced functionalities such as information management policy, access control, and workflow, if available and configured
List Items (defined within a list)
The following example brings many of the design elements discussed in this chapter together in a cohesive manner. The conceptual architecture is shown in Figure 7-3. Figure 7-4 illustrates how you might use the provided building blocks to implement portal and project collaboration services. Specifically, this example:
Combines the following:
SharePoint building blocks
Well-defined requirements based on comprehensive customer feedback
Generated or feedback-derived taxonomies and metadata elements
To create the following:
Site collection hierarchy
Common content type hierarchy
Common Site Column definitions
Expresses content as the following:
Sites: Provide the frame in which people come together to work toward a common objective (shown in Figure 7-3)
Content Types: Represent functions performed by people as information outputs generated during the course of their work together (shown in Figure 7-5, Figure 7-6, and Figure 7-7)
Site Columns (metadata): Provide the granular ability to define those outputs as being related to other entities, items, or designations of significance in a meaningful way (shown in Figure 7-5, Figure 7-6, and Figure 7-7)
Each of the permutations illustrates different possibilities for combining the building blocks described with gathered feedback-derived information types. Each permutation represents an option for how information could be arranged within the architecture to create context and significance.
Entities. Something that exists as, or is perceived as, a single separate object, such as the following:
Department
Project
Community
Initiative
Team
Asset
Attributes. A quality, property, or characteristic of an entity, such as the following:
Name
Status
Identifier
Team
Asset
Note that both team and asset can exist as either an entity or an attribute. Based on the provided information architecture, an individual data item could be represented in many ways. For example, Figure 7-5, Figure 7-6, and Figure 7-7 illustrate a few of the options available for creating these representations using different building blocks.
Of course, there are many more permutations possible for arranging this information. Information architecture provides the framework for finding and storing data by defining the following:
Relative significance of each entity (what should be represented as a site, list, item, or field)
Arrangement of each entity based on that significance (e.g., departments, then projects, then teams)
Attributes for each entity, which create the contextual significance between a given item instance and other related entities or designations
The provisioning of additional objects within the architecture is a function of the request process as defined by the governance model, as well as the framework and conventions provided by the architecture. Based on the provided example architecture and the nature of the request for additional services, a short list of alternatives for provisioning the request can usually be generated via a quick review of Figure 7-3.
In cases where a clearly preferred alternative is not apparent, the usual culprit is a lack of detail in the request, but there will be occasions when you have multiple options for satisfying a request. In keeping with the example architecture, you can see that requests for additional departmental portal sites will be satisfied by simply adding a new site collection in the Web application for Portals under the /depts/ managed path. Portal sites in your architecture, as in most, will likely be controlled by a request to reduce site sprawl. If you need multiple site collections for each department, you could achieve this by creating a managed path for each department under which all of that department’s site collections would exist.
Requests for new project collaboration sites might be handled by way of self-service site creation, which can be enabled at the Web application level. Self-service site creation allows for the provisioning of new site collections by end-users on an as-needed basis. In our example, this is ideal for project collaboration sites, because new projects, both big and small, are started frequently and need new sites right away. It is important to set up the appropriate quotas and locks, as well as deletion notifications, to prevent a storage overload.
The underlying Site Templates and definitions could include business rules that seamlessly pump content to your Records Center sites to ensure that official record content is always safe from deletion. Enable self-service site creation from Central Administration via the Self-Service Site Management settings link under Application Administration, as shown in Figure 7-8. The option to require a secondary contact can be useful, as both contacts will receive notifications regarding the site.
