Organizing Information in SharePoint Server 2010

This post outlines the putability side of a robust information architecture, which means that it will focus on how information goes into your SharePoint farm. It also outlines some of the latest research and thinking as it relates to the development of any information architecture. The technical administrator might find much of this non-technical information as boring or irrelevant. Nothing could be further from the truth. The core pain that people will have with SharePoint 2010 will not be about the technology itself, but instead about how to map the technology to the organization's business goals and ensure that the technology is not getting in the way of the organization efficiently and effectively functioning. Much of this discussion about information architecture directly impacts your deployment. Understanding the business layer better will help you be a better SharePoint administrator.

Developing an Information Architecture with SharePoint 2010 in Mind

The development of an information architecture could consume several books in and of itself. Just Bing "information architecture" and you'll see a multitude of books, websites and organizations who offer ideas and services on the organization of information. In this section, you'll take a brief look at the state of information organization in most organizations today then delve into how to develop and information organization effort in your organization.

Value of Information

What is the value of Information in your organization? Because balance sheets for most companies don't track the soft costs of developing information, they often don't really know what their information is worth. If you were to ask most C-level individuals how valuable information is to their organization, most would swiftly tell you that it is highly valuable. Yet, getting them to agree to manage that information better is often difficult. Managing information can form a competitive advantage. In addition, the following statistics indicate that our need to manage information better is strong:

• Over 30 billion original documents are created and consumed each year
• Cost of documents is estimated to be as much as 15% of annual revenues
• 85% of documents are never retrieved
• 50% of documents are duplicate in some way
• 60% of stored documents are obsolete
• For every $1 spent to create the document, $10 are spent to manage it

It's obvious that we're great at creating documents, but not so good at managing them. Most organizations have a strong tendency to commit resources to creating information and less resources to manage that information. As a result, operating knowledge is often undocumented, tacit knowledge is rarely documented and knowledge is easily lost through transitions such as retirement or attrition. In most industries, it is becoming more important to retain key knowledge that can be taken by competitors. Most "how to" information is held in people's minds in an undocumented way.

In addition, in many organizations, SharePoint is installed in such a way that it is working in conflict with other ECM systems. When asked how well SharePoint was working with other ECM systems, respondents to a recent survey indicated that:

• 29%SharePoint is working in conflict with other ECM systems
• 16%SharePoint is integrated with existing ECM suites
• 12%It's the only ECM suite
• 43%SharePoint is used to "fill in some functions"
• 36%IT rolls out SharePoint with no input from Record Managers or ECM teams
• 14%Admit that no one is in charge and that SharePoint and ECM is out of control

SMS/text messages, blogs, wikis and other web 2.0 technologies lack inclusion in the ECM solution in 75% of organizations. This represents a major risk to companies while ensuring that much collaborative activities remains (essentially) unmanaged. Compliance officers are wrestling with how to incorporate Web 2.0 technologies into their ECM compliance standards while ensuring that teams can collaborate to achieve business goals.

What is Putability?

Putability is the quality of putting content into an information management and retrieval system with the correct metadata. It is the degree to which you put quality information into your information management system and is the first part of an overall information process. When it comes to developing an information process, you must pay attention to three essential parts, as shown in Figure 1. How information goes into any information retrieval system will directly impact how well it comes out.

Figure 1:Three essential parts to an information process

When it comes to putability, there are two truths to which you must pay attention. Ignore them at your own peril. First, what goes in, must come out. This is the old "garbage in, garbage out" truth that has been known about in computing since the 1960's and was originally developed to call attention to the fact that computers will unquestioningly process the most nonsensical of input data (Garbage in) and produce nonsensical output (Garbage out). It is amazing that otherwise very smart people will expect they can load high volumes of documents into SharePoint with little thought to organization and then expect to find individual documents quickly and easily. Chaos does not lead to organization and it is organization that is foundational for findability.

Secondly, users will resist taking the time to put quality information into the system. Managers seem to be especially resistant to having their information workers take time to properly tag their information as it goes into the system. It seems that the vast majority of users of information retrieval systems strongly believe the mistaken notion that as long as the information is indexed, they'll be able to find it. User resistance is one of the most difficult obstacles to overcome when implementing a robust information organization effort. When asked who is responsible for tagging information, the same survey elicited the following responses (multiple answers were allowed to this question, hence the total of more than 100%):

• Authors: 40%
• Records Managers: 29%
• SME's: 25%
• Anyone: 23%
• Don't know: 12%
• No one: 16%

This means that in many organizations, users simply don't know who is responsible for tagging information or are not directly assigned the tagging task to make that information more findable. In the absence of a governance rule that details who is responsible for tagging documents, the result is that anyone (and yet no one) will be able to apply metadata to a document. This is not a recipe for success.

What is Findability?

Findability is the quality of being locatable or navigable. It is the degree to which objects are easy to discover or locate. As with putability, there are some truths to which you should pay attention. First, you can't use what you can't find. It really doesn't matter if the information exists. If you can't find it, you can't use it. The corollary to this is that information that can't be found is pragmatically worthless. You might have spent millions to develop that information, but if you can't find it when you need it, it's pragmatically worthless.

Secondly, Information that is hard to find is hardly used. It would stand to reason that users who won't work hard to take the time to put quality information into the system will also not take much time to find the information they need. Often, if users can't find information quickly and easily, they will simply e-mail someone or just not include that information in their decision-making processes. Now, there is the reality that the more the information is needed by the user, the harder they will work to find it. But in the long run, they won't put out any more effort than they feel is minimally necessary to do their job.

NoteOut of the three parts to the information process, putability and findability are the most interwoven. The hosting of the information is merely the static retention of that information between the two major actions of putting information into the system and then pulling it back out. But the quality of information input into SharePoint will directly impact the output of information from SharePoint.

