Disclosure: The author, Dennis Howlett is part of ESME’s core team and helps to promote/evangelize the project. TouchBase Blog welcomes those affiliated with an application to guest post about their application, provided there is full disclosure of their association and a distinct effort not to write advertorial copy. Submit such requests, leads and tips for guest posts here.

My last post discussed the value of eventtrack as a service that sits on top of many microblogging and content services. It allows me to ‘track people in the moment’ and so get a feel for what is happening at specific events. But what about solving real world business problems? The research consistently suggests that 80% of what knowledge workers do revolves around problem solving of one kind or another. In times past, we would turn to Joe or Betty as the ‘go-to people’ who knew this or that system and could instantly pinpoint a solution. While that is still possible, it is no longer optimal, especially in large, distributed organizations.

We all use email, yet the amount of material coming at us is overwhelming. We don’t have the attention bandwidth to parse the flow let alone spot the digital red flags business colleagues may be waving in our direction. We certainly don’t have discovery mechanisms that will help surface the right solution at the right time. The question then becomes, “how might microblogging help and differentiate against other methods?”

In the last few months, we’ve seen the emergence of many contenders for enterprise microblogging services aimed at solving this problem. Most start with the premise that microblogging behind the firewall needs to be a private affair. In my opinion, most other services are no different to private Twitter and if that was all there was to it then we’d be done. But it isn’t.

Microblogging behind the firewall is a whole different world to the public fire hose that is Twitter, and to that extent, that’s where the similarity ends. However, that doesn’t mean we can’t take some of the concepts behind Twitter and apply them to new services. For example, the ability to discover others through the ‘follower’ connections people make is a valuable element in Twitter’s proposition. It taps directly into the idea that networks have intrinsic value. How might a group of developers go about creating something that has the utility required? Why crowdsource from within an existing community? That’s what happened with ESME.

How and Why We Started ESME

While the full story is outlined here, the short version goes something like this. A bunch of SAP Mentors were idly ruminating on the topic at Plurk. Within a matter of days, the germ of an idea exploded into a full-blown project with contributors coming in from India, Peru, Norway, Austria, UK, Spain, Germany and the US. It doesn’t get more distributed than that! We were off to the races. Wind the clock on a couple more days and one of the team suggested giving the project a goal of entering SAP TechEd 2008 DemoJam at Las Vegas, Berlin, and Bangalore. That gave us less than three months to go from idea to product.

In time honored enterprise software development tradition, we lashed together a breathless promo video (see above) and started cracking code. Unusually, the development team brought in business process experts and business user types (like me) right from the get go to help sketch out the business scenarios we’d need to consider.

Our principle design goal was to develop something that went way beyond private groups. We needed to think about how a microblogging service might sit within identifiable business use cases. That’s because business will only buy into a solution where there is a clear and obvious benefit. In other words, we were looking to provide the context for a solution that delivers faster, better, and cheaper (yes, you can have all three) solutions to business problems. Rather than go for a broad brush solution, we decided early on to tie what we’re thinking about to SAP. Why?

• The group are mostly SAP Mentors, so why go elsewhere?
• The team understands the different SAP systems and especially those used by large enterprise
• There’s a community of 1.3 million developers to tap into
• SAP touches around 50% of the world’s IT at some point.
• The SAP customer community represents a universe of potentially 12 million users today
• SAP acts as a natural magnet for developers who want to do ‘edge’ stuff
• SAP’s Imagineering Group which deals with ‘edge’ development could become a locus for attention
• There was an opportunity to tap into new development environments like Adobe Flex, AIR and frameworks that are designed for this type of application
• Developing against SAP meant that we could automagically take advantage of existing enterprise class security and process models with which enterprise users are familiar and comfortable

All these factors meant that we are able to directly address the largest ecosystem of packaged business application users on the planet. They would guide what needs to be done rather than us scratching heads.

What We’ve Developed

The initial scenario was one where a sales portal was failing and users were going offline to manually complete sales orders. The person running the portal was unclear how to solve the problem and needed to reach out to co-workers for a solution. That scenario has been modified, but you get the general picture.

Developing ESME to the point of getting an alpha release was challenging, largely because of the time constraints but it got done and was generally well received. While we had high hopes for DemoJam Vegas, ESME didn’t win. But we learned a great deal. It is clear, for instance, that the SAP geek community is not familiar with microblogging, so the concepts were not understood. We reckon maybe 5% of the 6,000 attendees had a sense of what Twitter is about.

That is a common problem for edglings and serves as a timely warning for those expecting these services to simply proliferate inside the enterprise. Adoption is an issue. Yet we have found that certain large organizations are very interested in taking this forward. I can’t name names, but we have received enthusiastic feedback from five major groups and are now in the process of rolling out pilots where we expect to see business use cases as the trigger for adoption and feedback.

What else did we do? Most of this is not immediately obvious because we’ve gone to great lengths to hide complexity from the end user while making it as easy as possible to onboard organizations that wish to test ESME.

• ESME is currently open source. You can get the code, hack it and play around to your heart’s content. If you want an intro, then check out this tutorial. But don’t expect support today. We’re still working on a business model which is much more complex than simply applying a per user/per month license model or a supported option.
• We used OpenID rather than username/password because that is inherently more secure. Initially I was against this idea because I’ve found OpenID a bit clunky. Today I wouldn’t have it any other way because it saves me so much effort.
• We developed clients for the web, AIR, SAPGui and SAP’s Web Dynpro client so that users have choice. A mobile client will come in due course.
• We have track so people can follow topic tags.
• We are developing the concept of actions so that people can choose to take a topic offline to another medium such as email.
• Users can pull whole conversations out of the flow to see the context.
• We are working on managed groups so that where necessary, Chinese walls can be erected inside highly regulated organizations.
• We have audit and traceability, vital for SOX and other forms of compliance.

What’s next?

We continue to develop business use cases for ESME and offer those as development jump off points both internally and externally. We’re listening to early users as a way of gauging what needs to be done, setting priorities, and creating a sensible roadmap for the future. We’re thinking more about how ESME can be embedded into business processes beyond simply mashing it up into a desktop or web client.

Finally, while we remain closely aligned to SAP and its community and have retained the karma that a committed group of individuals can generate, ESME can be used inside other technology environments because the major components are modularized.

Dennis Howlett is a full time researcher, consultant and blogger on enterprise software whose primary outlets are at ZDNet. He is part of the ESME core team.

Related articles by Zemanta

• Is the Enterprise Ready for Microblogging Tools like Twitter?