If you want to see a recap of research methodology, this paper is instructive, but the research results are obscured. The paper covers topics of critical importance, such as: What constitutes “research” in information systems development methodology? What are the objectives of research in IS development methodologies? and How does the IS developer select a methodology? Here is a transportation analogy. Suppose trucks, buses, and cars are available. Which is the right one for you? It depends on how many individuals are traveling, the goods you are transporting (their weight and volume), what you want to spend, and so on.
Multiview addresses a comparable problem: You have to build a system; what is an appropriate methodology to use? You might expect questions like
What is the degree of novelty in the application for the developers? Is the underlying business activity routine or novel?
How technologically complex is the system and its platform?
What resources are available? (Better, what is the appropriate categorization of resources before measuring availability?)
Instead, Multiview is defined at a conceptual level. The authors recap six broad themes in system development methodologies from earlier related work: Systems approach
Planning approach
Participative approach
Prototyping
Structured approach
Data analysis
They then sketch five different stages of system analysis and design: Analysis of human activity
Analysis of information
Analysis and design of sociotechnical aspects
Design of the human-computer interface
Design of technical aspects
The rules for combining methods, or contingencies for selecting methods, are not described; the authors call Multiview “an explorative structure” (p. 104). Let’s cut through all this. What the researcher wants is to provide a framework of assumptions and parameters governed by system objectives and resource alternatives so that appropriate techniques and tools can be applied to successfully develop a system. This should include the wider definition of tools and techniques such as the make-or-buy decision, project organization and control, and so forth.
An extensive bibliography favors theoreticians and British sources. The style is ponderous, the organization of thought is overly analytic (as contrasted with the applied research promised in the introduction), and the terminology is awkward and wordy. The authors “argue that it is unreasonable to rely on one approach” to IS development and “no methodology can be appropriate to all situations” but users of Multiview “select [techniques and tools] which are appropriate to the context, in effect creating a unique methodology for each application” (p. 98).
Simplistic statements like “through the use of prototyping tools the applications backlog can be reduced by the greater speed of information systems development” (p. 100) continue misjudgments that pervade our discipline. Only part of information systems development is affected by prototyping, and the effect is not always speed-up. Reducing the applications backlog is not always the goal; the desired effect of prototyping can be a deeper understanding or a richer analysis in building the solution. Also, only selected backlog problems (perhaps specifications or user requirements definition) can be addressed through prototyping.
The authors point out that one only fully understands the Multiview methodology by using it. They nicely summarize several lessons and conclusions:
Conventional descriptions of methodologies are inappropriate.
The political dimension is important in the context of human activity and “socio-technical aspects.”
As you entertain more detailed understanding of a specific situation, a more precise prescription of the tool is needed. (Consequently, as the tool is prescribed in more detail, generality is lost.)
Proposing a methodology for information system development requires articulating not only assumptions but also constraints, hypotheses, and so on for its use. Evaluation is difficult.
Development methodology must be contingent on both the specific situation and the resources available.
In an attractive departure, the paper touches upon the significance of “richness” of problem understanding and the need for pragmatism and a “gentle touch” in working with the user. The authors lament the failure of “action research” to produce generalized learning (p. 110). I understand their term “action research” to be akin to the idea of an application case study in the United States. If so, I would argue that, on the contrary, learning to approach system development as a contingent process is perhaps the most significant learning experience of the seasoned developer.
