Coevolving Innovations

… in Business Organizations and Information Technologies

System envisioning (OOPSLA 1998 workshop summary)

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 with the permission of Ralph Hodgson received 2006/02/16. The original article is not available online, but the reference is provided as 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:

  • How do we formulate and choose among alternative concepts of a system?
  • What considerations affect the trade-offs and the interrelationships between requirements, specification, and design?
  • How are these aspects of system development affected by the political, social, and cultural issues within an organization?


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.

Goals and Objectives

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:

  • re-conceptualize the possibilities of a software system;
  • identify interventions and techniques for imagining and sharing the possibilities of a “could-be” or “to-be” system;
  • share ideas and experiences on the role of metaphors and analogies in system conceptualization;
  • explore the relationships between systems thinking and object thinking;
  • define what system envisioning is and why it is important;
  • give examples of what happens when you do and don’t do envisioning, suggest who needs to be involved in doing it, and define what the results of envisioning look like;
  • give examples of where we know envisioning was and was not done;
  • have plans for ourselves on how we each might improve our skill at envisioning;
  • suggest ways for system envisioning to be shared, nurtured and followed;
  • create a conceptual model of system envisioning.


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

  • Reported on four experiences in which different scenarios were used for specifying system designs and requirements.

“System Envisioning” – Marilyn Bates, IBM Systems Journal, USA

  • Reported the experience of an associate editor with the IBM Systems Journal: learning a new process, then visualizing and communicating the process, and finally becoming a spokesperson for and participant in changing the process.

“System Envisioning” – Tom Bridge, IBM Consulting Group, OTP, Canada

  • Inspired by Alexander’s work the submission expressed the motivation for pattern languages as a means for creating a shared language for customers, architects and developers.

“Stories, Use Cases, Envisioning” – Alistair Cockburn, Humans and Technology, USA.

  • Explored the role of stories and metaphors as the fundamental thinking blocks that provide a foundation for envisioning.

“System Envisioning, Communication and Collaboration” – Robert Coyne, IBM Object Technology Practice, North America

  • Examined the relationship between system envisioning as inherently a group social activity whose outcomes depend on the quality of communication and collaboration processes and their infrastructure.

“System Envisioning” – Martine Devos, Argos, Belgium

  • Reported on the importance of system envisioning as an on-going activity of aligning business goals and users interests. Stressed the importance of anticipating the effect of systems and engaging all interested parties in their design. By so doing, systems are used and can evolve as opposed to being irrelevant, rejected or obsolescent.

“Systems Envisioning – A Tale of a Paradigm Lost”- Ralph Hodgson, IBM OTP, North America

  • Reported on system development as a speculative activity where visions and needs become lost, distorted and modified as work proceeds through “hand-overs” in the process. Expressed the view that to envision a system means anticipating the evolving world in which the system is a part. Ambitiously, it means creating systems as “holons” that can be readily adapted, or, are themselves self-adaptive to their environments.

“Typical Problems with System Envisioning” – Dr. Mike Karchov, IBM OTP, North America

  • Explored the place of system envisioning within the development process. The Business Domain Object Model and Business Processes define a boundary for what the system will and will not do. These processes serve as a prerequisite to the system envisioning phase. Against this background, some typical problems and mistakes made during engagements were reported.

“Providing a System Vision through Analogical Reasoning and Reusable Solutions and Assets” – Deborah Leishman, IBM OTP, North America

  • Presented three forms of envisioning. The first is no envisioning, the second is envisioning by use of personal experiences, analogies, metaphors and stories. The third type relates to utilizing explicit representations of past system problems and their solutions through reusable solutions and assets. Analogical reasoning allows the retrieval and usage of solutions and assets. Through these assets, a context in which to explore problems and solutions is possible.

“Information System Envisioning for a New Era” – Doug McDavid, IBM OTP, North America

  • Reported a vision for how a new era in information systems has been ushered onto the scene leading to an era of enterprise and trans-enterprise information systems. Thought of as the nervous systems for our businesses, our organizations, and our society, these systems embody “living systems” concepts and provide a form of enterprise cognition.

“Support Tools for Enhancing the Software Development Process” – Charles E. Matthews, Synergistic Technologies, USA

  • Reported specific elements which appear to provide beneficial assistance to the project development process. In addition to top quality people who follow sound logical development processes, a software project can be aided significantly by an effective suite of project development support tools. Such tools will assist with tracking the progress and the state of the project in accordance with the evolving project requirements.

