Bienvenue chez nous!
Logo Ex Libris

The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad

  • Livre Relié
  • 352 Nombre de pages
(0) Donner la première évaluation
Évaluations
(0)
(0)
(0)
(0)
(0)
Afficher toutes les évaluations
Informationen zum Autor Michael A. Cusumano is the Sloan Management Review Distinguished Professor at the MIT Sloan School of Man... Lire la suite
CHF 35.90
Habituellement expédié sous 3 semaines.

Description

Informationen zum Autor

Michael A. Cusumano is the Sloan Management Review Distinguished Professor at the MIT Sloan School of Management and one of the world's leading authorities on software development and the management of software companies. He is the author or coauthor of seven other books, including the bestsellers "Microsoft Secrets" and "Competing on Internet Time," as well as "Japan's Software Factories" and most recently "Platform Leadership."





Auteur
Michael A. Cusumano is the Sloan Management Review Distinguished Professor at the MIT Sloan School of Management and one of the world's leading authorities on software development and the management of software companies. He is the author or coauthor of seven other books, including the bestsellers Microsoft Secrets and Competing on Internet Time, as well as Japan's Software Factories and most recently Platform Leadership.

Texte du rabat

A leading expert on the global software industry reveals the inner working of software giants like IBM, Microsoft, and Netscape, and shows what it takes to create, develop, and manage a successful company--in good times and bad--in the most fiercely competitive business in the world.



Résumé
The world's leading expert on the global software industry and coauthor of the bestseller Microsoft Secrets reveals the inner workings of software giants like IBM, Microsoft, and Netscape and shows what it takes to create, develop, and manage a successful company -- in good times and bad -- in the most fiercely competitive business in the world.
In the $600 billion software industry it is the business, not the technology, that determines success or failure. This fact -- one that thousands of once glamorous start-ups have unhappily discovered for themselves -- is the well-documented conclusion of this enormously readable and revealing new book by Michael Cusumano, based on nearly twenty years of research and consulting with software producers around the world.
Cusumano builds on dozens of personal experiences and case studies to show how issues of strategy and organization are irrevocably linked with those of managing the technology and demonstrates that a thorough understanding of these issues is vital to success. At the heart of the book Cusumano poses seven questions that underpin a three-pronged management framework. He argues that companies must adopt one of three basic business models: become a products company at one end of the strategic spectrum, a services company at the other end, or a hybrid solutions company in between. The author describes the characteristics of the different models, evaluates their strengths and weaknesses, and shows how each is more or less appropriate for different stages in the evolution of a business as well as in good versus bad economic times. Readers will also find invaluable Cusumano's treatment of software development issues ranging from architecture and teams to project management and testing, as well as two chapters devoted to what it takes to create a successful software start-up. Highlights include eight fundamental guidelines for evaluating potential software winners and Cusumano's probing analysis, based on firsthand knowledge, of ten start-ups that have met with varying degrees of success.
The Business of Software is timely essential reading for managers, programmers, entrepreneurs, and others who follow the global software industry.

Échantillon de lecture
Chapter 1

The Business of Software: A Personal View

If the software business were like other businesses, there would be no need for this book. But software is not like other businesses. First of all, the technology consists of a digital "soft" good -- usually English-like programming commands eventually translated into zeros and ones -- that provide instructions to a computer. These instructions form products that companies can standardize for many users, customize for individual users, or do something in between. Companies that rely on this highly malleable technology for their livelihoods must be unique in many ways, particularly in how they deal with business models, product strategy, people (especially software engineers), and management of a core activity: software development.

There are many examples of how software technology and software companies differ from what we see in traditional manufacturing and service industries. In how many businesses does making one copy or one million copies of your product cost about the same? How many businesses have up to 99 percent gross profit margins for their product sales? In how many businesses do many products companies eventually become services or hybrid companies (that is, providing some customization of product features and technical services such as system integration and maintenance), whether they like it or not? In how many businesses is there frequently a ten- or twentyfold difference in productivity between your best employee and your worst one? How many businesses tolerate some 75 to 80 percent of their product-development projects routinely being late and over budget, with "best practice" considered to be 20 percent on time? How about a company where the people who build products often consider themselves artists rather than scientists or engineers and have the mercurial temperament to go with it? In how many businesses are customers "locked in" to a particular vendor because of product decisions someone made a decade or two ago that can't easily be reversed?

