Dissatisfaction comes from the numbers of these interfaces and the lack of cohesive roadmap to all there is to be found. You already know what you know and what you need to know. Sometimes you know how to find what you need to know but more often you don't know and stumble through a variety of possibilities up to and including asking someone else how to find it. That missing roadmap is more than an annoyance; it is a major encumbrance to doing your job and top management does not get it. They simply won't accept that one or two content roadmap experts (overhead) could be saving many people-years of company time and lost productivity.

In most cases, the simple notion of creating clear guidelines and signposts to enterprise content is a funding showstopper. It takes human intelligence to design and build that roadmap and put the technology aids in place to reveal it. Management will fund technology but not the content architects, knowledge "mappers" and ongoing gatekeepers to stay on top of organizational change, expansions, contractions, mergers, rule changes and program activities that evolve and shift perpetually. They don't want infrastructure overhead whose primary focus, day-in and day-out, will be observing, monitoring, communicating, and thinking about how to serve up the information that other workers need to do their jobs. These people need to be in place as the "black-boxes" that keep search tools in tip-top operating form.

Last week I commented on the products that will be featured in the Search Track at Gilbane Boston, Dec. 3rd and 4th. What you will learn about these tools is going to be couched in case studies that reveal the ways in which search technology is leveraged by people who think a lot about what needs to be found and how search needs to work in their enterprises. They will talk about what tools they use, why and what they are doing to get search to do its job. I've asked the speakers to tell their stories and based on my conversations with them in the past week, that is what we will hear, the reality!

From search appliances Thunderstone and Google Search Appliance, to platform search solutions based on Oracle Secure Enterprise Search, and standalone search products Coveo, Exalead, and ISYS, we will hear from those who have been involved in selecting, implementing and deploying these solutions for enterprise use. From a Forrester industry analyst and Attivio developer we'll hear about open source options and how they are influencing enterprise search development. The search sessions will be rounded out as we explore the influences and mergers of text mining, text analytics with Monash Research and semantic technologies (Lexalytics and InfoExtract) as they relate to other enterprise search options. There will be something for everyone in the sessions and in the exhibit hall.

Personally, I am hoping to see many in the audience who also have search stories within their own enterprises. Those who know me will attest to my strong belief in communities of practice and sharing. It strengthens the marketplace place when people from different types of organizations share their experiences trying to solve similar problems with different products. Revealing competitive differentiators among the numerous search products is something that pushes technology envelopes and makes for a more robust marketplace. Encouraging dialogue about products and in-the-field experiences is a priority for all sessions at the Gilbane Conference and I'll be there to prompt discussion for all five search sessions. I hope you'll join me in Boston.

Because I follow enterprise search for the Gilbane Group while maintaining a separate consulting practice in knowledge management, I am struggling with his conflation of the two terms or even the migration of one to the other. The search we talk about is a set of software technologies that retrieve content. I'm tired of the debate about the terminology "enterprise search" vs. "behind the firewall search." I tell vendors and buyers that my focus is on software products supporting search executed within (or from outside looking in) the enterprise on content that originates from within the enterprise or that is collected by the enterprise. I don't judge whether the product is for an exclusive domain, content type or audience, or whether it is deployed with the "intent" of finding and retrieving every last scrap of content lying around the enterprise. It never does nor will do the latter but if that is what an enterprise aspires to, theirs is a judgment call I might help them re-evaluate in consultation.

It is pretty clear that Mr. Altendorf is impressed with the potential for Fast and Microsoft so he knows they are firmly entrenched in the software business. But knowledge management (KM) is not now, nor has it ever been, a software product or even a suite of products. I will acknowledge that KM is a messy thing to talk about and the label means many things even to those of us who focus on it as a practice area. It clearly got derailed as a useful "discipline" of focus in the 90s when tool vendors decided to place their products into a new category called "knowledge management."

