Big IT: Doomed

Computerworld - Big IT projects are doomed. Want proof? Just look at the four-year, $100 million-plus project to rebuild the air-travel reservation system run by Sabre Holdings Corp. . Sabre's decades-old system was 10 million lines of mainframe assembly language code. The new version is C++ and Java running on 17 HP NonStop database machines and 45 Linux servers -- which means everything is getting overhauled. And halfway through the project, it's all working.
So how does this big -- and successful -- IT project prove that big IT projects are doomed? It became successful only because Sabre stopped running it as a big IT project.
See, Sabre has tried to overhaul its reservation system before -- most infamously from 1988 to 1992, when it spent $125 million on a megaproject to do just that. This was Sabre's giant leap into the future. Project architects polished the design down to the last interface and buffer. Project managers broke it into manageable pieces to be built in parallel, just the way the experts said it should be done.
After three and a half years of development, the pieces were put together into a finished system. It didn't work well. Three months before the project was set to go live, with partners like Budget Rent A Car and the Hilton and Marriott hotel chains waiting to use it, managers began to realize the problems might not be fixable.
A few weeks ahead of the promised completion date, Sabre had to junk the entire system.
Now that was a big, doomed IT project. And for 10 years, it spooked Sabre away from anything that big.
So what makes this new four-year, $100 million-plus success different from that old four-year, $100 million-plus catastrophe?
This time, it wasn't a big leap. Borrowing techniques from so-called agile programming, Sabre did it as a series of small steps.
Because of that, the project's architecture has already changed twice so far. Originally, all the mainframe functions were going to be ported to the fault-tolerant NonStop servers. As the project progressed, some of those functions were shifted to Unix servers. Then they were moved to Linux. And the data-replication system was also rearchitected midstream.
As a result, the system already looks a lot different now than the design did in 2001, when the project started. Small steps -- and a willingness to change direction -- make that possible.
Small steps also make it possible to respond to changes in technology. That's why Linux, which didn't look like a viable option in 2001,