The software business also differs from conventional industries because it is not really one kind of business. Software becomes whatever function or application it addresses. This means that the range of possible products and services is almost infinite. Software can help you write a report, calculate your taxes, build a bridge, navigate an automobile, control the space shuttle, or dial your telephone. Not surprisingly, there are many categories and even layers of software products and customized programs that work with one another to form complete systems (such as networking software with operating systems, and operating systems with applications). The definitions of these categories and layers are relatively well accepted, though Microsoft and other companies have been blurring the traditional distinctions for many years.

These and other observations describe aspects of software technology, software companies, and the software business. They also describe some other high-tech markets, such as telecommunications and various types of businesses heavily dependent on information systems and digital content. But surely these observations describe an unusual type of business.

As I discuss in Chapters 2 and 3, get the strategy and the management side right, and the software business can be like having a license to print money. Just ask Bill Gates of Microsoft or Larry Ellison of Oracle, among many other software billionaires and multimillionaires around the world. But get the business model wrong, and -- to borrow a metaphor from Frederick Brooks's The Mythical Man-Month -- software companies can resemble dinosaurs futilely trying to escape the death grip of an ancient tar pit. The more you struggle -- that is, the more time, money, and people you pour into product development, sales, and marketing in the hope of a turnaround -- the deeper you sink and the quicker you die. In the software business, this is not only because the more people you add to a late software project, the later the project can become -- a rule of thumb now described as "Brooks's law" (and not always true). But the broader downward spiral can accelerate for a whole company and become self-fulfilling as present and potential customers flee from software producers unlikely to survive long enough to deliver, support, and upgrade their products.

In bad economic times, or when there is bad corporate news, we can see the sales of once high-flying software companies suddenly drop as if they had fallen off a cliff. Billion-dollar companies can shrink to half their peak size (e.g., i2 Technologies), declare bankruptcy almost overnight (e.g., Baan), or turn suddenly from modern-day gold mines into investment nightmares. SAP, Oracle, Siebel Systems, Business Objects, and many other blue-chip software companies lost 80 to 90 percent of their value at one time or another during 2000-2002, depending on when an investor bought the stock -- despite having solid products and businesses. Even Microsoft dropped about two thirds of its value during this period of boom and bust. We have seen this phenomenon of rapid growth and dramatic decline as well in the telecommunications equipment and services industries (e.g., Lucent and WorldCom), businesses that are also heavily based on software technology but even more distressed in terms of profits and sales.

Since software technology, software companies, their people, and their markets have unique challenges and opportunities, I believe that the business requires a unique approach to strategy and management. For example, software managers, programmers, and entrepreneurs need to encourage innovation wherever and whenever they can, but they have a special need to contain it as well; otherwise projects and plans can spin out of control. Perhaps most important, a large number of software companies -- those selling "enterprise software" to other companies and large organizations -- have to be nimble enough to tailor their products and their strategies to the needs of individual users and particular kinds of customers. Often they must survive the transition from selling high-margin products to selling low-margin services, especially in bad economic times and as their products and customer bases age.

This last idea -- that many software companies need to sell both products and services to maintain a successful business -- is a central theme throughout this book. I argue in Chapter 2 that there are basically three business models that fall along a spectrum: On one end are software products companies, which get all or most of their revenues from new product sales (called "software license fees"). On the opposite end are software services companies, which get a majority of their revenues from IT consulting, custom software development, integration work, technical support, systems maintenance, and related activities. In the middle are what I call hybrid solutions companies -- software firms that have some new product sales but derive as much as 80 percent of their revenues from services and "maintenance" (incremental product updates or special enhancements sold through long-term contracts to the purchasers of the initial software license).

