H & R Block: RIO proves less taxing than manual conversion to Java |
 |
By ASC Inc.
27 Dec 2004 | ASC Inc. |
|
|
Consumer tax filing company H & R Block has long been an advocate and user of AS/400 RPG applications. They run several large AS/400s that process all of the back end business applications that their retail and on-line applications depend on. Based in Kansas City, Missouri, the company retains thousands of IT professionals who manage the logistics of this multi-platform enterprise. This includes developers, QA testing teams, DBAs, and so on. H & R Block has been an AS/400 customer since 1987.
Like many other companies, H & R Block spent that time period perfecting a reliable process built around the AS/400. In their case, this process was termed the 'Common Database' (CDB) application. It served as the focal point for collecting and tracking office logistics, financial hierarchy, common control file, and franchise contract information for all of their remote office locations. As this application quietly went about its work, many departmental or smaller enterprise applications evolved on the company's Windows servers. Eventually, a replacement application for CDB (called ELMS) was developed to eventually replace CDB as a single platform source for all office logistics data. Today, ELMS still uses the data supplied by CDB, which the company hopes to change in the near future. CDB turned out to have fairly critical business logic that was not easily replicated, and the company grew concerned about the cost of ELMS legitimately replacing what CDB had been doing for years.
While the office tracking application served its purpose well on the AS/400, it also made sense to the company's IT staff that this application would be best located and architected similarly to its sister Windows applications, which rely heavily on both Java as well as .Net. H & R Block Web Architect Tom Brown, explains.
"In the old days, location tracking codes were manually assigned to each location and tracked by the accounting department. Not an efficient process by any means. When the entire system became computerized in the early 1970s, the original host was an IBM S/34, then later migrated to an AS/400. As time passed, it became increasingly obvious that the RPG language placed some functional limitations on our systems. More modern languages were evolving that allowed us to meet the demands our business requires of us, yet our dependence on the RPG-based CDB application had grown. It had reached an unacceptable level of dependence, and that more or less led us to migration considerations."
Making such decisions wouldn't come easily to any organization. The concept of taking a perfectly reliable RPG application on an AS/400 and porting it to another language on another platform was daunting, yet seemed plausible. After doing some research, Brown realized that there was no silver bullet to making this transition. Further complicating the issue was the company's desire to retain as much of the application's business logic, look, and feel as intact as possible. "We just didn't see the logic of reinventing the wheel given our dependence on the application" added Brown. "Our users were not clamoring for a sizzling interface- their preference was to limit their exposure to learning a whole new application."
The alternatives began shrinking almost immediately after the company realized that most technical solutions would require a complete rewrite of their application. This not only would have undermined their goal of retaining their RPG application feel, but also would have been grossly expensive. Brown explains, "We didn't need a soup to nuts consulting firm on this project, cost being one of the reasons. We needed a software tool that would take us as close to the desired result as possible."
The search for software really began and ended with RIO. "There were other companies indicating they had a tool, but they never quite delivered the goods. RIO was licensed based on the number of source members we wanted to translate. It's pretty obvious that if someone wants to charge you a fee based on the lines of code converted, then they aren't really offering a software product," observed Brown.
The project started with a proof of concept over H & R Block's source code. ASC has 2 methods of recreating the 'green screen' interface in the translated Java application. One method relies on the WebFacing perspective in IBM's WebSphere Development Studio client (WDSc). RIO's APIs allow the WebFacing client to produces JSPs that are independent of the AS/400, yet work with the translated code. The other method allows RIO to generate raw XML/XSL in place of the host screens. The WebFaced approach made sense for H & R Block, since its intent is to simulate the behavior of the RPG application as much as possible. ASC successfully converted some sample code and screens, and from there the decision was made.
"RIO was pretty stable from the get go. There were some hold-over things in our code that had to be reengineered, like some GOTO statements. It was the WebFacing client that posed more of a challenge for us. ASC was very responsive, but it was also clear that as IBM made changes to WebFacing, that had consequences for RIO working properly. That said, we're sitting here today with a completed project on time and under budget. I speculate how often that happens with some of these other solution providers. I've worked closely with Andrew Clark our RIO engineer from ASC, and that's been the key factor in this whole thing working successfully."
|
|
|
|