Why is Putability and Findability Important? Because, you can do all of the following correctly and still not succeed (from your user's viewpoint) with your SharePoint implementation:

• Capacity plan your servers correctly
• Scale out your farm correctly
• Implement all of the customizations correctly
• Implement a robust Search and Indexing solution
• Train your users correctly
• Write the business and technical requirements for your deployment
• Manage your servers to the point where there are no errors or warnings in any of the event logs

The real success of any SharePoint implementation will be evaluated largely in terms of how well users can manage and find information via the features in SharePoint. While the rest of the elements in the previous bullet list are essential to a successful deployment, the support and furtherance of the business goalswill be the final arbiter of whether or not the deployment is successful. In most environments, those business goals will be defined, in part, in information management terms.

How Well is Findability Understood?

In the Findability and Market IQ survey by AIIM, when asked "How well is findability understood in your organization?", the following answers were given:

• It is well understood and addressed: 17%
• It is vaguely understood: 31%
• Not sure how search and findability are different: 30%
• No clear understanding of findability at all: 22%

This means that over half (55%) of organizations today either don't know what findability is or they are not able to differentiate findability from search technologies. Many believe that if they have a stand-alone search tool, then findability is being adequately addressed. Nothing could be farther from the truth.

Search is too-often viewed as an application-specific solution for findability. Search technologies focus on trying to ask the right question and on "matching" keyword queries with content under the assumption that if the right words are input as the query, the right content will be found. What we all need to understand is this: Findability is not a technology: It is a way of managing information that is baked into the organization. Achieving success with the information process relies on a well defined of patterns and practices that are consistent applied to our information. While it is true that search technologies support our efforts to find information, search can't fix the "garbage in, garbage out" problems present in most organizations today. The carelessness with which we manage our information cannot be resolved by a technology.

The Paradox of Findability as a Corporate Strategy

When asked the degree to which Findability is critical to their overall business goals and success, 62% of respondents indicated that it is imperative or significant. Only 5% felt it had minimal or no impact on business success. Yet, 49% responded that even though Findability is strategically essential, they have no formal plan or set of goals for Findability in their organization. Of the other 51% who claimed to have a strategy, 26% reported that their strategy was ad hoc, meaning that they have no strategy at all. Hence, 75% of organizations have no Findability strategy, even though many believe it is strategically essential.

The Opportunity Cost of a Poor Information Process and Architecture

So, what are the opportunity costs of maintaining a poor information process and architecture? While the information on cost studies is not robust, the information that is available suggests that organizations are hemorrhaging money on this problem. A good study on this suggests the following:

• 3.5 hours spent trying to find information but not finding it
• Another 3.0 hours recreating information that they know exists, but they cannot find

More InfoAn opportunity cost is the cost of passing up the next best choice when making a decision. For example, if an asset such as capital is used for one purpose, the opportunity cost is the value of the next best purpose the asset could have been used for. In this chapter, the opportunity cost is that which is given up by the corporation because they choose to pay their workers to spend time working within a problematic information system as opposed to having their work focused on other, potentially revenue generating, activities.

This means that the average knowledge worker spends 6.5 hours/week searching for information, not finding it and then recreating that information so that the worker can move forward in his/her job. At an average salary of $60,000/year, this equates to $9,750 cost/worker/year. For a company of 1000 employees, this equates to an annual opportunity cost of $9.7M/year (US dollars). In addition, for a company of 1000 employees, they will spend $5.7M/year (US dollars) just in having users reformat data as it moves between applications and another $3.3M/year in version control issues.

Organizing Information for a Call Center

The reality is that if a company improves the organization and findability of its' information, it will not see a real cost savings because an opportunity cost is a hidden cost that is not easily measured. But a company should see improved productivity and improved revenue generation activities that will reveal themselves in other measurements that are (seemingly) disconnected from the cost of a project that improves information organization and management.

For example, there is a call center that was providing telephone support for the company's products, and the average call was consuming nearly five minutes. After an analysis was done to determine what activities those five minutes were focused on, they learned that it took nearly 2 minutes for the employee accepting the inbound call to find all of the customer's contact and purchase information. After implementing an information organization project, analysis showed that employees were able to find the same information much more quickly—usually in less than 30 seconds—and this led to a significant decrease in the length of an average call. This meant that fewer people could work with the same number of calls, making each employee more productive. The opportunity costs were realized on the bottom line when the company came out with new products to support and they found that the call center didn't need to hire more individuals to work the phones because of the information organization project they had undertaken.

While the increase in inbound calls increases, it is seemingly disconnected from the information organization effort in which the call center engaged, in reality, they were directly connected. But the measurements of the project's success had to be seen in seemingly disconnected numbers from the cost of the information organization project.

So, what keeps us from finding information? The AIIM survey found the following:

• Poor search functionality: 71%
• Inconsistency in how we tag/describe data: 59%
• Lack of adequate tags/descriptors: 55%
• Information not available electronically: 49%
• Poor navigation: 48%
• Don't know where to look: 48%
• Constant information change: 37%
• Can't access the system that hosts the info: 30%
• Don't know what I'm looking for: 22%
• Lack the skills to find the information: 22%

What is interesting is that the first three reasons that users cite for not being able to find information are really about the putability side of this information process. It stands to reason that if an organization has inconsistency in how information is tagged and described, then the users will experience a poor result set, which is described in this list as "poor search functionality".

A poor search functionality, from the viewpoint of the user, is really about a result set that is not helpful, or irrelevant. A relevant result set has content items that are useful and helpful to the user. In most cases, a poor result set that is blamed on a poor search technology is really just a mirror of a bad information architecture implementation. In other words, garbage was put into the system and so the result set tends to be garbage and this results in the end user blaming the technology for a poor search functionality. However, if you have a strong information architecture coupled with users who work in concert to maintain a set of patterns and practices for how information is managed, your search results will likely be relevant to the user. Again, the real problem in the management of information has not to do with technology, but rather with the people who interact with the information management and retrieval system and an organization's willingness to invest in the "peopleware" as well as the "software".

Why Your C-Level Executives Will Want a Robust Information Process and Architecture

There are not many things that get the attention of a Chief Executive Officer (CEO) more swiftly than the ongoing threat (reality?) of legal action against your organization or the unintentional, but preventable breach of customer and other confidential information.

35 states have laws requiring that individuals be notified if their confidential or personal data has been lost, stolen or compromised. The Privacy Rights Clearinghouse has identified more than 215 million records of U.S. Residents that have been exposed due to security breaches since 2005. A 2007 Study by Ponemon Institute found that the average cost of a data breach is $197/record, which represents a 43% increase from 2005. They also found that the average total cost per reporting company was $6.3M (US dollars). But the cost of lost business due to a loss of goodwill and trust by customers increased as well, to an average of $4.1M/company and $128/compromised record. Lost business now accounts for 65% of data breach costs compared to 56% in the 2006 study.

A CheckPoint Study in 2009 found that the number one threat to company's network security was employees who inadvertently exposed confidential information. Consider who manages the security of your SharePoint extranet sites. In the vast majority of cases, it is not the information technology team. Instead, it is the owner of the site - a non-technical, (often-times) under-trained end-user. When implementing your information architecture and process, you must consider the risk of inadequate training for your end-users.

The other risk is legal action against your organization. As part of a litigation effort against your company, opposing counsel will ask the judge to allow them to "discover" information within your electronic systems to help them build their case against you. This process is called e-discovery. This process includes, but is not limited to, computer forensics, e-mail archiving and online discovery of documents. If you have reasonable expectation to be involved in a case, then you have a duty to preserve evidence.

If you can't quickly produce documents and records or if you don't have a well-defined set of policies that outline how information is to be managed in your organization, you're opening yourself up to serious legal exposure. You should, of course, consult with your legal team, but a minimum, your organization should undergo a litigation readiness review to ensure that in the event your company is involved in a legal action—even as a third party—that you're able to find and produce records quickly and reliably.

SharePoint, Putability, and Findability

There is a concept in marketing called the long tail and explained by the same author in the magazine Wired. The concept is rather simple and when applied to a SharePoint implementation, can help us all understand why information that is held in SharePoint isn't necessarily more findable than it is if it is held in a database or a file server.

In short, the concept is that, given the total number of items in a population set that can be found, the majority of those items will be seldom requested while a minority of those items will be frequently requested. For example, most of your users will likely visit your intranet portal while a minority of your users will visit any given team site. But in most implementations, the number of team sites utilized will be far larger than the number of frequently accessed sites, like an intranet portal.

When you realize that most of the sites, lists and libraries that are created in a typical SharePoint 2010 implementation are seldom accessed by more than a handful of people, the planning issues for a SharePoint 2010 implementation take on important dynamics.

While you'll want to ensure that your heavily accessed portals are well planned, you'll want to spend a similar amount of time planning for how important information that is hosted in team sites that are rarely accessed by more than a handful of people will be just as accessible and findable as that which is hosted in your heavily accessed portals.

The core of those planning issues should answer questions such as:

• How will those who frequently access team sites find those team sites?
• How will those who infrequently access team sites find those team sites?
• How will those who infrequently access team sites know what information is in those sites?
• How will we find documents corporate wide when we're conducting an exhaustive search for a given type of information?
• How will we find documents when we're looking for a sample of data that need not constitute an exhaustive search?
• Should we provide a federated navigation hierarchy for users to browse to find information? If so, how should we implement this?

These and other questions begin to get to the heart of findability within SharePoint. Because most of that which is created in SharePoint is in the long tail, it stands to reason that most who utilize SharePoint will not consume most of the information within the SharePoint Server 2010 implementation. Yet, your implementation will need to make all of the information findability by, potentially, many of your users (assuming they have permissions and a need to see the information).

Finding information merely by the document's content will not work in those environments where the data set is large. In most organizations, their use of words tends to be homogonous, meaning that they tend to use a certain set of words repeatedly in their documents. For example, an accounting firm is likely to use a different set of words in their documents than a medical firm or a marketing firm. When words are used in similar ways across multiple documents, those words lose their effectiveness at discriminating between documents. The entire point of entering a keyword in a query is to discriminate between documents. If that keyword is an often-used word across a plethora of documents, it is really useless as a discriminatory tool.

Moreover, you find that the same word can be used across multiple documents with very different meanings. For example, is it a:

• horn? (Beep-beep)
• or a horn? (trumpet)
• or a horn? (on an animal)

You might enter the keyword "horn" and be looking for a trumpet. But if you get a result set full of content items pointing to a car horn, then while the result set might be syntactically accurate, it will be irrelevant to you. So, what users are often after is more than just a result set that matches their query - they are aftermeaning within information. To the extent that the content items are meaningful to them (as well as useful and accessible), then the result set will be viewed as being relevant.

Defining meaning in a query is best achieved through a complex query that not only requests documents with certain keywords, but also documents that have certain metadata characteristics. For example, you might be looking for the Project Budget for Customer A. Now, you would normally expect that a document like this would contain the word "budget" along with the customer's name, "Customer A". However, it's also possible that the budget document doesn't contain the word "budget". So, what are the possible ways to query and find this document?

In most environments, people will query only for keywords that they think (or hope) will exist in the document. In this running example, we would normally query for these words:

• budget
• customer A

If the document had metadata attached to it, we could further refine our query if the metadata were filled out:

• Security level: "Confidential"
• Project Name: "SharePoint 2010 Implementation for Customer A"
• Project Lead: "Bill English"
• Project Type: "Consulting"

You can see that by adding several metadata fields to the project budget document and then including those fields in your query (using the Advanced Query web part), you can be more confident of finding the right document that you need. More to the point, the better you can define the document that you're trying to find, the better you can inform SharePoint 2010's search technologies of what you mean with your query. For example, if your company had completed twenty projects with Customer A, then merely querying for the words "budget" and "Customer A" would return at least twenty different results, nineteen of which would likely not be relevant. Moreover, depending on how information is managed, these two words could return hundreds of false positives - spurious results that lack relevancy to what we're looking for. But if you can enter in the project name, the security level, the current project lead (assuming that the project lead is different for different projects with this customer), then you help define what we mean by the keyword query of "budget" and "Customer A" with further, more discriminatory information.

For metadata to be helpful in finding information, the metadata must be:

• discriminatory
• input accurately
• input consistently
• defined

Referring back to the discussion on the word "horn" and how it can have different meanings, the same principles hold true for metadata. For metadata to be discriminatory, the metadata words that are entered must have a specific meaning that is understood by all who use that metadata and those meanings must have discriminatory power between documents in either a stand-alone or when used in conjunction with other metadata.

For example, assume you have three standard metadata fields that must be applied to each document:

• Security Level
• Project Name
• Department Name

Each of these three metadata fields will have some discriminatory abilities when used by themselves. For example, assume you're looking for the budget file for Project A and the file's security level has been set to "confidential". If you enter a keyword "budget" and "confidential" for the security level, you'll get back results that include any budget for any project across all departments that has a security level of "confidential". So a single metadata field can have discriminatory abilities.

But you'll find that if you setup your metadata correctly, combining multiple metadata fields into the same query can return a much more relevant and concise result set. For example, if you enter a keyword "budget" and then enter "confidential" for the security level, "project A" for the project name and "Information Technology" for the department name, you're assured that the results will only include those documents that have the word "budget" plus the three metadata values as outlined in your query. That result set is likely to be much more focused and relevant because it is better defined.

For metadata to be meaningful, both the metadata field names and the range of potential values have to be defined and distributed. Hence, a glossary is needed to define the meaning of both the field names and the metadata values. And then the glossary needs to be distributed and utilized as a business tool.

Putability and the Managed Metadata Service

For all of the reasons discussed thus far in this chapter, the Managed Metadata Service (MMS) must be utilized if you're going to significantly improve the findability of information in your environment. It is the only way you'll achieve consistent application of metadata to your data within SharePoint 2010. Once your users are consistently applying metadata to information, they will be able to find information more easily and quickly. The MMS is all about putability in your information architecture.

Table 1 provides an outline of how content type syndication and the MMS achieves the metadata needs we've outlined thus far in this chapter.

Metadata Criteria	Managed metadata service	Notes
Discriminatory	ü	Though the central management of content types, metadata fields can be controlled and applied Closed choice fields can be promulgated across the enterprise, ensuring that metadata values selected have been vetted as being discriminatory
input accurately	ü	Closed choice fields can ensure that metadata is selected, not input and thus reduce, if not eliminate, misspellings, undefined synonyms or other extraneous data input
input consistently	ü	By setting the metadata fields in the content types to require population, you can ensure that metadata is applied consistently
Defined	ü	Baseline your end-user education about metadata with the glossary that defines the metadata fields and possible values

By the product team's own presentations, the MMS was built on four basic scenarios. The first scenario is about consistency: Is the description of the data (the content type) the same across the enterprise? Do the metadata fields and the values input into those fields contain consistency in both structure and application? When you stop to think about it, content types and metadata are really about consistent governance, management and standardization of information descriptors in the enterprise. In other words, if I build out content type "A" in site collection 1, is it the same construct as when it is used in site collection B? The MMS answers this question in the affirmative and yet provides localized extensibility for greater usability of the content type in specific scenarios.

NoteA content type is merely a data element plus metadata combined into a persistent structure that can be utilized throughout the SharePoint Server 2010 environment.

The second scenario is about identity: What is in the content type? When it comes to the enterprise, is this content contain the same type of data and metadata? Understanding the construction of the content type helps us understand its focus, purpose and meaning.

The third scenario is about location: Where is this content type and how can I use it? The MMS will allow you to pull down the content type from the hub and ensure that it is located in your site collection.

The fourth and last scenario is about lifecycle: This scenario encompasses the creation, consumption and disposition of the content type in the enterprise. More specifically, the content type can be mapped to a document's lifecycle and then utilized across the enterprise in distinct ways using the content type's information policies and workflow associations. So, we can use workflows to move the document from one lifecycle stage to the next, ensuring that compliance is enforced, tracked and audited.

NoteA taxonomy, as defined in this chapter, is not the same thing as an ontology. And ontology is the philosophical study of the nature of being, existence or reality in general, as well as of the basic categories of being and their relations. By contrast, when the term taxonomy is used in this chapter, it refers to a hierarchy of objects that will likely include synonyms, equivalencies, parent/child relationships and metadata. In contrast, a folksonomy can be thought of as "free-form" method of describing data without a hierarchy of terms from which to draw metadata values.

Building an Information Architecture

The phrase "information architecture" appears to have been coined, or at least brought to wide attention, by Richard Saul Wurman, a man trained as an architect who has also become a skilled graphic designer and the author, editor, and/or publisher of numerous books that employ fine graphics in the presentation of information in a variety of fields. In the 1960s, early in his career as an architect, he became interested in matters concerning the ways in which buildings, transport, utilities, and people worked and interacted with each other in urban environments. This led him to develop further interests in the ways in which information about urban environments could be gathered, organized, and presented in meaningful ways to architects, to urban planners, to utility and transport engineers, and especially to people living in or visiting cities. The similarity of these interests to the concerns of the information profession is apparent. When a building architect designs a building that will serve the needs of its occupants, the architect must

• Ascertain those needs of those who will occupy the space and how they will use it
• Organize the needs into a coherent pattern that clarifies their nature and interactions
• Design a building that will--by means of its rooms, fixtures, machines, and layout—meet those needs

In short, Wurman developed the following characteristics for information architecture:

• The organization of the patterns inherent in data, making the complex clear
• The creation of the structure or paths to the information which allows others to find the knowledge

Peter Moreville and others expanded Wurman's thinking about information architecture to include the following elements:

• The combination of organization, labeling, and navigation schemes within an information system.
• The structural design of an information space to facilitate task completion and intuitive access to content
• An emerging discipline and community of practice focused on bringing principles of design and architecture to the digital landscape

Information architecture directly impacts the user's experience of how they consume and manage information on their jobs. Information architecture is not just an abstract, theoretical exercise. Jesse James Garrett developed the elements of the user experience within a web site design context, connecting what is often seen as an unnecessary exercise to the day-to-day work of most users. But his elements are easily transported to the use of information generally:

• User needs and site design
• Functional and content requirements
• Interaction design and information architecture
• Interface and navigation design
• Visual design

Donna Mauer has expressed her ideas on the main elements that an information architecture incorporates: business needs, user needs and content design. Where those three elements overlap is where you'll find your information architecture.

To summarize this discussion thus far, there is no clear consensus on what an information architecture is. Moreover, many confuse information architecture with the following:

• Interaction Design
• Information Design
• User-centered Design
• User-interface Design
• Usability/Usability Engineering

While all of these elements are helpful to fleshing out an information architecture, they are really not the same as an information architecture. For example, the design of a user interface is merely the presentation layer of the information. Interface design doesn't describe how information is hosted and tagged. Hence from the viewpoint of the authors, an Information Architecture (IA) is the art and science of structuring and organizing information systems that support business goals and objectives. All you're doing with an IA is specifying the systems that will hold the data that support the business. Within the IA, a Content Taxonomy (called an Operational Taxonomy in Figure 10-4) will provide the organization of the various types of content, relative to the business needs, user needs, technology support and relationships between the various types of content.

Hence, you first need to understand what the business does and how the business really works. Without understanding what the business does in terms of activities, it is difficult to know what systems (broadly speaking) will be needed to support the information the business will need to be successful. It is plausible that some will think you should start by outlining all of the various types of information and work your way back to the systems. But this method can cause you to look at departmental or divisional information types as being equivalent with enterprise level information. Thus, defining first the global systems based on the major activities of the company will help you get to the place of being able to organize the information within the systems based on how users interact with both the system and the information itself.

NoteIn some organizations, the enumeration of systems alone will not suffice because these organizations are highly process based. Hence, these organizations would do well to include how the systems interact and how (generally speaking) information moves between systems as part of their overall IA.

When applied to an environment in which SharePoint is being implemented, I have published an information architecture methodology that builds on these principles while emphasizing the business needs that form the foundation for the architecture.

The following sections discuss this taxonomy.

Business Taxonomy

The develop of a business taxonomy is different than the development of a taxonomy for content. Recall that a taxonomy is nothing more than an organization of objects. When we talk about how our businesses are organized, we need to think in terms that are different from our organizational charts.

More InfoFor more information about the development of a business taxonomy, please visit sharepointplan.com.

Information Architecture, Governance and Requirements

In this section, what you're building out is an overall Information Architecture. It need not be detailed and in most organizations, will not be specific to divisions or departments, unless those divisions require unique systems to host their unique information. For example, a research company like 3M or Dow Chemical will have widely different types of data between their various divisions, some of which is hosted by information-specific software programs. When this is the case, the IA will need to be built at the divisional as well as the enterprise levels.

Also, be aware that some IA will be process based, such as when a system doesn't hold only static data, but hosts data and a process and moves that data through the process. Microsoft's Customer Relationship Management (CRM) program would be a good example. A lead is turned into an opportunity, which is turned into a quote, which is turned into an order which is turned into an invoice. All the while, the data for the customer and opportunity are held in CRM and moved through the process. In addition, different types of data are added as the customer is moved through the process. While SharePoint can be configured to be a process-based platform, out of the box configurations make SharePoint a non-process based platform.

So, your IA should detail out both the types of data hosted in each system as well as any mission-critical processes and which systems will host those as well.

Information Architecture in the Real World

Recently, a small company needed to develop their information architecture so that information could be more findable. This company provided critical information to its' customers in the form of different product offerings. Even though the company was less than 50 employees, they found they were having a hard time finding information related to their various product offerings, including which products customers had purchased, which information was embedded into which product and how that information was vetted for quality control. They felt this was mainly due to a lack of consistency in where information was held and how it was managed. No one had ever thought to organize their information and create governance on how information was to be managed.

Their IA was relatively simple to develop. They decided to hold all of their customer, partner and vendor contact information and history in Microsoft's CRM (Customer Relationship Management) program. All of their collaboration information and document management efforts were to be accomplished in SharePoint. Exchange provided their email system and Live Meeting provided their Conference platform. Accounting information is held in QuickBooks. Payroll information is outsourced. Their information was secured using Active Directory while employee information and corporate information were also hosted in SharePoint.

While larger organizations than this might need to list out twenty, fifty or even one hundred different systems to support all of their information, the process of forming the IA is really just a process to define the systems involved in supporting, hosting, securing and disseminating information. At the time of this writing, this company was working to organize their content within these systems and write out policies and procedures to help everyone in the company find and manage information better. Recognizing that this represented culture change, they gave themselves one year to learn how to do this and to arrive at a decent information taxonomy that was part of their overall information architecture.

While an IA is focused on systems, information architects organize content and design navigation systems to help people find and manage information better.

Governance

Governance is an inherent part of how the IA if fleshed out because each system will require the development of engagement rules with that system. In short, Governance is both the statement of rules on how users are to interact with the systems and information, but also the call-out on who will enforce the rules and make changes to the rules when needed. Without the second part - enforcement and management - Governance is essentially useless. It is like a sporting event with rules, but with no officials to enforce the rules.

Best PracticesSome organizations create long, difficult to read governance documents. However, a best practice is to do the opposite and not place a rule in the governance document unless that rule has the following elements:

• Rule is clearly written
• Rule is concise
• Rule is enforceable
• Rule is communicated to users

In a recent survey of 186 SharePoint deployments, fully two-thirds of those were either unhappy or only partially happy with the state of their governance. The reasons for this were clustered around a lack of ability to enforce governance rules, lack of staffing to support the governance effort and lack of upper management support for governance in general. These and other reasons continue to hamper SharePoint implementations as organizations grapple with the "people" side of their implementation. Understanding how information should be managed and how users should interact and utilize the features in SharePoint is essential to achieving a successful implementation.

For example, in SharePoint, you can turn on Self Service Site Creation (SSSC), which allows users to create new site collections without having to loop through the SharePoint farm administrators. Without some type of direction and education on how, when and why to create new site collections, you'll likely end up with chaos in that part of your SharePoint deployment.

More InfoYou can download various sample governance plans from Microsoft's TechNet web site at http://technet.microsoft.com/en-us/office/sharepointserver/bb507202.aspx.

Requirements

Every SharePoint deployment should be based on strong business requirements that both define the problem and outline the desired solution. Requirements are not something that you can just blow by and then expect to retrofit into the feature set of SharePoint. They should be developed in a technology-agnostic environment and then turned into technical requirements before you select a software package to support those requirements.

It's pretty obvious that Microsoft has done a good job of building a software product whose features meet the needs of a number of businesses and their business problems, otherwise, SharePoint wouldn't be selling well and you wouldn't be reading this book. But it's also obvious that many implement SharePoint in an impulsive manner that doesn't account for the mapping of business requirements to the use of the technology.

Developing Requirements and Mapping Those Requirements to a Governance Plan

The first step in developing business is to define the problem in business terms. Outlining its' impact on the business is helpful to the quantification of the problem's severity. Here is an example of a problem definition:

Problem Statement: When a document is being created by a team of users, they are complaining that they can't easily control which document is the latest and most up-to-date version.

Problem Cause: This problem can be created when documents are e-mailed to team members after being edited by one team member without knowledge that other team members are also editing the document at the same time.

Problem Solution: Users need a versioning control system that enforces a serial, not parallel, modification to documents by team members.

Severity: Users estimate they spend up to 3 hours/week just looking for the latest version of a document. At an annual average salary of $50,000 (US Dollars), this equates to a loss of productivity worth $3750/year/employee.

You can see that in this problem definition, that the business problem has been outlined, the business solution identified, and information against which the problem's severity can be assessed has be provided. Turning the core business requirement into a technical requirement would be the next step, as follows:

Technical Requirement: 1) The system must support serial check-in, check-out and versioning of documents. 2) The system must allow asynchronous, secured access to the document for editing. 3) The system must allow documents to be uploaded into the system from file servers and users workstations. 4) The system must allow documents to be created from within the system itself. 5)

