The what and whence of issue-based information systems

Over the last few months I’ve written a number of posts on IBIS (short for Issue Based Information System), an argument visualisation technique invented in the early 1970s by Horst Rittel and Werner Kunz.  IBIS is best known for its use in dialogue mapping – a collaborative approach to tackling wicked problems – but it has a range of other applications as well (capturing project knowledge is a good example).    All my prior posts on IBIS focused on its use in specific applications.   Hence the present piece,  in which I discuss the “what” and “whence”  of IBIS:  its practical aspects – notation, grammar etc. –   along with  its origins, advantages and limitations

I’ll begin with a brief introduction to the technique (in its present form) and then move on to its origins and other aspects.

A brief introduction to IBIS

IBIS  consists of three main elements:

1. Issues (or questions): these are issues that need to be addressed.
2. Positions (or ideas): these are responses to questions. Typically the set of ideas that respond to an issue represents the spectrum of perspectives on the issue.
3. Arguments: these can be Pros (arguments supporting) or Cons (arguments against) an issue. The complete  set of arguments that respond to an idea represents the multiplicity of viewpoints on it.

The best IBIS mapping tool is Compendium – it can be downloaded here.  In Compendium, the IBIS elements described above are represented as nodes as shown in Figure 1: issues are represented by green question nodes; positions by yellow light bulbs; pros by green + signs and cons by red – signs.  Compendium supports a few other node types,  but these are not part of the core IBIS notation. Nodes can be linked only in ways specified by the IBIS grammar as I discuss next.

Figure 1: IBIS Elements

The IBIS grammar can be summarized in a few simple rules:

1. Issues can be raised anew or can arise from other issues, positions or arguments. In other words, any IBIS element can be questioned.  In Compendium notation:  a question node can connect to any other IBIS node.
2. Ideas can only respond to questions – i.e.  in Compendium “light bulb” nodes  can only link to question nodes. The arrow pointing from the idea to the question depicts the “responds to” relationship.
3. Arguments  can only be associated with ideas –  i.e in Compendium + and –  nodes can only link to “light bulb” nodes (with arrows pointing to the latter)

The legal links are summarized in Figure 2 below.

Figure 2: Legal Links in IBIS

The rules are best illustrated by example-   follow the links below to see some illustrations of IBIS in action:

1. See this post for a simple example of dialogue mapping.
2. See this post or this one for examples of argument visualisation .
3. See this post for the use IBIS  in capturing project knowledge.

Now that we know how IBIS works and have seen a few examples of it in action, it’s time to trace its history from its origins to the present day.

Wicked origins

A good place to start is where it all started. IBIS was first described in a paper entitled, Issues as elements of Information Systems; written by Horst Rittel (who coined the term “wicked problem”) and Werner Kunz in July 1970. They state the intent behind IBIS in the very first line of the abstract of their paper:

Issue-Based Information Systems (IBIS) are meant to support coordination and planning of political decision processes. IBIS guides the identification, structuring, and settling of issues raised by problem-solving groups, and provides information pertinent to the discourse.

Rittel’s preoccupation was the area of public policy and planning – which is also the context in which he defined wicked problems originally.  He defined the term in his landmark paper of 1973 entitled, Dilemmas in  a General Theory of Planning. A footnote to the paper states that it  is based on an article that he   presented at an AAAS meeting in 1969. So it is clear that he had already formulated his ideas on wickedness when he wrote his paper on IBIS in 1970.

Given the above background it is no surprise that Rittel and Kunz foresaw IBIS to be the:

…type of information system meant to support the work of cooperatives like governmental or administrative agencies or committees, planning groups, etc., that are confronted with a problem complex in order to arrive at a plan for decision…

The problems tackled by such  cooperatives are paradigm-defining examples of wicked problems. From the start, then, IBIS was intended as a tool to facilitate a collaborative approach to solving such problems.

Operation of early systems

When Rittel and Kunz wrote their paper, there were three IBIS-type systems in operation: two in governmental agencies (in the US, one presumes) and one in a university environment (possibly, Berkeley, where Rittel worked). Although it seems quaint and old-fashioned now, it is no surprise that they were all manual, paper-based systems- the effort and expense involved in computerizing such systems in the early 70s would have been prohibitive, and the pay-off questionable.

The paper also offers a short description of how these early IBIS systems operated:

An initially unstructured problem area or topic denotes the task named by a “trigger phrase” (“Urban Renewal in Baltimore,” “The War,” “Tax Reform”). About this topic and its subtopics a discourse develops. Issues are brought up and disputed because different positions (Rittel’s word for ideas or responses) are assumed. Arguments are constructed in defense of or against the different positions until the issue is settled by convincing the opponents or decided by a formal decision procedure. Frequently questions of fact are directed to experts or fed into a documentation system. Answers obtained can be questioned and turned into issues. Through this counterplay of questioning and arguing, the participants form and exert their judgments incessantly, developing more structured pictures of the problem and its solutions. It is not possible to separate “understanding the problem” as a phase from “information” or “solution” since every formulation of the problem is also a statement about a potential solution.

Even today, forty years later, this is an excellent description of how IBIS is used to facilitate a common understanding of complex (or wicked) problems. The paper contains an overview of the structure and operation of manual IBIS-type systems. However, I’ll omit these because they are of little relevance in the present-day world.

As an aside, there’s a  term that’s conspicuous by its absence in the Rittel-Kunz paper: design rationale. Rittel must have been aware of the utility of IBIS in capturing design rationale: he was a professor of design science at Berkley and design reasoning was one of his main interests. So it is somewhat odd that  he does not mention this term  even once  in his IBIS  paper.

Fast forward a couple decades (and more!)

In a paper published in 1988 entitled, gIBIS: A hypertext tool for exploratory policy discussion, Conklin and Begeman describe a prototype of a graphical, hypertext-based  IBIS-type system (called gIBIS) and its use in capturing design rationale (yes, despite the title of the paper, it is more about capturing design rationale than policy discussions). The development of  gIBIS represents a key step between the original Rittel-Kunz version of IBIS and its  present-day version as implemented  in Compendium.  Amongst other things, IBIS was finally off paper and on to disk, opening up a new world of possibilities.

gIBIS aimed to offer users:

1. The ability to capture design rationale – the options discussed (including the ones rejected) and the discussion around the pros and cons of each.
2. A platform for promoting computer-mediated collaborative design work  – ideally in situations where participants were located at sites remote from each other.
3. The ability to store a large amount of information and to be able to navigate through it in an intuitive way.

Before moving on, one point needs to be emphasized: gIBIS was intended to be used in collaborative settings; to help groups achieve a shared understanding of central issues, by mapping out dialogues in real time. In present-day terms – one could say that it was intended as a tool for sense making.

The gIBIS prototype proved successful enough to catalyse the development of Questmap, a commercially available software tool that supported IBIS. However, although there were some notable early successes in the real-time use of IBIS in industry environments (see this paper, for example), these were not accompanied by widespread adoption of the technique. Other graphical, IBIS-like methods to capture design rationale were proposed (an example is Questions, Options and Criteria (QOC) proposed by MacLean et. al. in 1991), but these too met with a general reluctance in adoption.

Making sense through IBIS

The reasons for the lack of traction of IBIS-type techniques in industry are discussed in an excellent paper by Shum et. al. entitled, Hypermedia Support for Argumentation-Based Rationale: 15 Years on from gIBIS and QOC.  The reasons they give are:

1. For acceptance, any system must offer immediate value to the person who is using it. Quoting from the paper, “No designer can be expected to altruistically enter quality design rationale solely for the possible benefit of a possibly unknown person at an unknown point in the future for an unknown task. There must be immediate value.” Such immediate value is not obvious to novice users of IBIS-type systems.
2. There is some effort involved in gaining fluency in the use of IBIS-based software tools. It is only after this that users can gain an appreciation of the value of such tools in overcoming the limitations of mapping design arguments on paper, whiteboards etc.

The intellectual effort – or cognitive overhead, as it is called in academese – in using IBIS in real time involves:

1. Teasing out issues, ideas and arguments from the dialogue.
2. Classifying points raised into issues, ideas and arguments.
3. Naming (or describing) the point succinctly.
4. Relating (or linking) the point to an existing node.

This is a fair bit of work, so it is no surprise that beginners might find it hard to use IBIS to map dialogues. However, once learnt, a skilled practitioner can add value to design (and more generally, sense making) discussions in several ways including:

1. Keeping the map (and discussion) coherent and focused on pertinent issues.
2. Ensuring that all participants are engaged in contributing to the map (and hence the discussion).
3. Facilitating useful maps (and dialogues) – usefulness being measured by the extent to which the objectives of the session are achieved.

See this paper by Selvin and Shum for more on these criteria. Incidentally, these criteria are a qualitative measure of how well a group achieves a shared understanding of the problem under discussion.  Clearly, there is a good deal of effort involved in learning and becoming proficient at using IBIS-type systems, but the payoff is an ability to facilitate  a shared understanding of wicked problems – whether in public planning or in technical design.

Why IBIS is better than conventional modes of documentation

IBIS has several advantages over conventional documentation systems. Rittel and Kunz’s 1970  paper contains a nice summary of the advantages, which I paraphrase below:

1. IBIS can bridge the gap between discussions and records of discussions (minutes, audio/video transcriptions etc,). IBIS sits between the two, acting as a short term memory. The paper thus foreshadows the use of issue-based systems as an aid to organizational or project memory.
2. Many elements (issue, ideas or arguments) that come up in a discussion have contextual meanings that are different from any pre-existing definitions. In discussions, contextual meaning is more than formal meaning. IBIS  captures the former in a very clear way – for example a response to a question “What do we mean by X? elicits the meaning of X in the context of the discussion, which is then subsequently captured as an idea (position)”.
3. Related to the above, the commonality of an issue with other, similar issues might be more important than its precise meaning. To quote from the paper, “…the description of the subject matter in terms of librarians or documentalists (sic) may be less significant than the similarity of an issue with issues dealt with previously and the information used in their treatment…”  With search technologies available, this is less of an issue now. However, search technologies are still limited in terms of finding matches between “similar” items (How is “similar” defined? Ans: it depends on context). A properly structured, context-searchable IBIS-based project archive may still be more useful than a conventional document archive based on a document management system.
4. The reasoning used in discussions is made transparent, as is the supporting (or opposing) evidence. (see my post on visualizing argumentation for example)
5. The state of the argument (discussion) at any time can be inferred at a glance (unlike the case in written records). See this post for more on the advantages of visual documentation over prose.

Issues with issue-based information systems

Lest I leave readers with the impression that IBIS is a panacea, I should emphasise that it isn’t. According to Conklin, IBIS maps have the following limitations:

1. They atomize streams of thought into unnaturally small chunks of information thereby breaking up any smooth rhetorical flow that creates larger, more meaningful chunks of narrative.
2. They disperse rhetorically connected chunks throughout a large structure.
3. They are not is not chronological in structure (the chronological sequence is normally factored out);
4. Contributions are not attributed (who said what is normally factored out).
5. They do not convey the maturity of the map – one cannot distinguish, from the map alone, whether one map is more “sound” than another.
6. They do not offer a systematic way to decide if two questions are the same, or how the maps of two related questions relate.

Some of these issues (points 3, 4) can be addressed by annotating nodes;  others are not so easy to solve.

Concluding remarks

My aim in this post has been to introduce readers to the IBIS notation, and also discuss its origins, development and limitations.  On one hand, a knowledge of the origins and development  is valuable because it  gives  insight into the rationale behind the technique, which leads to a better understanding of the different ways in which it can be used. On the other, it is also important to know a technique’s limitations,  if for no other reason than to be aware of these so that one can work around them.

Before signing off, I’d like to mention an observation from my experience with IBIS. The real surprise for me has been that the technique can capture most written arguments and discussions,  despite having only three distinct elements and a very simple grammar. Yes, it does require some thought to do this, particularly when mapping discussions in real time. However,  this cognitive “overhead”  is good because  it forces the mapper to think  about what’s being said  instead of just writing it down blind. Thoughtful transcription is the aim of the game. When done right, this results in a map that truly reflects a  shared understanding of the complex  (and possibly wicked) problem under discussion.

There’s no better coda to this post on IBIS than the following quote from  this paper by Conklin:

…Despite concerns over the years that IBIS is too simple and limited on the one hand or too hard to use on the other, there is a growing international community who are fluent enough in IBIS to facilitate and capture highly contentious debates using dialogue mapping, primarily in corporate and educational environments…

For me that’s reason enough to improve my understanding of IBIS and its applications,  and to look for opportunities to use it in ever more challenging situations.