I also argue that even companies trying to emphasize products eventually end up selling more services and incremental maintenance upgrades to their existing customer base than new products to new customers. They often fall unwittingly into the services or hybrid business models and are not prepared for the change. Bad economic times can accelerate this transition as customers postpone purchases of new software products. It also seems an almost inevitable transition for software companies that sell to corporate customers (enterprises): their revenues increasingly consist of sales of services and maintenance upgrades to existing customers, rather than new product sales to new customers. It can be devastating to a software company to find its new-software-product sales collapse, but it happens frequently. This is why managers, programmers, and entrepreneurs need to understand what the future usually holds for enterprise software companies, and how to manage and adapt to that future as effectively as possible. Accordingly, because of the potential for rapid change in the marketplace, software companies must combine extraordinary levels of structure with flexibility. Companies must pay constant attention to strategies and business models as well as continuously evolving their technical skills and core technologies. They must often experiment with new-product development while preventing projects from running years behind schedule or devolving into chaos.

Software as a Technology

How a software firm manages the technology to create and deliver products and services is usually central to its long-term success. Almost any firm can have a onetime hit product. But following this first product with multiple versions for different customer segments or with compelling updates and new services that meet future customer needs requires thought and careful management. But what does "managing the technology" mean in the context of a software producer? In this book, I treat the question in fairly straightforward terms, separating "the technology" from "technology management."

Technology Versus Management

Software technology is many things. I have already described it most directly as code -- programming instructions or algorithms, eventually translated into zeros and ones. But for practical reasons, we must also include system architectures, program designs, the data or digital content that computer programs need to do anything useful, user interfaces, application programming interfaces, programming support and testing tools, test cases, documentation, and other physical and nonphysical artifacts. Software technology also includes the effects of what programs do -- how one module of code interacts with other programs, modules, and computers, and what the whole system enables users to do.

Managing the technology in a software business primarily refers to overseeing the process of designing a software product or information system for a particular customer need and then building, testing, delivering, supporting, and enhancing that software product or system over its lifetime of use. Chapter 4 contains a lot of what I have learned about managing this chain of activities. In addition, though I do not talk much about managing the science, managing the technology should include facilitating communication between scientists pushing the state of the art and engineers building real-life applications.

From a business point of view, managing software technology well should imply knowing how to go through the phases from design to delivery at a cost that is less than the revenues generated from selling the resulting product or service. This may be common sense, but it is not always common practice. Here is where marketing and sales -- and financial discipline -- become as important as anything else in the software business. Managers, programmers, and entrepreneurs need to understand how to build or package technology and price it in a way that both makes people want to buy it and earns them a profit. Selling software and services at enormous losses (and I will discuss many examples of this, ranging from start-ups to established firms) is not a business. Many software companies waste millions and billions of dollars on development efforts, acquisitions, or marketing campaigns that generate no profitable results.

As a researcher and consultant, I have found that managing the technology well becomes a serious problem at one time or another in the lifetime of nearly all software businesses, including dedicated software companies and firms that do a lot of software development for in-house use. As I discuss in Chapter 3, IBM went through the pain of building OS/360 in the 1960s and eventually created a structured process that worked, despite a great deal of variation within the company and without much concern for flexibility or innovation. The Software Engineering Institute (SEI) at Carnegie Mellon University, to a large degree, has disseminated the best practices of IBM for large-scale systems development. The Japanese also attempted to solve problems in large-scale systems development by incorporating many practices similar to IBM's approach into their software factories of the 1970s and 1980s. Microsoft struggled mightily in the 1980s and came up with more flexible but still structured "synch-and-stabilize" techniques that worked well during the 1990s and early 2000s. Another giant, Oracle, in the early 2000s was still figuring out how to build high-quality applications the first time around. And these firms are all success stories! There are many other examples of start-ups and established firms wasting years and millions of dollars on software development, with little or nothing to show for it.

I also know of many cases (such as some of the start-ups described in Chapter 6) where the software engineers knew very well what they were doing but still failed anyway. They were able to create a prototype or small-scale system without spending too much time or money. But then problems almost always set in as these firms tried to build a commercial-grade product with more sophisticated features, or as they took on hybrid-solutions projects that rose quickly in complexity and then overwhelmed their management skills or financial resources. And even where managing development of the technology was not a major problem, understanding how to market and sell the technology they were creating was a major factor in their struggles or demise. As Chris Peters of Microsoft once said, it is just as important in software development to decide what you are not going to do as it is to decide what you are going to do.

