Ruby and Rails Get Enterprise-Ready
In the recent, rather entertaining discussion between James McGovern and the rest of the world, about Ruby and Rails being enterprise-ready or not, a lot of emphasis was placed on the speed of development that Ruby and Rails may offer. Anne Zelenka correctly stated that speed of development isn’t all that important in an enterprise environment.
In a way it is sad, but big enterprises, large corporations, might not care much whether an application could be developed with Rails in half the time it would take with Java. Development (I’m including design here) is only a small piece of the entire implementation of an application. There’s functional testing to be done, training of end-users as well as support staff, setting up and maintaining the technical infrastructure for development, test, acceptance and production environments, data conversion, and overhead costs like project management, meetings, planning, the works. Things you can happily do without (more or less) if you’re a web startup, but not so for your average enterprise. (I’m not saying an enterprise couldn’t cut back on them, but most just don’t or won’t — it seems to be a given when you’re entering the enterprise world). And then of course there is application maintenance. Long ago I learned that, as a rule of thumb, application maintenance costs 20% of application development — yearly. That’s 20% of the costs of design, development and testing. Which means that, if you keep developing new applications, your yearly planning slowly fills up with maintenance work.
Instead of just focussing on the amount of development time you might save on, why not focus more on the reasons why development time can be saved on? For example, one of the reasons developing in Rails is so much faster, is the principle of ‘convention over configuration’. I think that might hold some attraction, as it is something that many enterprises are already trying to achieve, for instance with software factories: standards based coding. As a by-product of this, you need less code for your application, which also means less code to maintain. Another example is the shorter build cycle (at my current Java project, the “record” for longest build time stands at 1.2Ms). And how about prototyping? You might actually sit down with an end user and prototype view, model and controller in a Rails application. I’ve never seen that done properly in a Java environment. Prototyping often results in better user acceptance. Or test driven development, which in Rails is not an afterthought as it is in Java. TDD can prevent many unnecessary bugs, so also means less maintenance. (At the moment I am on a project where unit tests “are not needed because all code is generated with OptimalJ.” Yeah right.)
If Ruby and Rails can solve problems that enterprises currently have in their development environment, and save time and money in the process, they could become more interesting for bigger companies.
Of course, there are also reasons why enterprises may not want to use Ruby and Rails — but that’s for another post. Or maybe I should leave that to James McGovern.
Disclaimer: I am neither an enterprise architect, nor a thought leader on that subject. My opinions are based on my work for Dutch enterprises, which may not be comparable to U.S. enterprises. And I’m talking primarily about developing web applications, where Rails excels.
2006-03-27. 8 responses.
Becoming Enterprise Ready…
Danny a dutch blogger said something intriguing regarding software development in Ruby that should be considered……
I don’t know if it’s correct to say speed of development isn’t important in an enterprise environment. It is one component of the total cost of ownership of an application, and every component of cost is interesting to executive management. Larger companies may have over a hundred development projects to carry out during any given year, and a limited staff to do them all. Shorter development times would certainly be of interest.
If you’re looking for ways to explain the value of RoR in enterprise computing, I suggest you approach the question from the point of view of management. They are not interested in the technical reasons why development time can be saved. They are only interested in cost and value.
Several characteristics of RoR contribute to cost control, and may be of interest to managers who have decision-making authority regarding the choice of development tools for enterprise software. You mention several of them in your post – in particular, ‘less code’ and ‘convention over configuration’ directly lead to reduced TCO, and management should be able to relate to them.
Another benefit is the ease with which applications can be made to comply with enterprise standards. By customizing template code, you can ensure all the RoR applications have the corporate look and feel, propagate and handle exceptions in a consistent way, call on enterprise facilities such as single sign-on as required, and many other details that collectively result in substantial TCO savings, especially when you consider the costs of supporting many enterprise applications.
The advantages of live prototyping in front of a customer depend on the corporate culture, the customer’s attitude toward and past experience with prototyping and iterative development, and the nature of the problem at hand. RoR’s ‘generate scaffold’ script may not actually give you the sort of functionality the customer is having difficulty with. They probably understand how a program can access and database and display a page. Where prototyping is helpful is in more complex scenarios where the customer cannot clearly visualize or explain his requirements. I’m not sure this is an especially strong selling point for RoR in the enterprise, because it may not be all that easy to prototype something like that immediately in front of a customer. Walking through a workflow using a whiteboard may actually be more effective in that case.
You mention software factories. The basic model that has been gaining ground is a service-oriented architecture to provide enterprise-wide shared services (probably based on Web Services), plus tactical application development tools that can orchestrate those services and provide customized value-add functionality for end users (probably based on familiar web technologies). RoR fits perfectly into the latter role. This could be an approach to ‘selling’ RoR in a company that is building a software factory.
Is James McGovern too Enterprisey?…
I have been noodling several things said by David Heinemeier Hansson and James Robertson who are co-Presidents of my fan club and their interesting outsider looking in perspectives on the enterprise. Felt it was not only important to respond to their…..
Would love your thoughts on this blog: http://enterprisearchitect.typepad.com/ea/2006/04/enterprise_arch.html
So who will be responsible for THE maintenance…
Only considering that all dynamic language programmers are not loved for their debugging skills….
Byee byeee rails… Enterprises do not need another nightmare like CGI
I also agree its somewhat too bad that big enterprises may not value shortened development time as much as they could. It kind of leads off into the discussion about the whole “If Rails/Ruby will ever become mainstream” thing. Just as DHH, I would much rather it NOT be mainstream.
Don’t have such a low threshold for measuring success. Success is Java, .NET, XML, Web Services, SOA, etc. Ruby has potential and an upward trajectory but can’t yet be called successful.
In terms of getting large enterprises whose primary business model isn’t technology involved in Ruby benefits Ruby by the simple fact that this demographic represents 90% (The masses) of all IT folks. More importantly, this same demographic has 590% more capital than the 10% that Ruby currently has. Capital allows folks to accelerate the growth, features and adoption of all the hard work the Ruby community put into it.
You should noodle this thought and even if you agree slightly, you should amplify it in your next blog entry…
Software Development Life Cycle…
Some portions of this article sounds interesting. May be you have some links where I could read more about this topic?…