Reported by: Charles E. Matthews and Ralph Hodgson
Workshop Organizers: Ralph Hodgson, Tom Bridge, Charles E. Matthews, Robert Coyne, Bruce Anderson, Deborah Leishman, Doug McDavid, Carl Ballard
Editorial note by David Ing: This report is republished on coevolving.com with the permission of Ralph Hodgson received 2006/02/16. The original article is not available online, but the reference is provided as http://doi.acm.org/10.1145/346852.346964 Some addresses at the end of the article have been corrected.
Systems are conceived out of an understanding and conceptualizing of a problem space. System Envisioning is about how we create possibilities for what a system might and should do and seeks to answer:
This workshop was motivated by an interest in sharing experiences on the relationships between problem domain understanding and creative thinking on formulating systems concepts. We were interested in how different types of thinking and action are involved in developing the conceptual architecture of a system. Particularly, we were concerned with requirements elicitation and generation, organizational design, systems thinking, holonics and cybernetics, object thinking, creativity and imagineering, metaphorical exploration, synectics and analogical reasoning, human communications and dialog-based interaction.
We wanted to identify motivational interests and to share experiences on how system envisioning has happened and can happen in system development projects – including experiences related to the effectiveness of tools used within the specification and development process. We wanted to share stories on “leaving behind” an “as-is” system to:
Each participant was required to prepare beforehand a one to two page paper describing thoughts and insights on system envisioning. The papers are listed below:
“Systems Envisioning” – Bruce Anderson, IBM EMEA Object Technology Practice, UK
“System Envisioning” – Marilyn Bates, IBM Systems Journal, USA
“System Envisioning” – Tom Bridge, IBM Consulting Group, OTP, Canada
“Stories, Use Cases, Envisioning” – Alistair Cockburn, Humans and Technology, USA.
“System Envisioning, Communication and Collaboration” – Robert Coyne, IBM Object Technology Practice, North America
“System Envisioning” – Martine Devos, Argos, Belgium
“Systems Envisioning – A Tale of a Paradigm Lost”- Ralph Hodgson, IBM OTP, North America
“Typical Problems with System Envisioning” – Dr. Mike Karchov, IBM OTP, North America
“Providing a System Vision through Analogical Reasoning and Reusable Solutions and Assets” – Deborah Leishman, IBM OTP, North America
“Information System Envisioning for a New Era” – Doug McDavid, IBM OTP, North America
“Support Tools for Enhancing the Software Development Process” – Charles E. Matthews, Synergistic Technologies, USA
“Systems Envisioning” – Branko Peteh, Versant Object Technology, USA
“Envisioning Future Cellular Phones through Virtual Prototypes” – Petri Pulli, VTT Finland.
“System Envisioning” – Jack Ring, Innovation Management, USA
“Visualizing Artifacts – Conjuring the Future” – Kalev Ruberg, IBM OTP, North America
“System Envisioning” – Jim Salmons, IBM Object Technology Practice, North America
“Domain Thinking: Domain Engineering as a System Envisioning Technology” – Mark Simos, Organon Motives, Inc., USA
The workshop activities were organized using the theme of a “ThinkShop” – a dialog-based approach combining the idea of a “Think-Tank” with elements of “Future Search” conferences. The workshop scenario was based on the theme:
We have been asked to come to this “ThinkShop” on System Envisioning to improve our ability to deal with the “System Crisis”. Objects solved the “Software Crisis”- now we have to improve our ability to conceive the “right” systems. Following mixed experiences with BPR, OO, Client-Server, Expert Systems, and the “promise” of new technology entrants such as Intranets, our organizations increasingly are aware that the system focus with support for envisioning is important to the creation of effective human activity and software systems. We have been asked to return with a clearer idea of what system envisioning is, why it is important and how we should do it.
The workshop began with general discussion focused upon identifying first the “As-Is” problem situations and then the “To-Be” desired situation. A panel discussion fostered an in-depth examination of some specific projects which displayed good or bad envisioning principles. This was followed by a role-playing exercise in which the workshop participants formed three groups. Each group was given the task to select a problem statement, do a mini-envisioning session on that problem statement and report back in plenary to the workshop.
System Envisioning resembles a “soft” science in many respects because architects and designers experience a great deal of trouble in defining exactly what it is and what aspects of envisioning cause it to be difficult. Even describing “What does System Envisioning look like”, implies that an accepted view exists today.
There was no exact definition of what System Envisioning involved, but several issues were found to be shared by many of the participants. Three primary themes of the “As-Is” discussion were:
Envisioning depends upon teamwork and collaboration, which is not generally taught in computer science education. Also, many company organizations neither encourage nor permit effective teamwork and collaboration.
If envisioning is to be taught, then we need a shared mental model of what it is, ways to represent it, and a process to capture it. A common language and a workable representation must exist. The semiotics of how you present the vision are critical for the vision to be communicated and owned by the customer. The customer must see concrete representations – possibly animated visions or an enacted model of behavior.
Once the “How” of envisioning is understood, the “When” and the “Who” concerns become relevant. Not everyone can do envisioning. Creativity can be thwarted when logical minds have their way. Some people have visions and dreams. Other people can only deal with logical concrete things. A real tension can exist between these groups of people.
Envisioning has a better chance of success when a shared vision exists and is communicated. Symbols and terms need not be limited to written communication. For example, some aspects of user role-playing are evident in applications involving use-cases. Use of animation and user drawing (or painting) appear promising as mechanisms for representing a system vision.. What is essential is an agreed semantic language to deal with the many levels of abstraction that “convey” the vision.
Even if a shared vision exists and is communicated, other difficulties arise. Because products are constantly taking on increasing information content, envisioning will never be an exact process. Using an analogy to biology, one can view system envisioning as patterns of mutations – natural selections occurring in the environment of users and markets. We need a framework for “dancing around” the design mutations and for dealing with constant change.
When envisioning is successfully occurring some common characteristics emerge, especially when the design is being communicated to someone outside of the architectural team. A gradual revelation of the system design occurs as abstract layers are peeled back to reveal more concrete components of the design. The higher levels of abstraction must be flexible enough to handle mutations and changes to the design with evolution of requirements. And since large projects invariably have many people, an effective environment requires a shared workspace for communicating information and knowledge quickly among all of the project members.
Envisioning brings changes in skills and training. Much of the training should involve using experienced envisioners as mentors or coaches. This is a shared process that weaves envisioning, realization, and reflection into an integrated process at the organizational level. As such, skills such as creativity techniques and the tools for using them are important considerations.
Panel: Kal Ruberg, Doug McDavid, Jack Ring
Moderator: Deborah Leishman
The panel discussion began with short presentations from three attendees acting as “seasoned envisioners”. They expressed the common view that those projects which established an emotional or visceral feeling among the participants had a much better chance of success. Vision “gropes” without any direction do not seem to work.
The architect must “live the situation” personally. If you are writing a system for the manufacturing line, go down and work on the manufacturing line for some time. If you are developing a system for running an oil rig, imagine how an oil rig responds to different conditions. Jack Ring presented stories of race car personnel who would become the race car when they thought about the race.
Experience is essential – not only among the architects but also among the managers. Everyone must have a clear understanding of the state of the total technology support.
The fulfillment of the purpose of a system is what it actually does, not what it was designed to do. Anticipating what a system will actually do in the context of real use, you must thoroughly understand the problem situation, articulate a vision of the imagined world of what the customer is saying is wanted and communicate that vision to the developers.
The participants were organized into groups. Each group constructed a scenario, did envisioning and presented results back to the workshop. Each scenario was constructed using the template:
“You are an X being asked to do Y in the presence of Z with an interest in W”.
The three scenarios were:
Different members were asked to play different roles such as project leader, customer and recorder of events. Although each group took different routes to their final destination, each group, at some point in time, accomplished the following activities:
Interestingly, the groups experienced the same problems as actual projects:
In A Writer’s Time [ATCH95] Kenneth Atchity states, “Writers have always recognized that language is insufficient for perfect communication of their private vision. The vision of the islands [of thought] cannot be expressed except through the wordless language of feeling, which the writer experiences in isolation. That experience must be translated into words that express the writer’s island vision, so that we can share it.”
When we are doing envisioning, it is difficult to represent what we want to communicate. Specific roles and processes are needed, as are shared workspaces and tools which promote collaboration and teamwork.
[ATCH95] Atchity, Kenneth. A Writer’s Time. New York: W. W. Norton, 1995.
[CHEC81] Checkland, Peter. Systems Thinking, Systems Practice, New York: John Wiley & Sons, 1981.
[CRUS86] Cruse, D.A. Lexical Semantics, New York: Cambridge University Press, 1986.
[NONA95] Nonaka, I. “The Knowledge-Creating Company.” Harvard Business Review, November-December 1986.
[SENG90] Senge, P. The Fifth Discipline. New York: Doubleday/Currency, 1990.
[TAYL82] Taylor, David. Mind, New York: Simon & Schuster, 1982.
[TREH91] Trehub, Arnold. The Cognitive Brain
Bruce Anderson, IBM OTP EMEA, UK
email@example.com Bruce.Anderson@uk.ibm.com, firstname.lastname@example.org
Marilyn Bates, IBM System Journal, USA
Tom Bridge, IBM Consulting Group, Canada
Alistair Cockburn, Humans and Technology, USA
Robert Coyne, IBM OTP, North America
Martine Devos, Argo, Belgium
Ralph Hodgson, IBM OTP, North America
Michael Karchov, IBM OTP, North America
Deborah Leishman, IBM OTP, North America
Guillermo Lois, IBM Consulting Group, Europe
Doug McDavid, IBM OTP, North America
Charles E. Matthews, Synergistic Technologies, USA
Branko Peteh, Versant Object Technology, USA
Petri Pulli, VTT, Finland
Jack Ring, Innovation Management, USA
Kalev Ruberg, IBM OTP, North America
David Sapp, IBM OTP, North America
Mark A. Simos, Organon Motives Inc., USA