Now Departing: Union Pacific's 40-Year-Old Mainframe
After decades of service from a mainframe that kept on chugging, Union Pacific IT leaders knew they had to retire their workhorse. But how do you get rid of a massive, core technology system, without disrupting business operation, breaking the bank, or biting off too much change at once? Here's advice from a CIO who's in the midst of doing it right.
CIO — Union Pacific, the railroad company that transports chemicals, coal, food, minerals and automobiles in and around 23 Western U.S. states, has had two workhorses that toiled tirelessly for the past four decades: the diesel locomotive and the IBM mainframe.
The Iron Horse, of course, has been around for more than a century. But it was the arrival of Big Iron that was a game changer at Union Pacific in the 1960s. IBM introduced the massive computing stacks in 1964, and UP was an early adopter, says Lynden Tennison, CIO since February 2005. Union Pacific rolled out early transaction-processing systems and was the first railroad, Tennison claims, to implement a car-scheduling application, which replaced manual processes.
"We believe it differentiated us in marketplace," he says. "We could offer a more reliable service because we could guarantee your shipment moved a certain way since we planned it on the front end."
What followed as the years progressed—always with the mainframe at the core—was a first-generation centralized computer-aided dispatching system that reached across Union Pacific's entire network. Then, on-board computing systems arrived inside UP's locomotives that offer satellite communications, GPS tracking and a number of locomotive-specific sensors. "All that tied back into this host mainframe environment," Tennison says. (See "How IT is Helping the Railroad Industry Improve Efficiency and Service" for more on this topic.)
"But today, it's now getting to be 40 years old," he says. Computing skills and languages have changed: Finding programmers willing and able to manage the mainframe's 11 million lines of macro assembler code isn't easy.
And the business changed, too. For example, UP now needs to know more about what is inside the rail car—not just the rail car itself. When transporting automobiles (GM is Union Pacific's second-largest customer), the company needed to track the autos' vehicle identification numbers. "So there was a whole different set of business problems that we had to patch, as best we could, and implement in various systems," he says.
The mainframe kept chugging along, but at some point after the turn of the new millennium, Tennison and other senior IT and business leaders knew they were going to have to retire their workhorse. But just how do you get rid of this massive, core technology system, without disrupting business operation, without breaking the bank, and without getting trapped by a massive and risky technology project with tight timelines that usually wind up with less than desirable business results? (For more on the pressures of massive IT projects, see "After a Massive Tech Project Failure: What IT Can Expect.")
"We were going to have to live in the house while we built it—there was no big-bang replacement here," Tennison says. "So we've had to keep the old world alive while we transition to the new world."
The march is on toward 2014: That's the approximate end-of-service date for Union Pacific's mainframe.
The Long, Slow Haul to Uncouple from a Mainframe
Like Union Pacific, other long-time IBM mainframe customers appear to be transitioning away from Big Blue's Big Iron as well. In 2009's second quarter, IBM suffered a nearly 40 percent drop in mainframe revenues, which, according to a Businessweek article, "seems to signal that this long-time mainstay of IBM's business is on its way to the junkyard." (IBM executives steadfastly disagree.)