It sounded so promising and useful, this idea of KM software that could just suck the brains out of experts and the business know-how of enterprises out of hidden and lurking content. We know better, we who try to refine the art of leveraging knowledge by assisting our clients with blending people and technology to establish workable business practices around knowledge assets. We bring together IT, business managers, librarians, content managers, taxonomists, archivists, and records managers to facilitate good communication among many types of stakeholders. We work to define how to apply behavioral business practices and tools to business problems. Understanding how a software product is helpful in processes, its potential applications, or to encourage usability standards are part of the knowledge manager's toolkit. It is quite an art, the KM process of bringing tools together with knowledge assets (people and content) into a productive balance.

Search is one of the tools that can facilitate leveraging knowledge assets and help us find the experts who might share some "how-to" knowledge, but it is not, nor will it ever be a substitute for KM. You can check out these links to see how others line up on the definitions of KM: CIO introduction to KM and Wikipedia. Let's not have the "KM is dead" discussion again!

Most sizable non-profits want their collections of content and other information assets exposed to the public. But each department manages its own content collections with software that is unique to their specific professional methods and practices. In the corporate world the mix will include human resources (HR), enterprise resource management (ERP) systems, customer relationship management (CRM), R & D document management systems and collaboration tools. Many corporations have or "had" library systems that reflected a mix of internally published reports and scholarly collections that support R & D and special areas such as competitive intelligence. Corporations struggle constantly with federating all this content in a single search system.

Non-profit organizations have similar disparate systems constructed for their special domain, museums or research institutions. One area that is similar between the corporate and non-profit sector is libraries, operating with software whose interfaces hearken back to designs of the late 1980s or 90s. Another by-product of that era was the catalog record in a format devised by the Library of Congress for the electronic exchange of records between library systems. It was never intended to be the format for retrieval. It is similar to the metadata in content management systems but is an order of magnitude more complex and arcane to the typical person doing searching. Only librarians and scholars really understand the most effective ways to search most library systems; therein lies the "public access" problem. In a corporation a librarian often does the searching.

However, a visitor to a museum Web site would expect to quickly find a topic for which the museum has exhibit materials, printed literature and other media, all together. This calls for nomenclature that is "public friendly" and reflects the basic "aboutness" of all the materials in museum departments and collections. It is a problem when each library and curatorial department uses a different method of categorizing. Libraries typically use Library of Congress Subject Headings. What makes this problematic is that topics are so numerous. The number of possible subject headings is designed for the entire population of all Library of Congress holdings, not a special collection of a few tens of thousands of materials. Almost no library systems search for words "contained in" the subject headings if you try to browse just the Subject index. If I am searching Subjects for all power generation materials and a heading such as electric power generation is used, it will not be found because the look-up mechanism only looks for headings that "begin with" power generation.

Let's cut to the chase; mountains of metadata in the form of library cataloging are locked inside library systems within non-profit institutions. It is not being searched at the search box when you go to a museum Web site because it is not accessible to most "enterprise" or "web site" search engines. Therefore, a separate search must be done in the library system using a more complex approach to be truly thorough.

We have a big problem if we are to somehow elevate library collections to the same level of importance as the rest of a museum's collections and integrate the two. Bigger still is the challenge of getting everything indexed with a normalized vocabulary for the comfort of all audiences. This is something that takes thought and coordination among professionals of diverse competencies. It will not be solved easily but it must be done for institutions to thrive and satisfy all their constituents. Here we have yet another example of where enterprise search will fail to satisfy, not because the search engine is broken but because the underlying data is inappropriately packaged for indexes to work as expected. Yet again, we come to the realization that we need people to recognize and fix the problem.

I bring this up because the latest Gartner "magic quadrant" lists Microsoft (MS) as the "leader" in enterprise search; this is the same place Gartner has positioned Fast Search & Transfer in the past. Whether this is because Fast's assets are now owned by MS or because Gartner really believes that Microsoft is the leader, I still beg to strongly differ.

