We've had several customers lately stuck in the same boat: they exist in a conservative industry (insurance), they have a large set of fixed costs for their IT needs (AS400s), and it has been years since they've been able to add new features to their software (COBOL.NET never took off). These are exactly the kinds of teams and problems that have resisted new technologies in the past; the inertia of the current system and its sunk costs were just too high. Incremental changes didn't seem cost effective, or even possible. That is no longer the case.
Working with these customers, we've been able to take advantage of Ruby on Rails and agile development processes to leapfrog their existing infrastructure and several generations of intermediate enhancements to bring them to a modern infrastructure with newfound opportunities for feature enhancement. The key is to leverage the real value of Rails (simplified, productive development environment and cheap, easy deployment) while simultaneously avoiding the siren song of Web 2.0 (flashy UIs, needless frivolity, the urge to redesign everything).
In order to succeed at one of these leapfrog projects, you have to focus on the core business strategy. We have been lucky enough to work with customers who understood this to the bone: first, do no harm to your existing users. Next, quickly eliminate needless costs. Then, and only then, start dipping into that well of pent-up feature demand. Without a deep commitment to this set of values, such a project is likely to suffer from cost overruns, angry users, and lost revenue. In other words, the 75% scenario for corporate IT investments.
Insurance companies with green screen apps may have difficulty adding new features to their applications, but they generally don't have disgruntled users. That's the dirty little secret of our industry; green screen apps are usually pretty darn fast. They aren't simple, though. They are designed for trained users, users who have long since added their app usage patterns to their muscle memory. Anything that causes them to have to think about how to use the application is going to up the GrouchyMeter(tm) another notch. So when a company sits down to think about how to bring the app into the modern world, they should be thinking about the infrastructure, and what additional features a new infrastructure might be enabling. The only time they should be considering modifying the current user experience is if they have historical feedback about necessary changes.
The worst thing you can do to an account representative, billing clerk, claims processor, etc., is slow them down at their required data tasks. You can make it twice as bad if you do it just to make the application "prettier". So our customers resisted the urge to "bring in the designer" and "make the app more Web 2.0". The focus was on recreating the green screen experience through the browser, including field layouts and keyboard shortcuts, in order for the experience to be as close to identical as possible. Clearly, we don't force it to look exactly like the green screen application. It should use modern web design sensibilities as much as possible. Just don't upgrade for the sake of upgrading.
Rails brings simple Ajax and JavaScript integration (and testing) to the table, making it simple to focus on the user experience and the back-end processing at the same time.
Next, focus on the cost savings inherent in the new effort. In the case of our customers, this came down to two items: the ongoing hardware and maintenance costs of the AS400s and the payroll costs of the programmers knowledgeable enough about RPG/COBOL keeping the system alive. As a team, we kept our focus on recreating existing functionality in the new architecture, using standard web development techniques, Ajax, and some custom JavaScript to keep the user experience as close to the original as possible. The only new features added at this stage were infrastructure upkeep features, like automated deployment via Capistrano, and database upkeep tools for dealing with their new open source relational database. Nothing in the historical backlog of user requests was addressed at this point; that came later.
By switching over to Rails, they were able to replace the expensive monthly maintenance of their AS400s with commodity servers running an open source OS (Linux, natch). What's better, they have offloaded the actual hardware maintenance entirely to a hosting company, thus enabling them to refocus parts of their IT staff on higher value tasks than mainframe upkeep.
Additionally, they can plan ahead for a smaller investment in programming talent since Rails developers and Linux sysadmins are cheaper than RPG/COBOL programmers and AS400 administrators, respectively. This means that we helped them achieve both an immediate cost savings, and a projected accelerated cost savings by shifting the infrastructure over the course of a single project.
Finally, with a modern software architecture in place (with access to things like continuous integration, unit testing, etc.), the teams can finally begin addressing the years worth of pent-up feature demands. By conscientiously avoiding new feature development until after the existing functionality was deployed and usable, the teams were able to make new feature development decisions funded by the immediate and projected cost savings of the new system. Instead of agonizing over feature requests in the face of a vague notion of costs, they could spend the new savings more concretely on advanced features.
Once again, choosing Rails had an immediate impact on our customers. We were able to address several ancient feature requests quickly and inexpensively, because while they didn't fit particularly well in an old green screen style application, they were perfectly suited to modern web applications, and of course, we find Rails to be the most productive environment for quickly building web applications.
Over several of these projects, we've identified a set of core technical themes that have helped the efforts succeed.
Teams with legacy hardware and software infrastructure shouldn't be waiting around in fear of incremental change anymore. Modern, open source development tools and deployment environments are easy enough to migrate to that it now costs more to continue supporting the existing legacy system. As long as your team keeps a laser-like focus on achieving equivalency before enhancement, there is no good reason against moving forward. Don't just sit around on a pile of 1975—the tools are available to modernize your codebase and move your organization ahead.