Because software can perform an almost infinite number of functions, the challenges of managing the technology well continue to be enormous, especially for inexperienced start-ups or established firms where software development is not the primary business. Managers, programmers, and entrepreneurs have to accommodate different kinds of projects and customer requirements, as well as anticipate changes in the technology and market needs. What do you have to think about if you are working on software for the space shuttle? It is very different from what you must think about if you are working on a video game. What software producers must do well may be the same at a high conceptual level -- they need to design, build, test, deliver, support, and maintain a product or a custom-built system. But the demands vary considerably depending on how customers will deploy the software technology in their particular applications or markets. In short, the requirements of managing software as a technology vary with the requirements of managing software as a business.

My Involvement with the Software Business

This book is very much a personal view of the software business, seen through the lens of nearly two decades of research on the industry, professional involvement with dozens of software companies and organizations, and teaching a class titled "The Software Business" at MIT since 1997. I am not a programmer, but I have been fascinated by computers since first using an IBM mainframe in college during the mid-1970s. But my first recognition that software was a special business with special problems in strategy and management came in 1985. That is when I started studying how Japanese companies built large-scale industrial software systems and were trying to add sophisticated software skills to their already formidable hardware skills. Since the late 1970s, I had been studying Japanese production and quality management techniques, particularly in automobile design and manufacturing. But I had tired of looking at this one industry and thought that the next great challenge for Japan after automobiles would be computer software.

I began the new research by reading about the history of the computer industry in Japan as well as some articles on Japanese software engineering practices. One fact immediately got my attention. Since 1969, the major Japanese computer manufacturers had been concentrating their people with software expertise in relatively large facilities and had been trying to apply the same disciplined approach to software production and quality management as they had done in "hard" manufacturing businesses. I then began to write case studies and conduct surveys of software projects and development practices at Hitachi, Toshiba, NEC, Fujitsu, NTT, and several other Japanese firms. I also studied IBM, DEC, System Development Corporation, and Andersen Consulting, among other U.S. firms, for comparisons. I learned a great deal about process and organization in mostly custom or semicustom software development for mainframe computers. But I ended up wondering why process excellence and "zero defects" did not necessarily make a company successful in software as a business.

I remember giving a press conference for the American Electronics Association's Tokyo chapter in February 1991 to announce the results of my research on Japanese software. I began with the statement that the "$60-billion-dollar question" people had been debating for years was whether or not the Japanese could write software. I said that I finally had an answer, though I divided this into "good news" and "bad news" from the point of view of American firms.

The bad news was that the Japanese could write software. In fact, they wrote a lot of software, and they wrote it as well as or better than U.S. firms in terms of reliability (few "bugs" or defects) and crude measures of productivity (code output per programmer, including large amounts of reused and semiautomatically generated code). The "factory-like" approach that the Japanese computer manufacturers used for software development also differed from the approaches common in the United States. The Japanese emphasized incremental innovation in feature design, standardized development techniques, common training programs, reusable component libraries, computer-aided support tools, rigorous quality assurance techniques, and statistical data to manage projects. The Japanese also tended to staff projects with a combination of experienced people and relatively low-skilled programmers who had merely a few months of training.

But there was also good news, again, from the perspective of U.S. firms: the Japanese approach seemed well suited for building certain kinds of software systems but not others. Moreover, Japanese companies didn't seem to know much about how to make money from software or compete outside Japan, except for software embedded in products such as programmable machine tools, VCRs, and microwave ovens. The Japanese were focused mainly on labor-intensive custom or semicustom information systems built to sell mainframe computers and targeted to Japanese customers. They had limited innovation capabilities and ambitions, although Fujitsu, NEC, and Hitachi routinely beat U.S. competitors in the Japanese market because of their quality, service, and reliability. The Japanese economy would continue to modernize through the introduction of more computers and new PC-based or workstation-based information systems. But there was no dominant global software player likely to come from Japan, except perhaps in niches such as the video game industry. (This was an area of software that the Japanese excelled in, perhaps because of their fascination with comic books from childhood through adulthood.)

