Enterprise’s interest and adoption of Web 2.0 technologies grows each day. Much has been and is being written on this trend; simply google “web 2.0 enterprise” and you will have lots to read. My interest is the significance and impact of this trend.

I think enterprise systems have historically worshipped data: ERP, CRM, knowledge management, and data warehousing are applications that capture, mine and organize data. While of course such information is important, data and the “system” tend to be the first class citizens at the expense of the interests of users (i.e. people).

By contrast, I think Web 2.0 applications are people-centric. Social networking has informed many new models of how to organize information and anchor it to people. The data exists to support the person, whereas the reverse feels true at times in enterprise. Furthermore, user experience and satisfaction are emphasized, if for no other reason than pragmatic market survival. Enterprise software rarely makes user satisfaction a primary goal.

I think enterprise software will evolve to reorient data modeling around people and focus on the quality of user experience. The legacy of being data-centric is based on the assumption that workers are more productive if provided better information. While I don’t challenge that assumption, I think the implementation of said principle has presumed volume and completeness of information was the key. I think Web 2.0 has shown that data accessibility, which is driven by data structure and usability, is more important.

Application integration has been challenging in enterprise. At times it was just expensive and in other cases simply didn’t work. Technologies like CORBA or DCOM and the more recent SOA/ESB/SOAP approach, while ranging in adoption, haven’t delivered great results, in my opinion. But most IT shops have tried to implement these standards nevertheless.

Mashups have demonstrated application integration can be relatively cheap and simple. Where numerous enterprise integration have spent tens of millions of dollars for mediocre results, it is fairly common place for Web 2.0 applications to share data, expose API’s and leverage other applications based on modest effort. REST, JSON and simple XML/HTTP APIs are proving more effective and attractive than the presumed standards of SOAP in enterprise.

Integration has always been a pain point in enterprise and I think Web 2.0′s approach can provide some insight for tactics that make it more economically and technically viable.

Many enterprise IT groups and ISV’s are already looking to exploit and borrow Web 2.0 technologies and experience. While I think this will result in lower development costs, better applications and probably higher productivity, I don’t think the trend will simply consist of enterprise visiting the land of Web 2.0 and bringing back trinkets from its travels.

I think the line between consumer Web 2.0 and enterprise will blur and fade, though not completely. Many of the same people who are users of enterprise software at work, are users of Web 2.0 at home. And they already use the same applications in both arenas; Google Maps and Wikipedia are just two examples of such applications.

Many sales groups already use LinkedIn to generate and pursue leads. (The salesforce.com AppExchange has applications to integrate with LinkedIn.) Google Apps is frequently used by office workgroups to collaborate on documents instead of using Microsoft Office.

Ten years ago email was typically a discrete application; at the millennium “Send As Attachment” functionality was commonplace in applications. Web 2.0 technologies such as RSS feeds are already being integrated into many applications and I imagine the ubiquity of other Web 2.0 elements will continue. I think we are quickly approaching a world where the tools used at work and at play will frequently be the same.

Chris’ recent article has stirred up quite a debate (see comments) about Rails and whether you’d have to be drunk to suggest using it. I’d like to expand a bit on Chris’ point and talk a little more about how we approach technology choices and where/why we use Rails. This article’s working title was “Why Rails (Mostly) Reigns Supreme (at Pivotal)”

Personally, I’m very suspicious of any argument that says one technology will dominate all others. It’s like saying that eventually the only tool anyone in their right mind will use is a 3/4″ socket wrench. I don’t believe this is Chris’ argument, but it was clearly taken that way.

