• Dennis reported on an internal SAP Enterprise Twitter research project, and pointed at a number of the other pages I’ll mention. (Note: If that goes anywhere, it will have to be in conjunction with Business Objects.)
• Jevon MacDonald listed pros (many) and cons (few) of Enterprise Twitter.
• Andrew McAfee argues at length that an enterprise needs multiple social networking tools, to match up with different intensities of collaboration among coworkers.
• Niall Cook offers a short, convincing use case for Enterprise Twitter.
• JP Rangaswami also offers use cases.
• Ed Yourdon argues that Twitter is “good enough” for enterprises. But he seems to concede it could indeed be a lot better.
• Paul Gillin praises Twitter’s business potential for us self-employed consultant types.
• Sid offers a number of quick-hit use cases for Enterprise Twitter.
• Bill Ives takes a more skeptical view, focusing on enterprises uses of today’s Twitter.
• Nancy offers many Twitter use cases, some of which are enterprise-relevant.

Here’s my take on the subject.

I see four basic (and somewhat overlapping) use cases for Enterprise Twitter:

Real-time short communication. This is a major part of enterprise communication, especially when face-to-face meetings need to be arranged. Enterprise Twitter could do this better than email. It would require limited archiving, decent URL-attaching, and good targeting or filtering by user (work)groups.

Real-time wide outreach. The CEO could (briefly!) share her thought for the day. The cafeteria could announce specials. The salesman on the Universal ACME account could see if anybody else is familiar with UA. The users who help others with crashed PCs could let themselves be interrupted only when they actually don’t mind helping. This is probably the Enterprise Twitter use that requires the fewest changes from Twitter’s current form, although stuffier enterprises may require profanity filters and the like.

IM integration. Instant messaging is a very useful enterprise tool, since the alternatives are less timely or more distracting. That can and should be wholly integrated with Enterprise Twitter. Sometimes IM conversations expand to more than two people. That’s all the more reason for Twitter integration.

Beyond the firewall. IM discussions can and should penetrate the firewall, including employees, partners, customers, suppliers, and so on, just as email does. The Enterprise Twitter form of this is like a permanent (and hence very low average volume) IRC/AOL chatroom. To make that happen you need good group selectivity, good security, and perhaps also some nannyware oversight (profanity, intellectual property, hucksterism, etc.) .

If the messaging and office productivity software vendors don’t provide filter-rich Enterprise Twitter, somebody else most likely will.

 This could be interesting …

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.