IBM Rochester Shows Off Its Agility

February 18, 2013 Alex Woodie

When IBM i 7.1 shipped three years ago, it marked a significant moment in the history of the IBM i product. However, few people outside of IBM‘s lab in Rochester, Minnesota, fully understood the future ramifications of the changes IBM was making, and IBMers like chief architect Steve Will didn’t really try to explain it at the time. But with the sixth Technology Refresh (TR6) on its way, the proof is in the pudding: IBM Rochester has adopted agile in a big way.

Will says Rochester’s agile development strategy arose as a result of the work it was doing in developing new capabilities in the OS across multiple releases, and the desire to minimize disruptive upgrades for customers. Before IBM i 7.1, Rochester developers would not only figure out how to build new features for upcoming major releases, but they also spent time and energy back-porting the new stuff to older releases. That all changed with 7.1.

“We got the whole development organization to shift gears,” Will tells IT Jungle. “So now instead of trying to, after the fact, figure out if can we put something back on a prior release, for every new thing that we think of, we say, can this be put out in between releases, or does it have to go in a major release? So that is a shift. We couldn’t make that shift though, until we got the capability to do technology refreshes within the 7.1 release. So we’ve been driving towards being able to ask ourselves that question for a while.”

Will says that, at the moment, Rochester developers are working on IBM i 7.1 TR7, the next Technology Refresh after that, and the next major release of the OS, presumably to be called IBM i 8.1. IBM has committed to delivering two TRs per year, and the current roadmap shows a major new release of IBM i sometime in the 2014 to 2015 timeframe, which is tentative, of course.

“As we adopted agile, it became clear that we could marry the development process with these deliverables that we wanted it to do,” Will says, “and avoid the disruption of major releases. We’re always going to need major release for certain things, but our clients want this new capability without the disruption of a major release. I hate to think of our major releases as disruptions, but the point is that we want to make sure that we can get whatever is possible without a disruption. And then, when we have to do a major release, we want make it clear to them the value of that major release, and the key things that are being added that require them to go through that upgrade.”

And it is not just an upgrade that is a pain, but the recertification of applications to make sure they can run on a new version (what people are calling a major release in some circles these days).

The upgrade from i5/OS V5R4 to IBM i 6.1 was quite disruptive, due to the program conversion required. Applications that weren’t constructed well need tinkering to get them compatible with IBM i, and that has been a major roadblock in the upgrade process for the IBM i ecosystem across the world. IBM listened to the pushback it received from customers, and learned from that experience.

The good news is, once customers get to IBM i 6.1–or even better, upgrade straight from V5R4 to IBM i 7.1–the business disruptions due to OS upgrades tapers off dramatically thanks to the TR program that IBM put in place. IBM adopted the TR program specifically to minimize disruption while still giving IBM i shops new functionality, and by all accounts, it’s worked out well.

“The key big difference between what we’re doing now and what we were doing a few years back is that we have the capability to produce these in-between release deliverables,” Will says. The big leap forward was due to “the redesign of SLIC to allow Technology Refreshes to be added. It was something that was a major piece of what we delivered in 7.1, but we couldn’t really describe how useful it was until we’ve gotten out to the point now where we can add these major new functions that way.”

Now that we are five TRs into the game, with the sixth is due to ship via PTF by the end of March, the upgrade process has been smoothed tremendously and IBM i shops are upgrading more quickly, and in larger numbers than before.

“We constantly are tracking how many people have adopted the TRs, and the rate of adoption for the last TR, TR5, was so fast that you can almost look at as, pretty much every client that had 7.1 wanted to go to TR5 as quickly as possible, and implemented it very, very quickly,” Will says.

“We don’t anticipate there will be any trouble with [TR6] in the future,” he continues. “They’ve gotten used to idea that TRs will come on, they will cause no disruption, and so they adopt them very quickly. When we did our first couple of TRs, we could see a slow ramp up of when people adopted them. But now it’s just like the cumes [cumulative updates]. When the cumes come out, most clients schedule to take advantage of them. Now with the TRs, they’re doing the same thing.”

Interestingly, Rochester has even figured out how to deliver major new functionality without disruption. The Live Partition Mobility (LPM) functionality that was added with TR5 is a major upgrade to PowerVM, yet it didn’t require a major upgrade of the OS or the underlying SLIC.

“The important thing is we don’t change any of the APIs in any sort of disruptive way. That’s what makes this possible to do in a non-disruptive environment,” Will says. “There shouldn’t be a noticeable change. If you want to take advantage of new capability, you can do that. But nobody has to make changes if they want to take advantage of it.”

A key characteristic of the IBM i server has always been its capability to insulate customers from technological change (in the good sense). With the TRs, it has found another way to shield its customers from the disruptive side of technological change, while delivering the benefits that new technology provides. It will be interesting to see what other new tricks Rochester can pull out of its hat without ruffling any features.