You are on page 1of 5

78 January 2003/Vol. 46, No.

1 COMMUNICATIONS OF THE ACM


Where Now By David E. Avison
and Guy Fitzgerald

forDevelopment
Methodologies
THIS BRIEF history of systems development methodologies identifies and
explores eras of development and speculates on their future. Today’s “post-
methodology” era involves methodologies that can be viewed by developers as out-
dated and inappropriate for rapid development, Web applications, and other current
? The current
swirl of diversity
could signal a
requirements. Perhaps we are in danger of returning to the bad old days of the pre- return to the days
methodology era and its lack of control, standards, and training. of ad hoc systems
development,
Pre-Methodology Era building computer-based applications focus- lack of formal
The early computer applications of the ing on the identification of phases and stages methodology,
1960s and 1970s were developed and imple- it was thought would improve the manage- and consequent
mented without explicit or formalized devel- ment of systems development and introduce increase in failure.
opment methodologies. The emphasis was discipline—an approach that has come to be
on programming and solving technical known as the Systems Development Life
problems, particularly those resulting from Cycle (SDLC), or, more commonly, the
the rather limited hardware of the time. waterfall model. It typically consisted of a
Developers were trained in computer tech- number of development stages that had to be
nology but rarely understood the business or followed in sequential order, including: feasi-
organizational contexts in which the systems bility study, systems investigation, analysis,
were implemented. User needs were rarely design, development, implementation, and
well defined, with the consequence that sys- maintenance. One phase had to be com-
tem designs were often inappropriate for pleted before the next one could begin
meeting genuine user and business require- (hence the term waterfall), and each phase
ments. The approach programmers took to had a set of defined outputs or deliverables to
development was typically individualistic, be produced before it could be deemed com-
often resulting in poor control and manage- plete. SDLC was also associated with a set of
ment of projects. One emphasis was main- techniques (such as flowcharting) for use in
taining operational systems rather than particular phases. There was also the notion
developing new systems and responding to of iteration around the phases, as problems
user needs. These limitations led to a new were encountered or changes required,
appreciation of standards and a more disci- though in practice it was often ignored.
plined approach to developing information This approach also involved serious limi-
systems in organizations. The result was the tations [1], including the way it was used.
first development methodologies based on Notable traps were: failure to meet the real
the systems development life cycle. needs of the business (due to concentration
on technological efficiency improvements at
Early Methodology Era the operational level of the organization);
This era, during the late 1970s and early overly conservative systems design (due to
1980s, was characterized by an approach to emphasis on the existing system as a basis for

Illustration by Michael Schröter

COMMUNICATIONS OF THE ACM January 2003/Vol. 46, No. 1 79


the new system); instability (due to the modeling of OO. The identification of objects and attributes (in
processes that are unstable due to changing businesses whole or part) and classes helped provide the theo-
and markets); inflexibility (due to the output-driven retical benefits of inheritance and reuse.
orientation of design processes, thus making changes in Participative. The crucial feature was involvement of
design difficult and costly); user dissatisfaction (due to users and other stakeholders.
problems with computer-orientated documentation Strategic. The emphasis was the planning of informa-
and users’ inability to “see” the system before it is oper- tion systems and development of an information
ational); problems with documentation (due to its systems strategy to support and enable the overall
computer rather than user orientation and the fact it is objectives of the business; business process reengi-
rarely kept current); and application backlog (due to neering is sometimes viewed as a development
the maintenance workload, as attempts are made to approach focusing on strategy.
change the system in order to reflect changing user Systems. The complexities of human activity systems
needs). were addressed by adopting a holistic view far
beyond a system’s single-application boundaries.
Methodology Era
A number of newer approaches emerged in response to These approaches were not necessarily mutually exclu-
one or more of these limitations, thus launching the sive. The era saw the coming together, or blending, of
methodology era. The term “methodology” was prob- a number of themes within a single methodology; the
ably first used to describe these different approaches, method-engineering movement embraces this view.
and methodologies proliferated. A methodology is a Associated tools supporting many of the approaches
recommended collection of phases, procedures, rules, were also developed, including project management
techniques, tools, documentation, management, and software, systems repositories, drawing tools, and com-
training used to develop a system; we also note the puter-assisted software (or systems) engineering
importance of the philosophy behind the methodol- (CASE) tools.
ogy, or the set of beliefs and assumptions underpinning Although they characterize the methodology era,
it, explaining why the methodology functions as it not every organization at the time used a methodology,
does. It may embody a belief that the key to successful particularly one with a name and that was developed
development is user involvement and that users have a by and bought from a vendor, whose claims, in any
right to participate in developments that affect their case, would certainly have to be viewed with caution. A
lives. These beliefs and assumptions are often not stated 1999 survey of U.K. organizations [5] found that 57%
explicitly by a methodology’s authors. of the sample claimed to be using a methodology for
The main motivations for adopting a methodology systems development, but only 11% reported using an
varied by organization and individual but were generally unmodified commercial development methodology;
to achieve: better end products (meeting user demands); whereas 30% reported using a commercial methodol-
a better development process (improving developer ogy adapted for in-house use, 59% used a methodol-
control and productivity); and a standardized process ogy they claimed as unique to their organization, often
(enabling better systems integration and the benefits of internally developed. Thus, methodologies were in rel-
a common approach in an organization). atively widespread use, though they were often devel-
We classify the methodology era’s emerging method- oped in-house rather than as commercial products.
ologies into seven broad themes, or approaches: Despite the claims of being unique, many were clearly
influenced by existing commercial methodologies.
Structured. The concepts of structured programming Even those organizations not using explicit method-
were applied to analysis and design, and techniques ologies were influenced by the methodology move-
(such as data flow diagramming) enabled the top- ment through, say, associated tools and techniques.
down analysis and representation of complex
processes. Post-Methodology Era
Data-oriented. The focus was understanding data as The success or failure of development efforts cannot be
the key element in a system’s development, and the attributed exclusively to the use, misuse, or nonuse of
most important technique was entity-relationship methodologies, but the post-methodology era starting
modeling. in the late 1990s has been characterized by a serious
Prototyping. The emphasis was building an approxi- reappraisal by researchers and practitioners alike of the
mation or representation of the system, allowing concepts and usefulness of the earlier methodologies.
users to visualize and respond to it prior to its physi- As a result, some organizations continue to turn
cal implementation. to yet different (perhaps newer) methodologies and

