Let’s face it – it’s the rare bit of information that will be the most relevant search result for everyone, every time. Like information itself, search results are always contextual. Meaning, if I search for ‘wizard’ on the Internet, am I looking for information about the Wizard of Oz, a wizard for downloading drawing software to my computer, or the Washington Wizards basketball team? Google thinks it’s the Washington Wizards, because it knows I’m in Washington, DC, which is part of the context of my search – my geographical region. If I were searching from Liverpool, England, it would have probably given me several hits for Wizards Den online clothing store instead. To Google, and most of us, it makes sense that objects closer to me would be more relevant to me, more often than not.
This type of inference is what organizations need to give Enterprise Search engines if there is any hope of bringing them close to delivering the Internet search experience that staff often crave on company Intranets. It’s very surprising, however, that although most standard commercial Enterprise
Search Systems come with the ability to provide contextual searches to different user groups across the organization, this feature is vastly underutilized by search teams. The work required for leveraging contextual search functionality in the enterprise would rely on a few prerequisites discussed below.
1. Roles and Personas (Business Analysis layer)
Before spending another minute tinkering with your current Enterprise Search engine, proceed to leveraging a skilled set of analysts to define the roles and personas in your organization. This definition can be done at a very high level (e.g., Paul Employee works in X Dept., which is based in Y city), or at a more granular level, describing job roles. At a minimum, think of the Roles in the context of the major categories of information being used by different subsets of employees.
Once you finally define a set of key staff groupings in the organization for targeting search results, you can only target content at them if you (i.e., your search engine) can identify that content in the first place. Example, if you want to give priority to marketing-related search results for employees in your Marketing Division only, then the search engine has to be able to identify and bubble up the marketing-related content while filtering out the rest. It would be pretty easy to do if this content were all together in one place on your company’s Intranet. This brings us to the next step.
2. Enterprise Content Model (Information Architecture layer)
Based on the defined business needs for information use, the content can then be mapped into a structure that aligns with the defined Roles/Personas – an Enterprise Content Model. An Enterprise Content Model is based on the simple concept of keeping like information together in an organized manner. It is different for each organization, because the subject matter and relative importance of each category of information varies from one organization to another. So, sorry, there is no one-size-fits-all content model that can be purchased and applied to your Intranet. Skilled information architects must be leveraged to think through how people need to share, find and use information on the company Intranet, and what information subsets are more important to some groups than to others. Content can then be added to the Intranet according to the content model.
3. Intranet Site Structure (Application Architecture layer)
The physical structure of the company Intranet (which is visible from URL compositions) should be aligned completely with the Enterprise Content Model that was derived from analysis of roles and information needs in the organization. In a SharePoint environment, which tends to be common in organizations today, content can be architected at different levels of granularity to allow
for flexibility in targeting content groupings. Within one content farm, the logical site architecture and consequent content grouping could be as follows, allowing for specific Roles to be mapped to specific applications, paths, site collections, etc.:
http://web_application/managed_path/site_collection/site/…
Ironically, most organizations approach these three steps above in the reverse order, where technical staff determine the architecture of the company Intranet based solely on server-side, database and other technical dependencies, with little to no thought or plan for the information that will be shared on the Intranet and who will use it.
Enterprise Search Meets Enterprise Architecture
1. Organization/Business Analysis (assess how information users are grouped)
2. Content/Information Architecture (map information groupings to groups of users)
3. Site/Application Architecture (design to match information groupings)
If your organization did indeed approach this architectural challenge in the reverse order (or not at all) and you are now stuck with a de facto content model on your Intranet and dissatisfying search results, all is not lost! With a few temporarily broken URLs and some elbow grease, key sites can be moved around and metadata tags can also be applied to bring some content together virtually,
even on a go-forward basis. If the mess is just too much for a quick fix, consider investing in an end-to-end Intranet re-architecture project using steps 1 through 3 above.
Although I have described the steps above in a rather whimsical fashion, they are not typically simple undertakings and will require some professional expertise. The last thing you want to do is spend time coming up with a whole new blueprint, only to discover later that it’s all wrong and actually brings your staff further away from satisfaction with Enterprise Search quality. The resources invested in applying context to Enterprise Search correctly will pay-off in the long run, guaranteed.
This type of inference is what organizations need to give Enterprise Search engines if there is any hope of bringing them close to delivering the Internet search experience that staff often crave on company Intranets. It’s very surprising, however, that although most standard commercial Enterprise
Search Systems come with the ability to provide contextual searches to different user groups across the organization, this feature is vastly underutilized by search teams. The work required for leveraging contextual search functionality in the enterprise would rely on a few prerequisites discussed below.
1. Roles and Personas (Business Analysis layer)
Before spending another minute tinkering with your current Enterprise Search engine, proceed to leveraging a skilled set of analysts to define the roles and personas in your organization. This definition can be done at a very high level (e.g., Paul Employee works in X Dept., which is based in Y city), or at a more granular level, describing job roles. At a minimum, think of the Roles in the context of the major categories of information being used by different subsets of employees.
Once you finally define a set of key staff groupings in the organization for targeting search results, you can only target content at them if you (i.e., your search engine) can identify that content in the first place. Example, if you want to give priority to marketing-related search results for employees in your Marketing Division only, then the search engine has to be able to identify and bubble up the marketing-related content while filtering out the rest. It would be pretty easy to do if this content were all together in one place on your company’s Intranet. This brings us to the next step.
2. Enterprise Content Model (Information Architecture layer)
Based on the defined business needs for information use, the content can then be mapped into a structure that aligns with the defined Roles/Personas – an Enterprise Content Model. An Enterprise Content Model is based on the simple concept of keeping like information together in an organized manner. It is different for each organization, because the subject matter and relative importance of each category of information varies from one organization to another. So, sorry, there is no one-size-fits-all content model that can be purchased and applied to your Intranet. Skilled information architects must be leveraged to think through how people need to share, find and use information on the company Intranet, and what information subsets are more important to some groups than to others. Content can then be added to the Intranet according to the content model.
3. Intranet Site Structure (Application Architecture layer)
The physical structure of the company Intranet (which is visible from URL compositions) should be aligned completely with the Enterprise Content Model that was derived from analysis of roles and information needs in the organization. In a SharePoint environment, which tends to be common in organizations today, content can be architected at different levels of granularity to allow
for flexibility in targeting content groupings. Within one content farm, the logical site architecture and consequent content grouping could be as follows, allowing for specific Roles to be mapped to specific applications, paths, site collections, etc.:
http://web_application/managed_path/site_collection/site/…
Ironically, most organizations approach these three steps above in the reverse order, where technical staff determine the architecture of the company Intranet based solely on server-side, database and other technical dependencies, with little to no thought or plan for the information that will be shared on the Intranet and who will use it.
Enterprise Search Meets Enterprise Architecture
1. Organization/Business Analysis (assess how information users are grouped)
2. Content/Information Architecture (map information groupings to groups of users)
3. Site/Application Architecture (design to match information groupings)
If your organization did indeed approach this architectural challenge in the reverse order (or not at all) and you are now stuck with a de facto content model on your Intranet and dissatisfying search results, all is not lost! With a few temporarily broken URLs and some elbow grease, key sites can be moved around and metadata tags can also be applied to bring some content together virtually,
even on a go-forward basis. If the mess is just too much for a quick fix, consider investing in an end-to-end Intranet re-architecture project using steps 1 through 3 above.
Although I have described the steps above in a rather whimsical fashion, they are not typically simple undertakings and will require some professional expertise. The last thing you want to do is spend time coming up with a whole new blueprint, only to discover later that it’s all wrong and actually brings your staff further away from satisfaction with Enterprise Search quality. The resources invested in applying context to Enterprise Search correctly will pay-off in the long run, guaranteed.
RSS Feed
