NEWS AT SEI
This library item is related to the following area(s) of work:Process Improvement
This article was originally published in News at SEI on: December 1, 2001
This is the fourth of five columns on the future of software engineering. The first two columns focused on trends in application programming, particularly related to quality and staffing. The previous column covered systems programming and the systems-programming business. In this column, I explain the three kinds of operating-systems (OS) businesses and predict where these businesses are likely to go in the future.
To refresh your memory, the principal points made in the previous column were as follows:
The principal conclusion of the previous column was that a standalone business for operating systems is not viable over the long term. Ultimately, the supply of attractive new functions will be depleted. Then, while people will need occasional enhancements and new operating-system versions for new hardware, they will prefer to stay with their existing operating-system version, rather than buy a new one. This rather stable operating-system business will likely be viable, but it will be very different from what we know today.
Even though the operating-system business will probably not survive by itself, it would be a natural companion to a hardware business. In that case, you might expect the hardware companies to absorb the operating-systems businesses. However, in today's world, it seems more likely that the operating-systems businesses will absorb the hardware companies.
One might argue that the Internet changes everything. It is true that the Internet is a radical change and that it presents enormous opportunities for innovation and creativity. However, since the Internet revolution is still in its infancy, there are likely to be many surprises. But, since I am being controversial in this column, I might as well stick my neck out and hazard some predictions.
One likely way to couple computers and the Internet would be essentially to move the Internet inside the application programming interface (API). This would use the Internet to reference data and programs, regardless of their physical location. It would also presumably permit multiple remote systems to cooperate much as they could if they were at the same location. Producing these capabilities would be a substantial challenge and, when accomplished, would provide a glorified data, file management, and distributed computing capability. While such offerings will almost certainly be started by the software businesses, the Internet can be viewed as just another device. As advantageous as this Internet capability would be, its support would best be handled by hardware. Ultimately, the most efficient and cost-effective way to handle device support is as a hardware facility and not as a new operating-system function.
Second, the idea that people will use the Internet as a pervasive computing resource is not realistic. People will certainly use the Internet for communications, for retrieving programs and data, and for incidental and cooperative processing. However, most will not use it as some kind of computing utility, and anyone who believes they will does not understand history. The problem is not communication speed or computing capacity. We had computing centers decades ago with fast access and private terminals. Even when computing power greatly exceeded people’s needs, users were not satisfied with remote support. The problem was not technical; it was both personal and political. People simply wanted to control the resources they needed, and no amount of remote capacity could satisfy them. This was true then and, as computing capability becomes less and less expensive, it is inconceivable to me that people will want to use remote computers for their bread-and-butter needs. This will be particularly true when they can get supercomputer power of their own for less than it costs to buy the desk on which they will put it.
This implies that the advent of application service providers (ASPs) is an anomaly. Asps provide computing capability, essentially as a utility. Many view Asps as the wave of the future and have invested a great deal of money in them. While it is possible that Asps will become big business, the prime reason that organizations subscribe to Asps is to avoid the cost and expense of operating their own computing systems .
In essence, the reason that the ASP business is attractive is not because it is a fundamentally new way of doing business. It is attractive as a way to avoid the costs and headaches of current computing systems. This implies that the entire ASP industry depends on our inability to make computing systems that are easy for the public to install and use. However, depending on the continued unresponsive performance of an entire industry is highly risky. That may be a viable strategy for a niche offering, but now that the ASP and software service businesses are growing faster and generating more profit than all other parts of the computer industry combined, we can expect things to change.
There is no question that many organizations can make a great deal of money operating computing facilities for their clients. However, this business presents a tempting target for someone to produce a computing system that is so simple to install and operate that most people could do it with little or no training. Then, much of this service industry would be replaced by a new class of highly usable systems. Of course, there would still be three important parts of the software service business that would not go away:
While these three categories are all likely to be important businesses, they are not the principal reason that most organizations currently use Asps Most do so to avoid the cost and aggravation of installing, maintaining, and using their computer systems.
Before concluding my argument for why a standalone operating-system business is not viable, I must comment on timing. I started preaching about the importance of usability many years ago. At the time, I was IBM’s director of programming and the company’s 4,000 systems programmers all worked for me. While I should have been able to affect what they did, and while nobody disagreed with me, I was unable to get much done. Since many others have long preached the same usability story, you might wonder why so little has been accomplished. I have concluded that there are four reasons:
This suggests that the current ASP and software service businesses are likely to be viable for many years, but not forever.
In exploring what is likely to happen in the future, we must first consider the three main kinds of operating-systems businesses and their characteristics. These three business types are as follows:
In the hardware-coupled operating-systems business, the objective has been to sell hardware. In projecting what will happen in the future, the automobile industry provides a useful analogy. For the first 50 years or so, automobile technology was engine-centric. That is, the design and marketing of automobiles featured the engine’s power and reliability. Leading up to and following World War II, however, this changed. While engines continued to be important, they were no longer a principal discriminator in the buying decision. In fact, today, few people could tell you the horsepower or displacement of their car’s engine. The last 50 years or so of the automobile industry have been largely dominated by comfort, style, service, and economy. We are also beginning to see safety, quality, and environmental concerns emerge as important buying discriminators.
This suggests that the hardware-coupled OS business will evolve from selling power, cost, and function to featuring usability, installability, reliability, and security. Since the hardware and software are likely to be marketed together, there will be little motivation to add capabilities that do not sell new systems. The profit motive would also limit new functions and features to those that could be financially justified. Since this is precisely the kind of business IBM had before we unbundled software, experience shows that operating-systems development will be tightly constrained and that there will be little motivation to add features purely to improve the capabilities of the existing systems. The key is what sells new products.
Not surprisingly, the objective of the standalone operating-systems business is to sell operating systems. Since one of the principal ways to sell them is with new hardware, we can expect the OS vendors to strive to increase the market for the hardware that uses their systems. While selling new operating systems with new hardware is an attractive business, it is largely captive to the ups and downs of the hardware business. This suggests that operating-systems vendors will add functions and features to make their systems attractive to installed hardware users. These OS vendors will then urge the customers to upgrade to the new operating systems without necessarily buying new hardware.
Because of the growing volume of application programs and because of the necessity of continuing to support an increasing number of old applications with every new OS version, the API must become progressively more stable. It might even become public. Then, possibly many years down the road, some clever and well-financed entrepreneur will produce a new OS that emulates the API of one or more of the dominant operating systems. This new operating system would presumably integrate the latest hardware and software technology to offer dramatically improved performance, usability, reliability, and security. Since the stand-alone OS suppliers would have trouble competing with software alone, they would either have to team up with hardware suppliers or lose much of their business.
The third case is the open-source OS business. Here, the motives are entirely different. There is no desire to sell new hardware or software, only to provide a more usable, installable, reliable, and secure system. The great attractiveness of the open-source OS business is that it caters to the desires of a steadily growing body of installed users. These people feel that their current systems are marginally adequate and do not want to change or evolve their OS versions. They are not even terribly interested in the latest “gee-whiz” chip. They would just like installable, usable, reliable, maintainable, and secure systems that do precisely what their current systems do. While the operating-systems suppliers could largely eliminate the attractiveness of the open-system offerings by dramatically improving the user characteristics of their systems, that is not likely to happen very quickly. As a result, the open-source business will likely continue to grow. This also suggests that the open-source movement is, at least to some degree, competing with the software service and ASP suppliers.
All of the preceding argument has ignored an important segment of the software industry: middleware. By middleware, I mean that growing family of programs that are used to administer, support, and use computing systems. This kind of software includes programs to handle administrative, operational, and support activities; provide support for application development; and furnish generic application support for system developers and users. Since, as I noted in the first column of this series, the volume of application programs will continue to grow for the foreseeable future, all of these middleware categories are also likely to continue to grow.
The challenges in the middleware business include all of the challenges of starting and running a new business in a competitive industry. They also include the challenge of resisting the threats and blandishments of the OS suppliers. Middleware businesses really are in the middle. While they must have creative and marketable ideas and the funds and know-how to start and run a business, once their ideas are financially successful, they become attractive targets. Since all three types of operating-systems businesses must continually add features to their systems to survive, the natural trend will be for the OS suppliers to incorporate the most attractive middleware features into their systems. They might either acquire the middleware companies or simply appropriate their ideas. This suggests that most middleware businesses will be transient. While they are likely to continue to be valuable sources of innovation, they will have to do four things to survive:
While the current situation is likely to continue essentially as it is today, at least for many years, technology will ultimately win, and we will see the standalone operating-system business merge into the larger computing-systems business. This, I am convinced, is the long-term answer. However, since the nature of the first two types of operating-systems businesses has been essentially static for more than 20 years, the long term could be very long indeed.
In my next column, I will explain what these trends in applications and systems programming mean for software engineering and what they mean for each of us.
In writing papers and columns, I make a practice of asking associates to review early drafts. For this column, I particularly appreciate the helpful comments and suggestions of Marsha Pomeroy-Huff, Jim McHale, Julia Mullaney, and Bill Peterson.
In closing, an invitation to readers
In these columns, I discuss software issues and the impact of quality and process on engineers and their organizations. However, I am most interested in addressing issues that you feel are important. So, please drop me a note with your comments, questions, or suggestions. I will read your notes and consider them in planning future columns.
Thanks for your attention and please stay tuned in.
Watts S. Humphrey
 Kerstetter, Jim, "Software Shakeout," Business Week, March 5, 2001, pp 72-80.
Watts S. Humphrey founded the Software Process Program at the SEI. He is a fellow of the institute and is a research scientist on its staff. From 1959 to 1986, he was associated with IBM Corporation, where he was director of programming quality and process. His publications include many technical papers and six books. His most recent books are Managing the Software Process (1989), A Discipline for Software Engineering (1995), Managing Technical People (1996), and Introduction to the Personal Software ProcessSM (1997). He holds five U.S. patents. He is a member of the Association for Computing Machinery, a fellow of the Institute for Electrical and Electronics Engineers, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners. He holds a BS in physics from the University of Chicago, an MS in physics from the Illinois Institute of Technology, and an MBA from the University of Chicago.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.