SAP TechEd 2006: Enterprise Search

One of the announcements from SAP TechEd was the release of SAP’s Enterprise Search. Enterprise Search is quite the posh now-a-days, of course, of the Google. As I’ve outlined elsewhere, Charles Phillips of Oracle articulated the “customer demand” quite well with an anecdote along these lines (not a direct quote, just my recollection of it):

I was talking with one of our largest customers just last week. He said, “you know, if I want to find something on the web, anything, I just type it into Google and have it in less than seconds. And then, when I get onto my corporate Internet, I can’t even find PO’s that need to be paid. What’s the deal with that?”

And there, is the best anecdote for the shift I talk about frequently: business no longer drives IT innovation, instead consumer tech is driving IT innovation.

A New Desire

Unfortunately for businesses, Google let customers see what search can be like and how it can change the way you do workflow, to use an enterprisey word. Would people know that they wanted search if it weren’t for Google? And just now, this year, it seems like all of the major enterprise software companies are getting their game together.

Sure, they like to complain “we’ve had search forever! What’s so special about these new guys?” but that’s like hearing US car makers in the 70’s, 80’s, and today complain about Asian cars by saying “but we’ve sold cars forever! What’s so special about these new guys?”

Putting the Enterprise in “Enterprise Search”

The key question is: why don’t I just get a Google Search Appliance or, as I did when I was at BMC, a Google mini? Believe me, dear readers, if you have no or just a lame intranet search, hooking up one of Google’s search boxes behind your firewall will be magic. It works just as well as it does on the Internet: you find what you need instantly, right out of the box.

For now, behind the firewall there are two things that differentiates “Enterprise Search” from Google Search:

• A Command and Control mentality, or, access rights and “security.”
• Searching over non-web based data-stores.

In both cases, Google could easily catch up by coding up those features…if it had the will. And the perception of unwillingness for Google to “go enterprise” is all that Enterprise Search vendors have in their favor.

FUD on Google: “Those guys don’t understand you, we do. Please sign here.”

That FUD is well called for though. I’ve talked with several people about the difficulties the *-2.0 people have going enterprise. Oddly, it often boils down to sheer misunderstanding and unwillingness to sell to those kinds of customers.

Certainly, if you’re not savey when selling to enterprise customers, you’ll get your lunch eaten several times, but with very subtle ways you change your mentality, sales, and support you can start grabbing those bags of cash that enterprises are desperate to hand over to bring the value of the public web behind their firewalls.

As an aside, from conversations I’ve had with a few people here, FeedBurner apparently works well with enterprises. They don’t have the allergies that others seems to inflict themselves with.

While it’d be fun to analyize the problem of consumer companies making the jump to selling into enterprise — Apple would be an especially interesting case given the last round of Xserv announcements and the history of being the business desktop of choice in the 80’s for a time — let’s get back to Enterprise Search.

Access Control

Access control in Enterprise Search means “I can prevent people from seeing secret data.” This means to do a search, you need to log in to the system (sure, you might be all SSO’ed into paradise and so not have to manually log in), which is where I start thinking about lunch instead of the product. Low barriers to entry is incredibly important and it’s a large part of the success of Google over Yahoo!, MSN, and other “pre-Google” searches (who eventually caught up, sure).

There is real-life validity to the desire of enterprises to control who can access what data. Controlling information is a key tool in maintaining a command and control organization, which is what most every enterprise is. If every worker could get access to every piece of internal-information about a company, the whole thing would start to tumble down. That is, an enterprise doesn’t want to bring the flattening and disintermediation effects of the web behind-the-firewall.

More importantly, if someone has been a bone-head enough to post an Excel spreadsheet with all the employees names, SSN#, salaries, and bank routing numbers on a public SharePoint, once search comes in, every worker will find it. And that, my friend, is when whisper revolutions start happening, you get distracted, and command-and-control becomes crap-your-pants.

Companies like SAP, Oracle, and others, then, offer search that controls what information users can find. The enterprise isn’t ready to let employees make that decision for themselves. Of course, a consequence of that is that if you want to compete against that type of enterprise, you now have a[nother] differentiation hook available.

How Does Google Spell SAP?

The other thing that Enterprise Search promises to deliver is information from non-web sources. Google’s and other’s appliance, of course, has ways to pull in information from any source, but it takes converting it to a web page. I crap you not, my friends, when I had a Google mini, the answer to questions like, “how can I search over Exchange” was “convert the emails to web pages.”

As we call it in code-monkey jungle, a “hack.” (I’ll be happy to correct that if Google would like to tell me other wise ;>)

So, Enterprise Search means integration with non-web and non-text data sources, like ERP information from SAP or task information from workflow portals like IBM’s or BEA’s. More importantly, Enterprise Search implies a semantical understanding of that data. By understanding semantics, you can start adding action links next to things. If you recall my discussion of RSS in systems management, it’s very similar to adding in links to events or spam comments in RSS feeds.

