| " Reports of my demise are greatly exaggerated." When I think of mainframes, I think of Mark Twain's well-known quote. Today, when people discuss mainframes and mainframe applications, they use the term legacy . This has the connotation of something old, something thrust upon us that would not be our first choice. A legacy applicant to a fraternity is one whose family has a history of membership and who therefore receives special consideration. Perhaps without this consideration, the applicant would not pass muster. Is this really the state of the mainframe market today? Do mainframes have a place in the IEBI? To answer these questions, we must first understand what a mainframe is. When I sat down to write this chapter, I thought I could easily put this into words. Surprisingly, I couldn't. As a Supreme Court justice once said of pornography, "I know what it is when I see it." Coming up with a definition is a bit more difficult. A mainframe is a big computer system, a really big computer system. How's that? As technology advances system capabilities, the lines between the mainframe and a large server have blurred, making it more difficult to compose a simple definition distinguishing the two. The very technologies upon which these systems are based have merged as well. Mainframes are replacing ECL (Emitter-Coupler Logic) components with CMOS (Complementary Metal-Oxide Semiconductor), resulting in more compute power in smaller spaces. We can see that at least as far as hardware is concerned , the mainframe is far from a musty old beast sent out to graze. These systems are excellent when processing large volumes of data, especially in a batch mode. In addition to huge processing power, they also have tremendous Input/Output (I/O) capabilities. But, what about the software? Two years ago people were predicting the end of the world. The Y2K bug was going to bring about not only the end of the world, but also the second coming of Christ. (I say this not to be flip; I actually knew people who sincerely believed this.) The media-engendered hysteria, however, entirely missed the point. The date problem that became known as a bug, wasn't. It was not the result of poor programming, but of good! I actually remember sitting in a COBOL class in the late 1970s and being told by the instructor to only use two digits. He made the offhand remark that no one would be using these programs in the year 2000, so why worry about it. We all expected our code to be scrapped long ago. The problem was that the code worked too well . There was no need to change something that was doing the job. Such is the case with most mainframe software. There is a very real downside. While many organizations that have mainframes as part of their information infrastructures are still spending substantial sums on upgrading their systems, most of the money is spent in maintaining the existing systems. Hence the mainframe's legacy reputation. We have noted how the term legacy connotes something handed down from previous generations. Such is the case with mainframes today; they still host applications built a generation ago by programmers who have long since hung up their flowcharting templates. Many of the investments in upgrading the applications themselves , such as providing Internet access, are merely putting a new coat of paint on an old barn. The legacy applications remain at the heart of these systems. These applications are not rolling stonesthey do gather moss. The lack of documentation and staff intimately familiar with the already existing software leads to functions being re-created over and over again. This results in redundant applications and code scraps , both of which ultimately increase system costs. In addition, the very nature of the implementation makes it cumbersome to modify the business logic in applications. The biggest challenge faced by the mainframe is not really technology. It is more of a matter of perception. The mainframe is like a tanka big, bulky monster that moves forward with great deliberation. The thing about tanks is that they are sure handy on a battlefield. They aren't, however, terribly sexy. Next time you're at an IT cocktail party, tell the new blonde-haired, blue-eyed programmer who just graduated from Malibu State College with a B.S. in computer science and surfboard waxing that you are a COBOL programmer. See what kind of reaction you get. This is the problem: Mainframes have lost their sizzle. We aren't impressed anymore by banks of blinking lights, dip switches, and spinning tape drives . Fewer people are interested in the technology. This makes it even more difficult to find talented technical staff in an already tight market. Can the mainframe pass muster? Certainly, but as time passes , it will become increasingly more difficult to do so. In Chapter 2, we discussed that one of the factors leading to the success of the American industrial revolution was the lack of an infrastructure that needed to be replaced . The early Americans simply implemented a new solution to the production problem. Since there was no old solution already in place, there wasn't any hindrance to this new approach. The complexity of the software along with the dwindling supply of programming talent creates a downward spiral. It begins when parts of the organization approach the IT department requesting reports or modifications to existing applications. Since these changes are complex and there are fewer programmers to make them, these changes take time even under the best circumstances. Managers who are not familiar with the causes of the delay grow frustrated and view IT as resistant or, worse yet, incompetent. More than once, I have attended meetings to discuss changes to a large mainframe-based application, and production managers were there with their same old complaint: "Why can't you guys get your act together? My son-in-law wrote a program for me on his PC that does the same thing in just a week." Any explanation of the differences between a PC-based, single- user database program and a mainframe enterprise application was lost on them. In many instances, however, perception becomes reality. The perception was that IT was slow and resistant. IT developed a siege mentality , thus becoming slow and resistant. In the mind of the user, IT saw themselves as the high priests of information. Users, as supplicants, paid homage to the lords of silicon and their representatives, the IT department. IT in turn passed judgment on which requests were worthy of consideration. This set the stage for the client/server revolution. Client/server systems empowered users, giving them unprecedented access to their systems and applications. Individual department managers became mini-CIOs, each implementing solutions that met their specific needs. While mainframes were islands of information, client/server dispersed information throughout the organization. Claudius Caesar said that within every lie, there is a truth, and within every truth, there is a lie. There are points on both sides of this issue that are correct and points that are somewhat exaggerated. To understand this more fully, let's try to dispel some of the myths around client/server. |