At this point, you have the technical requirements that support the versioning requirements. Notice that both the business and technical requirements are written in technology-agnostic language and you haven't backed your way into writing business requirements based on SharePoint's features. So assume, at this point, that SharePoint is the software package created. How would these requirements inform the governance document? Sample verbiage for the governance document is provided here:

Employees are required to utilize the Major/Minor Versioning features in a document library anytime a document is modified within SharePoint.

To complete this discussion, user's would need to be trained on both how to use the Major/Minor versioning of a document within a library as well as the governance requirement that this type of versioning be utilized. Hence, while the users are being taught how to use versioning in SharePoint, they would also need to be reminded that the use of versioning is a requirement. Here is a sample text for a PowerPoint slide:

Slide Title: Versioning in SharePoint

Slide Text:

Use the document library settings to turn on Major/Minor versioning

Check with the legal department on the number of versions to be retained for the type of documents you'll host in the library

NOTE: the use of Major/Minor versioning is a requirement based on our company's business need and legal determinations.

By following this process, perhaps you can see how a business requirement can be turned into a technical requirement, which then informs the governance document and that informs the training and education that we give to our users on how to use the system. The combination of attention at these four levels will help ensure that SharePoint is utilized in the best possible way to support the goals of the business.

Putability and Operational Taxonomy

