Mad Dog 21/21: Classical Architecture
August 13, 2007 Hesh Wiener
|
In the 16th century, the Italian architect Andrea Palladio designed buildings that reached back 2,000 years to the golden age of Greece for their inspiration. Two hundred years later, during what would be called the neoclassical period, Thomas Jefferson built Monticello, a tribute to Palladio’s work. Even today, classical architecture remains an influence in the construction of buildings that are intended to be monuments to governmental power, educational prowess, or financial strength. Computers have architectures, too, and some of them are indeed classical in their own way. IBM‘s computer architects, at their best, understand classical aesthetics. IBM’s system designers may not be at their best right now, though. They seem to be taking their computers from classic to Byzantine. Users’ technical teams are trying to adapt, moving in the directions taken by IBM’s various product lines. But even with their best efforts, even with IBM’s support personnel behind them, there is a point at which computer systems can become so ornate that it is no longer practical for most users to extend, support, or even properly maintain their applications. At that point, customers may freeze their technology, emphasizing preservation over progress. And they may start shopping for alternatives.
It’s not quite back to basics, because in computing even the simplest systems continue to evolve. But it is a search for new standards, standards that differ from those IBM favors. The standards these users seek are ones that attract a large pool of talent, and particularly the kind of talent that engages in lively, open dialogs. When a computing architecture or software environment gives birth to a lively user community, it produces helpful knowledge bases, libraries of reference materials, and a pool of places users can turn for advice that’s not available as a download or a book. Similarly, the growing standards communities attract ambitious suppliers of goods and services. The competition makes for superior value today and the promise of even better value in the future. This value is self-evident to users. By contrast, the value of systems and software that are not surrounded by substantial communities is not as easy to identify. Suppliers have to persuade customers that their products and services are worth the price, and that effort adds to vendors’ costs; it’s a strategy that has within it an element of self-defeat. In all its product lines, IBM faces the contradiction between classicism and innovation that to some extent distinguishes its offerings from the classics. Its difficulty is most acute in proprietary System z and System i platforms, but it is also a factor in its somewhat more standardized System p products. The System p server runs a Unix environment, but Unix on Power is not a uniform standard, even though at its core it has many of the characteristics of a classic. IBM is most classical in its System x line, of course. Wherever IBM has strayed from classical designs, it creates dilemmas for itself and its customers. Classical Greek architecture was an expression of the finest accomplishments of the culture that gave it life. It was a tangible result of Greek intellectual life. It took advantage of the educational process of the Golden Age, which encouraged creative thought in philosophy, mathematics, and science. (Yet that same society, most often tolerant of unpopular notions, sometimes punished its intellectuals for their controversial ideas, and the punishments included death, as evidenced by Socrates.) The Greeks also took full advantage of a bustling economy, advances in maritime technology, and considerable military prowess. Best of all, the Greeks left excellent records of their civilization in the form of buildings, statues, manuscripts, and an oral culture that crossed linguistic and cultural boundaries with remarkable success.
When the Greeks were overtaken (but not overwhelmed) by Rome, their aesthetics, learning, and ideas survived, sometimes intact, sometimes as an influence, sometimes as relics that were clearly too valuable to discard. The Romans had a different climate and, as their empire grew large, a more diverse one, too. They had access to different raw materials. They also brought manmade materials, notably concrete, into wide use. They augmented the straight lines of the Greeks with founded arches, a development that later led to even more sophisticated mechanisms for supporting heavy structural loads, including the Gothic vaults used to this day in cathedrals and elsewhere. The Romans also developed hydraulic systems that were far beyond anything built by the Greeks; portions of these systems still function beneath the streets of Rome. Of all IBM’s classics, the most outstanding single example is the System/360, which is not only an ancestor of today’s mainframes but also served as an inspiration for other system architectures that have become classics. X86 and now X64 processors from Intel and Advanced Micro Devices descend from 8- and 16-bit chips that were unquestionably influenced by the System/360, not so much in mimicry but as a foundation and inspiration, much the way classical Greek architecture contributed to classical Roman architecture. While there were dozens of CISC processors introduced over the years, nearly all of them with truly valuable characteristics, none stand out the way the IBM System 360 and the Intel 8086 do. Another IBM classic is its RISC processor concept, which grew into today’s Power family of chips and their cousins the Cell circuits. Power is hardly alone in the RISC world, and some technologists argue that other processor families, such as Sun Microsystems‘s Sparc, are also classic examples of chip architecture. Still, no computer scientist would argue that the Power design is less than a classic, nor would one deny the System/360 its prominence. IBM’s efforts in the X64 realm adhere to architectural standards that retain classical characteristics in part because IBM has no choice but to stay in step with the rest of the industry. IBM does not offer an operating system for its System x processors and instead supports versions of Windows and Linux, sometimes Solaris, and probably SCO Unix but IBM doesn’t want to talk about that; ditto for NetWare. Similarly, System x card slots and other physical interfaces also have to address recognized standards that exist outside the IBM realm. IBM might wish to make more aspects of its X64 servers proprietary, both to gain a advantage on its competitors and to lock customers into its products, but it seems it cannot.
Two results of IBM’s adherence to standards are greater freedom for customers to switch hardware vendors and to use peripherals from alternative sources and sales growth that in the most recent quarter was more twice as great as its fast-selling System p machines and four times that of its flagship mainframe line. (There can be no meaningful mathematical comparison with System i sales for the second quarter of 2007, because System i revenue growth went negative, as it has for nearly two years.) IBM’s System p Unix systems have retained many of the characteristics common to RISC/Unix technology, but over the years the processors in these machines have become far more complex. The resulting chips don’t seem to have reduced instruction sets, even though that is the term still applied to circuits with certain architectural characteristics. While there is support for Linux in the System p line, customers generally run IBM’s AIX Unix variant. The System p servers support alternatives to IBM’s DB2 database software, such as databases from Oracle and Sybase as well as IBM’s acquired Informix database , and other software for the System p is also available for use with other popular Unix platforms, such as those from Sun and Hewlett-Packard. Nevertheless, users who install complex clusters of System p servers have to become experts in technology that is unique to that product line and, very likely, unique to current and recent generations of System p servers, too. Platform migration in the Unix world is more challenging than in the Linux or Windows worlds. Customers may not be locked in, but neither are they free do move from one vendor’s hardware to another the way they are in X86 and X64 country. IBM clearly faces more competition in the Unix market than in its proprietary segments, but less than it faces in the X64 realm. IBM is constantly boosting the capabilities of its Power processor chips in an effort to stay ahead of its rivals–roughly every three years there is a new generation of Power chips, with an architectural tweak every year and a half or so. To a somewhat smaller extent than in the X64 world, users understandably feel that IBM must respond to competitive pressures and this pace in Power chip development helps them trust the System p line to deliver good value for money. Nonetheless, the System p products have lost some of the clarity and simplicity that made it a classic in its earlier generations. The technologies used for clustering, fault management, and virtualization differentiate today’s System p from other platforms, including older models in its own line. (A lot of this technology, of course, was imported from the AS/400, iSeries, and System i lines, but the Unix gurus never cop to this fact.) It is more likely than not that IBM will discover that there are limits on its deviation from classical principles, but for now customers seem to be satisfied that they can master the System p or, when they can’t, that there is ample support available from outside sources. If, on the other hand, IBM completely abandons the classical roots of the System p and the product line becomes as hairy as a bear with minoxidil, it might be able to get higher margins on what it sells, but it will have a harder time hitting its top line targets.
The System i is an example of a system that might have become a classic but which somehow failed to attain that stature. Conceptually, at birth as either the System/38 or the AS/400 (you decide), it embodied a brilliant concept: For small- and medium-sized business users (and maybe big ones, too), making the database system a fully integrated part of the environment could simplify and standardize application development and maintenance. However, IBM did not go far enough. It did not offer application components that brought sophisticated information processing well within the reach of programmers with only modest training. IBM did not do for the application programming interface what Apple and later Microsoft did for the personal computer user interface. It’s hard to say why this was so. Perhaps it was a failure of courage on the part of an IBM afraid to offend the application developers who had supported the System i’s predecessors (not merely the AS/400, which is really the same line by another name, but also the System/34 and System/38 communities). If that was the case, IBM called it wrong. Many of these developers have long since made Windows or Linux a priority anyway, and in doing so have put the System i at a disadvantage. IBM needed to trust a visionary, and it didn’t, maybe because it lacked one, maybe because it could not abide that kind of trust. IBM suffered another coward’s fate as it incorporated X86 processors into its System i boxes. IBM tacitly admitted that there was software and functionality in the classic X86 that it needed to provide complete solutions to its System i users. But IBM did not have the nerve to port the entire System i to X86 or Itanium chips. Instead, over the years it went from homegrown CISC chips to Power processors. That was very patriotic, but the result has been nothing but heartbreak. These days, Apple‘s success in PCs is proof that the classical X86 platform is not the exclusive domain of Windows and, on the server side, Windows plus Linux. If Apple offered servers with an embedded and well integrated database engine, plus a surrounding collection of widgets and development aids, it would not only pick up a slice of the Windows and Linux markets, it would decimate the System i base, at least at the low end, because it would have fulfilled the promise of classical simplicity that IBM used to win over (and, too often, later break) the hearts of System i users. IBM could still do what it once set out to do. It’s not too late yet. But IBM can’t take forever. If the company thinks that all its System i problems will be ameliorated by a new line of processors based on Power6 chips, it is bound to be frustrated. It should have long since considered implementing the System i software stack on industry standard hardware.
During the eighteenth century, England went through a period of great philosophical growth known as the Enlightenment. It coincided with progress in science and industry, with advances in nautical technology, and with the growth of wealth outside the direct reach of royalty, particularly in its colonies. At the same time, the most promising British colonies were feeling their oats. The upshot was the American Revolution. During that same period, in England and what would become the United States of America (and elsewhere) there was a renewed appreciation of classical Greek and to a lesser extent Roman architecture. This particular aspect of the times was not a leading development, but in fact a belated echo of an architectural rival that took place in Italy a couple hundred years before. Architects, most notably Andrea Palladio, expressed the classical concepts of Golden Age Greece using more modern materials and applied these concepts to buildings that were quite different from those for which the classical Greeks are best known. Thomas Jefferson, one of the finest minds behind the American Revolution, felt that his young country, with its return to classical social principles, should express itself in classical architecture. He actually did what he though was appropriate, and built a home called Monticello that interpreted Palladian ideas in the context of climate, materials, and workers’ skills that was available to him in Virginia. Classical or more accurately neoclassical architecture figures prominently in the major buildings that make central Washington, DC, such a beautiful and uplifting national capital. Things could have gone quite another way, architecturally speaking, in the young USA, but they didn’t, and the result is a lot greater than just another pretty city. The neoclassical structures in Washington are a powerful reminder of the principles of liberty and thought and personal freedom on which America was founded and from which it achieved greatness. IBM might be able to have a neoclassical period of its own, and the System i would be great place for it to start. To do so, its management would have to find something in its spirit that is pretty much invisible these days. IBM, at the very top, would have to stop putting all its energy into chasing deals and instead seek to truly renew its classical spirit. The most unsettling example of IBM’s loss of vision can be seen in the System z line, which is the basis of a very large portion of IBM’s income. System z is a lot more than a hardware platform. It is the source of a huge software market, a segment where, mainly by acquisition, IBM has been able to boost its revenue even as the mainframe base, which once included medium-sized as well as large enterprises, retreats to higher ground. The mainframe is also at the heart of IBM’s services business. IBM’s future in services necessarily includes the rewards and risks experienced by the System z in the application platform market at large. IBM has gone off in a direction with its mainframes that may threaten this product line’s stature as a classic. What IBM has done is to emphasize specialty engines, processors that give its true mainframe architecture a reduced role, that of a facade. On the surface, the mainframe may still look to like a mainframe, at least to users. But inside, IBM has essentially said that it will hide other kinds of systems, created by using microcode to enable its mainframe engines to act more like X86 or RISC engines as they shoulder portions of what might have otherwise been a true mainframe workload. Mainframe Linux engines are the most popular of these specialty processors. They are very similar to ordinary mainframe engines; they are dedicated to Linux because IBM’s microcode limits them to this role, not because they have been drastically altered. These engines don’t provide raw price/performance that is a match for that of a modern X64 box. But in the larger context of a big computing shop that benefits from server consolidation, these engines present acceptable value . . . as long as IBM sells them for a low enough price. Linux engines don’t address the challenge posed to mainframes by Windows servers, though, and that is turning out to be a marketing problem IBM cannot so easily address. Other specialty engines help with Java and with database performance, in both cases by providing a boost to the mainframe at a reduced price compared to a standard mainframe engine. The only reason these engines make sense to IBM must be a business model somewhere inside the company that shows these engines produce a more favorable business outcome than, say, across-the-board price cuts that would make real mainframe engines more economical.
IBM says its strategy is working, but of course the way the strategy is implemented users don’t really have a choice. They have to do things IBM’s way or pay a hefty premium for computing power in their standard engines. The premium is not only hardware cost, but also software cost, because IBM’s software licensing plans greatly amplify the cost of every processor upgrade. The one company that truly honors the classical aspect of the mainframe architecture while overtly promoting the benefits of other architectures is Platform Solutions, which offers HP Itanium boxes that implement the mainframe architecture in microcode and at the same time provide Itanium support for Windows, Linux, and HP’s HP-UX Unix variant. IBM’s legal onslaught has made it very hard for Platform to sell its machines, but that hasn’t kept mainframe uses and others from seeing that the IBM mainframe is a very expensive solution. A user really has to want that mainframe, because if all the user wanted was a computing engine the mainframe would be a luxury. IBM is obviously feeling the impact of its strategy. In its most recent quarter, it was only able to squeeze out a 4 percent increase in mainframe sales (and only 1 percent were it not for favorable currency translation) while shipping 45 percent more computing power as measured in MIPS. If IBM has to keep pumping out half again as many MIPS as it did in the past just to beat break-even in mainframe revenue, it might eventually want to check out that business model it’s using. It could be that the model is right, and the mainframe is in a lot more trouble than it seems. But it could also be the case that the model fails to recognize the classical beauty of the IBM mainframe and take into account that there would be real price elasticity in that segment if IBM took a fresh look at its hardware and software pricing. But IBM seems to see only the Windows and Linux barbarians who would like to sack its mainframe empire and destroy its classical values along the way. If there’s a better solution than IBM has found so far, and there may very well be at least one, IBM’s leadership appears to be unable to find it. Palmisano is not Palladio.
|
