The differences between ESME and IM

Many people have, during the last couple of weeks, asked me about the difference between IM and ESME. There will probably be many more asking, so instead of answering everyone individually, I will explain it here.

Listed, these are the main differences between ESME and IM:

• Opt-In Following: Allowing an asynchronous follower/following behavior.
• Group Concept: Post different messages to different groups.
• Tag Clouds
• Integration of different corporation back-ends/SAP integration

To explain the opt-in following concept, I will use a story that happened to me recently.
It demonstrates the power of Twitter and explains (one of the ways) how ESME can be a valuable tool for the enterprise.
I will write more about the other points on the list in the weeks to come.

I was installing LiveCycle ES at work, using a so-called turnkey installation, that turned out to be not-so-turnkey after all. (surprise surprise!)
Because this was a part of Adobe’s prerelease program, finding help was difficult and the forums on the prerelease program site wasn’t exactly like the forums I was used to on SDN. Days went by without any answers, so instead of wasting my time waiting for one, I shared my headaches with my friends on Twitter.
My friends shared that with their friends again, and within a couple of hours I had Adobe employees writing to me on Twitter offering their help.
The next day all problems were solved and I could finish my installation.

Everyone helping me were people I didn’t know, so without Twitter I wouldn’t have known where and how to find them. This approach lets them find me.

Because a service like IM uses a mutual following concept, you would have had to tell every single individual in your contact list about your problem individually and they would have had to do the same with their contacts etc.
With Twitter you write your message only once and it reaches hundreds of people (of course this depends on how many people follow you), and if a friend re-tweets and he has a couple of hundred friends and so on, you can reach thousands of people with only 3-4 messages.

Finding the right person to ask can sometimes be as time consuming, as solving the problem itself can be. This is no different in big organizations.
If you don’t know whom to ask for help solving your problem, finding this person can be a daunting task.
This is where ESME comes into play.

ESME – Taking It To The Next Level

It is only a week ago, since I wrote my last post on EMSE, the Enterprise Social Messaging Experiment.

In this one week, we moved from loosely discussing frameworks, design and implementation on wikis and Google groups, to submitting a 6 minute video for the Demo Jam at SAP TechEd.

To be part of this team has been an amazing experience, and I have gained much from it, both on a professional and on a personal level.

I will write more about my experience in the next couple of days, I just wanted to present our video for now.

Further ESME blogs on SDN:
Dennis Howlett
Abesh Bhattacharjee

ESME – Social Enterprise Messaging Experiment

Earlier this year I saw this picture (from Sapphire) with the words SAP, Innovation, Enterprise 2.0 and Enterprise social networking together and it got me thinking.

A couple of weeks later, during one of the recent Twitter downtimes, some of us ran to the newly started Plurk, to let the world know what we were doing.
Of course that wasn’t so easy without an API in place, so that didn’t last long.
It was however just enough time for ESME – Enterprise Social Messaging Experiment – to be born.

ESME started off from one Plurk conversations (or here as RSS).
Now 20 days later, the project has already come so far, that the architecture and design ideas are being discussed in detail.

What I have found interesting and fun in this process, is that we have only used microblogging and collaboration tools to plan this project. Not once did we call each other or use IM.
20 people from all over the world have put their names on the ESME SDN wiki page (even though some are involved as “listeners”), so logistically it has not been an easy task.

Though through using tweets with a 140 character limitation and the wiki when we needed to go into details, we have built an architecture, the foundations of UIs we want to use, the implementation, discuss the social network aspects and think of scenarios where such a tool would be useful.
If someone had told me even just a year ago, that something like this would be possible, I probably would have laughed at them..
This has been an amazing experience so far, and I hope this is just the beginning!