Social Glass

Joe McKendrick hit on a great point when he asked “Is Gartner telling us to ‘make sure there are adults in the room’ before launching into Web 2.0 activities?”. Joe goes on to point out that “All the excitement around various aspects of Web 2.0 may truly be a distraction from SOA”. Mashups, or web-based applications that bring together functionality from multiple systems to do something in aggregate that they do not do on their own (think twittervision), require a mature service oriented architecture from which said functionality can be sourced.

We talk so much about widgets and web oriented architectures (the visual aspect of SOA) that we forget about the significant investment that companies must make to deploy enterprise mashups. I touched on this a few weeks ago, but Dion Hinchliffe mentioned that an immature services landscape is a major barrier to mashup adoption. He writes “Mashups are predicated upon the ready preexistence of ready-to-use Web services and network APIs which are ready to be used to build on top of.”

In other words, if I want to create a Customer Search widget I’ll need to have first developed an interface into my customer database of record that, oh yeah, was programmed in Fortran in 1978. That costs money, and in my experience a lot of companies just aren’t there yet.

Shiv Sing makes an interesting point about the Microsoft investment in Facebook, where he says “What does this mean from an enterprise perspective? Quite simply that Facebook can get into the intranet market”. I couldn’t agree more. Susan Scrupski points out that Microsoft is very serious about Web 2.0 with recent deals negotiated with Atlassian and Newsgator to integrate their tools into Sharepoint.

Microsoft’s new association with Facebook will only strengthen its position in the Enterprise 2.0 space - that is if Facebook is actually willing to engage in the enterprise market. If it is, Microsoft, which is already entrenched in most of the Fortune 1000 companies, will be a good conduit through which “Facebook for the Enterprise” can be introduced. I’m going to be keeping my eye on this as it develops. Next year could be very interesting.

I’m a Java and C# guy. I’ve grown to be very comfortable with the two languages and associated frameworks (J2EE, ASP.NET), and can write programs that at least compile in each without having to search through the internet for examples. Hence my hesitation to learn Ruby - the language required for me to indulge in Ruby on Rails. But everybody’s doing it, and I don’t want to be left behind.

I decided to build a Ruby on Rails-based enterprise search application leveraging the Google Search Appliance (GSA) REST API. My aim was to show that A) Ruby on Rails is an agile framework leading to quick application development and B) the extensibility of the Search API (being that it can be leveraged from virtually any programming framework).

Here’s what I did:

I created controller class called Search Controller that manages the API invocation. This is done in an action handler method called on_search. This method invokes the GSA API, then converts the XML response into a REXML::Document object (part of the Ruby on Rails library.

url_escape is a nifty little method I found here that converts a search term like, say “technology integration” into “technology%20integration”. If you don’t do this things will break. params[:query] contains the search term the user enters into the search box on my search.rhtml page. Last the @search_results object is stored in the session and is a container for a collection of search results plus some global information about the search (like result_count and search_time). This object is bound back to my search.rhtml page to display the search results.
Next, I had to pull relevant information out of the XML response and add it to user-friendly objects that are then used to display the results on the view:

This method leverages ‘rexml/document’ to parse XML, i.e. search_response.elements[”GSP/RES/M”].text. “GSP” is the root node in the GSA XML API response document, and in this example I’m pulling out the result count, appropriately called “M”, inside the “RES” element under the document root. Parsing continues where I iterate through each search result, pull out the relevant information (snippet, url, title), add it to a SearchResult object, then add said object to the results collection in the SearchResults object (which, again, is stored in the session).

That’s it. In two quick and easy methods I can invoke the GSA XML API and parse its response into usable objects that I bind to my view. There is a lot that I’m not doing (i.e. good error handling), but I’ve at least proven what I wanted to. I’ve done this before in Java, and it took me less time to do it in Ruby even though I was learning the framework as I went.

I love Ruby on Rails.

“Wouldn’t it be interesting to have a way to measure the Social Capital in an enterprise?” This question is posed by Peter Riser where he outlines the idea of community equity over on his blog, Riser 2.0. Peter is working with a team building an application called “Customer Engineering 2.0″ (CE2.0) (recently showcased at the Sun Customer Engineering Conference in Las Vegas), and community equity is used to calculate a sort of user reputation based on four functional areas:

• Contribution
• Participation
• Skills
• Role

CE2.0 is an “enterprise facebook” application (and I don’t think it’s available yet) and looks intriguing. It’s ability to measure community equity will go a long way to encourage uptake as users compete for top equity scores. I’ll definitelyh be keeping an eye on this app as it seems very promising.

In a previous post I described an Enterprise 2.0 implementation roadmap. The last component in the roadmap is Enterprise Mashups. In a utopian world, enterprise mashups give the knowledge worker spreadsheet-like flexibility to dynamically create composite applications that suit his specific business needs. Companies like Kapow, Serena Software and IBM are building enterprise mashup engines, but none have reached this utopian state.

Dion Hinchliffe wrote a great post about challenges facing enterprise mashups. He identifies 10:

1. No Commonly Accepted Assembly Model
2. An Immature Services Landscape
3. The Splintering of Widgets
4. Management and Support of End-User Mashup Apps
5. Deep Support for Security and Identity
6. Data Quality and Accuracy
7. Version Management
8. Awareness and Realization of the Potential of Mashups by the Business Community
9. Low Levels of Support by Major Software Firms
10. Few Killer Demo Apps

In my professional life I’ve encountered obstacles around items 2 and 4 when discussing enterprise mashups with potential clients. We can show impressive demos, like IBM’s QEDWiki, but we’d need a seriously mature SOA to build the “widgets” a knowledge worker would use to create such a mashup (issue 2). And Dion asks who’s going to support these things once they break? “The IT department? The business units? Using what tools” (issue 4). Good question.

At the end of the day an enterprise must have a strong SOA initiative and support from IT before the value proposition behind enterprise mashups can be fully realized.