Soft Systems Methodology (SSM) in Information System Analysis

Hui Zhou

Abstract

Soft Systems Methodology (SSM) has long been associated with information system analysis. . Its social construction perspective and management focus distinguish SSM from the software engineering approach of information system analysis, making it a valuable candidate methodology in highly unstructured problem settings. This paper describes the principals and basic structure of SSM, and discusses its strengths and limitations in system analysis practice. The primary purpose of this paper is to foster innovative thinking of effective use of SSM.

Introduction

Systems analysis defines the problems to be solved and provides the architecture of the proposed system. As information systems became more complex, system analysts sought advanced tools to assist them in the analysis process. The field of system analysis has seen the emergence and prospering of many structured methodologies. Lifecycle/waterfall approach, CASE tools, prototype, RAD/RSD, JAD, and object-oriented methodology are all part of the continuously expanding list. Despite all their differences, most of these methodologies share a primarily technical perspective. They assume that there exists an optimal system design for the scenario and that it is possible to find this optimal solution through the analysis process. People involved in the information systems are viewed as stable elements who always react to the system in a predictable and “rational” manner. In short, all these methodologies take a technically based approach of system analysis to seek the best design of the system. However, some commentators argue that these technology-centered methodologies are insufficient in real world problem situations, especially when the relevant situation is messy and ill structured or when political and cultural factors are prevalent in the organization. As a reaction to these perceived inadequacies, soft system methodology (SSM) is identified as a valuable candidate for IS analysis methodology. Premised on the social construction paradigm, SSM provides a mechanism to allow relevant human, social, political, and cultural factors to form structure and act as explicit entities in the system analysis process.

The primary objective of this paper is to discuss the effective way of using SSM in information system analysis. The remainder of the paper is organized as follows. The next section provides the background knowledge through a brief review of the “hard” IS analysis methodologies. Then, the principals and basic framework of SSM are outlined. The following two sections discuss the challenges in implementing SSM and provide some examples of possible solutions. The last section summarizes and concludes.

Review: “Hard” IS Analysis Methodologies

The waterfall approach is probably the most basic and popular methodology for information system analysis and development. This methodology divides the analysis process into different phases with specific descriptions of the tasks for each phase. The results for each phase are documented using specified forms, and the subsequent phase only begins when the supervisor/client gives approval for the results of the current phase. Under this methodology, the analysis process should not return to the previous phases if a new phase has started. While the waterfall methodology may provide a structured approach to analyzing the system in an efficient manner, it has been criticized for lack of flexibility and user participation.

Recognizing these inadequacies of the waterfall methodology, system analysts have developed a number of methodologies to supplement or substitute the waterfall methodology. The adoption of computer-aided systems engineering (CASE) tools represents the efforts of streamlining the system analysis process by taking advantage of the advancement in information technology. Another response has been the use of the prototyping technique at a early stage of the analysis process to verify that the specifications of the system can meet the user requirements. However, the effectiveness of prototyping is compromised by several factors. It has been reported that users tend to evaluate the interfaces of the prototype (e.g. screen layout, color) rather than the actual IS design and capability. In addition, it is also very difficult to decide the optimal scale and timing of prototypes in a complex project. Another solution is the rapid application/systems development (RAD/RSD) methodology. Although this methodology encourages user participation in specification review, the feedback also tends to focus on the user interface rather than the functionality of the system. Join application design (JAD) represents another approach to involving user in the system analysis process. Users are responsible for compiling their requirements adequately beforehand and informing analysts of the requirements. Analysts then develop alternative versions of the specifications, which are evaluated during the free discussions between system analysts and user representatives. The final version of system specifications is obtained after several rounds of revision, and formal agreements are often signed to prevent unintended changes. Although JAD has been praised for actively considering user requirements in the analysis process, in reality it is very difficult for users to define and articulate how to design the system or which part of the work should be improved through information systems. According to a survey conducted by Purvis and Sambamurthy in 1997, users are often suspicious about the effectiveness of the agreed management.

The objected-oriented methodology is another response to the weaknesses of the life-cycle approach. Unlike the waterfall approach, methodologies using object-oriented approach analyze the system in terms of the “problem domains” and the corresponding system responsibilities instead of focusing on the functional complexity of the system. As such, the object-oriented methodology has provided another perspective to analyze information systems. However, this methodology is yet to demonstrate its full potential (Lauesen 1998).

Compared with the traditional waterfall approach, these methodologies explicitly recognize the role of user involvement and offer a greater degree of flexibility. However, as with the waterfall methodology, they all share a ‘positivist’ view of information systems.