After studying Japanese software factories, I decided to "follow the money," so to speak. I decided to look at the company that made the most money and seemed to care the least about the process of product development: Microsoft. As it turned out, I soon learned that Microsoft managers and programmers did care a lot about process. But compared to the approaches followed by traditional U.S., Japanese, and European software organizations, they cared in a way that was much better suited to the fast-paced and somewhat unpredictable world of PC software and, later, the Internet. Microsoft people also cared more about strategy and money than they did about following textbook processes. They were interested in dominating markets -- albeit too interested at times, so much so that the company ran afoul of antitrust laws. My new interest in Microsoft turned into another book published in 1995 with Richard Selby. In subsequent research, I continued to follow the evolution of Microsoft through the Internet age and competition with Netscape as well as into the world of .NET and Web services.

My research also created opportunities to work with approximately fifty software producers in Europe and Asia as well as the United States, beginning in 1987. These organizations include software products and services companies; computer hardware and semiconductor companies with large software businesses; financial services companies heavily dependent on software technology; and telecommunications equipment and services companies. I am also fortunate to have served on approximately a dozen boards of directors and advisers for software companies and venture capital firms in New England, Silicon Valley, and London. What I have written in this book, consequently, is colored not only by my experiences with the Japanese and Microsoft, but also from studying and working with a wide variety of software producers around the world.

Some International Generalizations

My international experiences (including residing in Japan for about seven years) have often led me to compare people and organizations in different parts of the world. Here I would like to offer some generalizations about how the software business might differ in three regions I know reasonably well: Europe, Japan, and the United States. Like all generalizations, there are exceptions. I also think these generalizations were more applicable a decade or two ago than they are today. But I believe that they still contain more than a grain of truth. They also reflect a key motivation for me to write this book: the conviction that software is too important to be treated simply as a technology, or as part of the field of computer science. Software has the power to change the world, especially when treated as a business by managers, programmers, and entrepreneurs who also want to change the world.

The Europeans

The Europeans, along with the Americans, pioneered a lot of the inventions in computer design. But too many European companies I have encountered tend to treat software as a science. The reason is not hard to understand. The Europeans have excellent university-level education in computer science, especially programming languages and principles of design. And so, from Europe, we get things such as formal methods (a way of specifying requirements for software systems in mathematical terms that can be verified and validated mathematically) and object-oriented analysis and design (a clever way of breaking up software programming instructions and data into small, reusable objects, based on certain abstraction principles and design hierarchies).

We also get from Europe enormously rich but complex applications remarkable in their detail and structure, like those the German company SAP has produced. In addition, we can find elegant but simple applications that enable nonprogrammers to query databases and generate useful reports, such as those the French company Business Objects created a decade ago around object-oriented technology. Europe has also produced stunning innovations such as the World Wide Web, invented by Tim Berners-Lee, an Englishman, while he was working at the CERN physics research lab in Switzerland. But I have often found that many European software producers place more attention on achieving elegance in software design than on shipping products for mass markets and making the most money they can from their excellent technical skills.

The Japanese

The Japanese, for much of their history, have followed IBM and a few other American companies in designing and building mainframe computer systems. Japan's computer manufacturers and software firms have shown significant skill in writing programs for all sorts of applications, ranging from real-time banking systems, to fault-free bullet train control and reservation systems, to video game software. But most of these systems are custom-built for specific customers in Japan and contain relatively few innovative features, by design. The largest Japanese producers of software mainly write code to sell hardware and services, as IBM has done for decades. The country has also underinvested in basic research and higher education. Not surprisingly, Japan has had relatively weak university training in computers and information systems. Japan has also lacked the broad diffusion of computers, knowledge of English typing, and programming expertise among young people that has led to a strong "hacker" tradition in the United States and, to a lesser extent, in Europe.