It is at this layer where you'll build out the taxonomy for each bucket in your business taxonomy. In most environments, you'll not have more than 2-4 metadata fields that you want attached to each document or record across the enterprise. But within each bucket, you'll have a more robust taxonomy that will be more flexible and unique to that part of the business. For example, referring back to Figure 10-4, you'll notice that there is a place for the accounting, or "money" part of your business. Because this area of your business is already described and regulated by General Accounting Principles, the Security Exchange Commission and others, a taxonomy already exists for this part of your business if you care to use it.

Don't think that you need to re-invent the wheel when creating your taxonomy. Be sure to check out the standard taxonomies that already exist that you can take and modify. These taxonomies are a great place to start when looking at the build out of your unique taxonomies.

Dublin Core

The Dublin Core Metadata Initiative (DCMI), in its' early days, outlined a fifteen-element core of metadata that they thought would be a core set of metadata that could be applied to any record or page anywhere in the world and is outlined in RFC 5013, ANSI/NISO Standard Z39.85-2007 and ISO Standard 15836:2009. This standard is reflected in the Dublin Core content type that ships out of the box with SharePoint Server 2010. If you need a basic place to start building your operational taxonomies, the Dublin Core might be a good place for you to do this. The fifteen elements include:

• Title
• Creator
• Subject
• Description
• Publisher
• Contributor
• Date
• Type
• Format
• Identifier
• Source
• Language
• Relation
• Coverage
• Rights

