There’s nothing like a deadline for getting a job done, and a deadline is what Service Nova Scotia and Municipal Relations (SNSMR) faces to get rid of its mainframe.
The Nova Scotia government has told all its departments to migrate their remaining mainframe applications to other platforms by April 2007. Founded in 2000, SNSMR delivers assorted programs and services to citizens and municipalities. Among them are the two legacy systems the department is now in the process of moving to Unix servers: the Registry of Motor Vehicles (RMV) and the Registry of Statistical Information and Events (ROSIE).
Both were built on Software AG’s Adabas database management system and Natural data manipulation language, and run on an IBM mainframe.
The department won’t be sad to leave the mainframe behind. “The mainframe applications have caused us grief for a long time, mostly around application support,” said Robert Devet, project director for the mainframe modernization project office at SNSMR Registry and Information Management Services. “It’s very difficult to deal with the enhancement requests that would come from the business areas, and very difficult to share data with other organizations.”
Given the tight deadline, Devet said, the department considered the option of simply moving the existing applications based on Adabas and Natural to a Unix server. But while that would have met the provincial deadline for abandoning the mainframe, it would not have solved the other problems.
Service Nova Scotia knew where it wanted to go. It has a policy of developing all new applications using Java 2 Platform, Enterprise Edition (J2EE) and Oracle Corp.’s database software. So what it needed was a way of transforming the legacy RMV and ROSIE applications to that environment.
Once the department started researching the problem, Devet said, it soon discovered a niche of companies that use automation to help their customers with this type of migration. The final choice was Make Technologies Inc., a seven-year-old Vancouver firm that specializes in what Jean-Guy Faubert, its executive vice-president and general manager, calls “transformation legacy migration.”
Make uses automated tools to parse the legacy applications. “That extracts the IP, or intellectual property, that has been embedded in these old caskets for years and years and years,” Faubert said.
But Make doesn’t simply translate the legacy applications into J2EE. SNSMR looked at services that do that, Devet said, but they didn’t solve the full problem. “It would be Java,” he explained, “but it would still be difficult to maintain.”
Make’s process doesn’t rely purely on analysing the legacy applications with automated tools, but adds some elements of new systems development too – like talking to users to learn what Faubert calls the “tribal knowledge” of how systems work. That’s designed to help find inefficiencies in the applications, which are then cleaned up. “It’s modernizing the application,” Faubert said. “What we do is we streamline and update.”
SNSMR wanted to be sure early on that Make Technologies could deliver, so the department built an early proof of concept into its request for proposal. When Make was awarded the roughly $3-million contract in September, the conditions called for it to take a small part of the legacy code and run it through the entire process to produce a final prototype of that one “sliver of functionality” by the end of 2005.
“We basically only gave them two months,” Devet said, “and they delivered an application that the department has accepted.” That small prototype contained a few bugs, he said, but not major ones – and it has given SNSMR “the confidence that we picked the right company.”
Make is now in the process of analysing the rest of the legacy code. Devet said. Its job should be completed by about the end of this year. Then it will be up to SNSMR to finish implementing the new systems by the April 2007 deadline.
Comment: [email protected]
