Social Glass

Susan Scrupski recently wrote about how the likes of Tim Bray feel that Ruby on Rails is a great option for the enterprise. I couldn’t agree more with Tim. I’ve been working closely with the framework in recent times and also built some demos with it back in my consulting days. Once I got over the differences between Java and Ruby I began to see the magic of how Rails makes it easy to build web pages, REST services and interact with databases. A decent programmer can stand up a Ruby on Rails app much quicker than he can a Java or .NET app. Period.

There are concerns, however, over RoR’s ability to scale. Last year, Alex Payne, developer at Twitter, was asked “How has Ruby on Rails been holding up to the increased load?”. One of the things Alex said was “All the convenience methods and syntactical sugar that
makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise”. In other words, “magic” = “slow”.

But these are issues that can be solved with conventional measures. David Heinemeier of loudthinking.com points out:

I’ve said it before, but it bears repeating: There’s nothing interesting about how Ruby on Rails scales. We’ve gone the easy route and merely followed what makes Yahoo!, LiveJournal, and other high-profile LAMP stacks scale high and mighty. Take state out of the application servers and push it to database/memcached/shared network drive (that’s the whole Shared Nothing thang). Use load balancers between your tiers, so you have load balancers -> web servers -> load balancers -> app servers -> load balancers -> database/memcached/shared network drive servers. (Past the entry point, load balancers can just be software, like haproxy). In a setup like that, you can add almost any number of web and app servers without changing a thing.

Ruby on Rails faces the same scalability issues as other frameworks. The solution to the problem, then, becomes relatively standard. Share session information, load balance web servers, load balance application servers.

And let’s face it, enterprise applications will never need to contend with as many users as a web site like Twitter does. The largest organizations have hundreds of thousands of people. Not millions (and viral web sites need to scale to millions).

Given the speed of development and agility of the framework, I Ruby on Rails apps will increasingly disseminate across next generation enterprises - enterprises looking to implement Enterprise 2.0.

Only in San Francisco can you find advertising for open source software. SugarCRM is a popular open source Customer Relationship Management application. Good competitor to the likes of Siebel and Peoplesoft. I was walking in the lobby of a building in the financial district when I saw this. I must say it’s pretty cool to be in the land of technology and innovation.

I must say I’ve gotta love Jive’s new approach to marketing. I took a picture of something I received from them the other day in the mail - a condom wrapper. It’s hard to read (took the photo with my iPhone), but across the top it says:

“Protect Against: Sharepointitis, email clogging & blogules.”

Then below “Clearspace”, it reads:

“collaborate from top to bottom”

Jive provides a link to jivesoftware.com/condom where you can view these condom wrappers with better resolution. I like the approach Sam!

I’ve noticed that the ideas behind Enterprise 2.0 have remained relatively unchanged for a year and a half or so. Sure, we’ve seen the evolution of Andrew McAfee’s SLATES mnemonic to one called FLATNESSES by Dion Hinchcliffe. “SLATES” appeared in Spring, 2006, and “FLATNESSES” over a year later. Fundamentally the elements both are made up of are the same:

• Links
• Social Bookmarking
• Search
• Authorship
• Signals/Syndication
• Social Networking
• Folksonomies

And maybe that’s all there is to Enterprise 2.0 from a technology perspective. I suppose we could also talk about prediction markets and knowledge markets adding those to the mix. But I think we’ve exhausted all of the technical possibilities.

So I ask, is Enterprise 2.0 stagnating? What I mean is, is there anything else that needs to be thought out and developed, or is it time to simply start doing it?

I came across a post from Dion Hinchcliffe recently that talked about ideas for SOA architects in 2007 (ok, so it’s a year old). Dion talks about how Web 2.0 philosophies can be leveraged to enhance the effectiveness of SOA. The recommendation that stood out to me was “Deeply Embracing URI Addressability”, where Dion argues:

The hyperlink is the fundamental unit of thought on the Web and it should be in your service designs and (hopefully granular) schemas as well. Giving each discrete piece of information, every service, and all content a globally addressable URI instantly gives a service, and the data it carries back and forth across its interface, access to countless new consumption and reuse scenarios.

To illustrate how unique addressability might work, consider an organization that sells insurance to customers. Each customer is given an account number. The organization has an SOA strategy and decides to make use of REST (Representational State Transfer) to expose its information assets, including “customer” in an interoperable manner.

REST “strictly refers to a collection of network architecture principles that outline how resources are defined and addressed” (Wikipedia). It also makes use of the HTTP verbs POST, GET, PUT and DELETE (similar to database CRUD operations) to define what action to take on a given resource.

The insurance company develops a REST interface that sits on top of its CRM system. Customers become uniquely addressable by account number, as follows:

http://insuranceco.corp.com/customer/9886574

where “9886574″ represents the account number for a particular customer. A “GET” request (similar to READ on a database) to this URI might return the customer profile and claim history.

This is what Dion means when he says information should be uniquely addressable. Each customer has his own URI, which means behind the firewall other applications can reference a customer using this address. From here the possibilities are endless, where the intranet starts behaving like the internet. Information assets begin having inbound links, and this “democracy” so famously publicized by Google’s PageRank algorithm (where an inbound link counts as a vote) starts to apply not just to web pages, but to entities abstracted by services in an SOA (like “customer”). In this way information can be:

• Bookmarked in a social bookmarking system. Users include comments, like “Harry Young [customer 9886574] calls in every week and I’m tired of dealing him”. Users also tag these resources in the social bookmarking system, i.e. “disgruntled”, “customer”.
• Searched through an enterprise search engine. Adding “http://insuranceco.corp.com/customer/” to the seed of our enterprise search engine causes all customer information to be natively crawled and indexed.
• Referenced from wiki and blog posts.

As a blanket statement I’d say that any SOA architect should strongly consider exposing resources in this manner so that he can leverage the network effects and unintended uses that are achievable through unique addressability.  Good stuff Dion.