More InfoYou can learn more about the DCMI at dublincore.org.

Darwin Core

The Darwin Core is based on the standards developed by the DCMI and should be viewed as an extension of the Dublin Core for biodiversity information. The purpose of these terms is to facilitate data sharing by providing a well-defined standard core vocabulary in a flexible framework to minimize the barriers to adoption and to maximize reusability. The terms described in this standard are maintained by Biodiversity Information Standards.

Darwin Information Typing Architecture

The Darwin Information Typing Architecture (DITA) is an XML-based architecture for authoring, producing, and delivering information. Although its main applications have so far been in technical publications with a focus on information interchange and reuse. DITA focuses on reuse with a topic-based core set of metadata. A common misconception is that DITA, defines everything you could possibly want in content models. In reality, DITA defines only base models and its developers expect that you will create your own topic types to meet your own information needs.

The DITA architecture defines four layers:

Delivery context:The processing and delivery context

Typed topic structures:The formal content structure

Common structures:Metadata and table structures that can be shared with any topic

Shared structures:Content models for structures that can be used in all documentation

More InfoYou can learn more about DITA at dita.xml.org.

Other Taxonomies

There are other types of base taxonomies that you might want to leverage, given the type of information that you're trying to organize:

• DocBookPopular content model for software documentation
• SCORMAn XML-based method of representing course structures
• IPSVThe Integrated Public Sector Vocabulary (IPSV) is an "encoding scheme" for populating subject elements of metadata. This standard was developed in the United Kingdom.
• OpenDocument FormatAn XML-based file format specification for Office documents
• XMP (Extensible Metadata Platform)Adobe-led labeling technology that allows you to embed data about a file into the file itself
• NewsMLNewsML is designed to provide a media-type-independent, structural framework for multi-media news.

