You need software to run your business…and you need hardware to run your software. Your software—or more precisely, what your software does—is the reason you spend money on information technology. Some of that money has to go toward hardware, of course, but hardware is, functionally speaking, twice-removed from the “action.” Running your business profitably and efficiently is the “action,” and that’s why you want to keep your software up-to-date. But hardware also needs to be upgraded from time to time. Today’s CPUs and peripherals work faster and better than yesterday’s…and that’s reason enough to spend money on hardware, too.
This points up an important distinction between iSeries/AS400 users and most other businesses—the ones that rely on other technologies. When it comes to modernizing software and hardware, everybody is in pretty much the same situation: you do it only if—and when—the ROI is justified. iSeries/AS400 owners, however, tend to assume that that’s all there is to it. But the “other guys” periodically confront an unpleasant situation that is unheard of in the iSeries/AS400 world: the discovery that new hardware simply will not run one’s existing software. For the very smallest businesses—the ones that can use shrink wrapped applications right out of the box, the fix is usually simple and not too costly: they upgrade their applications to the latest version, the one that (hopefully) will run on the new hardware.
But for companies large enough to need customized applications, this compatibility issue can be very expensive because each hardware upgrade can necessitate costly and time-consuming software customization. Why is it that this unpleasantness—so ubiquitous in the world at large—is unheard of among iSeries/AS400 owners?
Remember, back in the ‘80s, when IBM PCs and clones caught on and the whole industry shifted from 8-bit to 16-bit microprocessors? Every application from the 8-bit generation had to be replaced by a 16-bit version. If a 16-bit version was not yet available for a particular application, it meant custom programming to re-write the application for 16-bit architecture.
In the early-to-mid 90’s we saw a similar situation with Pentium and Windows. This time around, it was the switchover from 16-bit to 32-bit architecture. Corporate Pentium/Windows users were forced to make a huge investment in 32-bit software, to make it compatible with the new 32-bit hardware.
So what happens when 64-bit catches on? Every 32-bit application will have to be re-written or the business will have to invest in all-new versions of each of its applications. Either way, this will be a VERY EXPENSIVE way to capitalize on newer technology.
The point of the newer technology is easy to understand. A 32-bit system cannot address more than 4 GB of data, while a 64-bit system can directly address more than 18.4 quintillion bytes (18,446,744,073,709,551,616, to be precise). So what? State-of-the-art business intelligence and data mining applications typically analyze years of transactions at a time, so the 4 GB addressing limit is easily exceeded. But it is very hard to exceed the addressing capabilities of the iSeries/AS400. A young Bill Gates, when publicly challenged about the memory limitation of DOS, replied, “Who would ever need more than 640K?” Although everybody—including Gates—has grown older and wiser since then, it’s instructive to note that the iSeries/AS400 has had 64-bit technology since 1995!
The Contrast
By contrast, the iSeries/AS400 has never had this issue of incompatibility between new hardware and existing software applications. Why not? Because of something IBM calls TIMI (Technology Independent Machine Interface), which has been an integral part of iSeries/AS400 design since its inception.
Here’s the concept: TIMI is a layer of software that sits between the hardware and the operating system. The hardware and its related drivers may change, but TIMI functions like a translator between the hardware and the operating system, so no program changes are necessary for your application software to run on new hardware.
As proof, in the mid-90s, IBM shifted the iSeries/AS400 from 48-bit to 64-bit…yet no user had to re-write or recompile his software to run on 64-bit architecture. And since then, the iSeries/AS400 has experienced 9 generations of new RISC processors without impacting any user’s application software. With TIMI as a shock absorber, each bump in hardware technology was isolated from the smooth functioning of all the existing application software. iSeries/AS400 users were free to upgrade their applications if—and when—the ROI could be justified by the improved performance of the software alone.
In the “other camp,” however, “shotgun weddings” happen all the time. Users of HP3000, DEC VAX and 16-bit DOS systems experienced transitions that were nowhere as graceful as those of iSeries/AS400 users. In fact, most enterprises inhabiting the non- iSeries/AS400 world hit a dead end. The cost? Typically, $100,000 to several million dollars to implement a replacement for the dead end system.
Leave a Reply