Skip to content

Is Enterprise Search an Application or a Feature?

Eric and the Google mini

After speaking with Brainware this morning, I’ve been left with the question “is enterprise search an application in itself, or just middleware (or a feature) for other applications?”

Remember Enterprise Search?

About a year ago, every major software company (IBM, Oracle, Microsoft, SAP, etc., not to mention all the medium and small ISVs) came out with an enterprise search product. Essentially, the product replicated Google behind the firewall, giving you a search box that allowed users to search over content behind the firewall. Sure, there were adaptors to previously “dark data,” security to limit access to sensitive search results, and the number one cliché use case of any new enterprise technology (a favorite of mine), the geo-cyborg salesperson:

so, you’re a sales guy in the bay area, and you have some spare time. Why spend that time on your own when you could opportunistically find other clients to pester and visit. You just type in your address and – BAAM! – it shows you the movement of clients in a 5 block radius. Look! That guy crossing the street is a client! Go human-spam him! Sell! Sell! SELL! (Hey, those 24″ inch monitors aren’t gonna buy themselves, code-monkey.)

Enterprise Search vs. (Just) Search

I’ve had a long history with trying to figure out enterprise search. The obvious, easy win that any Google mini (or whatever) will take care of is just fixing your intranet search. Intranets are littered with endless web pages and having one way to search over all of it should be required now-a-days. You know, for simple stuff, like, “what are the company holidays for 2008.”

You, dear readers with intranets (of any size), should do an experiment and see how long it takes you to find that info: no cheating if you have saved on your desktop or know how to directly click to it. Pretend that you have no idea where it is and can’t email or ask someone. How long does it take?

Other than simply searching over intranet pages, though, I haven’t heard too many stories of enterprise search being used as an application on it’s own, or even as critical a part of daily corporate work as Google is to daily public web work.

Hierarchical work drives category-think

Enterprise search as a Google-like drop in doesn’t seem to be taking off at the moment. I’m wide open to being corrected, in fact I’d love to be as I always have big hopes fro search.

There are numerous (possible) reasons for this (see an extended discussion from my SAP TechEd 2006 coverage, but at the end of the day, my current theory is that enterprise users just don’t think, or want, to use search as their primary tool. People are very siloed and categorized at work, and I think that mind set trickles down into an employees want to categorize things rather than search for them. As psuedo-metaphor: I’m sure more people – more “civilians” (non-powerusers) – use email folders than just search for their email amongst a pile of messages.

Search is Big with Breakin’ the Law

There is an exception here: search is big for workflows involving illegal activities. That is, lawyers love search for looking over emails for court cases, search is great for auditors and compliance. Basically, if you’re trying to “figure out what happened” when the law or regulations were broken, you love search.

While GRC is a lucrative field now-a-days, in the context of this discussion, I’d say it’s niche.

Search as a Feature

The alternative, which Brainwave spoke to, was the notion of search just becoming a feature in other software. Rather than being the start of a work flow – you go to – it’s embedded in other applications and work flows.

This is certainly the way I experience search in my daily life, on my OS X laptop. I search in my email, my calendar, on my blog (to look up past articles), and other silos. The distinction here is that I first go to the data silo in question and then search, instead of searching and then narrowing down to the silo.

Here, search is embedded in other applications or, the more general, silo. Brainwave seems to think that’s a good way to go (in addition to general search), and the discussion around Microsoft purchasing FAST for SharePoint search touches on that a bit. John Willis has also done a lot of research and thinking about using enterprise search in IT Management.

What’s your thinking?

So, the open question to you, dear readers, is just that: do you see enterprise search being used as the first part in workflows, that is, as a stand-alone application? Or do you see it being used more as a part, or feature, of other applications? And, to put it in the future tense, which of the potential uses seems better?

Disclaimer: SAP, IBM, and Microsoft are client.

Technorati Tags: , ,

Categories: Compliance, Enterprise Software.

Comment Feed

6 Responses

  1. How about the fact that intranet search simply doesn't work? It's not Google 2008 (pagerank), it's Altavista 1999 (keyword search). And people expect Google-like levels of relevance in their search results.

    It's all the linking that takes place on the Web that allows Google to provide ranked results that work. In most intranets, there isn't much linking going on. A lot of the docs are PDF, DOC, PPT, XLS with almost no links. And even HTML content tends to be link-poor (other than same-site links) compared to what you find on the real Web.

    To take your example of the list of company holidays, how many pages on the company's intranet typically point to the HR page with that information? Not many. Which is why that page is hard to find on search results (unless it is one of the common queries that has been manually configured by the search team). It is buried among pages such a question from a solutions architect in Poland asking how to configure Polish holidays in the CRM product. Back to "keyword search" level of relevance. Feels like the stone age.

    Another benefit of internal blogging: making the intranet search engine smarter.

  2. William. Yeah, you're probably right on that. It's hard to use crowd-AI to figure out what the right match is when there's a tiny, fire-wall trapped crowd to go off of.

  3. Sorry in advance for the long comment, but your post got me looking through some old notes on this issue of enterprise search.

    William is right, in that internal web sites are more about just getting the content out of people's heads and into documents/wikis/records, while external web sites are all about being findable via Google/Yahoo/MSN – which means good linking, good keywords, good titles.

    There's another aspect, though, which has to do with the type of searching being done.

    There's search as a substitute for bookmarking, which is how I think many people use an internal search system…they know the page is there, so they just need a quick way of finding it. Because of this, tuning search results based on the user's search history (and that of other internal users) has significant value for enterprise search. But in the end it doesn't add all that much value.

    Other types of searching, such as exploratory search, wind up having highly variable value, depending on the type of work an employee does. For many people with fairly stable routines at work, these other uses of search have little value.

    On the other hand, a true knowledge worker can get a lot of value out of a search system that supports learning and exploration.

    This last point is one that I'm extrapolating from our experience with developers, but it feels like it fits a general class of employees who do in fact need to be constantly learning and solving problems – in other words, the more highly compensated and valuable people in an organization.

    Which is why good search can be the most effective way for a company to get more out of its key employees.

    — Ken

  4. Michael, great analysis!

    You are absolutely right in saying that search is becoming a feature in other software.

    Yes, now you can use the search function in a array of applications. In some cases, you can make the most of the search technology without entering queries manually.

    For example, Brainware’s Intelligent Data Capture solution IDC-distiller™ ( uses the embedded fuzzy search function to automatically match invoice content with a vendor list and a purchase order, even if there is no exact match.

    This ‘unmanned’ search function greatly increases the proportion of payment documents that can be processed without any human ever touching them.

  5. Decades ago enterprise content was collected, indexed and shared through whatever technology the corporate library could get its hand on. Search was embedded and, as the gatekeepers for enterprise content, information specialists maintained metadata to make it searchable. That model is fading but the need for embedded search is still present. Knowledge workers tend to work within a framework of technologies and for most of their critical information needs will look for content within that framework.

    However, there is always a superset of enterprise content that need access by all, and it requires its own management tools. Ideally, intranet portals will provide search access to all shareable content without the need for security, and access to selected application content with requisite security. This may be done with federated search tools that can leverage content results from embedded search engines.

    Doing this well and with thoughtful build-out requires governance and a chief information architect who really understands the nuances of all the content, its security attributes and how it needs to be accessed.

    A single enterprise search engine, given the right packaging and deployment can do it all, but it requires human guidance.

Continuing the Discussion

  1. […] brush up this problem frequently when it comes to enterprise search: things just don’t seem to be working out as brilliantly as we’d hoped for when it […]