Insurance on Rails

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).

Focus on Core Values and Return on Investment

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.

Don't Fix What Ain't Broken

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.

Cost Savings

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.

Feature Enhancement

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.

The Technical Tools for Succeeding

Over several of these projects, we've identified a set of core technical themes that have helped the efforts succeed.

  • On day one, watch somebody use the existing application. For an hour. Understand what they are accomplishing with the application, and what the application does not do. Plan to provide the former. Stop thinking about the latter.
  • On day two, start migrating the existing data. Do not wait for this; legacy mainframe applications tend to have legacy database schemas. Rails in particular has some built-in assumptions about schema. Either the data is going to need to be changed, or your code will. Repeat this often; your schema will evolve over time, and you need to continue to ensure a clear path for the existing data to land in the new structure.
  • In week one, get a real user interacting with the application. They'll tell you immediately all the things you will never learn on your own: "The last step should be instantaneous. This is taking 10 seconds or more.", or "When I tab out of this field, this other field should be filled in. I never want to look at that field, it should be automatic.", etc. Do not wait until "the system is done" to do this.
  • Pick a good JavaScript keybinding library. Get one that works with your chosen JavaScript library, and that is snappy and responsive.
  • Do NOT bind asynchronous remote server calls to keyboard events. The point of using the keyboard is fast navigation; making a roundtrip to the server will always be slower than the user expects. As much as possible, cache the data you need to respond to keyboard events locally.
  • Target a single browser if you can. Most legacy mainframe apps have a limited user base, and the client can reasonably control expectations about usage scenarios. Pick a good, modern browser, like Firefox 2.0+, and develop against that. Treat further browser support as a feature enhancement, for shipping after the first deployment.
  • Benchmark your chosen server configuration against the original mainframe application as early as possible. We've never had an admin tell us that the new version was slower, but the political fallout of shipping an application where that is true would be catastrophic. So benchmark early and often.
  • Get a realistic set of test data. Bear in mind that most legacy mainframe applications have massive amounts of data. They've been operating for 20 or 30 years in some cases; even at a million records a year, you have 30 million records. Often, much more. Don't assume your application is going to perform correctly because your 100 rows of test data fly through the app. Find out how much data there is in the production database, and drive your app against that iceberg as early as you can.

It Doesn't Take Bionic Legs

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.

Get In Touch