Accordingly, the major Japanese producers of software -- Fujitsu, Hitachi, NEC, Toshiba, and NTT -- have had to train most of their own people on the job and have ended up treating software development mainly as a problem in production. With some exceptions, such as game software and some more creative consumer electronics applications, the big Japanese companies I know well have tackled large-scale systems development with heuristics (engineering rules of thumb), process discipline, some capital (e.g., computer-aided tools), and manpower. Hence, we have software factories. The factories were and remain good at cranking out multiple versions of custom or semicustom applications that follow standardized design patterns and evolve little from their original parameters. Software built in this way is useful in selling hardware and performing basic tasks or making construction of third and fourth versions of similar custom systems a bit easier and cheaper. But it doesn't change the world or make anybody a billionaire.

The Americansar

And then we have the Americans. People in the United States are unmatched in treating software as a business. That is, they see software technology as a vehicle for creating dedicated software companies that produce at least "good-enough" products and try to set industry standards as well as make lots of money in the process. And so, in the United States, we have companies like Microsoft and Netscape, both of which tried to and succeeded in changing the world. Bill Gates, who cofounded Microsoft with Paul Allen in 1975, wanted to see a personal computer on every desktop and was determined that those PCs run Microsoft software. Today more than 90 percent do. Gates also had the great insight in 1975 to conclude that the future value of computing would be in software, not hardware. Marc Andreessen, who cofounded Netscape with Jim Clark in 1994, felt that an easy-to-use browser that ran on Windows as well as other software platforms would make usage of the Internet ubiquitous, for both individuals and organizations. It now is. Microsoft and Netscape went on to introduce products that were no more than "good enough" from a technical point of view: MS-DOS, Windows, and Netscape Navigator.

Of course, software programming can still be science for Americans. Like the Europeans, we have great universities and computer scientists. It most certainly can resemble disciplined engineering practice, especially in the U.S. defense industry and mainframe software worlds, but also in the commercial operations of companies such as IBM, Sun Microsystems, Hewlett-Packard, and, yes, even Microsoft, when it comes to building products such as Windows NT/2000. But many American companies, and the occasional European company that operates like an American company, at least in marketing (witness Business Objects and SAP), have found ways of generating oodles of revenues and profits, and tremendous excitement for their employees and investors, by treating software as a business. This book is about how to do that, whichever country you are from and whichever part of the software industry you are in.

Basics of the Business: Two Case Studies

There are many issues of strategy and technology management that managers, programmers, and entrepreneurs in the software business need to understand in order to have successful companies in both good times and bad. To illustrate some of the key issues here, I introduce the stories of two companies I have worked for over the past several years: Business Objects and i2 Technologies. Both are public software companies. Business Objects (NASDAQ stock symbol: BOBJ) is based in Paris with a second headquarters in Silicon Valley, and i2 (stock symbol: ITWO) has its headquarters in Dallas and much of its development organization in India.

Business Objects is a clear-cut success story of a business intelligence company selling horizontal software to enterprises and institutions. From the beginning, it demonstrated a very focused strategy as a complement to Oracle and then other database products. It has benefited from superb leadership by the f...

Contenu
Contents

Acknowledgments

Preface

1: The Business of Software: A Personal View

2: Strategy for Software Companies: What to Think About

3: Services, Products, and More Services: How Software Became a Business

4: Best Practices in Software Development: Beyond the Software Factory

5: Software Entrepreneurship: Essential Elements of a Successful Start-up

6: Start-up Case Studies: Software Products, Services, and Hybrid Solutions

7: Conclusion: The "Ideal" Versus "Realistic" Software Business

Appendix

Notes

Index

Informations sur le produit

Titre: The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad
Sous-titre: What Every Manager, Programmer and Entrepreneur Must Know to Succeed in Good Times and Bad
Auteur:
Code EAN: 9780743215800
ISBN: 978-0-7432-1580-0
Format: Livre Relié
Editeur: Free Pr
Genre: Management
nombre de pages: 352
Poids: 581g
Taille: H236mm x B162mm x T27mm
Année: 2004

Évaluations

Vue d’ensemble

Mes évaluations

Évaluez cet article