***IM Planet Spring 2003
February 24 - 25, 2003
by James Sneeringer
Boston, MA
Instant messaging has fully arrived as an enterprise industry.
With statistics like 84% of US enterprises that have IM usage, it
is an application that any company with a network cannot ignore.
At a minimum, IT departments will want overlay solutions to
understand its effects on network usage and security, and HR
departments will want to ensure that its use falls within company
policies. But for many vendors, including Microsoft, IM goes way
beyond instant text messaging. With its RTC server, Microsoft
sees IM as the bridge to a communication system of the future
with highly integrated voice, video, text, presence, and
applications. Lotus recently announced that it would be tightly
integrating its Sametime IM application with its Websphere
server. And in many sessions, numerous companies discussed the
possibilities for using IM for applications communication.
The term of IM has been re-defined, from the traditional IM
paradigm of the buddy list, presence, and text conversation
window, to a general term for any combination of real-time
messaging with presence status. Presence, really, is the key
attribute of IM, and what distinguishes it from similar
technologies like SMS. The result is that IM is coming to be
considered as a logical transport layer, capable of pushing
dynamic status changes messages to a client in real time.
At this point every enterprise needs to ask itself several
questions. The first is, to what extent, and for what, is IM
being used by my employees? The second is, what do I want to do
with it? As a communication technology, it can be difficult to
quantify the ROI on IM usage, beyond several vertical
applications such as customer call escalation, or brokerage
communications. But as several people pointed out, it might be
unfair to ask IT departments to justify the cost of a basic IM
management overlay. After all, they didn't install the IM
clients; the employees did. Even if the company wishes to stop
all usage it will cost money to do so. And for financial and
health care companies, and the accounting departments of public
companies, there may be a regulatory requirement for logging of
all IM usage, for an audit trail.
At a higher level is the question of the company's long-term
communication strategy. IM is one of several technologies
impacting enterprise communications, including WLAN, mobile data,
and voice over IP. Microsoft sees IM as an integral part of the
converged enterprise communications of the future, and the
standard of SIP as the way to get there. But for many companies,
the cost of a full enterprise IM solutions such as Lotus Sametime
or Microsoft's RTC server cannot be justified. These companies
will be looking more to leverage the free public IM networks,
either with a management overlay from companies such as IMLogic
or Akonix, or an enterprise solution from one of the networks
themselves, such as AOL or Yahoo.
Themes
There are several themes that became evident during the
conference:
Tension Between Enterprise Solutions Based on the Public
Networks, and Private, Internal IM Servers
This was on display in the first two sessions, with the
Yahoo and IBM/Lotus reps taking the two respective sides in
the debates. In two consecutive sessions they traded
comments and debated the two approaches hotly. In general it
seems likely that large enterprises are more likely to go
with a full internal system like Sametime, while smaller
companies will be attracted to the price savings associated
with public network solutions.
IM enterprise solutions based on the public networks exist
on a range, from a simple security, management, and logging
overlay to existing public IM use, to a custom enterprise
solution from a big networks (AOL, Yahoo, MSN) that hooks
into the enterprise directory server. In most cases the
overlays are provided by 3rd parties such as IMLogic or
Akonix. These consist of a server that sits on the network
between the users and the Internet, monitoring and
controlling IM use. For many companies this is the next step
after discovering how wide-spread IM use is in their
organization.
Both Yahoo and AOL sat on the panel of the 3rd session of
the day, and both have enterprise solutions, although Yahoo
was by far the most vocal in pushing theirs (and the concept
of public IM enterprise solutions in general). Their public
IM enterprise solution is based on their network, with
authentication of the user taking place on the Yahoo
servers. The enterprise piece is providing the ability to
local IT to secure, manage, and log (if desired) the IM.
AOL's enterprise solutions provide an option to base
authentication on the local directory, essentially
"trusting" any IM user who is authenticated by that domain.
IBM/Lotus was pushing Sametime, with a completely different
view of enterprise IM. In this view, the enterprise deploys
Sametime for robust internal IM and collaboration. If they
want to communicate with a partner or customer, they can
negotiate and set up a connection between their internal
networks, based on SIP/SIMPLE standards, which like MS, IBM
is pushing hard. The rep could not stop talking about it.
For IBM/Lotus, enterprise IM is basically internal, and the
technical standard of SIP/SIMPLE will allow their customers
to set up connections to other enterprise networks if they
desire. The concept of free access to public networks is
only barely considered, with a connection to the AIM network
that (according to some on the show floor) is barely
implemented. Microsoft seems to be firmly in this camp,
although Windows Messenger is based on SIP/SIMPLE, and
interfaces with MSN.
The Need for IM to Fit Into Existing Corporate Policies and IT.
Everyone agreed that a stock brokerage cannot have one of
its brokers communicating with customers under the screen
name "studbroker22." Yet, the brokerage firm who discovered
this screen name could not even match it to a specific
broker. If IM use is to become a legitimate part of business
communications it must submit itself to the same constraints
that exist on other communications. These include:
Naming convention
Like e-mail, enterprise IM needs a naming convention.
This is to make identity clear, and provide more
professional interactions. Most solutions seem to lean
toward using the e-mail address as the screen name. For
public IM solutions, the use of the domain identifier
creates a possible revenue stream--the public network
charges to provide the domain as part of the screen
name. This may or may not be hooked into the private
enterprise directory.
Authentication
Hand in hand with naming convention is the ability to
trust that the person behind the screen name is who
they claim to be. Authentication is either hosted by a
public network (such as Yahoo) and provided for a fee
to enterprise users, or the enterprise IM solution
hooks directly into the internal authentication scheme.
IBM/Lotus emphasizes the selling point that their
solution (unlike Yahoo) does not double-charge for
authentication. AOL has a solution that can "trust" the
enterprise authenticated users for a particular domain.
Virus
Companies pay a lot of money for virus protection
software and services. Ideally the IM system will be
able to hook into the existing security framework.
Content filtering
A brokerage must be able to search outgoing content for
the words "guaranteed return," to protect themselves.
In addition, many e-mail systems filter for
inappropriate or harassing content. This must be
available on IM as well.
Disclaimers
Automated legal disclaimers are an important part of
many corporate e-mails. IM needs that ability as well.
Encryption
Standard IM travels as clear text. Like e-mail, some
enterprises have a requirement for encryption of this
text, to protect data while in transit.
Spam
IM spam is possibly even more intrusive than e-mail
spam, since it can pop-up on the desktop without
opening it yourself. This is a downside to using public
networks for enterprise IM, according to IBM. But,
Yahoo said to watch for an announcement on this from
them soon.
Logging
Logging is a regulatory compliance issue for financial
service companies, and some healthcare providers. The
paper trail must be preserved for audits. In addition,
there may be a requirement of ALL public companies to
preserve some traffic, due to the Sarbanes/Oxley bill
that makes CFOs directly responsible for the accuracy
of their books. However, IBM stated that for many of
their customers logging does not even make the top 10
list of desired features. In some cases, they adamantly
do NOT want to log unless required to by law.
There is also a personal component--allowing
individuals to store conversations locally. Most
clients already provide this.
Using IM for Application Communication
Going beyond people to people, this idea uses IM as a real-
time communication service with applications. Because IM is
real-time it is claimed that it can provide relief to call
centers if integrated into help applications, or it can
serve as real-time communication between apps. Presence also
provides opportunity as an application service; in this case
it is abstracted to mean any status that changes over time.
The advantage is the push nature of updating presence at the
distant client.
This has several components:
Using IM for people to communicate with apps
This places an application behind an IM screen name,
that the customer communicates with via text, either
using natural language, commands, or menu prompts
("Enter 1 for General, 2 for Engineering," etc). The
IBM rep put it best--the normal interface would have be
pretty bad to make this attractive. It is not far
removed from text role playing games or negotiating the
Internet from a Unix prompt--no one is going the pass
the Turing test. Because text is so light on bandwidth,
though, this type of app communication may be ideal for
mobile uses.
Using IM for apps to talk to apps
This was the talk of an afternoon session, and to be
honest it sounded like an hour of catch phrases. "Every
enterprise application has a component that would
benefit from real-time interaction"--this point was
raised over and over again. The key seemed to be the
push update nature of IM--one application could send
data as it changed, rather than wait for the other app
to request it on a regular schedule. The session was
full of off-the-cuff ideas but it seemed that few were
selling anything here yet.
Using presence
Presence is just a way of pushing a dynamic state
description out to distant users. For people the
gradations are from online to offline, with different
"away" messages in between. But for applications,
presence can be any state change. Examples during the
day included stock prices, eBay bid prices, weather,
and flight status. In this scenario, the application
sits in the buddy list via a screen name, with the
presence next to it. For example:
Buddy List
-- Friends
Wave Issue 0306 3/7/03 Article 2-01