At Pivotal we use a number of technologies, and in fact most web projects involve at least four languages. We generally use Ruby (though not always Rails, for general server-side web work, Java (Lucene, etc), extensive JS in the browser (often more lines of code than the Ruby), and C bits (Ruby C libraries, mongrel, etc) where performance matters. As well, we aggressively take advantage of Amazon’s web services (ec2, s3, and sqs). I have some knowledge of their implementations, but realistically it doesn’t matter.

The unifying theme here is Business Value. We choose technologies from our toolbox because they maximize the value we provide our clients. If Ruby/Rails doesn’t maximize business value, for example when a client already has 50 expert Java developers AND a million lines of Java invested in a “Platform”, we don’t use it.

Today a large part of Pivotal’s business (the part I’m involved in) is building web-based applications for early-stage start-ups. These companies in turn are trying to prove out novel business concepts. They don’t care about which language we use. They care about putting good software in front of users quickly so that they can make any necessary course corrections and get their business off the ground before the money runs out. This is where Ruby/Rails comes in [1].

As Agilistas
we’ve always delivered software early and often. But, Ruby/Rails gives us the ability to deliver much more, much more quickly. As Chris points out, this makes it cheaper to experiment, and therefor more likely that these businesses will succeed.

To borrow a Perlism, there is generally more than one way to do it. Parker’s corollary is that there’s often a best way. Having built quite a few applications in Ruby/Rails, our experience is that it is the best tool for the job it does.

[1] There’s are other arguments to be made about process, business value, Rails, and the relationship between, but we’ll save that for another post.

I believe that Ruby on Rails hallmarks the next era in software development. But before I explain the scope and significance of my claim, a little background and history of software development is necessary.

The C programming language marked a new generation for software development. It was a high-level language, compared to assembly, which made software development a viable investment on an unprecedented scale at the time. Unix was developed with C and it created new opportunities for computing; new markets and potential beneficiaries of technology were born with the advent of Unix. (While there were other languages at the time that also opened new markets for computing, such as Pascal, I am using C as the “poster child” for this era.)

But application development was very expensive with C. There were many bugs, sustainable development was hard and overall the costs made it difficult to realize a return on technology investments. (Unix, because of the scale of its adoption, made the return worth the pains and costs.) Many tried to develop various applications and found it daunting and not economically viable with C.

Java brought on the next revolution. As the next generation, higher level language, Java caused a new market to explode: enterprise development. Before Java, IT development was fairly limited to few companies with very large budgets. While there have been many incredibly expensive Java projects, the number of participants in computing erupted; even small organizations with a few employees invested in IT projects.

While Java development had a lower cost profile compared to C, it still was high. This culminated in the mid to late 1990′s with the Standish Group’s Chaos Report(first published in 1995). This landmark report noted that 5/6 software projects fail. It also described a variety of other disturbing statistics. In short, many organizations were investing in software and most of those investments failed miserably.

The rise in outsourcing in the late 1990′s and early 2000 was in response to the economic environment of software depicted by the Chaos Report. I think most of the industry was throwing up their hands — “If we can’t figure out how to build software, let’s make projects cost less and make a portfolio management play.”

But outsourcing proved not to be a panacea. In a somewhat parallel track from enterprise, and in the aftermath of the Web 1.0 bubble, a new interest in consumer oriented applications took hold early this decade. PHP marked another new era in software development.

The LAMP stack (Linux, Apache, MySql, PHP) offered a new paradigm for development. Thousands of small, focused web-based applications sprang up. Two developers in a few months were accomplishing what twenty developers couldn’t achieve in a year. Pragmatism drove ideas and it was being demonstrated that small teams could be incredibly productive in short time frames. The economics of development changed once again.

But PHP has problems. First, it is limited to website development. This makes it hard to adopt for general enterprise software, as integration can’t be effectively done with PHP. Second, it has provided a great option for first version websites, but at least in my opinion, PHP does not provide for a robust language/environment for sustainable software development; this is a must for enterprise.

The breadth and volume of topics to which software is being applied is growing. This creates tremendous pressure for the economics of software to be manageable. Furthermore, the line between enterprise software and consumer-oriented web 2.0 is getting more and more blurry. I think the market needs and demands a technology option that can be used by both markets and is economically viable.

This brings us to Ruby on Rails. Ruby is an elegant and mature programming language. Object-oriented geeks tend to love it and feel empowered to create software with it. It is also a disruptive innovation (as described by Clayton Christensen) that changes the economics of software; Rails brought forth a new vision: opinionated, convention based platforms can dramatically reduce the cost of development. I think Ruby/Rails can and will replace Java as the language and platform of choice for software development in the enterprise and will similarly establish itself as the premier option for Web 2.0, cementing the bridge between both markets.

There is much work to be done on Rails though. There are scalability issues and integration patterns are immature (on average, at least). But compare Ruby/Rails to where Java was in the 1990s and I think Ruby/Rails is much further ahead in its technology and adoption lifecycle.

And what about the alternatives like Python and Django? There is some debate over this question and that can be a series of posts by itself. For the moment, I will address this with the following observation: at Pivotal we have many developers who know Ruby and Java and the same developers are several times more productive in Ruby. In this comparison, my money is more on Ruby compared to Python than Rails compared to Django; I can’t see how we can be as productive with Python as we are with Ruby.

The momentum of Rails is not be underestimated. Geoffrey Moore, in “Crossing the Chasm”, describes how markets need, elect and will support a market leader. The need for manageable software development costs, both in terms of upfront and sustained development, create tremendous pressure, that combined with the current momentum of Rails, will drive forward the adoption and development of a rich Ruby/Rails ecosystem. As Rails becomes more and more established, its position is harder and harder to derail. (Sorry, I couldn’t resist the pun.) Think about Apple’s iPod: it isn’t enough to offer a better mp3 player as the market has invested in an iPod ecosystem of speakers, docks, cases, etc. Similarly, Rail’s position only continues to be secured.

In short, as is the case with many things, economics will dictate the needs of software and will establish the supremacy of Ruby and Rails.

And you thought it helped us be more productive, ha!