I have been perplexed by the Microsoft/Fast deal since it was announced earlier this year because, although Fast has always offered a lot of search technology, I never found it to be a compelling solutions for any of my clients. Putting aside the huge upfront capital cost for licenses, the staggering amount of development work, and time to deployment there were other concerns. I sensed a questionable commitment to an on-going, sustainable, unified and consistent product vision with supporting services. I felt that any client of mine would need very deep pockets indeed to really make a solid value case for Fast. Most of my clients are already burned out on really big enterprise deployments of applications in the ERP and CRM space, and understand the wisdom of beginning with smaller value-achievable, short-term projects on which they can build.

Products that impress me as having much more "out-of-the-box" at a more reasonable cost are clearly leaders in their unique domains. They have important clients achieving a good deal of benefit at a reasonable cost, in a short period of time. They have products that can be installed, implemented and maintained internally without a large staff of administrators, and they have good reputations among their clients for responsiveness and a cohesive series of roll-outs. Several have as many or more clients than Fast ever had (if we ever know the real number). Coveo, Exalead, ISYS, Recommind, Vivisimo, and X1 are a few of a select group that are marking a mark in their respective niches, as products ready for action with a short implementation cycle (weeks or months not years).

Autonomy and Endeca continue to bring value to very large projects in large companies but are not plug-and-play solutions, by any means. Oracle, IBM, and Microsoft offer search solutions of a very different type with a heavy vendor or third-party service requirement. Google Search Appliance has a much larger installed base than any of these but needs serious tuning and customization to make it suitable to enterprise needs. Take the "leadership" designation with a big grain of salt because what leads on the charts may be exactly what bogs you down. There are no generic, one-suit-fits-all enterprise search solutions including those in the "leaders" quadrant.

I'll try to share a clearer view of the model and explain why new systems of organizing content in enterprise search are quite different than the decimal model.

Classification is a good generic term for defining physical organizing systems. Unique animals and plants are distinguished by a single classification in the biological naming system. So too are books in a library. There are two principal classification systems for arranging books on the shelf in Western libraries: Dewey Decimal and Library of Congress (LC). They each use coding (numeric for Dewey decimal and alpha-numeric for Library of Congress) to establish where a book belongs logically on a shelf, relative to other books in the collection, according to the book's most prominent content topic. A book on nutrition for better health might be given a classification number for some aspect of nutrition or one for a health topic, but a human being has to make a judgment which topic the book is most "about" because the book can only live in one section of the collection. It is probably worth mentioning that the Dewey and LC systems are both hierarchical but with different priorities. (e.g. Dewey puts broad topics like Religion and Philosophy and Psychology at top levels and LC puts those two topics together while including more scientific and technical topics at the top of the list, like Agriculture and Military Science.)

So why classify books to reside in topic order? It requires a lot of labor to move the collections around to make space for new books. It is for the benefit of the users, to enable "browsing" through the collection, although it may be hard to accept that the term browsing was a staple of library science decades before the internet. Library leaders established eons ago the need for a system of physical organization to help readers peruse the book collection by topic, leading from the general to the specific.

You might ask what kind of help that was for finding the book on nutrition that was classified under "health science." This is where another system, largely hidden from the public or often made annoyingly inaccessible, comes in. It is a system of categorization in which any content, book or otherwise, can be assigned an unlimited number of categories. Wondering through the stacks, one would never suspect this secret way of finding a nugget in a book about your favorite hobby if that book was classified to live elsewhere. The standard lists of terms for further describing books by multiple headings are called "subject headings" and you had to use a library catalog to find them. Unfortunately, they contain mysterious conventions called "sub-divisions," designed to pre-coordinate any topic with other generic topics (e.g. Handbooks, etc. and United States). Today we would call these generic subdivision terms, facets. One reflects a kind of book and the other reveals a geographical scope covered by the book.

