An ISV answering the same question will probably say it is easier to develop and maintain applications for an AS/400 than for some other platform. ISVs who have the same application available on an AS/400 and on some other platform, such as a Unix system, often comment on the differences in the number of people they employ for the two platforms. They generally require far fewer people to develop and maintain their AS/400 applications. Again, the integration is what makes this possible. By ensuring that when any new function is added it works seamlessly with everything else in the system, we preserve the value proposition of the AS/400. All of Rochester’s systems up to and including the AS/400 have been integrated solutions, and that is the secret to Rochester’s success.

If our own developers miss the integration factor, what ensures that the AS/400 remains an integrated system? The answer is the MI. The MI does two things to guarantee integration. First, it provides a common interface to all application and operating system functions above the MI. Everyone is forced to use the system in the same way. Second, the MI presents a functionally complete interface. Because it is not possible to go around the MI, it must provide all the functions an application or operating system program needs. If some function is missing, that program will not run on an AS/400. MI also is highly extensible to allow new functions to be added as they are needed.

Before someone points out that other Rochester systems, such as the System/36, accomplished integration without a high-level machine interface, I should note that the MI provides two functions: integration and machine independence. While the System/36 did have the equivalent of a machine interface for most of its system functions, the same was not true for applications. The System/36 had two separate processors, one that ran the user applications and the other that ran certain operating-system functions. To get at these operating-system functions in the second processor required the use of a very structured interface between the two processors. This interface, like the MI, ensured that functions were complete and that they worked together. The applications, however, were still dependent on the underlying hardware. For this reason, an emulator is needed to support System/36 applications on other hardware, as we will see in Chapter 3.

The negative side of integration is a lack of flexibility. With an integrated solution, the approach is usually all or nothing. A customer cannot choose an operating system from one vendor, a database from another, and a security package from still another, primarily because these components are usually not designed to work with the integrated system.

It seems difficult to believe that any computer system would have components that are not designed to work closely together, but that is often the case. Components such as databases, security, and communications subsystems are routinely developed separately. Their intended use may be with several different operating systems. As a result, the components are usually self-contained, meaning they attempt to use as little of the operating system facilities as possible. This separation leads to duplication of functions between the operating system and the individual components. It also can lead to different interfaces for the user or system operator.

The advantage of having separate components from which to choose is total flexibility. The downside is that the customer must integrate these components into the business’ computer systems, and the cost is not just in the integration. There also is the cost of training users and operators on the different interfaces these components present. Then there is the cost of maintenance. Updates and changes made to one component may have an adverse impact on another component in the system. To complicate matters, many systems exist in networks, which themselves require management. In an attempt to eliminate many of the inconsistencies between components, some businesses choose to purchase all software from one vendor, but this usually doesn’t work either.

This reminds me of an experience I had not long ago purchasing and installing a new home theater system. Each of the four separate electronic components came with its own remote control. Because all the components were from the same manufacturer, the salesman assured me that each remote control was universal, meaning that it could control all the components. Only one would be needed for the whole system. Sure enough, a single remote could control some functions on each component; unfortunately, it couldn’t control them all. Total system operation requires the use of all four remote controls. Further, the user interface for each remote control is different. Buttons for the same functions are in different places and often have different sizes and shapes. Even the names for some of the same functions are different. Many business people are using several “remote controls” to run their business computer installations. For both of us, an integrated system would make more sense.