Sketches: Principles of SSM

Soft systems methodology (SSM) was proposed by Peter Checkland as a framework for implementing “soft” system thinking. Although originally developed as an OR technique, SSM has long been associated with information system analysis. Generally labeled as an ‘interpretive’ approach, SSM views system analysis as “a process of inquiry into problem situations of human affairs” and explicitly recognizes the multidimensional nature of information system rationality. As such, this methodology does not seek to define the ‘best’ systems. Instead, it aims to better meet the diverse needs of various stakeholders by exploring the problem in a forum that encourages discussion and debate among all the parties. Premised on the concept of social construction and incremental organizational learning, SSM allows relevant human, social, political, and cultural factors to form structure and act as explicit entities in the system analysis process.

The basic framework of SSM consists of seven steps that guide the analysis process moving from the ‘real world’ to the ‘conceptual (systems) world’ and back again, but these stages are not necessarily followed in a linear fashion. The seven steps are shown in figure 1.

Figure 1: Basic Framework of SSM

Stages 1 and 2: Finding out

These stages create a ‘rich’ picture of the problem situation and identify the ‘soft’ elements within it:

· People - essentially all those have interest in the system or who are likely to be affected by changes to it

· Culture - social roles, norms of behavior, values

· Politics - commodities of power and how they are obtained, used, preserved and transmitted

Stage 3: Developing the root definition

At this stage, the analysis process enters the system world by developing root definitions. Root definitions are basic descriptions of the proposed system. The development of the root definition is often combined with CATWOE analysis to answer the following questions:

C Who are the customers/victims/beneficiaries of the system?

A Who are the actors/participants in the system?

T What is transformed by this system: Input --> Transformation --> Output?

W Weltanschauung /worldview:

What are the underlying assumptions of the system?

O Who is the owner of the system? Who ultimately control and pay for the system?

E What are the environmental constraints to the system?

There are two types of root definitions:

"Primary tasks" root definitions, focusing on officially declared tasks of the system
"Issue-based" root definitions, focusing on problem issues, which would lead to systems that are not likely to be institutionalized in the real world.

Stage 4: Building conceptual models

At this stage, the root definition is converted to a conceptual model defining how the system functions and how it achieves its objectives. These models are often stated using active words to describe what is happening within the system. It is also desirable to present the model in pictorial or flowchart form to clarify the interlinked activities.

In addition, the conceptual model should also contain a monitoring and controlling subsystem to monitor:

The effectiveness of the system (Is this the right thing to do?)
The efficacy of the system (Does it work?)
The efficiency of the system (Does it use the minimum resources necessary?)

Stage 5: Comparing models with the real world

This stage is designed to provide structure and substance to an organised debate about improving the current situation. At this stage, the analysis process goes back into the real world by comparing the conceptual model with what happens in the real world. SSM provides a systematic way to conduct the comparison by asking a series of ordered questions for each activity depicted in the conceptual model:

Does this happen in the real situation?
How?
By what criteria is it judged?
Is it a subject of concern in the current situation?

Stage 6: Identifying changes

This stage defines the desirable and feasible changes based on the analysis in prior stages. In the ideal situation, the changes should cover all aspects of the system being analyzed and the viewpoints of all participants. However, projects in the real world are always subject to schedule and resource constraints. As a result, system analysts have to make decisions to prioritize the various requirements.

Stage 7: Taking action

This stage puts into practice the most appropriate changes identified in the previous stage. In the case of IS projects, this stage represents the development and implementation phases.

Discussion: Practical Value of SSM

As a soft OR technique, SSM has been under criticism for lack of theoretical rigor and practical value since its inception. Advocators of soft system thinking often scorn such criticism as hostile reactions by believers of hard system rationale. However, this paper would argue that SSM must seriously address the barriers to its wide acceptance in order to survive and prosper as a valuable methodology in practice.

Compared with classic ISD methodology, SSM are less tangible and more difficult to explain and use. This inevitably limits its opportunity to be adopted in practice. Moreover, the supporters of SSM often objects to applying explicit, measurable evaluative criteria to assess the success of SSM. The following comments by Checkland best represent their views on attempts to evaluate the success of SSM.

If some one says to me, ‘I have tried the methodology and it works’, I have to reply on the lines: ‘How do you know that better results might not have been obtained by an ad hoc approach?’ If, on the other hand, the assertion is: ‘Your methodology does not work’, I may reply, ungraciously but with logic, ‘How do you know the poor results were not due simply to your incompetence in using it?’