With the marvel of the Web page, hyperlinking, and "clicking through" hierarchical lists of topics we can click a mouse to narrow a search for handbooks on nutrition in the United States for better health beginning at any facet or topic and still come up with the book that meets all four criteria. We no longer have to be constrained by the Dewey model of browsing the physical location of our favorite topics, probably missing a lot of good stuff. But then we never did. The subject card catalog gave us a tool for finding more than we would by classification code alone. But even that was a lot more tedious than navigating easily through a hierarchy of subject headings, narrowing the results by facets on a browser tab and further narrowing the results by yet another topical term until we find just the right piece of content.

Taking the next leap we have natural language processing (NLP) that will answer the question, "Where do I find handbooks on nutrition in the United States for better health?" And that is the Holy Grail for search technology - and a long way from Mr. Dewey's idea for browsing the collection.

We entered the Web search era bundling content into a directory structure, like the "Yellow Pages," or organizing query results into "folders" labeled with broad topics. The controlled vocabulary that represented directory topics or folder labels became known as a taxonomic structure, with the early ones at NorthernLight and Yahoo crafted by experts with knowledge of the rules of controlled vocabulary, thesaurus development and maintenance. Google derailed that search model with its simple "search box" requiring only a word or phrase to grab heaps of results. Today we are in a new era. Some people like searching by typing keywords in a box, while others prefer the suggestions of a directory or tree structure. Building taxonomic structures for more than e-commerce sites is now serious business for searches within enterprises where many employees prefer to navigate through the terminology to browse and discover the full scope of what is there.

Taxonomies for navigation are but one purpose for them to be used in search. Depending on the application domain, richness of the subject matter, scope and depth of topics, these lists can become quite large and complex. The more cross-references (e.g. cell phones USE wireless phones) are embedded in the list, the more likely the searcher's preferred term will be present. There is a diminishing return, however; if the user has to navigate to a system's preferred term too often; the entire process of searching becomes unwieldy and abandoned. On the other hand, if the system automates the smooth transition from one term to another, the richness and complexity of a taxonomy can be an asset.

In more sophisticated applications of taxonomies, the thesaurus model of relationships becomes a necessity. When a search engine, has embedded algorithms that can interpret explicit term relationships, it indexes content according to a taxonomy and all its cross-references. Taxonomy here informs the index engine. It requires substantial maintenance and governance of a much more granular nature than for navigation. To work well, a large corpus of terminology needs to be built to assure that what the content says and means, and what the searcher expects are a match in results. If the results of a search give back unsatisfactory results due to a poor taxonomy, trust in the search system fails rapidly and the benefits of whatever effort was put into building a taxonomy are lost.

I bring this up because the intent of any taxonomy is the first step in deciding whether to start building one. Either model is an on-going commitment but the latter is a much larger investment in sophisticated human resources. The conditions that must be met to have any taxonomy succeed must be articulated in selling the project and value proposition.

Thinking about how product selections are made, prompts me to comment on a two major search product attributes that control the success or failure of search for an enterprise. One is the actual algorithms that control content indexing, what is indexed and how it is retrieved from the index (or indices). The second is the interfaces, interfaces for the population of searchers to execute selections, and interfaces for results presentation. On each aspect, buyers need to know what they can control and how best to execute it for success.

Indexing and retrieval technology is embedded with search products; the number of administrative options to alter search scalability, indexing and content selection during retrieval is limited to none. The "secret sauce" for each product is largely hidden, although it may have patented aspects available for researching. Until an administrator of a system gets deeply into tuning, and experimenting with significant corpuses of content, it is difficult to assess the net effect of delivered tuning options. The time to make informed evaluations about how well a given product will retrieve your content when searched by your select audience is before a purchase is made. You can't control the underlying technology but you can perform a proof of concept (PoC). This requires:

• human resources and a commitment of computing resources


• well-defined amount, type and nature (metadata plus full-text or full-text unstructured-only) to give a testable sample


• testers who are representative of all potential searchers


• a comparison of the results with three to four systems to reveal how well they each retrieve the intended content targets


• knowledge of the content by testers and similarity of searches to what will be routinely sought by enterprise employees or customers


• search logs of previously deployed search systems, if they exist. Searches that routinely failed in the past should be used to test newer systems