80 January 2003/Vol. 46, No. 1 COMMUNICATIONS OF THE ACM


approaches, while others have abandoned methodolo- for whatever reason. A typical reaction might be,
gies altogether. For many organizations, adoption of a “We’ve tried it, and it didn’t help and may have actively
methodology has not always worked out or been the hindered systems being implemented.”
success its advocates touted. Indeed, it was highly Some organizations have rejected the use of method-
unlikely that methodologies would ever achieve their ologies altogether, returning to less-formal, more off-
more overblown claims, like productivity increases, the-cuff, perhaps more flexible approaches. One area
made by some vendors and consultants. Real-world where methodologies are not widely used is develop-
performance has led some developers to reject method- ment of Web-based applications [7]. They are typically
ologies in general terms and attack the concepts (such developed in an ad hoc, trial-and-error manner, relying
as step-by-step development and meticulous documen- on the skills and experience of a few key people in an
tation) on which they are based. organization [3], not unlike the development approach
Many reasons for this developer backlash have been usually associated with the pre-methodology era of the
suggested. The most common is probably disappoint- 1960s and 1970s.
ing productivity; another is that the methodologies are
overly complex, usually designed for the largest and Alternatives
most complex development projects. They may lead to For other organizations, the problem is not the concept
developing requirements to the ultimate degree, often of a methodology but the inadequacy of the current
over and above what is legitimately required, sometimes methodologies, prompting them to keep looking for
encouraging users to create unrealistic wish lists. They different and better ones. Still others seek, not better
also require highly technical skills that can be difficult methodologies, but alternatives to traditional in-house
and expensive for developers and end users to learn or systems development; some are outlined in the follow-
acquire. Moreover, the tools advocated by methodology ing sections:
proponents can be costly, difficult to use, yet still not Development with tools. Some organizations pin their
deliver enough benefit. faith on the tool evolution, including automatic code
Methodologies are often not contingent on the type generation, to automate the development process. Using
or size of a project, nor upon the technology environ- tools without a methodology to guide their use can,
ment and organizational context. A methodology is however, be considered a return to ad hoc development.
often said to be one-dimensional, that is, it adopts only OO approach. Although part of the methodology
one approach to the development of projects that may era, the OO approach is still evolving with new meth-
well not address a particular organization’s underlying ods and techniques. Component-based development,
issues or problems. Few recognize or address the criti- which views systems development as the combination
cally important social, political, and organizational and recombination of existing components (usually
dimensions of development. OO), is being adopted by some software engineers.
A methodology may be inflexible, not allowing Incremental development. Incremental, or evolution-
changes to requirements during development. Most ary, development reflects the characteristic of building
methodologies make a number of simplifying yet upon and enhancing the previous versions of systems,
invalid assumptions (such as a stable environment, a rather than developing whole new systems each time. It
well-documented business strategy, users knowledge- aims to reduce the amount of time needed to develop a
able about their own requirements, or that a consensus system, especially in the form of Rapid Application
of requirements can be achieved). Rarely do such con- Development. It addresses the problem of changing
ditions exist in practice. The use of a methodology in requirements during the process of development; for
an organization may lead to its rote implementation example, the Dynamic Systems Development Method
and to a focus on following the procedures of the is an evolutionary methodology that has been adopted
methodology rather than on addressing the real imple- by a number of companies since the mid-1990s [6].
mentation and business issues. Strict adherence to the External development. Some organizations try satisfy-
methodology rule book has been described as slavish ing their systems needs by buying commercially devel-
adherence to the methodology and the fetish of tech- oped methodology packages. Although their purchase
nique, that is, the methodology is allowed to inhibit and implementation has been commonplace for some
creative thinking [8]. Some organizations have found it time, the post-methodology era is characterized by
difficult to adopt methodologies in practice, con- some organizations purposely not embarking on in-
fronting resistance from both developers and users. house systems development activities, satisfying all
Finally, and perhaps the acid test of whether a method- their requirements in the form of packaged systems.
ology is really worth using, is the conclusion of some This is regarded by many organizations as a quicker
organizations that a methodology led to poor systems, and more cost-effective way of implementing systems.