While these arguments make perfect sense logically, following such logic may lead SSM into a deadend. Unfortunately, many SSM advocators have chosen to stick to this path. They create a public image of SSM as an amorphous philosophy concept by presenting the soft system methodology in an ambiguous manner. They always elaborate on why SSM “makes sense” but seldom discuss the barriers to implementing SSM in system analysis practice. They attack traditional system analysis methodologies as narrow-minded and near-sighted and claim SSM as the best system analysis approach based on their belief, without giving sufficient empirical evidence to support their conclusions. Given these factors, it is not surprising that SSM have still not achieved wide recognition.

The value of SSM lies in its recognition of the importance of human/soft factors in organizational and social systems, the multifaceted nature of system rationality, and the role of incremental learning. The objective of SSM should be to provide mechanisms to better capture and explicitly incorporate these elusive elements in the system analysis process rather than to dismantle the process structure offered by other system analysis methodologies. This paper suggests that SSM advocators abandon the hostile attitudes toward classical system analysis methodologies and engage in the efforts to integrate SSM with its “hard” counterparts. The following section provides two examples of such integrated approaches.

Examples: Integrating SSM With Its “Hard” Counterparts

1. The Soft Information Systems and Technologies Methodology (SISTeM)

SISTeM is a second-generation soft methodology developed through a series of participative multidisciplinary projects within healthcare settings that incorporated both IS and organizational redesign. This approach directly integrates the SSM approaches to process reconfiguration and cultural development with traditional IS analysis tools and techniques. Atkinson et al (2002) summarizes the structure SISTeM diagrammatically (Figure 2). The methodology has two cycles. The first cycle of SISTeM follows the seven stages of SSM resulting a high level ‘strategic’ decision to act to accommodate the requirements of multiple stakeholders. The second cycle focuses on realizing the high-level decision arrived at the first cycle. Atkinson (2000) describes the detailed stages of the twin cycles:

Cycle 1

Stage 1.1: Experience and analyze the real world problem situation in terms of tasks and issues, intervention itself, social analysis, political/power analysis, market/competencies analysis, information analysis, and technology analysis.

Stage 1.2: Extract relevant human/machine activity systems from analysis of problem situation-using scenarios and root definitions.

Stage 1.3: Create conceptual, expressive, and matrix models appropriate to relevant systems using human/machine activity systems concepts

Stage 1.4: Compare real world problem situation with scenarios, root definitions, and conceptual or expressive models of human/machine activity.

Stage 1.5: Use differences to formulate agenda for debate among stakeholders in the problem situation.

Stage 1.6: Decide desired changes that are systematically desirable, value adding, culturally feasible, technically possible and ethically defensible.

Stage 1.7: Take action in line with the decision for change using SISTem Cycle 2 to address real world problem.

Cycle 2

Stage 2.1: Know the problem situation from all Cycle 1 analysis and the role, position, and power of those who seek change.

Stage 2.2: Know the decisions on what to change coming out of the debate stage of Cycle.

Stage 2.3: Identify change agents and team to carry out design and implementation.

Stage 2.4: Create an initial vision(s) of what the problem situations would look like if addressed. Form final vision.

Stage 2.5: Design change process using human/machine activity systems.

Stage 2.6: Provide designs using tools and techniques from structured IS analysis and methodologies to support the realization of stage 2.4 and 2.5.

Stage 2.7: Compare with real world situation.

Stage 2.8: Debate and decide on implementation strategy and organizational change.

Stage 2.9: Generate stakeholder intentionally for change.

Stage 2.10: Release the decision using the implementation strategy and vision of action to bring about a human/machine activity system in the real world.

In both cycles the decision criteria deployed are: systematic desirability, cultural feasibility, value adding, technical feasibility and ethical defensibility. These stem from both SSM and actual practice. The twin cycles form a potentially never ending process of inquiry, decision making and action in the real world, during which organizational learning plays a central role in promoting improvement.

(Atkinson et al., 2002)

2. Waterfall Approach of SSM

Jun Oura and Kyooichi Kijima (2002) develop a framework for integrating traditional waterfall approach with the soft system methodology based on an information system project in a Japan food manufacturing company. This approach breaks down the information system project into five phases corresponding to those of the waterfall approach. At each stage particular SSM processes are carried out. The specific phases are shown in Table 1.

Table 1: Waterfall Approach of SSM

