Geeks are more predictable than others!

However I was expecting it to be a bit earlier when I wrote Web2.0 simulation wave at SDN and that was almost a year back.

Geeks are predictable because they follow a technology trend more passionately than others. And at times they do create some useful stuff in the process.

Though great things happen when Geeks become unpredictable and come up with something very new to the world. But it can be difficult to handle such a disruption every now and then. And it's probably good that they tend to be predictable after every major disruption.

Not sure who said this first but there you go :

It's not just about who did it first but also that who did better.

So following a trend or even copying/adapting is not a bad idea provided you can do better than the original or carve a niche for yourself.

Geeks from SAP Community are getting together to adapt a twitter like functionality in an Enterprise environment and it's called Enterprise Social Messaging Experiment (ESME).

It was started by a conversation on Plurk. Read this post by Abesh and follow the links to get the story. Other deserving links are ESME - Social Enterprise Messaging Experiment by Yojibee. Dennis Howlett also blogged about his side of story on SDN.

Seems like this enterprise microblogging application will not only support human conversations but also the interactions between humans and system objects (Business Objects/Applications/Data). Read the Requirements document.

Requirement 1 is :

ERP notifications - Extensible notification system for events in backend systems. Think new sales order for customer x. Auto-generated enterprise tweets to Plurk-style cliques, defined by UME roles & groups (see #7). Could also include workflow notifications a la UWL.

I had something similar to say when I wrote this funny stuff ERP2.0 - The Blog of a SAP Purchase Order .

My suggestion will be to first concentrate on developing the UI and messaging architecture for human interactions. Enterprise services should be developed for communication with backend system.

Later these services can use the SAP Business object/Workflow event's existing subscribe/publish model for system generated notifications/alerts.

There are several type of events that gets triggered in a SAP system:

• Due to a change in the status of a Business Object/System [ e.g. SAP Business
  Objects/ABAP Objects (workflow) events ]. Also these events can be configured/coded to get published when a certain condition/status is reached. Like when a Business Objects ( e.g. Puchase Order ) is created/changed an event PO.Create can be triggered. Relevant workflows / Functions/ Methods can subscribe to these events.
  
  Basically, ESME Services can listen to a particular event by subscribing to the event of an Object. Actually, this is the way current workflow system works. However workflow tasks have added functionality. Workflow is not just a messaging / alert mechanism but it also helps in completing a process when a series of people / applications are involved.
• or just as an external/internal notification [ e.g. Job events to start a job or ABAP Object events to trigger a method ].
• There are other more system/application specific [ e.g. Report events ] but not
  very relevant here.
  

I will keep an eye on ESME but unlike earlier attempts of SAP community to replicate Blog/Wiki applications, this one seems have a better case for replication.