In either case, human resource costs must be added to the bottom line. A large number of mature software companies and start-ups are innovating with both their indexing techniques and interface design technologies. They are benefiting from several decades of search evolution for search experts, and now a decade of search experiences in the general population. Search product evolution is accelerating as knowledge of searcher experiences is leveraged by developers. You may not be able to control emerging and potentially disruptive technologies, but you can still exercise beneficial controls when selecting and implementing most any search system.

SharePoint is the most popular new collaboration tool for organizations with a large Microsoft application footprint but it usually resides with multiple other repositories that also need to be searched. So, what search products are being used to retrieve SharePoint content plus other content? A majority of search applications provide a connector to index SharePoint documents and they would not be making that available without a demand. We would like to hear what SharePoint adopters are actively using for search. What are you experiencing? If you would like to participate in the Gilbane Conference, and have experiences you to share, I hope you will get in touch and check out the full program.

On a related note, I was surprised, during my recent research, to discover few identifiable user-groups or support communities for search products. Many young companies launch and sponsor "user-group meetings" to share product information, offer training, and facilitate peer-to-peer networking among their customers. It is a sign of confidence when they do help customers communicate with each other. It signals a willingness to open communication paths the might lead to collective product critiques which, if well organized, can benefit users and vendors. It is also a sign of maturity when companies reach out to encourage customers to connect with each other. May-be some are operating in stealth mode but more should be accessible to interested parties in the marketplace.

Organizing functions are difficult to manage by users on their own professional time, so, having a vendor willing to be the facilitator and host for communication mechanisms is valuable. However, they sometimes need to have customers giving them a nudge to open the prospect of such a group. If you would value participating in a network of others using your selected product, I suggest taking the initiative by approaching your customer account representative. Communities for sharing tips about any technology are important but so is mutual guidance to help others become more successful with any product's process management and governance issues. User groups can give valuable feedback to their vendors and spur product usage creativity and efficiency. Finally, as an analyst I would much rather hear straight talk about product experiences from those who are active users, than a filtered version from a company representative. So, please, reach out to your peers and share your story at any opportunity you can. Volunteer to speak at conferences and participate in user groups. The benefits are numerous, the most important being the formation of a strong collective voice.

Getting intent solidly defined is important for so many reasons, many of them relating to solving a business problem and the expected outcomes. Knowing what these are will give you the framework for isolating likely candidates, efficiently. A second critical reason for having strong intent is to stave off project scope creep. As a former vendor, and now consultant, I see this play out repeatedly as product research ensues. Weak backbones in selection team members or flimsiness of their business case leaves openings for vendors to promote additional features, which often distracts from what is really needed.

So, armed with the right skeleton, a strong framework, a core scaffolding you are ready to approach your research systematically. Four paths are open to a study team; I recommend using all of them, in overlapping passes. Discovery about products, product performance in real-world scenarios, vendor business relationships with their clients, and the user community you will be joining are all targets that need to be exploited. Discovering a user community on-line that might have expressed a potential problem with a vendor or product, should drive you back to do more research to discover potential limitations or why a user might be having a problem that they brought on through inappropriate implementation. Iteration in research for technology requires perseverance and patience. A comment on each path to research might be helpful:

• Online research - This requires creativity and the most persistence to verify and validate what you find. I am amazed at how superficially many people read any content. We may be taught that good business writing requires a clear statement in the first paragraph of what follows with a solid summary at the end, but most content does not follow "good" business writing practices. You need to read between the lines, think about what is not being said and ask yourself why, follow every link on the sites of vendors under serious consideration. Look at vendor news notes and press releases to see how much activity is going on with product advances or new installations, and read descriptions of customer implementations to see how closely those deployments match your business need. Finally, search those customer names on the Internet in conjunction with the product name. This may retrieve public content that sheds more light on user experiences.


• Professional groups - Professional organizations in which you participate are fertile ground for asking about what others in similar situations to yours are using. As you get closer to a final choice, go back to others you know personally or professionally to get answers to the direct question, "have you had any problems with this product or vendor?" and "what is the benefit of this product for you?"


