ADS specializes in using Ruby on Rails to build advanced, scalable, database-backed web sites for organizations of all sizes. Find out more at our website.

Measuring Return on Investment (ROI) is interesting as there are a few approaches, many of which are determined by how a company defines and determines returns and costs. Investopedia defines ROI as, “A performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments,” and uses the following equation to measure it:

ROI = (Gain from Investment - Cost of Investment) / Cost of Investment

Last weekend’s Managerial Accounting class provided these additional equations:

ROI = Operating Income / Total Assets

or

ROI = (Operating Income / Sales) - (Sales / Total Assets)

where

Sales Margin = Operating Income / Sales
Capital Turnover = Sales / Total Assets

Sales margin focuses on profitability - how much operating income division earns on every $1 of sales – whereas capital turnover focuses on efficiency - how efficiently a division uses its assets to generate sales.

Can we measure the ROI of any software development project in a seemingly simple equation? Hard benefits that result in a measurable cash benefit easily fit. Examples of hard benefits include increased sales, a measurable increase in employee productivity, and lower overall software maintenance and license costs. The numerous “soft benefits” aren’t so easy. In the article “Use ROI analysis for business software investments,”Microsoft lists soft benefits as:

• Productivity savings
• Improved quality
• Improved customer, employee, or partner satisfaction
• Improved information
• Reduced risk

How do you measure the ROI of Ruby on Rails?

You measure the ROI of Ruby on Rails the same way you measure the ROI of any software development project. Continuing with the Microsoft article, there are other costs involved above the actual development work. The biggest one mentioned is enterprise software deployment, which includes:

• Vendor license or development costs
• Vendor maintenance
• Implementation services
• Future-year services
• Hardware
• Systems management
• Training

Let’s address these point-by-point.

Measurements of Cost

Vendor license or development costs

Ruby on Rails is open source and free. The Rails application servers - Mongrel, Thin, Passenger - are open source and free. Apache, Nginx, and Lighttpd are open source and free. MySQL and PostgreSQL are open source and free. NetBeans is free. Linux is open source and free. All of the paid tools that might be used, including VMWare Fusion (my favorite), Parallels Desktop, TextMate, and Aptana Studio can each be purchased for less than $100 each. The highest part of the development cost is the development team, without which you have nothing.

Bottom line: license costs are non-existent, and with the development team, you get what you pay for - don’t go cheap.

Vendor maintenance

Ruby on Rails stresses convention over configuration. This means that an application development by one team will structurally look the same as an application development by another team. With the additional use of the model-view-controller (MVC) approach in Rails, and testing baked right in, maintenance costs (bug fixes and upgrades) are greatly reduced. Furthermore, using development methods such as agile development with Scrum can catch bugs sooner and ensure you get the features you want. Unlike licensed software where “maintenance costs are usually calculated as a percentage of the initial license cost,” this is not the case with Rails applications.

Bottom line: maintenance costs are low and a function of how much you want to add to the application functionality wise rather than a percentage of license costs.

Implementation services

Implementation services include the deployment of software into an enterprise. Ruby on Rails is used for web applications, so deployment time is greatly reduced. As everyone has a browser on their computer, whether they are using a Mac, a PC, or a Linux box, they are ready to go once the application is on a server and made available. Deployment options for Rails are numerous. Our enterprise clients have internal servers (development/testing and production) that their IT departments maintain, and our non-enterprise customers use hosting solutions including Morph, Amazon EC2 (using RightScale) Rails Machine, Engine Yard, and Slicehost. We can get an application deployed to Morph in 10 minutes or less, and 30 minutes or less on Rails Machine.

Bottom line: implementation (deployment) of a web-based Ruby on Rails application is next to nothing.

Future-year services

Future-year services include adding features to an existing application. As mentioned above under vendor maintenance, the use of convention over configuration, baked-in testing, and MVC make adding additional functionality simpler. What this really comes down to is the complexity of the new feature rather than the complexity of hacking, extending, or attempting to integrate with a packaged application.

Bottom line: it is generally easier to add functionality to a Ruby on Rails application.

Hardware

On the client side of this equation, there is no additional hardware required to run a Ruby on Rails application. If you have a web browser on your computer, which everyone does, you can use a Rails app. On the server side, hardware requirements depend mainly on two factors:

• What the application is doing - is it a CRUD application, are you transcoding audio and/or video, or are you front-ending a data warehouse?
• The amount of traffic you need to support - do you have 10 internal users or a million external users?

Bottom line: the amount of hardware required to run a Rails application depends on what the application is doing and the number of users you need to support.

Systems management

Web applications can run from a simple administrative interface for a database to a large-scale, multi-user system that does all sorts of great things. The more the application does and the more users it needs to support, the larger the potential management costs. I say potential because I have heard of small teams supporting huge applications. For instance, Wikipedia has 2 systems administrators, and YouTube has a team of 2 sysadmins, 2 scalability software architects, 2 network engineers and 1 DBA (database administrator) to support the serving of 100M videos per day. Rails applications are no different. One of our clients, Pediment Publishing, has a team of two (soon to be three) that supports a Rails application that sees 200K+ hits per day plus 2K+ daily photo uploads. All of their servers - load balancers, app, database, upload, and worker servers - run on Amazon EC2. If you choose the hosting route your support costs can be close to zero as that is in the hands of your provider. Ultimately, as with hardware, the amount of systems management required depends on the requirements of the application.

Bottom line: many companies have IT departments adept at managing server-side applications and infrastructure (servers, databases, network equipment, etc.) so the addition of Rails to the stack has minimal impact. Outside of that, it depends on the requirements of the application, however a minimal team can support a large application.

Training

The best designed software is highly intuitive, requires no manual, and requires no training of end-users. Many applications do not fall into this category, and on the people side, many people don’t care to learn everything an application does, they just want to know what they need to know to get their job done.

For us, our clients come to us because they have an idea or a problem, and they need a solution. They know how they want it to work from the user standpoint. We make it work from the code standpoint. By using agile development with Scrum, we bring our clients, and many time the end-users, into the process. As we add features they learn how to use them, and many times dictate how the features will work (again from the user standpoint). At the end, if training is required, it is very minimal.

Bottom line: using an inclusive development process can bring training costs to near zero.

Rail’s Affect on the Bottom Line

Rails has a hugely positive impact on the bottom line of a business. Open source and freely available software, low to near-zero maintenance, implementation, systems maintenance, and training costs keep total costs down and ROI well into the black. The main investment goes into the development of the product itself. Invest in quality and the return will be great.

Keep up with everything going on with Atlantic Dominion Solutions by subscribing to our monthly newsletter.

Share this post

Related Posts

• Let Reality Guide Your Project
• Transparency Comes from the Top
• Launch Your App With Revenue in Mind