Phase	Waterfall Stage	SSM Process	Objective
Phase 1	Work Analysis	Expressing problem status	Promoting the understanding of work
Phase 2	Requirement	Clarifying CATWOE	Arranging necessary functions
Phase 3	Specifications & Outline Design	Creation of conceptual model	Arranging Specifications
Phase 4	Detailed Design & Development	Comparison of the conceptual model and the real world	Discuss of the entire process by all personnel
Phase 5	Implementation	Innovating and improving the real world situation	Clarifying operations

(Qura and kijima, 2001)

The authors noted that the combination of the waterfall approach and the soft system methodology produced positive synergy effects. On one hand, the embedded SSM processes helped reduce delays often seen in projects using waterfall approach when the examinations in the later phases of analysis overturn the results of the previous stages. On the other hand, the phased approach of the waterfall methodology facilitated the SSM process by organizing the discussions in an efficient way. As such, the two methodologies not only work together toward the project objective, but also negate the weaknesses of each other to some extent.

In addition, the authors also discussed the factors facilitating the implementation of SSM in Japanese organizations. In most Japanese companies, employees play an essential role in the continuous efforts to improve business process. Such an organization culture provides an excellent environment for implementing soft system methodology.

Conclusion

This paper discusses the value of soft system methodology (SSM) in information system analysis. Its social construction perspective and management focus distinguish SSM from the software engineering approach of information system analysis, making it a valuable candidate methodology in highly unstructured problem settings. However, SSM is also subject to significant weaknesses that have inhibited its wide acceptance in system analysis practice. More often than not, SSM supporters tend to characterize any criticism of SSM as hostile attacks from hard-core technology-centered functionalists. Such an attitude has prevented them from proposing effective solutions to overcome the disadvantages of SSM. Given the nature of the information system discipline, it is neither practical nor desirable to totally abandon the technical standpoint in system analysis. As a result, the future of SSM lies in how it is able to integrate with the engineering-based methodologies to help system analysts effectively address all the critical factors, whether they are “hard” or “soft”. This paper gives some examples of the latest efforts to achieve such integration. However, no claim is made that these are the optimal solution to the effective use of SSM. Instead, these examples serve to elicit more innovative ideas about how to accomplish this difficult task.

References

Atkinson CJ (1997) Soft Information Systems and Technologies Methodology, SISTem: A case study of the electronic patient record. Requirements Eng., 2, 1-22.

Atkinson CJ (2000) The ‘Soft Information Systems and Technologies Methodology’ (SISTem): an actor network contingency approach to integrated development. European Journal of Information Systems 9(2), 104-123.

Atkinson C, Eldabi T, Paul R, and Pouloudi A (2001) Integrated Approaches to health informatics research and development. Logistics Information Management 15, 138-152.

Bentley T (1993) Soft Systems Methodology. Financial Management 71(7), 22.

Checkland P (1999) Systems Thinking, Systems Practice. Wiley, Chichester.

Checkland P and Scholes J (1999) Soft Systems Methodologies in Action. Wiley, Chichester.

Connell N (2001) Evaluating soft OR: some reflections on an apparently ‘unsccessful’ implementation using a Soft Systems Methodology (SSM) based approach. Journal of the Operational Research Society, 52, 150-160.

Lauesen S (1998) Real-life object oriented systems. IEEE Software 15(2), 76-83.

Oura J and Kijima K (2002) Organization Design Initiated by Information System Development: A Methodology and its Practice in Japan. Systems Research and Behavioral Science 19 (1), 77-86.

Purvis R and Sambamurthy V (1997) An examination of designer and user perceptions of JAD and the traditional IS design methodology. Information and Management 32: 123-135.

Rose J (2002) Interaction, transformation and information systems development—an exte4nded application of Soft Systems Methodology. Information Technology and People, 15(3), 242-266.

www.brunel.ac.uk/~bustcfj/bola/information/ssm.html

www.computer.org/proceedings/hicss/ 0981/volume%206/09816024.pdf: SISTem

www.cs.auc.dk/~jeremy/pdf%20files/SSM.pdf

epubl.luth.se/1404-5508/2001/060/

www.fielding.edu/research/ar_papers/Lopes.pdf

www.geocities.com/philchlee/CSC-SSMMforCDSS.htm

oldspice.soi.city.ac.uk/project/tej/ Abstracts/IST_PT/H/Welch.C.E.html

www.ipsj.or.jp/members/SIGNotes/ Eng/13/1993/046/article010.html

www.it.bton.ac.uk/staff/esg1/resource_centre/ One_Stop/One_Stop.html

members.tripod.com/SSM_Delphi/ssm4.html

http://mscmga.ms.ic.ac.uk/jeb/or/softor.html

http://www.scu.edu.au/schools/gcm/ar/areol/areol-session13.html