• Societies and academic institutions - These organizations publish content that may have a cost associated. When you consider thousands your organization spends on a selection process (in people time), contracting, licensing, implementation and deployment, it is wise to have a budget of several hundred dollars for reports that give detailed product evaluations. Get recommendations of librarians and peers as to publications' authoritativeness.


• User and analyst blogs and industry publications - The same guidance holds for industry publications as for societies and academic publishers but you will also want to pursue blogs of users and analysts. Users are a great source of discovering tidbits about products and vendors but continue beyond what you discover to see if the comments are isolated or follow a pattern.

This scenario plays out frequently and now I am uncomfortable because, as a consultant and search analyst, I know that there is a lot more I need to know before offering off-handed advice to that question. Here are some ideas for questions that you should be asking first so that, when someone like me wants more context, you have ready answers.

You first step is to survey your internal landscape and clearly document the following:

• What are the business outcomes you expect to derive from the search product, who will be using it, under what circumstances and for what purpose?


• What is the scope of the content that will be indexed for retrieval? Create a content map that explicitly illustrates: What, Where, Who, When. This means capturing what the content is in terms of document types and formats, numbers and size, and topic, and where it is being created, stored and managed. You need to know who created it, owns it, and will have access to it. Finally, it helps to document when it was created and information about retention.


• Who will be involved in product selection and evaluation, who needs to sign off at every stage of selection and procurement, who will be involved in installation and deployment, and who will maintain the system on an ongoing basis?


• What is your IT infrastructure and who controls it? If a schematic is not in place that depicts at least the portion of the computing infrastructure that will be integral to your search support, it is time to make sure one is prepared. You cannot make an informed decision about appropriate and workable search solutions without this information.


You will also be wasting the time of vendors when you seek product and licensing information if you do not have all of these issues sorted out. Much of the packaging of search products is dependent on numbers of documents or size of the corpus to be indexed, how the software will be installed, and who and how many will be accessing it. Pricing information will be vague until you have concrete content "demographics" to share with prospective vendors. You can't even establish a budget without answering the questions above, and you need a ballpark budget figure to help narrow your choices.

So, I am resolving to be more thoughtful in my responses when queried by friends and colleagues. Before answering I will be asking you for some meaningful data in advance of reeling off a list of products. It is time for you to do some preliminary research in-house before establishing the lineup of suitors. More on the next steps, next time up.

]]> http://gilbane.com/search_blog/2008/07/before_you_start_a_list_of_ven.html http://gilbane.com/search_blog/2008/07/before_you_start_a_list_of_ven.html Product Selection Search product procurement Thu, 31 Jul 2008 07:55:25 -0500 As I was developing concepts put forth in the report Enterprise Search Markets and Applications - Capitalizing on Emerging Demand I bounced around the Internet a lot to verify information I had previously noted about products listed in the vendor directory. As I did so, evidence began to emerge about the ease with which I could resurrect an earlier retrieved bit of content. It mystified me that vendors of products to aid retrieval of content would make it so difficult to find information on their own web site. One assumption of mine has been completely debunked, that vendors would use their own search product to help site visitors discover more about their products and services. It made me wonder why they would not be showcasing the full flavor of their offerings.

The report was not written to evaluate specific products but rather to give a more holistic view of how the markets for products break down and how products themselves can be categorized. In order to do the latter, it required reading about many products with which I had no hands on experience. I wanted to understand how vendors were positioning their products, what markets they felt their products are most suited to satisfy, and what search problems were best solved with their technologies. Coming up with generalizations, trends, and differentiators was one purpose for my research. When I realized how difficult it was to dig out specifics from many vendor Web sites, I moved on, probably leaving stones unturned but time was not on my side.

