Organizations increasingly rely on information technology (IT) both to perform their day-today operations and as a source of new products and services. The popular focus has been on hardware components, and that story has been overwhelmingly positive: the new technologies that come to market are cheaper, more reliable, and more portable than previous ones.
However, much less has been written about the software side of IT, and what has been written has not been positive. We commonly read that software is late, over budget, and of poor quality. Specific examples of software in the news are almost always negative — microcomputer software vendors that deliver releases late, federal government systems projects that never reach the implementation stage, and the recent telephone system outage that was blamed on a Texas supplier who “changed only three or four lines of the program.”1
This imbalance has reached such proportions that it has been termed the software crisis. Software production represents the single biggest obstacle to the successful use of IT in organizations; all precepts such as “using IT for strategic advantage,” “reengineering the business,” and “informating the workplace” become mere slogans if the necessary software is not properly delivered on time.
Into this void have rushed a multitude of vendors and consultants offering solutions to the crisis. A quick review of trade press magazines will reveal articles on such topics as computer-aided software engineering (CASE), rapid applications development, cleanroom software engineering, software factories, and object-oriented (OO) approaches. All of these represent software engineering process technologies, that is, means by which an application software product is created (hereafter “software process technologies”).2 The idea that process technologies in general are critical sources of economic success is gaining acceptance.3 However, the problem with this rich set of software process technologies is that they may be technically incompatible, or, if not, then at least sufficiently expensive and requiring significantly large changes in an organization’s operation that they are unlikely to be successfully adopted at the same time.
How, then, can the chief information officer (CIO) of a large business application development organization choose which, if any, of these new software process technologies to adopt? Unfortunately, the choice of a new approach is rendered very difficult by the lack of unbiased information sources. All of the technologies are shrouded in new vocabularies and explainable only by a self-selected cadre of experts.
1. M.L. Carnevale, “DSC Says Software Change Led to Phone Outages,” Wall Street Journal, 10 July 1991, p. 5.
2. The innovation literature distinguishes process technology innovations from product innovations. A process innovation is one that changes the production process, that is, the way a product is produced. Most industrial tools, when first introduced, are simultaneously process and product innovations — a product innovation for the tool producer and a process innovation for the tool consumer. For example, for a DBMS vendor, a new RDB offering is a product innovation; for a systems developer, RDB technology is a process innovation that, among other things, involves the purchase of a product. As this article is targeted at consumers rather than producers of software technologies, we define them as process innovations. For further reading on the topic of process and product innovations, see:
W.J. Abernathy and J.M. Utterback, “Patterns of Industrial Innovation,” Technology Review, June–July 1978, pp. 40–47.
3. L. Thurow, “Who Owns the Twenty-First Century?” Sloan Management Review, Spring 1992, pp. 5–17.
4. F.P. Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering,” IEEE Computer20 (1987): 10–19.
5. W.M. Bulkeley, “Bright Outlook for Artificial Intelligence Yields to Slow Growth and Big Cutbacks,” Wall Street Journal, 5 July 1990, pp. B1, B3.
6. “Software Made Simple,” Business Week, 30 September 1991, pp. 92–100.
7. E.M. Rogers, Diffusion of Innovations (New York: Free Press, 1983).
8. Ibid., ch. 6.
9. See, for example:
J.E. Eveland and L.G. Tornatzky, “The Deployment of Technology,” in The Processes of Technological Innovation, eds. L.G. Tornatzky and M. Fleischer (Lexington, Massachusetts: Lexington Books, 1990), pp. 117–148;
T.H. Kwon and R.W. Zmud, “Unifying the Fragmented Models of Information Systems Implementation” in Critical Issues in Information Systems Research, eds. J.R. Boland and R. Hirshheim (New York: John Wiley & Sons, 1987);
D. Leonard-Barton, “Implementation Characteristics of Organizational Innovations,” Communication Research 15 (1988): 603–631;
G.C. Moore, “End-User Computing and Office Automation: A Diffusion of Innovations Perspective,” Infor25 (1987): 214–235;
J.M. Pennings, “Technological Innovations in Manufacturing,” in New Technology as Organizational Change, eds. J.M. Pennings and A. Buitendam (Cambridge, Massachusetts: Ballinger, 1987), pp. 197–216; and
A.H. Van de Ven, “Managing the Process of Organizational Innovation” in Changing and Redesigning Organizations, ed. G.P. Huber (New York: Oxford University Press, 1991).
10. We use Rogers’s five innovation attributes mainly because they are familiar in the DOI field. Van de Ven, Moore, and Kwon and Zmud also use Rogers’s definitions, although others have provided alternative taxonomies of the salient attributes of complex organizational technologies. Leonard-Barton identifies transferability, organizational complexity, and divisibility. Pennings identifies concreteness, divisibility, and cost. Eveland and Tornatzky identify trialability, lumpiness, adaptability, degree of packaging, and the “hardness” of the underlying science. In most cases, these attributes can be mapped to one or more of Rogers’s original five attributes, at least as they are used here.
11. W.B. Arthur, “Competing Technologies: An Overview,” in Technical Change and Economic Theory, ed. G. Dosi (New York: Columbia University Press, 1987).
J. Farrell and G. Saloner, “Competition, Compatibility, and Standards: The Economics of Horses, Penguins, and Lemmings,” in Product Standardization and Competitive Strategy, ed. H.L. Gabel (Amsterdam: North-Holland, Elsevier Science, 1987);
M.L. Katz and C. Shapiro, “Technology Adoption in the Presence of Network Externalities,” Journal of Political Economy 94 (1986): 822–841.
13. Farrell and Saloner (1987).
15. N. Rosenberg, “On Technological Expectations,” in Inside the Black Box: Technology and Economics (New York: Cambridge University Press, 1982).
16. G. Rifkin and M. Betts, “Strategic Systems Plans Gone Awry,”Computerworld, 14 March 1988, pp. 1, 104–105.
17. R. Fichman and C. Kemerer, “Object-Oriented and Conventional Analysis and Design Methodologies: Comparison and Critique,” IEEE Computer 25 (1992): 20–39.
18. See S. Atre, “The Scoop on OOPS,” Computerworld, 17 September 1990, pp. 1115–1116;
J. Moad, “Cultural Barriers Slow Reusability,” Datamation, November 1989, pp. 87–92; and
M. Stewart, “Object Projects: What Can Go Wrong,” Hotline on Object-Oriented Technology 2 (1991): 15–17.
19. Moad (1989).
20. Stewart (1991).
21. Atre (1990).
22. Rogers (1983) notes that unfulfilled expectations about an innovation’s benefits are a primary cause of subsequent discontinuance. Leonard-Barton has argued that discontinuers can become influential “negative” opinion leaders, and that entrenched opinions about an early technology generation are hard to overturn, even when later and more viable technology generations become available. See:
D. Leonard-Barton, “Experts as Negative Opinion Leaders in the Diffusion of a Technological Innovation,” Journal of Consumer Research, 11 March 1985, pp. 914–926.
23. As mentioned previously, adoption context is important to the ratings. In some segments, such as CAD/CAM, CASE, operating systems, and simulation-oriented applications more obviously suited to OO’s strengths, a different classification may result.