1980: Advanced Systems Architecture
The Pacific project had been announced as the IBM System/38, but its performance wasn't everything expected, so Rochester management decided to delay its initial shipment by a few months. This caused a tremendous uproar all through IBM. Missing schedules just wasn't done. I've even heard of a major product being shipped to distribution when its management knew full well that the distribution tape wouldn't load. They left this "unexpected" problem to be detected in the field, reported through normal channels. This gave them the time they needed to finish debugging. It didn't matter that they'd cheated, they'd met their schedules. In contrast, Rochester management played it straight, admitted they needed a bit more time, and got criticized for it, regardless of the fact that they ultimately delivered a high quality product.
It was during this period of last minute performance tuning that a new Advanced Systems Architecture department was formed under Jim Archer. I was told this new department would begin to look at what came next, after the System/38, and that we'd have time to kick around some advanced ideas that had been tabled as too ambitious for the 38. I was pleased to be asked to join because I thought it meant respect for my abilities as a software architect. I was also pleased at some of the other people who were asked, people whose work I had respected like Dick Baines, Vic Berstis, Fred Ziciena, and Bob Tracy.
We had one meeting, in which Jim Archer asked us to begin developing an "Objectives" document. That was just about the last we saw of Jim Archer, at least as our manager. He was off and running, doing staff work and generally working as a trouble shooter. All of this may have been needed, but it left our new department rudderless. Each of us took off on our own pet projects, pretty much forgetting about any follow-on system, and pretty much out of touch with what was happening in the rest of the programming laboratory.
But we weren't quite forgotten. One morning, Jim called me into his office and said "Rich, they need help in developing performance test cases. How about going over and seeing if you can lend a hand?"
I wasn't opposed to this in principle, but practically, I doubted I could be of much help. It had been at least five years since I'd done any real programming, and I'd never learned the tools or languages used by the System/38 programming team. I did go over to see what was needed, but my worst fears were confirmed. I would only be a hindrance to them. There was just too much that I'd need to learn to be productive on their project, and I'd never catch up with their schedules.
I saw Jim the next morning and told him what I'd learned.
"You mean there's nothing you can do to help them?" Jim asked. "You know we're desperate to get this product out the door."
"I know, Jim, but I just don't have the skills and it would take too long for me to learn them. I'm an architect, not a programmer, and I really don't want to get in their way."
He shook his head. "How did we ever let something like this happen?"
"It's called specialization." I said. "I didn't have time to do both architecture and programming."
I heard later through the grapevine that I had refused to help, that mere programming work was beneath me, neither of which was true. I had really enjoyed the years I had spent programming, but I had been asked to do design work on the Pacific project, not programming.
Not having any other directions, I continued to work on enhancements to the System/38 Message Handler. I developed one proposal to make it easier for customers to create files of stored messages. Another proposal enabled different users of the same system to see messages in their own natural languages. And a third made it easier for application programs to display messages at work stations. The problem was that everyone else, outside of the Advanced Systems Architecture department, was too busy to look at these proposals. So I shelved them, assuming that they would be useful in either a follow-on release of the System/38 or in a follow-on system. As far as I was concerned, I was doing exactly what the department had been created to do getting ahead of current development activities and providing direction for future work.
And then, having exhausted the subject of Message Handling, I started thinking about "objects." The System/38 used this term to mean encapsulated address spaces; that is, segments of the system's uniform address space whose data contents were associated with specific programs that alone could access or modify that data. This was undoubtedly the single most important architectural concept in the system. It affected almost everything in the system, and even showed up in the system's command language. Almost all of the commands were requests for the system to do "some action to some object." But, where it stopped short was in support for application programming. Customers were expected to continue using the traditional, though somewhat enhanced, methods they had used for the System/34, namely using the Report Program Generator (RPG) language and system commands. Support for COBOL, PL/I and Fortran were later added, but this was just more of the same thinking. What, I wondered, could we do to make the advantages of object-based design available to application programmers?
At about this time, I read several books that set me on fire intellectually. One was Herbert Simon's The Sciences of the Artificial. From Simon I gained an appreciation of the role of subsystems in the development of complex, stable systems. Prior to reading this book I had been puzzled by the argument of fundamentalists that a biological system as complex as an eye, for example, could never have evolved, that it had to have been the work of a divine designer. Simon's example of a craftsman assembling a watch clarified this for me. It is true, he argued, that attempting to assemble a pocket watch all in one operation would be very difficult, with success highly improbable. But if subsystems of the watch are individually created as stable entities in their own right, then they can be used later to assemble still higher level subsystems, and so forth until the full system (the watch) was itself fully assembled and stable. This, Simon argued, was precisely what happened in biological evolution, and it what was needed in the development of artificial systems - anything from watches to computers to space craft. Wasn't this exactly what we had done with objects in the System/38? Many types of objects, such as queues, indexes, and data spaces, were themselves well-defined, highly tested, and highly stable subsystems, and they had been used as components of many more complex objects .
Another book that was important to me was The Conscious Brain. In this book, Rose introduced me to the importance of hierarchical levels of structure and the concept of emergent properties. The human brain, Rose points out, can be examined at many different levels of detail: in terms of particle physics, chemistry, cellular biology, and brain anatomy. At none of these levels can human consciousness be inferred, but this does not mean that consciousness exists apart, supernaturally, from the overall brain system. At each level, subsystems exhibit new properties that "emerge" from the interactions of their component subsystems. These properties cannot be easily inferred from an examination of just the components; they are new.
A simple example of emergent properties is water. Composed of two atoms of Hydrogen and one atom of Oxygen, the water molecule has properties that are amazing. Water has relatively high freezing and boiling points. The difference between the freezing and boiling points is broad. It is an almost universal solvent. It is incompressible. And when it freezes, water expands and floats. All of this is apparently the result of the angle at which the Hydrogen and Oxygen atoms combine, due to their electrical charges. But looking just at the Hydrogen and Oxygen atoms, few of the properties of water can be inferred.
The concept of hierarchical levels of structure, Rose pointed out, is really an artifact of human science, and there are many exceptions that seem to violate the levels. For examples, viruses seem to fit somewhere between the levels of complex molecules and true cells. The exceptions don't really matter because the levels themselves are essentially just abstractions of things that happen to share some of the same properties. For example, cells can self-replicate and they have an external membrane that encloses all of the substance and mechanisms of the cell. There are many types of cells, with a wide variety of different internal mechanisms, but because they can all self-replicate and they all have an external membrane, we call them all cells.
I wondered, could these concepts of hierarchical levels and emergent properties be combined with Simon's views on subsystems and applied to the design of software systems? The whole point of programming, after all, is the creation of new subsystems that exhibit new properties. And clearly, many subsystems share common properties. Would it be possible and useful to define software systems in terms of hierarchical levels whose components share common, emergent properties?
And then, I read The Dancing Wu Lee Masters by Gary Zukov. A tremendous amount of fun to read, this book is a popularization of the concepts of modern particle physics (at least as of the late 1970s). From it, I picked up two main ideas. The first is that we really have no way of knowing whether particles really exist. The best we can say is that experiments identify certain properties of matter, such as mass, charge, spin, and energy level that seem to go together in clumps. Some of these clumps of properties are called electrons, others are called protons, and so forth. In fact, physicists have postulated the existence of certain particles by defining clumps of properties that they thought it should be possible to find, and in some cases have succeeded in finding them.
The second idea is that there are really three different ways of looking at the real world: in terms of matter, in terms of energy, and in terms of interactions. Physicists use whichever way is most convenient for whatever they are doing, and perhaps software designers should also. I had initially been trained as a programmer to focus on the description of processes, but my experience with the System/38 put more emphasis on objects, and my work on the Message Handler had been focused on communications. Was there some way these ideas could be brought together in a better way to help us to define better software systems? Just within IBM, I knew of people who were focused almost exclusively, and competitively, on programming languages, databases, or communications. They paid only the barest amount of attention to the other conceptual orientations. Could a new approach be defined that would unify these orientations and revolutionize software design and development?
My head swimming with new ideas, I wrote a paper that attempted to build an analogy between Particle Physics as I understood it from Zukov's book, and information systems. The title of the paper was On the Objects of Information Systems: A Physical Analogy, and I did my best to draw lessons from the ways in which physicists thought about particles that could be applied to the design of software. I sent the paper to a refereed journal. One referee thought the whole idea of the paper was nonsense. The second referee commended me on my good taste in topics, but ripped my paper to shreds. And the third, who must have been a physicist, simply commented that neither Zukov or I had any idea what modern particle physics was really all about. I'm not one to give up easily and I was tempted to press on and address the points made by the second referee, but something else happened that prevented this.
My third line manager at this time was Jim Flynn, and his office was just down the hall from mine. One day, he stuck his head in my office and asked me to join him in his.
"Rich," he said "what are you working on? I can tell you're busier than hell and putting in all kinds of crazy hours, but no one I've asked has any idea what it's all about."
As succinctly as possible, I explained that I was trying to develop new ways of thinking about objects that would make application programming easier on the next system.
"What next system?" he asked.
"The one that Advanced Systems Architecture was formed to work on." I replied.
"Can't you see that we're struggling to get the System/38 out the door? And even if it's a success, it's more than likely that we'll just keep enhancing it over a series of releases. The next new system is years, if ever, in the future. So what am I going to do with you?" he asked. "You were asked to help out on performance testing, but you didn't want to do that."
"Whoa." I said. "It wasn't that I didn't want to help. I just didn't have the skills they needed."
"Well have you done anything to pick up those skills since then?"
"No" I admitted. "I thought we were going to start doing advanced architecture work and that I'd be into that again."
"Rich," Jim said "you may be doing absolutely great work, but I have no way of knowing it, and I can't use it on the System/38. Maybe it's time for us to find you a job that's better suited to your talents."
Over the next week, we identified three different jobs that Jim and I both thought could use my skills, one as an architect with the mainframe architecture department in Poughkeepsie, one as a teacher at IBM's Systems Research Institute in Manhattan, and one with a new project being formed in the T. J. Watson Research Center in Yorktown Heights, NY. I interviewed in all three areas and chose the job at the Watson Research Center.
The Advanced Systems Architecture department was disbanded.
Of course, I wasn't the only one who had been thinking about programming in terms of objects. Throughout the 1970s, a team under Alan Kay at the Xerox research center in Palo Alto, CA (Xerox Parc) had been quietly developing the Smalltalk programming language and development environment. When it was finally announced to the public in late 1980, I knew I'd seen the promised land of programming, but that's another story.
1980: Le bureau pour l'architecture des systèmes avances
Désolé, pas encore traduit.