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.
Overview
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?
Motivations
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.
Submissions
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:
- 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;
- 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;
- 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
Attendees
Bruce Anderson, IBM OTP EMEA, UK
bruce_anderson@uk.ibm.com Bruce.Anderson@uk.ibm.com, bruce@essex.ac.uk
Marilyn Bates, IBM System Journal, USA
mbates@vnet.ibm.com marilyn_bates@uk.ibm.com
Tom Bridge, IBM Consulting Group, Canada
tbridge@torovm1.vnet.ibm.com tbridge@ca.ibm.com
Alistair Cockburn, Humans and Technology, USA
arc@acm.org
Robert Coyne, IBM OTP, North America
rcoyne@vnet.ibm.com robert@topquadrant.com
Martine Devos, Argo, Belgium
mdevos@argo.be mmdevos@acm.org
Ralph Hodgson, IBM OTP, North America
rhodgson@vnet.ibm.com rhodgson@topquadrant.com
Michael Karchov, IBM OTP, North America
mkarchov@vnet.ibm.com Michael.Karchov@us.ibm.com
Deborah Leishman, IBM OTP, North America
dleishman@vnet.ibm.com leishman@lanl.gov
Guillermo Lois, IBM Consulting Group, Europe
gmolois@stovm1.vnet.ibm.com gloi@ch.ibm.com
Doug McDavid, IBM OTP, North America
mcdavid@netcom.com mcdavid@us.ibm.com
Charles E. Matthews, Synergistic Technologies, USA
chuckm@infonet.isl.net
Branko Peteh, Versant Object Technology, USA
Branko@versant.com
Petri Pulli, VTT, Finland
Petri.Pulli@vtt.fi
Jack Ring, Innovation Management, USA
jring@amug.org
Kalev Ruberg, IBM OTP, North America
kruberg@vnet.ibm.com
David Sapp, IBM OTP, North America
dsapp@ibm.net sappd@us.ibm.com
Mark A. Simos, Organon Motives Inc., USA
mas@organon.com
2 Comments