COMMUNICATIONS OF THE ACM January 2003/Vol. 46, No. 1 81


Only systems that are strategic or for which a suitable cratic types of methodologies of the methodology era;
package is not available would be considered for in- and for others it represents moving beyond in-house
house development. The market for packaged devel- development altogether.
opment software offers increasingly sophisticated Diversity characterizes the current post-methodol-
products and features and includes more and more tai- ogy era. However, today’s flood of methodology
lorable packages. Enterprise resource planning pack- options should not be interpreted as the death of
ages are especially popular with large corporations, as methodology; many traditional methodologies are still
are customer relationship management packages. being used, along with alternative methodologies and
However, there are notable disadvantages associated approaches. Moreover, even with the developer back-
with being locked into a particular supplier and of not lash against formal methodologies, they remain influ-
being in control of the features in a particular package, ential in practice. They might be adapted or other
a risk discounted by many organizations. techniques and tools used but still contribute in prac-
Outsourcing. For still other organizations, the con- tice; they are also important in training and education,
tinuing problems of systems development and the per- teaching good practice and forming a solid basis for
ceived failure of methodologies to deliver promised understanding systems development.
performance, has resulted in their outsourcing devel- Conversely, the current era may indeed be more a
opment to third parties. The client organization is no methodology era than is often supposed. Systems
longer as concerned with how a system is developed development methodologies may not be adopted by all
and which development approach or methodology is organizations, but they weren’t during any particular
used, but with the effectiveness of the system ulti- period. We might even claim methodologies are being
mately delivered. A client organization has to develop used more than ever. In light of today’s diversity, orga-
sharp skills to be able to select appropriate vendors, nizations are much more likely to find an appropriate
specify requirements in detail, and write and negotiate approach for their systems development work, even
contracts, rather than just apply methodologies [4]. though they rarely find a single clear strategy for doing
Contingency. Most methodologies today are so. Finally, the risk for organizations not using any
designed for situations that fit some ideal specification, methodology at all should be recognized and the
whether stated or unstated. However, some researchers lessons of history not completely ignored. c
and practitioners argue that each situation is different
and there is no such thing as an ideal in the real world. References
Such thinking advocates a contingency approach to 1. Avison, D. and Fitzgerald, G. Information Systems Development: Methodolo-
gies, Techniques and Tools, 3rd Ed. McGraw-Hill, Maidenhead, U.K., 2003.
systems development whereby a structure is presented, 2. Avison, D., Wood-Harper, A., Vidgen, R., and Wood, J. A further explo-
but tools and techniques are expected to be used or ration into information systems development: The evolution of Multiview2.
IT and People 11, 2 (Apr. 1998), 124–139.
ignored (or used and adapted), depending on the situ- 3. Eriksen, L. Limitations and opportunities of systems development methods
ation. Situations might differ depending on, say, the in Web information system design. In Organizational and Social Perspectives
type of project and its objectives, the organization and on Information Technology, R. Baskerville, J. Stage, and J. DeGross, Eds.
Kluwer, Boston, 2000, 473–486.
its environment, the users, and the developers and their 4. Fitzgerald, G. and Michell, V. The IT outsourcing marketplace: Vendors
respective skills. The type of project might also differ as and their selection. J. Info. Tech. 12, 3 (Sept. 1997), 233–238.
5. Fitzgerald, G., Philippidis, A., and Probert, P. Information systems develop-
to purpose, complexity, structuredness, degree of ment, maintenance, and enhancement: Findings from a UK study. Int. J.
importance, projected life, and potential contribution Info. Mgmt. 40, 2 (Apr. 1999), 319–329.
to overall corporate performance. Different environ- 6. Stapleton, J. Dynamic Systems Development Method: The Method in Practice.
Addison-Wesley, Harlow, U.K., 1997.
ments might exhibit different rates of change, number 7. Vidgen, R., Avison, D., Wood, R., and Wood-Harper, A. Developing Web
of users affected by the system, user skills, and analyst Information Systems. Butterworth-Heinemann, Oxford, U.K., 2003.
8. Wastell, D. The fetish of technique: Methodology as a social defence. Info.
skills. All these characteristics can influence the choice Syst. J. 6, 1 (Jan. 1996).
of required development approach. A contingent
methodology (such as Multiview [2]) allows for differ-
ent approaches, depending on the situation. David E. Avison (avison@essec.fr) is a professor in the
Information and Decision Systems Department of the ESSEC Business
School, Cergy-Pontoise, France.
Diversity Guy Fitzgerald (guy.fitzgerald@brunel.ac.uk) is a professor of
Thus there is diversity in terms of types of methodolo- information systems in the Department of Information Systems and
gies and their components, functions, and potential Computing at Brunel University, Uxbridge, Middlesex, U.K.
results in the post-methodology era. For some develop-
ers it represents the abandonment of methodologies
altogether; for others, it represents improved method-
ologies while moving away from the highly bureau- © 2003 ACM 0002-0782/03/0100 $5.00

82 January 2003/Vol. 46, No. 1 COMMUNICATIONS OF THE ACM