Introduction

Since our earliest days, New Idea Engineering has been in the business of helping companies implement enterprise search. Usually we get involved when the installation didn't go quite right, or when there was a need for advanced features that are difficult to implement. Usually the search solution already selected was right for the job; our customers just needed some help up the learning curve. Lately we've seen a change. We still get called in to implement advanced capabilities, or to help with installation and set-up; but it seems that more and more of the people we see have selected the wrong search technology for their requirements.

In the 1990s there were 'leading' vendors who understood search and who 'got' the internet; and there were other vendors whose technology wasn't quite up to speed and who sometimes didn't 'get it' about the 'net. But here in the new millennium, we're living the good life: most search engine vendors are offering pretty good products, though some customers still experience sticker shock when they see the final cost.

We still hear complaints about vendors and technology, some of which might be deserved. But seriously folks, if you've never tried to install and configure a 1995 vintage web-based search engine, then you may not appreciate how far the vendors have come.

The Wrong Stuff

To us, the number one reason that companies are dissatisfied with their search technology is that, as we start to work with them, it's clear they have bought the wrong search engine for the job. We're still pondering the cause of all this: it doesn't seem to be from intentional or malicious misrepresentation by the vendors sales teams. Nor is it from lack of effort by the companies: most have gone through at least some level of due diligence, and found the software to be promising... at first. But when the implementation starts, it becomes clear that the solution was either more powerful (and probably more expensive) than needed; or worse, that the solution was just not powerful enough for the task at hand.

Instead what we see is that vendor X returned phone calls promptly, and vendor Y blew it. Or that vendor Z did a drive-by analysis, and the customer probably should have asked for an on-site evaluation

We've also seen miscommunication between customers and vendors, particularly when it comes to the word 'can'. A company might ask a vendor ’Can your product index database content?” Vendors are optimistic, and the sales staff usually has a great understanding of features - and a list provided by their marketing staff - so if the feature list says the software can access database content, the answer is 'yes'.

But just as the word 'is' might mean different things to different people, the affirmative answer to the question 'can it...' might not be a complete. The product might be able to index database content as soon as you install it - probably the original intent of the question. But it could mean 'yes, when you buy the expensive extra add-in for database access'; or it could mean 'yes, if our consulting staff comes on-site for a six month assignment to write the code'. By the way, Jolt cola may be required as well.

Prospective buyers would do well to ask better questions: Does your product index database content in the standard configuration? If not, how much customization would be involved to enable database access? Do I need to use the API to do it, or is it a configuration option? And most importantly, 'Can I speak to a reference customer who has recently done the same thing with your software?'.

Another edge case of 'can it' miscommunication involves the simultaneous use of multiple features. For example, consider a company that has database content and web based content, and the sales staff says their product can index both. It might be good for the company to ask 'Can it do both at the same time'. It may be obvious to the company that indexing both in the same application is the desired capability; but when presented with a checklist of requirements, vendors don't always consider them as simultaneous requirements. When you are going to spend a bug chunk of your company's cash on software, be sure the vendor knows exactly how you plan on using it!

Some Examples of Mismatches

Examples make things so much clearer. Those presented here are fictitious, and no real companies or vendors were injured in the making of this newsletter. And the names have been changed to protect the innocent. And in the spirit of full disclosure, we may exaggerate to make the points clearer.

Vocabulary term: “API” means “Application Programming Interface”, which means the vendor will sell you a set of C or Java tools that will let you access their search engine from within your application at a much lower level. Programmers love APIs!

Scenario One:

Scenario Two:

Scenario Three:

Scenario Four:

Scenario Five:

Getting it Right

There are a few simple steps top follow if you are preparing to evaluate different search solutions.

• Determine the features you need
• Identify key sources of data to be included in search
• Identify security requirements
• Set up a representative test data are
• Identify potential vendor
• Describe the full requirements to vendors
• Ask vendors to show you your representative data in their standard application
• Insist the vendor spell out any options and the scope and price of any consulting

You may want to secure the assistance of an expert third-party company to assist in the evaluation. There are many companies that have experience dealing with multiple vendors, and they can help you navigate the process from initial specifications to final deployment. You may find it helpful to utilize industry or local associations, analyst tools like the Gartner "Magic Quadrant" for Enterprise Search, or independent tools like the New Idea Engineering Enterprise Search Matrix.