Now I am going back to learn more about the problem with researching search, something complained about by a number of buyers I interviewed. Vendors are not making it easy for buyers to narrow their search for search, and shame on them. This should be a "no brainer." If you are a vendor pushing a product that is easy to install, implement and deploy, there is no better way than to put it to work on your own site. On the other hand, if you have products that are more sophisticated in terms of offering complex retrieval by leveraging refined ontologies or rules, you had better take the time to make it work well for finding nuggets on a few hundred pages of your Web site.

I am going to be writing more about this because the deeper I dig, the more interesting the results. For starters, of the first 28 vendor on my list, twelve have no site search. Of those that do, several use a third-party search engine, not their own. One major vendor's search result count displayed nearly a hundred records that matched the search while also displaying the breakdown of records by category. The trouble was the category numbers totaled less than 20. Hmmm!

Perhaps the trouble in "searchland" is that no one wants to take the time to implement, deploy and maintain search to satisfy the user. I keep saying, "it's not the technology; it's the thought and skill that goes into the back room implementation." Or is it? Stay tuned.


]]> http://gilbane.com/search_blog/2008/07/taking_measure_of_search_on_ve.html http://gilbane.com/search_blog/2008/07/taking_measure_of_search_on_ve.html Product Selection Product evaluation Product testing Research Search marketplace Site search Thu, 24 Jul 2008 08:44:31 -0500 Amidst post Gilbane San Francisco business I have been reading what everyone else has been writing about search the past couple of months. While there continues to be much speculation and gossip about the Microsoft acquisition of FAST, and which companies may soon be absorbed into larger entities, there also continues to be interesting activity among the mid-tier and start-up search vendors. Meanwhile, I advise those who aspire to acquire a search solution for "behind the firewall," don't wait for the "big players" to come up with the definitive solution to all your search needs because it will never happen. I'm in good company with other analysts who advise moving on with point search solutions for specific business needs. You will save money, and time because many of the new products are optimized for rapid deployment, in weeks or months, not years.

If you check out my new research report, Enterprise Search Markets and Applications; Capitalizing on Emerging Demand, June, 2008, you will find a directory to companies offering search solutions with choices for what Steve Arnold refers to as "beyond search." Deep test drives of many of these products can be found in his report, as well. Meanwhile, new releases of products listed, and new products both continue to be announced. ISYS, Coveo and Expert System (Cogito) have brought new offerings to market in the last month and Collexis, a relative newcomer, is drawing attention to itself by demonstrating its products at numerous meetings this year.

So, keeping reading and checking out the possibilities. While you are at it, be sure to put the Gilbane Boston Conference on your calendar for December 3 - 4. We are all busy rounding out the program right now.

I am particularly interested in hearing from those of you who have participated in the selection of a search product in the past two years, implementing or deploying a system anywhere within your own enterprise. Please consider sending me a brief proposal for a presentation at the conference. For your effort, you will get to attend all the conference sessions, as well as help the audience with the needed reality checks on what it takes to conduct a selection process and follow through with implementation. I particularly want you to share your learning experiences: the good, the frustrating, and the lessons you have accrued. Professional speaking experience is not required - we want stories. [You'll find my email on the "Contacts" page of the Gilbane site and you should also look at the speakers guidelines for additional information.]

]]> http://gilbane.com/search_blog/2008/07/search_is_not_taking_a_summer.html http://gilbane.com/search_blog/2008/07/search_is_not_taking_a_summer.html Product Selection Cogito Collexis Conferences Coveo ISYS Product evaluation Search product procurement Thu, 17 Jul 2008 13:38:55 -0500 Search for the whole enterprise vs. point solutions was the subject of some discussion, especially since our keynote speaker, Stephen Arnold gave strong guidance that you can't think about one search solution ("product") for the entire enterprise and all content. This is something with which I pretty much agree, in most cases.

Just emerging from the Gilbane San Francisco conference, six sessions on search and a workshop I conducted, I want to share a couple of general impressions. Details and expanded reflections will follow in the days and weeks to come.