I haven’t really been impressed with how well companies do “Enterprise Search Integration” (to hijack the EAI term). It either falls along the lines of Google’s hack or does quite the opposite and lets the semantics of the pulled in entities leak too much into the search UI. One of the great things about Google’s more minamalistic approach to search is the normalization it does across all the different types of things out there. Primarily, it normalizes everything to content and, very rarely allows the nature of that content to effect the UI (movies, addresses, and other “actionable” items being notable exceptions). Even when those exception occur, they’re quite polite in their leakage: they don’t yell or require much attention.

The challenge is figuring out how to use search with workflow. And this is where things get both exciting and, from what I’ve seen so far of Enterprise Search options, goes pear-shaped.

Workflow

I’ve been using the term “workflow” a lot recently without spending much time defining it. But, to understand why Enterprise Search could be great, it’s worth laying out what I mean by workflow.

In talking about software, workflow to means “the process of taking some piece(s) of data and doing something with it.” The important part is that the process is structured enough to be tracked and componentized. Also, to get all dorky, the process can be recursive, or like fractals and Russian dolls for the less codey folks out there.

In the enterprise context, workflow invariably means “my boss can enforce, track, and approve/disapprove items in the workflow or the workflow as a whole.” Or, as folks like to call it “Governance, Compliance, and Audit.” This is where workflow gets a bad name because it can be used to create information cog-workers.

Shai Agassi illustrated a nice workflow in the SAP world in his keynote this week: one of his employees, Jeff, submitted a vacation request. So, there was a small workflow for Shai to handle: approve or reject. SAP has an endless set of user interfaces, so for the purposes of demo’ing them all, Shai logged into the portal, checked his email, used a widget, and even called into a voice system…to reject the request each time ;>

Workflow could be managing a lead (getting a customer to pay you money for a product, service, or, even better, no reason at all), it could be producing (writing, editing, publishing) a document, or it could be resolving an IT issue (why does it take 10 minutes to send an email?).

Current workflow platforms are built around the portal concept, esp. BEA’s approach. A user logs into the portal, checks out the tasks they have, and then starts executing on those workflows. Their bosses can log in check up on how employees workflows are going, assign new workflows, and approve/reject the milestones in workflows.

From Portal to Command-line Workflow

What Enterprise Search needs to become is a command line for workflow. To a limited extend, the Enterprise Search companies are starting to do this. In the SAP Enterprise Search demo we saw, you could search for people and locations and then “take actions” on them. But these were more like cross-launches into existing applications and mash-ups from the map level.

What I’d like to see, and what will be the true application of consumer tech behind-the-firewall, is a mix of using search and RSS to consume and deliver workflow behind-the-firewall. Currently email is the workflow king, and enterprise players keep trying to move it out of email: you hear the stories of how people defensibly keep copies of email to make workflow accusations (“look, you told me to do this 2 months ago!”). People like email. It’s easy, the model is well known, and it works.

That said, search and RSS delivery have the same characteristics of email but by adding a very thin layer of structure on top, allow for the hooks you need to add in enterprisey features.

Taking a different tact, a large part of what I’m saying is this: what’s important is the data, not the code. So, the code should be as unobtrusive as possible, while the data should be incredibly accessible and stable. I see search and RSS as the sweet spot between unobtrusive and the uncontrollable flurry of email, and I haven’t seen a vendor that delivers on that vision yet.

Admittedly, there’s a third component to this, and that’s the easy production of data for the other two to consume. I need to spend more time on that angle as the answer I have now — wikis, blogs, and email lists — seems too cliché…which doesn’t mean it’s incorrect.

Selling Less

Part of the problem is that there’s less to sell in this model, which makes it unattractive to companies who want to sell software. Another problem is the “value-incumbancy” of the current offerings: that is, both vendors and customers have spent millions, even billions on more complex approaches to workflow, and I’m suggesting, “how about you just need 10-40% of that?”

In such a situation, an outsider is the typically the one to disrupt. And that’s why people like me, and even more so, Charlie Wood always ask the Google question. Now, if Google would just be more forceful in it’s “we get Enterprise” messaging, we’d get laughed at less when we raise the topic.

Keep in mind though that the way I use Google is practically a sort hand for anyone who could bring the benefits of the public web behind the firewall. In all of this, I’m not saying it can only be Google. It could be Yahoo!, Microsoft (that’s a long-bet), or anyone who has the balls to take the challenge on.

Enterprise Will

Ironically, I don’t think it’s too tough of a challenge. The task is a lot more low-risk than most people think. People are still feeling the scorch marks of The Bubble where the idea of extreme disruptive change from the consumer world was way, way over-hyped, much more than what I’m talking about here.

In addition to that, the problem is getting ahold of a team of people who can think consumer-tech and enterprise-sales at the same time, which is exceedingly rare to find; I think, just because of the sheer unwillingness of those two groups of people to cross-over. And that’s the real FUD in the favor of “traditional” enterprise software vendors, and the challenge for those wanting to get into enterprise sales.

Update: I liked the below summary so much I wanted to add here:

If email is the de facto interface to workflow, then “what Enterprise Search needs to become is a command line for workflow”

Thanks, rodcorp!

Disclaimer: BMC, IBM, BEA, and Oracle are clients. SAP paid my T&E to be at SAP TechEd 2006.

Tags: behindthefirewall, google, lasvegas, oracle, sap, sapteched2006, search, stallgeruch