There are also some pre-defined vocabularies that you might be able to leverage as you build out your taxonomy:

• Gale Accounting Thesaurus (Gale Group, Inc.)
• European Education Thesaurus (Eurydice European Unit)
• ACM Computing Classification System (Association for Computing Machinery)
• taxonomywarehouse.com

Referring back to the methodology, you'll see that it's at this layer that we need to develop our tagging and Putability policies. Based on the old Garbage In-Garbage-Out principle, you can understand that how information goes into SharePoint will directly impact how it comes back out. Be sure, in this part of your IOPS, that you take the time to understand not only the taxonomies and their values for the data you're describing, but also the policies that users must follow along with the ways that the information repositories will accept the tagging of data.

Usability and Tool Development

At the next layer, you're developing the user interfaces and tools necessary for both Putability and Findability. An example of a Findability tool would be the development of a custom advanced web part that exposes key metadata for a multi-keyword query. And example of a Putability tool would be the development of a custom interface that allows metadata to be input at the time a new document is first saved.

Content Types can be viewed as putability tools whereas search web parts can be viewed as Findability tools. Table 3 offers some additional ideas on how SharePoint tools can be leveraged. This is not an exhaustive list.

Tool/Feature	Putability	Findability	Both
Sites Directory			X
Managed Paths		X
Content Types	X
My Site Personalization		X
Audiences		X
Scopes		X
Records Center			X
Site Columns			X
Folders		X
Metadata Managed Service	X
Search web parts		X
Indexing		X
Breadcrumbs		X
URL and Site Design	X

The tools that you utilize, whether out-of-the-box or customized, will entirely depend on why SharePoint is being implemented in your organization, the type of data that will reside in SharePoint and the outcomes of your IOPS effort. Best Practice is to utilize the tools and web parts that ship with SharePoint Server 2010 before writing any custom code. Moreover, if you can purchase third-party code instead of developing it yourself, that is also smart.

Use of SharePoint and Maintenance

At this point, you're ready to roll out SharePoint and have your users use the product. As part of your rollout plan, you'll want to ensure they have been trained well and that you're following regular procedures to enforce the governance plan. Also, be prepared that as your information grows, changes and evolves, that your IA and taxonomies will adjust as well. This is an ongoing, but not a constant, effort.

Information Organization Project

This section outlines at a high level the steps necessary to successfully complete an information organization project. The first order of business will be overcoming resistance to the idea that your company's information really does need to be organized.

So, how do you go about getting others in your company to buy into the idea that they need to invest in an information architecture and more specifically, in a project that leverages the information organization features in SharePoint? This is never easy because the objections of decision-makers are entrenched and well known:

• If we need it, we can usually find it. This is the attitude that if we need something, we can always find it. All I have to do is send an e-mail around and someone will find it for me. But this assumes that you know the information exists in the first place. What if you're in an e-discovery effort and you need to perform an exhaustive search for a certain type of information? Most people don't know all of the information that exists in their environment.
• No one will ever sue us. This is an attitude of denial. But their thinking is that if we do get sued, we'll find what we need to defend ourselves. Again, not a smart way to approach this problem.
• We've got to pick our battles: If it costs $20/file a document, $120/find a misfiled document & $220 to re-produce a lost document, then the costs are tilted in favor of the occasional need to re-produce a lost document as opposed to the repeated costs to correctly file a document. What isn't taken into account in this line of thinking is the opportunity costs associated with a poor information architecture and the potential legal costs and exposure to liability if the right documents can't be found quickly during an e-discovery phase.
• Information security isn't at the top of our list of things to do, I trust my employees to handle documents correctly. While the vast majority of employees will handle files the way they are told to, there are always a few who won't. Moreover, in the absence of clear direction, users will default to doing what makes sense to them and you'll find that they all don't think the same way about how to handle documents!
• ECM is too expensive and there's little ROI, so why invest in it? Because the opportunity costs, while difficult to measure, are still there and you're still paying for them.

Overcoming these objections is not easy and it will take some real work on your part. To engage in an information organization project for SharePoint (IOPS), you'll need to understand that you're asking for change in how information is developed, managed and disseminated. Such change is not a small thing. It is likely that there are many information kingdoms in your organization with people who already take personal ownership of that information. That is not a bad thing, in and of itself. But it is something to be recognized and leveraged as part of your IOPS effort.

There are (essentially) six stages to an IOPS. This section outlines each stage and gives you tools for achieving your goal.

More InfoThere are other paths that can be followed to help with your SharePoint implementation. For example, BearingPoint has released their methodology on how to organize information, which is an open source standard for information management. You can learn more about this at http://mike2.openmethodology.org/. Moreover, the AIIM (Association for Information and Image Management, http://www.aiim.org) group has published several certifications that relate to SharePoint implementations. These are the Enterprise Content Management Specialist and Information Organization Specialist credentials. At the time of this writing, they are introducing a SharePoint Specialist certification that bridges the gap between the SharePoint technology and their expertise in how to manage information. The stages presented in the following section represent a suggested path on how to achieve a strong organization of information in SharePoint. But this is only a suggested path. You might find that using the MIKE 2.0, AIIM or another methodology will work better for your organization. Companies that following this method in their consulting practices include Summit 7 Systems (www.summit7systems.com).

Overall, the project is divided into six basic phases. The early phases are the most important and each subsequent phase builds on the previous phase. Moreover, the quality of success at each phase will directly impact the quality of success in the following phases that are left.

Phase 0: Information Organization Assessment

In the first phase, you'll want to gather information about the scope of the project and who the main stakeholders will be. You'll want to inform yourself about the environment in which you're working. Don't be fooled into thinking that you can bypass this stage because your working on your own environment. Doing this questionnaire will enable you to cover all the bases up front, loop in everyone who will be involved and set proper expectations on how the IOPS will flow.

The questionnaire should cover the following topics:

• Definition of the documents that are in-scope vs. out of scope
• Definition of the systems that are in-scope vs. out of scope
• Definition of the processes and policies that are in-scope vs. out of scope
• Statement of the technical environment that currently exists and what changes will need to be made to support the IOPS effort
• Definition of the problem that has given rise to the need for this project
• Definition of the desired outcome, which should be stated in measurable terms
• Discussion of the interview data that supports the project's effort
• Statement of the project's sponsor, project manager and champion
• Outline of the communication plan for the project
• Outline of the project plan

As you can see in the next figure, there is more to this phase than mere documentation of the problem, solution and current environment. In this same phase, you're also writing explicit business needs (not requirements) as well as conducting a Cost of Doing Business Analysis (CODB). Writing out the business needs is really how you'll define the Findability problem in business terms. The Persona interviews (next paragraph) illustrate those needs in an easy-to-understand way and the CODB quantifies the severity of the problem in opportunity costs.

In this phase, you're also going to need to conduct a CODB analysis. This is different from a Return on Investment (ROI) analysis. In nearly all companies, the value of their information doesn't appear on the balance sheet, so it's nearly impossible to calculate a hard return on investment against the cost of an IOPS. However, you can more easily calculate savings based on increased efficiencies as a result of an IOPS. Those calculations need to be completed in Phase 0.

More InfoRefer back to the section on "The Opportunity Cost of a Poor Information Process and Architecture" for more information regarding a CODB analysis.

The Persona Interviews can't be overlooked because they form the basis of a CODB. Have a business analyst document current processes and the cost of those processes is the foundation against which the savings calculation is made. Persona interviews are conducted on real people whose stories and daily lives in the workplace are folded into a composite person with a fictitious name. Once that persona is developed, that fictitious person is used as an example of how the IOPS will improve that employee's life. It's usually best if 3-5 personas are developed because different employee types will be affected in different ways.

You'll also need to do a Findability study before you can create the Statement of Work (SOW). You'll need to gather both antidotal and measured responses on how well employees are able to find the information they need and how easy that transaction is. Don't worry about measuring Putability in this phase, since a poor Findability solution will point out deficits in your putability processes.

When all of these activities are combined, you'll be able to describe the problem in real terms, quantify the opportunity costs in real dollars, express how the IOPS will improve efficiencies and how the day-to-day work lives of employees will improve. All of this is wrapped up into a Statement of Work and is usually tied to a request for additional funding to complete the next four phases. At the end of Phase 0, you're outlining the costs, staff and cycles necessary to complete the IOPS.

Phase 1: Business Requirements Development

In this phase, you'll do essentially two things: build out the business requirements based on stakeholder interviews, the problem definitions from Phase 0 and an overall grassroots survey. You'll want to document the requirements and then hold a series of requirements workshops to vet the requirements and ensure that everyone agrees on the definition of the problem as well as what is required in the solution.

This phase is an important phase that involves much writing and consensus building. This phase is illustrated in the next figure. But this phase will not complete the groundwork for your IOPS. Instead, you'll need to complete this phase in order to be prepared for Phase 2. It could be argued that the business requirement effort should be moved into Phase 0 and in some environments this will be the right way to conduct the IOPS. The placement of the effort to develop business requirements is in Phase 1, after the project has been approved and funded (which occurs after Phase 0), because of the cost and time consumption required to develop requirements.

Phase 2: Technical Requirements and Project Charter

In this phase, shown below, you're going to be focused on taking the business requirements and turning them into technical requirements. These technical requirements will bridge the business requirements with the feature set in SharePoint. The technical requirements will also outline the current state of hardware and software and then describe any changes that will be needed to implement SharePoint Server 2010. Also, in this phase, you'll need to document your current governance plan for SharePoint and then outline any modifications that will be needed as part of the SharePoint Server 2010 implementation.

