Susan Gasson
Associate Professor, Information Systems

• Home
• Research
• Publications

Index

• SSM Rationale: "Soft Systems" Thinking
• SSM ObjectivesThe Philosophy of SSMSSM As A Method For IS Requirements Analysis (and Change Analysis Generally)SSM as an Academic Research Method

Root Definitions

Checkland's argument is that, until you have put a name to something, you cannot possibly understand its function or purpose. The Root Definition "names" the system in a structured way.

A common problem with this stage is that, if you do not try to be precise in naming the system, you become confused as to who is performing the activities of the system and what those activities should be.

Stage 3b: Use the CATWOE framework to produce a Root Definition for each transformation

A Root Definition names the system which supports each transformation. 

The important thing is to examine each transformation from one perspective: you can happily repeat the exercise using another perspective, to see if you can integrate the two (sometimes this may not be possible, for example, how do you integrate the needs of drivers in transformation (1) with the needs of pedestrians?). If you cannot integrate competing perspectives, you must take a decision about whose perspective will have priority - this is where your client's objectives come into play. In every change, there are winners and losers; your job is to make it explicit who loses and who wins!

Use the CATWOE framework to ask the following questions:

When deriving Root Definitions, you often need to cycle around, redefining inputs and outputs, then trying to derive a definition from the input-output which you have defined. A common problem is that of being too sloppy in defining terms. For example defining the transformation in terms of "parking system" is meaningless. It tells us nothing about what the process is which gets us from cars parked in inappropriate places to cars parked in appropriate places. Similarly, defining the input-output as "illegally-parked cars" and "legally-parked cars" tells us nothing about how illegal and legal will be interpreted by different people involved in the system - you need to either define illegal in your Weltanschhaung (e.g. W: "Parking in congested streets causes accidents, so it should be punished by law") or define the input and output more tightly (i.e. Input = cars parked in congested streets; Output = no cars parked in congested streets). By being precise about terms, everyone involved in the system understands exactly what is involved - what activities need to take place and how the system's success can be measured.

The most important part of the CATWOE is the Weltanschhaung, as this communicates why we want to achieve this purpose of the system. So we need to work hard at communicating a rationale for the transformation. If we just said W: "Parking should be punished by law", this does not communicate the perspective of how important it is that this should happen, or why it should happen. However, W: "Parking in congested streets causes accidents, so it should be punished by law" communicates two things - the rationale for prevention of parking in congested streets and the reason that the stakeholder wants this as a purpose of the system. Figure 3 provides a Root Definition for the systems represented by input-output diagrams (2) and (7).  

Figure 3a: Root Definition for Input-Output Diagram (2):

 

CATWOE:

Customer:               Pedestrians

Actor(s):                 Traffic Wardens

Transformation:       Penalize parking that puts pedestrians at risk

Weltanschauung:     Pedestrian safety should have priority over driver convenience and drivers will not consider 
pedestrian safety unless they fear punishment.

Owner:                   Local Government Administration

Environment:           Unlimited road-use is considered a right by most drivers and drivers have powerful political lobby groups.

      Any system to administer road-use must be self-financing.

      Most local Government administrations regard road safety as low priority.

Root Definition:

A system owned by Local Government officials, where Traffic Wardens punish parking which puts pedestrians at risk, on behalf of pedestrians, because pedestrian safety should have priority over driver convenience and drivers will not consider safety a priority unless they fear punishment. The system will operare under the constraints of powerful drivers' political lobby groups, who consider unlimited road-use a right, the need for a self-financing system and the low priority that local Government gives road safety.

Figure 3b: Root Definition for Input-Output Diagram (7):

CATWOE:

Customer:                  Environmental lobbyists (the “public”)

Actor(s):                    Local Government officials

Transformation:          Make driving less attractive than public transport

Weltanschauung:        The number of cars on the road is directly related to environmental degradation and public health problems.

Owner:                      Local Government Administration

Environment:              Unlimited road-use is considered a right by most drivers and drivers have powerful political lobby groups.

                                  Financial incentives alone will affect poor drivers but not wealthy ones.

Root Definition:

A system owned by Local Government Administration, where Local Government Officials make driving less attractive than public transport on behalf of Environmental Lobbyists among the public because the number of cars on the road is directly related to environmental degradation and public health problems, but limited by the need to find alternatives to financial incentives alone and the power of drivers' lobby groups.

It is important to reflect that the root definition should not describe a method of doing something (the system mechanisms or how the system works), but what needs to be done (system purpose). If we defined the transformation as "charge more for road use than for public transport" or "make road use more expensive than public transport" (the "obvious" way of defining this transformation!), then we would miss the opportunity to think laterally about ways of incentivising the use of public transport vs. disincentivising driving. Maybe we will not think of any ways of doing this, other than by financial measures. But at least we are leaving in the opportunity to do this (and to get suggestions from stakeholders about how to do this), by defining the transformation in terms of "what" and not "how". We also leave open the opportunity to make the system more effective and so change things for the better - this should be the point of a really good system requirements analysis, rather than just automating what's there  ...

If you examine the two root definitions derived above, you will see that these describe completely different systems. These are definitions which involve a completely different set of goals and activities. This is why we use SSM to analyze a situation: in a conventional systems analysis, it would be very easy to skimp on the analysis by using input-output diagram (1) to define our system. All the other transformations may well be intended by the Government, but if they are not stated explicitly, they may well be left out of the eventual system because no-one remembers to include them!

©Susan Gasson 2013.
Web template (Plain 2.0) designed by James Koster for OSWD. Adapted by Susan Gasson