The Grass Is Greener On The Enterprise Side

James McGovern recently talked about large enterprises and why they don’t care about Ruby. He touches on something I’ve noticed in consulting for large enterprises here in New York CIty.


There’s no doubt there exists an invisible wall between the web community and Web 2.0 startups that enjoy using technologies that are more grass roots than Big Corp (Ruby/Rails, Ajax, MySQL, PHP, CSS, etc.) and traditional business that is still heavily reliant on your classic “enterprise” platforms (.Net, Java, Oracle, SQL Server). I think there are a few reasons behind this.
First and foremost, the decision-makers in large organizations can’t miserably fail if they pick a vendor and technology that is widely marketed, established and recognizable. If a Microsoft product fails, nobody will their MIS director “how could you pick them?” In contrast, if they choose some open source XML database and it fails, he’s going to feel the brunt of a backlash on that decision. Risk aversion is already rampant in large enterprises and many idiotic decisions are made because people are too conservative with their choices. Throw some homegrown platform into the mix and you’ve got chaos in their world.
Within the enterprise arena, building is just the beginning of an application’s life span. Once released into the wild, maintenance, upkeep, updates dominate both time and money. Large organizations need the peace of mind of knowing that their is a large player behind their solutions; that their people are not only competent but also replacable with others (compare replacing a .Net developer with a Ruby developer); and that many of their tools and libraries are not their own but rather products that have been proven elsewhere. Agile development has its merits, but agile maintenance dominates the enterprise work day.
A final point worth mentioning is the level of complexity often associated with Enterprise applications. Heavy, complex transactions, Sarbanes-Oxley compliance, heightened security requirements. These are all important requirements that simply can’t be slammed through with a three or four developers without a spec in sight. Documentation is a critical because it’s not only a means of communication but an artifact that survives the departures and arrivals of different participants. You can’t give a five minute walk-thru of apps of this size.
With all that said, I think enterprises have a lot to learn from agile, web 2.0-style development. The focus on usability. The spirit of “just get something done” that can help offset the common paralysis that exists within these organizations. The ability to look at technology as a means to solution, rather than a shopping cart full of shrink-wrapped vendor products. These are all important lessons to be learned within the enterprise.
One of the things we’re seeing today is the bigger players (IBM, Microsoft, Sun) embracing (i.e. “packaging”) these trends and providing them to their customers under their own banners. IBM has done a great job of bridging the Linux and Java communities to the enterprise. In the end, I think that’s what this is all about: relationships and trust. These organizations have relied upon and want to continue to rely upon their partners to help them make decisions. Let’s not forget that technology for most enterprises is a services group. There is no room for experimentation and renegade development efforts that “might fly.” They just want stuff to work in a predictable (read: boring) way.
So the Ruby fans shouldn’t feel bad if it doesn’t penetrate the enterprise. Big business is a pretty boring place. It’s more fun to play outside anyway.

3 Comments The Grass Is Greener On The Enterprise Side

  1. JD on EP

    Enterprise requirements

    Enterprise requirements: Richard Ziade sums up the practical angle behind the whole controversy over last week’s James Gosling quote about how “php or ruby don’t compete with java”. Rich mentions the “nobody got fired for buying IBM” line, where the in…

    Reply
  2. James

    We practice agility (as in manifesto) every single day. You may have noticed from my blog I am one of the biggest advocates of agile methods and even speak publicly on it.
    My attack isn’t on agile methods, it is on the agile practitioners. They are not necessarily one in the same…

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *