1. We recognize that this is a simplification of the “build” or development process, and that there are many different methodologies, tools, and techniques, some of which we mention later. The point here is that, while there are clearly many variations, at a higher level, there is also some basic commonality. The steps we outline here are performed, either in sequence or iteratively, regardless of methodology.
2. See I. Aaen and C. Sorensen, “A Case of Great Expectations,” Scandinavian Journal of Information Systems 3 (1991): 3–23;
G. Anthes, “User Role Gains CIO Backing,” Computerworld, 24 February 1992, p. 63;
B. Caldwell, “Techno Shift Underway,” InformationWeek, 31 January 1994, p. 14; and
W. Orlikowski, “Division among the Ranks: The Social Implications of CASE Tools for System Developers” (Cambridge, Massachusetts: MIT Sloan School of Management, Center for Information Systems Research, Working Paper No. 194, July 1989).
3. We use the term “rapid development” to refer to a collection of techniques (briefly described here) that have been introduced, under various labels, to improve the systems development process. For further discussion of these techniques, see, for example:
L.J. Arthur, Rapid Evolutionary Development (New York: John Wiley, 1992);
D. Hough, “Rapid Delivery: An Evolutionary Approach for Application Development,” IBM Systems Journal 32 (1993): 397–419;
J.M. Martin, Rapid Application Development (New York: MacMillan Publishing Company, 1991);
J.D. Naumann and A.M. Jenkins, “Prototyping: The New Paradigm for Systems Development,” MIS Quarterly 6 (1982): 29–44; and
L. Orman, “Evolutionary Development of Information Systems,” Journal of Management Information Systems 5 (1988–1989): 19–32.
In addition, object orientation is a relatively recent software process innovation that holds great promise for improving the time, cost, and quality of the application development process. However, object orientation represents a radical change in the systems development process, and there are few business systems to date that have been developed using it. For discussion of the adoption of object-oriented methods, see: A.A.R. Cockburn, “The Impact of Object-Orientation on Application Development,” IBM Systems Journal 32 (1993): 420–444;
R.G. Fichman and C.F. Kemerer, “Adoption of Software Engineering Process Innovations: The Case of Object Orientation,” Sloan Management Review, Winter 1993, pp. 7–22; and
R.G. Fichman and C.F. Kemerer, “Object-Oriented and Conventional Analysis and Design Methodologies: Comparison and Critique,” IEEE Computer 25 (1992): 22–39.
Reuse, and code reuse in particular, is an innovation that has a longer history than object orientation; however, while some individual programmers do reuse code on an ad hoc basis, it has generally not been institutionalized. The reasons for this have been widely debated and range from technical to cultural. For discussion of the issues around reuse, see, for example:
T. Biggerstaff and C. Richter, “Reusability Framework, Assessment, and Directions,” IEEE Software, March 1987, pp. 41–49;
G. Caldiera and V. Basili, “Identifying and Qualifying Reusable Software Components,” IEEE Computer 24 (1991): 61–70; M. Cusumano, Japan’s Software Factories (New York: Oxford University Press, 1991); and
J. Karimi, “An Asset-Based Systems Development Approach to Software Reusability,” MIS Quarterly 14 (1990): 179–198.
4. While there are some packages that can be modified somewhat through the use of tables rather than changes to the code, changing the tables remains a very involved and lengthy process. The alternative to modifying the package to fit the organization is to modify the organization’s business process workflow to fit the package. However, this too can be extremely difficult and costly.
5. While sharing a mission-critical application with a competitor can be perceived as a disadvantage in some industries, this does not seem to be the case in the airline industry. Since the time of this case study, Canadian has resold the template to Lufthansa. The IS executive at Canadian explained that the true advantage lies not in the system itself but in how it is used. Moreover, in Canadian’s view, the advantages of recovering some of the system’s cost far outweigh the disadvantages, because the “competition will eventually catch up anyway.”
6. Canadian has allocated 1.5 maintenance personnel to this application; this compares to seven individuals on a system comparable in size and complexity, but residing in a different technology.
7. There are three major categories of business activity in publishing. The first is book project management, which includes activities from signing an author to write the book until the book is in the warehouse. Second is the “core process” that covers all activity from the warehouse to the customer, and third is sales and marketing. The core process was chosen as the first candidate for replacement systems because it was considered the most stable and the requirements could therefore be more accurately defined. Wiley has since begun replacing the systems that support book project management and is using the template process to help redesign the business process.
8. While the data are relatively similar across sites, business processes do vary. For example, payment cycles vary by country. A normal accounts receivable cycle in the United States might be thirty or ninety days; in the Far East, it might be 210 days before an initial payment is expected.
9. Wiley must still spend some time understanding, reconfirming, retesting, and redocumenting each function. It should be noted, however, that the effort involved in understanding each function is significantly reduced by working at the design level, because it is easier to understand a design model than it is to understand someone else’s code.
10. One difference between this company and the other two is in the area of maintenance. In the Canadian and Wiley examples, changes were made to design models rather than to the code during both development and maintenance. At Western, changes were made to design models during development; however, once the code had been generated (i.e., during maintenance), subsequent changes were applied to the code itself.
11. For a discussion of the advantages of working with models, see, for example:
B. Curtis, M. Kellner, and J. Over, “Process Modeling,” Communications of the ACM 35 (1992): 75–90;
M. Hess, “Information Systems Design in Industrial Practice,” in Concise Encyclopedia of Information Processing in Systems & Organizations, ed. A. Sage (Arlington, Virginia: Pergamon Press, 1990);
J.F. Rockart, “Model-based Systems Analysis: A Methodology and Case Study,” Industrial Management Review, Winter 1970, pp. 1–14; and
J.A. Zachman, “A Framework For Information Systems Architecture,” IBM Systems Journal 26 (1987): 276–292.
12. Fichman and Kemerer (1993, 1992).
13. For discussion of the changes associated with the introduction of CASE tools, see, for example:
M. Chen and R. Norman, “Integrated Computer-Aided Software Engineering (CASE): Adoption, Implementation, and Impacts,” IEEE (1992): 362–372;
M. Friesen and W. Orlikowski, “Assimilating CASE Tools in Organizations: An Empirical Study of the Process and Context of CASE Tools” (Cambridge, Massachusetts: MIT Sloan School of Management, Center for Information Systems Research, Working Paper No. 199, October 1989);
W. Orlikowski, “CASE Tools as Organizational Change: Investigating Incremental and Radical Changes in Systems Development,” MIS Quarterly 17 (1993): 309–340; and
J.F. Rockart and J.D. Hofman, “Systems Delivery: Evolving New Strategies,” Sloan Management Review, Summer 1992, pp. 21–31.
14. See, for example,
M. Riccuiti, “Build Custom Apps at Packaged Prices,” Datamation, 1 June 1993, pp. 71–72;
CASE Strategies IV (1992): 1–12;
Ira Sager, “Consulting the Oracle,” InformationWeek, 2 August 1993, pp. 32–33.