Now departing: Union Pacific's 40-year-old mainframe

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

Page Break

PAGE 2

Discussions about Union Pacific's eventual move off its mainframe started some seven or eight years ago. The project kicked off in earnest four years ago. Tennison says UP couldn't find what it was looking for from packaged software vendors, so his team decided to build their future system themselves. (For more on today's mainframe issues, see "5 Things CIOs Need to Know About Mainframe Modernization.")

First up, Tennison's team had to create, the nearly decade-long technology roadmap. The vision was to deliver a distributed, automated network and applications platform that could scale with the company, and could also control UP's 8,400 locomotives traveling across 32,000 miles of track. The system would need to manage customer orders, schedule trains, track shipments and many other transactional processes. And it would also have to integrate with the company's SAP ERP system.

Underpinning this new system, called NetControl, would be a service-oriented, event-driven architecture that relies chiefly on open-source technology. Several tenets guided Tennison and his team during initial prototyping. For instance, he says they looked to computer science and engineering graduates and the types of environments they were using-"the Linux, Java, Unix worlds," he says-and matched many of those C.S. trends to their development strategies.

A nod to the past, however, influenced two other areas. Because monolithic mainframes had always offered forced standardization-in development and database tools, in middleware components, in security-Tennison and his team wanted to keep as much standardization and discipline as possible in NetControl. "Making sure everybody does stuff the same way to a large degree," he says, "drives productivity and ease of use, minimizes security risk, and maximizes your purchasing power."

They were also thinking long-long-term again. "We wanted to make sure anything we put in place could have the potential for another 40 years of life, just as our original one had," Tennison says. "So we had to guarantee that we had almost unlimited scaling capacity, and moving to a network of horizontally designed servers gave us that."

A successful prototype delivered several years ago confirmed IT's technological vision and architectural framework for Union Pacific's new system. "Now," Tennison recalls, "we had to go after business issues."

The Big Sell

To pull this transition off, Tennison knew he had to get UP-wide buy-in: from the chairman and board to all the key VPs, operations and supply chain managers, marketing and finance execs, and everybody else who would touch the system. Some business areas would be especially affected; others, not so much. But it would, for sure, touch everybody in some way. Tennison needed to make the "sale" of his career and convince others that this was less a "tactical" project and more a "strategic" one.

"It was very easy for a departmental head to stand up and say: 'I need this system for my department,'" Tennison says. "It was hard to get any single department head to say: 'I need to change up an entire core infrastructure component of our business that's going to touch everybody else,' because they had a lot of other things they were fighting every day."

And because the project cut across so many departments, lining up funding for the project-expected to cost $200 million by the end-was challenging. "This is one of those things where the direct benefits cut across the whole organization," Tennison says, "and sometimes the benefits are much about interrelationships between the organizations as they are around direct results in one organization."

Once funding was approved, the NetControl project group placed key UP employees on the teams (from both high and low levels and from many different UP organizations) to become if not leaders of the teams, key members. Though the project duration is disarmingly long, Tennison and his project managers have "decomposed it into small chunks," he says. "Architecturally, this all has to fit together. But with each of these chunks, you have to eat the elephant a little bit at the time."

So far, Union Pacific has spent $70 million and is 35 percent complete with the project. Tennison seems pleased with the progress. One of the many early benefits has come in UP's bill-of-lading processes (when a customer tenders a shipment and gives instructions on where to pick up and drop off the commodity). The critical data contained in these bills determines the movement and configurations of trains and drives the billing process; UP receives hundreds of thousands of in-bound bills each month, according to the company. The system in place can "recognize and correct many common problems, allowing for greater automation of shipment handling," according to UP.

Tennison has also delivered some critical project and functionality wins, which is important from a self-preservation standpoint. "I do worry about these long, long duration projects because the reality of world is that you do tend to get measured on quarterly and annual results, and you have to be able to stand up and say: This is what I did for you last quarter," Tennison says. "You have to have some wins along the way."

Do you Tweet? Follow me on Twitter @twailgum. Follow everything from CIO.com on Twitter @CIOonline.