“Systems Envisioning” – Branko Peteh, Versant Object Technology, USA

  • Expressed the challenge of incorporating existing systems into new systems. and the role of system envisioning in reconciling requirements for integration and co-existence of systems. To respond to rapidly changing technology and environments, developers often use tools and technologies of prototype-like quality in production environments, increasing the risk of failure. Envisioning of software systems often requires this risk of reaching for new technologies ahead of their maturity.

“Envisioning Future Cellular Phones through Virtual Prototypes” – Petri Pulli, VTT Finland.

  • Reported the role of virtual prototyping, in the context of consumer electronics and telecommunication industries. Described how industries in many high-volume global businesses, such as consumer electronics and telecommunications are moving to a two-phased product development paradigm with a speculative all-digital front-end to develop the product concepts, and an agile production capability to manufacture and market the product.

“System Envisioning” – Jack Ring, Innovation Management, USA

  • Envisioning creates a vision, first in the mind of the originator, then, through appropriate communication, in the minds of associates. And a system is a set of entities that are interrelated in such a way that the system stimulus-response characteristic is more than the sum of their individual characteristics. System envisioning explores the nature of the system and its purposes. We envision about not only the information and decision automation system but also the development project — the Context, Content, Structure, Process, and Behavior of work and conclusions.

“Visualizing Artifacts – Conjuring the Future” – Kalev Ruberg, IBM OTP, North America

  • Expressed the premise that “Design is Magic” and that “successful” design of artifacts relies heavily on analogy, past experience, and the ability to “see” the complete design before its parts. Successful envisioning requires pulling all the spatial and temporal constructs together in a “sketch” of the final system. This typically occurs through one person who, after “living the problem” (requirements gathering), conjures the solution from a personally known solution space (at least to the degree that they are willing to avoid risk). Illustrations of project successes and failures were cited.

“System Envisioning” – Jim Salmons, IBM Object Technology Practice, North America

  • Reported on the Executable Business Model (EBM) technology under development at IBM, as an explicit attempt to leverage object technology by building a collection of Smalltalk frameworks which support the direct execution of analytic business models (the problem space), significantly reducing, eventually eliminating, the need for transformation into design/implementation models (the solution space). By objectifying the “stuff” of which our client/partner mental models of their business are made, we put ourselves squarely in our client’s problem space. Objects and object technology disappear as a topic of discourse on an EBM-based engagement.

“Domain Thinking: Domain Engineering as a System Envisioning Technology” – Mark Simos, Organon Motives, Inc., USA

  • Expressed the view of domain analysis (or, more broadly, domain engineering) as an emerging discipline. Reported on their experiences of how a systematic domain engineering process creates a “cognitive shift” that enables software engineers to view the systems they create and their relationship to the surrounding organizational context in new ways. A major qualitative result being an enhanced capacity to envision new system capabilities, both in terms of innovative features and feature combinations, and in terms of new application contexts for domain functionality. Suggested that, along with “systems thinking” and “object thinking,” “domain thinking” should be considered as a valuable technique to explore for systematic envisioning.

Workshop Format

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.

The “As-Is” State of System Envisioning

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:

  • the lack of education, training, and experience;
  • the medium for capturing and sharing representations of envisioning;
  • process barriers – how to engage the right people.

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.

The “To-Be” Desired State

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 Discussion

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.

Break-Out Group Sessions

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:

  1. You are a publisher being asked to evolve to electronic publishing in the presence of traditional development technology with an interest in promoting web-based technology;
  2. You are a steel company being asked to create a system to reduce order fulfillment time in the presence of competition with an interest in reusing solutions in multiple steel mills;
  3. You are a software provider to school administrations being asked to create a system to help control drug use in the presence of decreasing federal funds, increasing drug use, and increasing public pressure with an interest in selling successful software systems.

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:

  • Identified the current state of the problem;
  • Searched for the core requirements;
  • Searched for analogies with other systems;
  • Created a rudimentary solution model.

Interestingly, the groups experienced the same problems as actual projects:

  • Customers who could not articulate their real requirements;
  • Difficulty in thinking out of the box – when the mind jumps ahead to a solution, it skips other opportunities;
  • Difficulty in distinguishing between creative visions and “hallucinations”.

Concluding Remarks

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.

Selected References

