SAP’s “search” strategy isn’t about search
I caught up with Dennis Moore today to talk about SAP’s search strategy. And the biggest thing I learned was – it’s not about the search. Rather, it’s about a general interface, of which search and natural language just happen to be major parts.
Dennis didn’t actually give me a lot of details, at least not ones he’s eager to see published at this time. That said, SAP has long had a bare-bones search engine TREX. (TREX was also adapted to create the columnar relational data manager BI Accelerator.) But we didn’t talk about TREX enhancements at all, and I’m guessing there haven’t really been many. Rather, SAP’s focus seems to be on:
A. Finding business objects.
B. Helping users do things with them.
“What,” you may ask, “is a business object? Is it a database record? A group of database records linked by metadata? A web service?” SAP’s answer to that question is an emphatic “Yes!” As I’ve long documented, SAP’s technical strategy is heavily post-relational, with a strong DBMS2 flavor. Even so, I have trouble imagining how the “finding business objects” part will soon work, other than by the standard technique of text search that includes the indexing of relational database columns.
So once the objects are found – then what? Well, if you find a person or invoice or whatever, there are only so many application functions that can be performed on them. Thus, SAP aspires to present these functions to you. (Analogy: The SAP/Microsoft Duet product line.) Which ones will be presented first – i.e., which will be the most “relevant results?” Uh, that’s not so clear. There are a range of possibilities, ranging from hard-coding* to a simple voting mechanism based on earlier users’ choices in similar situations. Fortunately, SAP doesn’t have to find the single best fit; with good portal technology, it’s realistic to present a number of top functionality choices more or less at once. This fits in well with the flexible access to business objects that SAP has been talking about for quite some time.
*Actually, I’m pretty sure this would be “modeled” rather than “coded.” But in any case hand-building is definitely an option, especially in early releases of the technology.
Another topic in the mix is natural language. Presumably, that would start with natural language BI query, a technology that has been floating around since at least the early 1980s. Or maybe it wouldn’t; elementary command-and-control can actually be achieved through a search interface. For example, “Dennis Moore interviews” might call up a variety of text documents, or a calendaring interface to schedule a meeting. But “give Dennis Moore a raise” might bring up the human resources application.
Comments
2 Responses to “SAP’s “search” strategy isn’t about search”
Leave a Reply
[…] Enterprise information management could be transformed. Oracle is batting about 0-for-the-decade in search. Google has is selling a lot of not-terribly-useful low-end enterprise search boxes. There’s room for both to do a lot better. Ex-Oracle executive Dennis Moore has some good ideas in that regard. […]
[…] Alternatively, you can navigate via a search box, searching both on names of objects (e.g. users, divisions) or on names of tasks. This is somewhat reminiscent of an approach SAP was considering a few years ago. […]