Search for the whole enterprise vs. point solutions was the subject of some discussion, especially since our keynote speaker, Stephen Arnold gave strong guidance that you can't think about one search solution ("product") for the entire enterprise and all content. This is something with which I pretty much agree, in most cases. However, a question arose in one of the sessions in which a couple of presentations talked about a single search engine for what appeared to be the entire enterprise. A member of the audience asked for clarification in view of Arnold's earlier comments.

I chose to intercede so as not to put our speakers on the defensive about what, for their organizations were very reasonable choices. Both of the cases were for research or professional services organizations with a high incidence of uniformity in the scope and type of content. They are relatively flat in structure with the bulk of the population being researchers: consultants, engineers, scientists. The applications were for intranets that were being leveraged to connect content and experts, so that from either direction (finding an expert and then looking at their content, or finding content to reveal expertise) other professionals could leverage organizational knowledge. It is a safe bet that other search does exist elsewhere in these companies, even if it is in stealth mode or embedded in other applications. Still, in general, large organizations with highly differentiated personnel with functional and disparate content requirements will find value in point search solutions that may only have purpose in a single internal domain.

To that point, if you are a finance professional or business manager you might want to sign up for a webinar this Thursday, June 26th, when I will be laying out a business case for a particular kind of search solution that is targeted at your demographic. This Apps Associates sponsored webinar also describes a solution leveraging Oracle enterprise search, but the ideas in it will give you a sense of what search can provide in your domain.

Judging from the topics presented on search, the reasons and ways in which it is being applied are more diverse than even I imagined. Opinions about what is good/bad, appropriate or not, and how to approach search technology ran the gamut of simple to complex. Two strong points of view were expressed about taxonomy vs. just tagging or letting the search engine categorize. Neither side would give an inch to the other as having an approach that is often "good enough." It is pretty clear that hybrid solutions offering both a structured approach to search where a taxonomy is applied through metadata, and auto-categorization by the search engine without a supporting taxonomy in the background will be applied in many enterprises.

]]> http://gilbane.com/search_blog/2008/06/afterthoughts_on_the_state_of.html http://gilbane.com/search_blog/2008/06/afterthoughts_on_the_state_of.html Search Problems/Solved Search Problems Auto-categorization Search case studies Taxonomy for search Tue, 24 Jun 2008 11:29:13 -0500 Meaning is a very large concept in every aspect of search technology and dozens of search product sites include either the words "semantic" or "meaning" as a key element of the offered technology. This is not as far fetched as search product claims to "know" what the searcher wants to find, as if "knowing" can be attributable to non-human operations. However, how well a search engine indexes and retrieves content to meet a searcher's intent, is truly in the eyes of the beholder. I can usually understand why, technically speaking, a piece of content turns up in a search result, but that does not mean that it was a valid scrap for my intent. My intent for a search cannot possibly be discernible by a search engine if, as is most often the case, I don't explicitly and eloquently express what, why, and other contextual facts when entering a query.

The session we have set aside at Gilbane San Francisco for a discussion on current activity related to semantic technologies will undoubtedly reveal more meaning about technologies and art of leveraging tools to elicit semantically relevant content. I suspect that someone will also stipulate that what works requires a defined need and clear intent during the implementation process - but what about all those fuzzy situations? I hope to find out.

This is the last posting before the conference this week so I hope you will add this enterprise search session (EST-6: Semantic Technology - Breakdown or Breakthrough) being moderated by Colin Britton to your agenda on June 19th. He will be joined by speakers: Steve Carton, VP Content Technologies, Retrieval Systems Corp., Folksonomies: Just Good Enough for all Kinds of Thing, Prakesh Govindarajulu, President, RealTech Inc, Building Enterprise Taxonomies from the Ground Up, and Jack Jia, Founder & CEO, Baynote.

See you in San Francisco in person or virtually thereafter.

]]> http://gilbane.com/search_blog/2008/06/what_is_semantic_technology_an.html http://gilbane.com/search_blog/2008/06/what_is_semantic_technology_an.html Search Technologies and Products Folksonomies Semantic search Taxonomies Mon, 16 Jun 2008 13:33:10 -0500