[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,

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

  • RSS (Mastodon)

    • daviding: Provocative statemen February 1, 2020
      Provocative statement by Canadian automobile reviewer. > There isn’t now and likely never will be enough electricity available worldwide to replace all the petroleum for the vehicles we currently drive.> And given that at least in Canada, only 11 per cent of fossil fuel emissions come from passenger vehicles (that’s not from some climate-change-denying website […]
    • daviding: Lecture on "Are Syst January 23, 2020
      Lecture on "Are Systems Changes Different from System + Change?" at #OCADU_SFI #SystemicDesign master's, web video and digital audio now at . Lecture of 1h18m covered 37 of 55 slides, all online for #SystemsChange #SystemsThinking #theoryofchange
    • daviding: The 2019-2020 fires January 5, 2020
      The 2019-2020 fires in Australia are associated with a slow history of human activity. > Three hours north, in Sydney, the air quality was worse than in Jakarta. [....] > There is no doubt that the fires are growing more ferocious. Even without the changing climate, it would be inevitable; 250 years of land mismanagement […]
    • daviding: > ... a fascinating December 18, 2019
      > ... a fascinating study by Javier Miranda, principal economist at the U.S. Census Bureau; Benjamin Jones, professor at the Kellogg School of Management at Northwestern University; and Pierre Azoulay, professor at MIT’s Sloan School of Management and research associate at the National Bureau of Economic Research. They took a detailed look at the demographics […]
    • daviding: A week of deepening December 15, 2019
      A week of deepening *democratic recession* says @FareedZakaria . Citing term by #LarryDiamond "Facing Up to the Democratic Recession" | Jan. 2015 | J Democracy at
  • RSS on IngBrief

    • Plans as resources for action (Suchman, 1988)
      Two ways of thinking about practice put (i) “plans as determinants of action”, and (ii) “plans as resources for action”. The latter has become a convention, particularly through research into Human Computer Interaction (HCI) and Computer Supported Collaborative Work (CSCW). While the more durable explanation appears the Suchman (1987) book (specifically section “8.2 Plans as […]
    • The best time to plant a tree was twenty years ago
      Does “the best time to plant a tree was twenty years ago and the second best time is now” date back further than 1988? It is time to look long and hard at the value of the urban forest and create the broad-based efforts — in research, funding and citizen participation — needed to improve […]
    • 2019/11/05 13:15 “Barriers to Data Science Adoption: Why Existing Frameworks Aren’t Working”, Workshop at CASCON-Evoke, Markham, Ontario
      Workshop led by @RohanAlexander and @prof_lyons at #CASCONxEvoke on "Barriers to Data Science Adoption: Why Existing Frameworks Aren't Working". For discussion purposes the challenges are grouped within three themes: regulatory; investment; and workforce.
    • Own opinion, but not facts
      “You are entitled to your own opinions, but not to your own facts” by #DanielPatrickMoynihan is predated on @Freakonomics by #BernardMBaruch 1950 “Every man has a right to his own opinion, but no man has a right to be wrong in his facts”. Source: “There Are Opinions, And Then There Are Facts” | Fred Shapiro […]
    • R programming is from S, influenced by APL
      History of data science tools has evolved to #rstats of the 1990s, from the S-Language at Bell Labs in the 1970s, and the
    • Bullshit, Politics, and the Democratic Power of Satire | Paul Babbitt | 2013
      Satire can be an antidote, says Prof. #PaulBabbitt @muleriders , to #bullshit (c.f. rhetoric; hypocrisy; crocodile tears; propaganda; intellectual dishonesty; politeness, etiquette and civility; commonsense and conventional wisdom; symbolic votes; platitudes and valence issues).
  • Recent Posts

  • Archives

  • RSS on

    • 2020/01 Moments January 2020
      Back to school, teaching and learning at 2 universities.
    • 2019/12 Moments December 2019
      First half of December in finishing up course assignments and preparing for exams; second half on 11-day family vacation in Mexico City.
    • 2019/11 Moments November 2019
      Wrapped up paperwork on closing out family buildings in Gravenhurst, returned to classes and technical conferences in usual pattern of learning.
    • 2019/10 Moments October 2019
      Tightly scheduled weekdays at Ryerson Chang School, weekends in Gravenhurst clearing out family building as we're leaving the town permanently.
    • 2019/09 Moments September 2019
      Full month, winding down family business in Gravenhurst, starting Ryerson Chang certificate program in Big Data, with scheduled dinners with family and friends.
    • 2019/08 Moments August 2018
      Enjoyed summer with events in Toronto, followed by trips back my home town Gravenhurst, staying overnight for the first time in over 30 years.
  • RSS on Media Queue

  • Meta

  • Creative Commons License
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
    Theme modified from DevDmBootstrap4 by Danny Machal