The combination of the main elements from the first three phases will form the content and rational for the project charter to which everyone involved should sign-off on so that the project can move forward. Assumed in this process is the funding of the IOPS and the authority for those leading the project to make decisions, approve expenditures and implement policy changes.

Phase 3: Audit and Analysis

Taking the outputs from Phase 2, it's time to inventory the documents and records that are in-scope for the project as well as their security assignments. This is an exhaustive inventory and will require the purchase of third-party tools that can enumerate both the complete list of documents and well as their security descriptors.

This part of an IOPS can be rather difficult, because you're trying to discover old, outdated or irrelevant data that can be discarded. You're working with a multitude of content owners to help them decide which documents need to be kept and which ones need to go. You're also uncovering security problems with documents and are finding security processes and policies that will need to be updated to ensure those problems don't occur again.

Using Search Technologies to Check Your Audits

One way to check your audit efforts is to index the content in question, then commit queries against that index under different security contexts to see what documents appear in the result set. Recall that SharePoint's search technologies index and honor the security descriptors on content that is crawled, so there can be times when you'll want to execute queries to see if the security is set properly.

For example, if Juan and Sue have access to a document and you're able to find that document via search technologies under your security context, then you can know that the security on that document is not set correctly. In one real-world example, a research company was implementing SharePoint's search technologies for the first time and after indexing their most critical, proprietary document, they found that members of the IT staff were able to access those documents via Search. After looking at the security tab, they were perplexed because no one on the IT staff was listed as having permissions to those documents, either through inheritance or through group assignments. But when we looked under the Advanced permissions, they found that several global groups had been assigned pervasive, special permissions to nearly all of the documents and folders on their most "secured" file servers. They immediately suspended their SharePoint implementation while they inserted a very fast NTFS audit project to ensure that all of their content was properly secured on their file servers before they released the search technologies to their users.

There will be times when executing a query against the index should produce zero (0) results. If structured correctly, the query can ensure that those documents in scope for the query are properly secured, meaning that they do not appear in the result set.

As part of this phase, you'll need to ensure that you're communicating well with your users with whom you'll need decisions about which artifacts to keep and which can be discarded. A common resistance at this phase is from users who will claim that they don't have time to help out. At the beginning of the project, this resistance should be anticipated and dealt with in some form or fashion. A couple of ideas to manage this resistance include gaining authority to discard files over X number of months or years old or the authority to move their documents into an unsupported file server that will be excluded from the project.

Phase 4: Development of Putability and Findability

This phase is where you're developing the operational taxonomies, user interfaces, tagging policies and educational materials for users to utilize in their ongoing management of information. This is a busy phase and involves high "touch and feel" for your end-users. This is a highly visible phase that needs to go well in order for your project to complete successfully.

It is in this phase that nearly all of the previous discussion in this chapter under the heading "Building and Information Architecture" will be conducted. While the development of the business taxonomy can be conducted in parallel with phases 0-3 in this larger methodology, the rest of those activities will occur in this phase. Refer to the detail provided in the previous discussion and note the visual aid for this phase. Then move onto Phase 5.

Phase 5: Governance and Maintenance

This phase is the ongoing phase that supports and maintains not only the SharePoint implementation, but for the discussion here, the ongoing organization of information within the SharePoint implementation. It should be noted that information will change over time, so how information is organized and tagged may need to be adjusted accordingly. Engaging in a regular review of how information is managed, tagged, input and found will help ensure your efforts to organize information in SharePoint will not have gone to waste.

Also, as your company matures in the area of end-users managing information effectively, your governance rules and enforcements will necessarily change. Ensure that you have a process and positions identified who can make changes to the governance rules and then communicate those changes to your entire organization.

The next figure illustrates this last phase, which, in some senses, is really never completed due to the ongoing nature of maintenance, review and assessment and training. When considering the latter, be sure that your orientation materials for new employees teaches your IA, policies, procedures and rules of enforcement so that your organization doesn't experience incremental loss of use of that which this project will produce.

SharePoint Tools to Organize Information

SharePoint ships with a number of tools that can help you organize information. Table 4 outlines these tools and what they organize but it is not intended to be an exhaustive list.

SharePOint tool	Information Organized by the tool
Sites Directory	Links to the root sites of site collections
Web applications	Root URLs and Managed Paths
Managed Paths	Site collections that act as end-points of the "path"
Site Collections	One or more sites that host lists and libraries related to a common project or collaboration effort
Site	Lists and libraries
Lists and libraries	Documents and content items
Content types	Metadata that is related to a content element, such as a list item or document
Filtered views	List data based on pre-selected metadata, sorting and/or grouping rules
Web Part Zones	Web parts and their display
Audiences	Reveals information based on audience membership
Records Center	Official records that meet compliance requirements
Managed Metadata Service	Tagging of information via content type syndication
RSS (Really Simple Syndication)	Information that is delivered via the RSS standard

Best PracticeMake it a point to discern the difference between information that is reported and information that is organized. All information that is presented in a report format must necessarily be organized in some manner. However, don't view reporting, strictly speaking, as an organization method. Instead, it should be properly viewed as a method of dissemination

When organizing information within SharePoint, you'll need to understand that you have a group of embedded containers that ultimately hold the content. These containers can be organized in different ways and that's why, referring back to Table 4, you'll find that some containers only organize other containers rather than information directly.

For example, web applications host a root site collection plus managed paths. Manage paths host and organize site collections. Site collections host and organize sites and galleries. Sites host and organize web parts, but for our discussion, the focus is on lists and libraries. Lists and libraries host content items and site columns. Galleries - in particular the content type gallery - hosts content types, which is really a pre-defined and re-usable content item plus a defined set of site columns.

Hence, the URL organization, the managed path organization, the way web parts are organized across sites within a site collection - all of those organization tools affect how users navigate to and find information. While putability is focused on the granular level of tagging content items with metadata, the larger organization picture can also improve navigation to the content's hosting location if attention is paid to the various layers of container organization. Because this is more art than science, it is difficult to provide a model as to how to organize the various layers of SharePoint to make navigation work well. But the overall idea is to ensure you pay attention to both the navigation and the search technologies as the two basic ways users will find information within your SharePoint deployment.

I hope this has been helpful to those who need to organize information in SharePoint.

I hope this has been helpful to those who need to organize information in SharePoint.

Bill English, MVP
Mindsharp

Posted in: Bill English