Reprinted from GroupWare '92, Proceedings
of the GroupWare '92 Conference, San Jose, CA, Aug 3-5, 1992, Morgan Kaufmann
Publishers, (pp. 77-100).
Achieving tomorrow's high-performance organizations will involve massive
changes throughout their capability infrastructures. The complexity of implementing
these changes will be daunting, and deserves a strategic approach. Groupware
will support important, special new knowledge capabilities in these infrastructures,
and also can play a key role in an evolutionary strategy.
1.1 Shared Visions and the "Groupware Community"
Groupware to me, personally, is a strategic means to an important end: creating truly high performance human organizations. My pursuit began in the '50s, aiming to make our organizations and institutions better able to handle complexity and urgency. By 1962 I had evolved a basic conceptual framework for pursuing that goal (Ref-1 and Ref-2). I have essentially lived and worked within that framework ever since, steadily evolving and enriching
it via many relevant experiences.
It is becoming relatively common of late, in the increasing flow of literature
about organizational improvement, to highlight the need for the members
of an organization to have a shared vision of where and how the organization
is moving, in its marketplace and in its internal evolution. I assume that
the same principle should be applicable to a looser organizational unit,
in this case, to the community consisting of organizations and researchers
interested in the overlapping domains of organizational improvement and
"groupware," and including the information-system marketplace
whose business is providing products and services to end-user organizations.
From my experience, the nature of this shared vision will be the single
most important factor in how directly and how well the digital-technology
marketplace will indeed support significantly higher organizational capability
- which I assume is our basic objective in the evolution of groupware.
MY own vision about pursuing high-performance organizations has matured
over the years into a quite comprehensive, multi-faceted,
strategic framework. It may seem a bit radical in nature, but my continuing
hope is that it will be merged into such a shared community vision.
The full purpose of our Bootstrap Institute is to promote constructive
dialog with critical stakeholders in the community about this "bootstrap
strategy," to facilitate its trial adoption, and to further the strategy's
own "continuous improvement."
In this paper I summarize the key elements of this strategic framework
and highlight the role that would be played by the "groupware community."
In Ref-3 is an explicit historical treatment that provides a good deal of
background on framework development up to 1986. Also, Ref-4 gives a relatively
balanced description of our associated groupware and application developments
with an underlying framework treatment.
1.2 Capability Infrastructure and its Augmentation System
Any high-level capability needed by an organization rests atop a broad
and deep capability infrastructure, comprised of many layers of composite
capabilities, each depending upon the integration of lower-level capabilities.
At the lower levels lie two categories of capabilities: Human-Based and
Tool-Based. The functional capabilities of groupware fit into the latter
category, along with a wide variety of facilities, artifacts, and other
In pursuit of higher organizational performance, this infrastructure
is the obvious focus of attention. Then it is a matter of establishing system
and goal perspectives to determine how much of this infrastructure to include
as serious candidates for change, and how radical a change to contemplate.
I arrived at a singularly global perspective from the following considerations.
Figure 1 shows the result of a great deal of thought about how over the
centuries our cultures have evolved rich systems of things that, when humans
are conditioned and trained to employ them, will augment their basic, genetically
endowed capabilities so that they, and their organizations, can exercise
capabilities of much higher nature than would otherwise be possible. For
lack of a ready-made term, I named this our Augmentation System, and found
it valuable to partition it into the two parts as shown - a Human System
and a Tool System. I have developed many things from this model that have
proved useful and valid over the years - including essentially everything
I've developed in the groupware arena (tools, concepts, strategies).
Figure 1. AUGMENTED CAPABILITIES - WITH HIGHER LEVELS DEPENDING UPON
A bit of thinking about this model brought me the realization that we
are far short of being able to do a one-pass re-design of any major portion
of this capability infrastructure - if only because of their pervasive,
underlying dependence upon human processes.
And as we pursue significant capability improvement, we need to appreciate
that we will be trying to affect the evolution of a very large and complex
system that has a life and evolutionary dynamic of its own. Concurrent evolution
of many parts of the system will be going on anyway (as it has for centuries).
We will have to go along with that situation, and pursue our improvement
objectives via facilitation and guidance of these evolutionary processes.
Therefore, we should become especially oriented to pursuing improvement
as a multi-element, co-evolution process. In particular, we need
to give explicit attention to the co-evolution of the Tool System and the
And, along with these foregoing perceptions, another factor popped into
the scene to create a very significant effect on my emergent framework.
1.3 The Relevant Implications of Radical Scale Change
Some years earlier, I had studied the issues and prospects associated
with extreme miniaturization of functional devices, towards assessing the
likelihood of digital equipment becoming extremely small, fast and cheap.
I was personally motivated because I would have to be relatively confident
of very significant progress in that regard in order to commit a career
towards facilitating widespread computer augmentation.
I learned enough to convince myself that, with the expected high industrial
and military demand toward digital technology, the achievable limits on
micro scalability were far beyond what would be enough to warrant my particular
pursuits. And in the process, looking into references dealing with dimensional
scale in living things, I became aware of a very important general principle:
if the scale is changed for critical parameters within a complex system,
the effects will at first appear as quantitative changes in general appearance,
but after a certain point, further scale change in these parameters will
yield ever-more striking qualitative changes in the system.
For example: The appropriate design for a five-foot creature is not that
much different from that for a six-foot creature. But the design for either
of these would be totally inappropriate for a one-inch creature, or for
a thirty-foot creature. A mosquito as big as a human couldn't stand, fly
or breathe. A human the size of a mosquito would be badly equipped for basic
mobility, and for instance would not be able to drink from a puddle without
struggling to break the surface tension, and then if his face were wetted,
would very likely get pulled under and be unable to escape drowning.
The lesson: Expect surprising qualitative changes in structural assemblage
and functional performance when a complex system adapts effectively to drastic
changes in critical parameters.
I could only assume that the same is very likely to be true for the complex
Augmentation System that supports an organization's capability infrastructure.
Here, the radical change in the scale of Tool System capability - in speed,
function, capacity, presentation quality, transmission, etc. of emergent
digital technology - greatly transcends any other perturbation in system
parameters that our organizations have ever needed to adapt to in so short
a time as a few decades.
Much more could be said about the scaling issue that is relevant to the
general theme of organizational change. Sufficient here to say that these
thoughts drove me definitely to view as global and massive both the opportunity
and the challenge that we humans were facing with respect to increasing
the performance level of the organizations and institutions upon which mankind's
continuing existence depends.
1.4 The Underlying Importance of Paradigms
In the ensuing thirty years since the model of Figure 1 first evolved,
I have become ever more convinced that human organizations can be transformed
into much higher levels of capability. These digital technologies, which
we have barely learned to harness, represent a totally new type of nervous
system around which there can evolve new, higher forms of social organisms.
In the face of mounting evidence that our organizations and institutions
can not cope adequately with the increasing complexity and urgency of our
society's problems, it seems highly motivating to explore every avenue that
offers reasonable probability of improving their capability to cope.
Those were my thoughts thirty years ago; they seem even more germane
today. The technologies have been demonstrated, and our organizations are
aligning toward internal improvement. What seems still to be lacking is
an appropriate general perception that:
(a) huge changes are likely, and really significant improvements are
(b) surprising qualitative changes may be involved in acquiring higher
(c) there might actually be an effective, pragmatic strategy for pursuing
In developing a basic, scaleable strategy, the above issues of perception
are important enough to warrant being explicitly factored into it. In other
words, the strategy should provide for the need of significant shifts in
our perception of our likely and possible futures.
Perceptions, shared visions, paradigms - their evolution is critical,
yet they receive little or no direct developmental attention. The slow,
un-shepherded paradigm drifting of the past isn't an adequate process for
times when deeper global changes are occurring than ever before accommodated
by such massive social bodies. And the rates of such change are more likely
to increase than to diminish.
I interject such thoughts here because I actually believe that what can
be produced by the groupware community can make a very large difference
(in a proper strategic framework) to our capability for coping with large,
complex problems. The ability to acquire this new capability is heavily
dependent upon evolving an appropriate paradigm, which result in itself
represents the type of complex challenge that our institutions need to become
more capable of handling.
This leads to an assumption that an important factor to hope for, in
an early stage of the future paradigms possessed by key players in this
transformation of our organizations, is the perception of importance and
a can-do attitude about consciously cultivating appropriate evolutionary
trends and change rates in our future paradigms. Shifting our paradigm about
What role will you play?
2 IMPROVING THE IMPROVEMENT PROCESS
The next step in developing an explicit strategic framework was generated
from the conceptual content of Figure 1 by asking what sort of investment
principles would make sense. I hoped to solicit R&D money and wondered
how we might get the best return on those funds in facing this very large,
unstructured problem. I also was prepared to invest essentially the rest
of my professional career: how should I invest that time to get best net
progress? And what basic guidelines should be adopted for launching (bare
handed, so to speak) such a program?
The only serious approach that I could imagine, towards really significant
improvement, would be a long-term, pragmatically guided, whole-system evolution.
I was addressing a very complex system, and the challenge would be further
complicated by the fact that the subject organizations would have to keep
functioning at better than survival level while undergoing large, systemic
So the image depicted in Figure 2 emerged from realizing that the capability
of an organization to improve itself would have to become much more prominent
and effective. It then seemed natural to consider a strategy wherein the
earliest improvement efforts might be concentrated upon improving this capability
(i.e., to improve the organization's improvement capability).
Figure 2. CO-EVOLUTION IS A CAPABILITY THAT WARRANTS
SERIOUS HIGH-LEVEL ATTENTION!
3 THE ABC MODEL OF ORGANIZATIONAL IMPROVEMENT
In doing some further thinking about improvement activities and the capabilities
that support them, I found it useful to extract from Figure 2 a simpler
abstraction dealing with organizational improvement, as in Figure 3. Here
we separate the two types of activities, A and B, and show that the capability
for each type of work is supported by its respective Augmentation System
(comprised of Human and Tool systems).
Figure 3. SIMPLE ORGANIZATION MODEL SHOWINGEXPLICIT
PROVISION FOR IMPROVEMENT
Given this model, we can now consider the prospects of improving the
organization's improvement capability, as discussed earlier in Figure 2,
as improving the capability of the B Activity. And for such a critical
pursuit to be effective requires yet another explicit organizational activity,
depicted in Figure 4 as the organization's C Activity. Executive efforts
to assess and improve B-Activity funding, staffing, and high-level approach
would qualify as a C Activity. C Activities would also include introducing
new knowledge and skills into the B Activity, providing better means for
participatory interaction with its AActivity clients, or improving how pilot
operations are managed.
Figure 4. HERE IS A USEFUL WAY TO CHARACTERIZE THE GOALS
OF B AND C ACTIVITIES
4 LOOKING FOR A MULTI-PAYOFF CAPABILITY CLUSTER
In considering the infrastructure elements that support this higher-level,
self-improvement B Capability, I realized that many of its important subordinate
capabilities are also actively employed by many of the higher-level A Capabilities
that are important to the basic operations of the organization. For example,
identifying needs and opportunities, designing and deploying solutions,
and integrating lessons learned. This led to the following rhetorical question:
Is there a set of basic capabilities whose improvement would significantly
enhance both the higher-level operational A Capabilities and this self-improvement
The answer was a clear "Yes!" A core set of knowledge-related
capabilities rapidly emerged as the prime candidate.
An investment that boosts the A Capability provides a one-shot boost.
An investment that boosts the B Capability boosts the subsequent rate by
which the A Capability increases. And an investment that boosts the C Capability
boosts the rate at which the rate of improvement can increase. (To be slightly
mathematical, investing in B and C boosts respectively the first and second
derivative of the improvement curve - single and double compounding, if
We are assuring here that selected products of the two capability-improvement
activities (B and C) can be utilized not only to boost the capabilities
of their client activities, but can also to a significant extent be harnessed
within their own activities to boost their subsequent capability. This is
depicted in Figure 5 by the "feedback" paths.
Figure 5. EXTRA BOOTSTRAPPING LEVERAGE
This was where the term bootstrapping became welded into my continuing
professional framework. It turns out that there are many choices that we
will face where balanced consideration of the bootstrapping possibilities
can make a difference. I place much confidence in the potential payoff from
thoughtful application of the principles that have evolved from such thinking.
5 THE CODIAK PROCESS CLUSTER: BEST STRATEGIC APPLICATION CANDIDATE
Over the years I have tried various ways to label and characterize the
above-mentioned key knowledge capabilities. For lack of an established term,
I have settled on an acronym that embraces the main concepts of this cluster
of high-leverage capabilities - CODIAK:
The concurrent development, integration and application of knowledge.
As complexity and urgency increase, the need for highly effective CODIAK
capabilities will become increasingly urgent. Increased pressure for reduced
product cycle time, and for more and more work to be done concurrently,
is forcing unprecedented coordination across project functions and organizational
boundaries. Yet most organizations do not have a comprehensive picture of
what knowledge work is, and of which aspects would be most profitable to
The CODIAK capability is not only the basic machinery that propels our
organizations, it also provides the key capabilities for their steering,
navigating and self repair. And the body of applicable knowledge developed
represents a critically valuable asset. The CODIAK capability is
crucial in most A Activities across the organization, whether in strategic
planrang, marketing, R&D, production, customer support, or operations.
It is also crucial in the B and C Activities, whether identifying needs
and opportunities, designing and deploying solutions, or incorporating lessons
learned - which of course is also used in key A-Activity work. As such,
the CODIAK capability should be considered a core business competency in
the organization's capability infrastructure, and is an ideal candidate
for early improvement to achieve the extra bootstrapping leverage discussed
above in Figure 5.
For best exposure to full CODIAK issues, it helps to consider heavy knowledge-intensive
activities such as a large, complex project. Figure 6 represents the high-level
core of such a CODIAK process. In the center is a basic organizational unit,
representing the interactive knowledge domains of a single individual, or
of individuals or groups within a project team, department, functional unit,
division, task force, committee, whole organization, country, or association
(any of which might be inter- or intra- organizational).
Each organizational unit is continuously analyzing, digesting, integrating,
collaborating, developing, applying, and re-using its knowledge, much of
which is ingested from its external envirorunent (which could be outside
of, or within, the same organization).
Figure 6. EVERY VIABLE ORGANIZATIONAL UNIT REQUIRES BASIC KNOWLEDGE
A result of this continuous knowledge process is a dynamically evolving
knowledge base as shown in Figure 7 below, consisting of three primary knowledge
domains: intelligence, dialog records, and knowledge products (in this example,
the design and support documents for a complex product).
Intelligence Collection: An alert project group, whether
classified as an A, B, or C Activity, always keeps a watchful eye on its
external environment, actively surveying, ingesting, and interacting with
it. The resulting intelligence is integrated with other project knowledge
on an ongoing basis to identify problems, needs, and opportunities which
might require attention or action.
Dialog Records: Responding effectively to needs and opportunities
involves a high degree of coordination and dialog within and across
project groups. This dialog, along with resulting decisions, is integrated
with other project knowledge on a continuing basis.
Knowledge Product: The resulting plans provide a comprehensive
picture of the project at hand, including proposals, specifications, descriptions,
work breakdown structures, milestones, time lines, staffing, facility requirements,
budgets, and so on. These documents, which are iteratively and collaboratively
developed, represent the knowledge products of the project team,
and constitute both the current project status and a roadmap for implementation
and deployment. The CODIAK: Concurrent Development, Integration, &
Application of Knowledge (CODIAK) process is rarely a one-shot effort.
Lessons learned, as well as intelligence and dialog, must be constantly
analyzed, digested, and integrated into the knowledge products throughout
the life cycle of the project.
Figure 7. The CODIAK Process - Collaborative, Dynamic, Continuous
With minor adjustments in the boxed lists in Figure 7, this basic generic
CODIAK model seems to apply equally well to academic scholarship, heavy
industry, government, medical research, social institutions, consumer product
businesses, consulting firms, trade associations, small non-profits, and
We need to note here that basic CODIAK processes have practically forever
been a part of society's activity. Whether the knowledge components are
carried in peoples' heads, marked on clay tablets, or held in computers,
the basic CODIAK process has always been important.
What is new is a focus toward harnessing technology to achieve truly
high-performance CODIAK capability. As we concurrently evolve our human-system
elements and the emergent groupware technology, we will see the content
and dynamics represented in Figure 7 undergo very significant changes.
More and more intelligence and dialog records will end up usefully recorded
and integrated; participants will steadily develop skills and adopt practices
that increase the utility they derive from the increased content, while
at the same time making their contributions more complete and valuable.
Generally, I expect people to be surprised by how much value will be
derived from the use of these future tools, by the ways the value is derived,
and by how "natural and easy to use" the practices and tools will
seem after they have become well established (even though they may initially
be viewed as unnatural and hard to learn).
Inevitably, the groupware tools which support the CODIAK processes within
and across our organizations will need to be fully integrated and fully
interoperable. Consider the larger organization depicted in Figure 8 in
which our representative complex project may be embedded (for example, in
the Engineering Department of a manufacturing organization).
Figure 8 Knowledge Domains of a Manufacturing Organization
Each of the enterprise's functional units studded around the circle represents
an activity domain that houses at least one CODIAK process. Then, because
of their mutual involvement with the operations of the whole enterprise,
the CODIAK processes within each of these enterprise sub-domains would with
strong likelihood benefit from being interoperable with those of the other
As operations between enterprises steadily become more closely knit,
the interaction processes with customers, subcontractors and suppliers also
want to become increasingly effective - and therefore the issue of knowledge-domain
interoperability becomes ever more global.
As developed in the sections that follow, our framework assumes that
all of the knowledge media and operations indicated in Figure 7 will one
day be embedded within an Open Hyperdocument System (OHS). Every participant
will work through the windows of his or her workstation into his or her
group's "knowledge workshop."
With this in mind, consider the way in which the project group's CODIAK
domain, with all of its internal concurrent activity, will be operating
within the larger enterprise group depicted in Figure 8.
And consider that the whole enterprise, acting as a coherent organizational
unit, must also have a workable CODIAK capability and possess its own evolving,
applicable CODIAK knowledge base.
Here an important appreciation may be gained for the "concurrency"
part of the CODIAK definition. CODIAK was introduced above with the sense
that all of the development, integration and application activities within
a given organizational unit were going on concurrently. This establishes
a very important requirement for the groupware support.
In Figure 9 we get the sense of the multi-level "nesting" of
concurrent CODLAK processes within the larger enterprise. Each of the multiply-nested
organizational units nee s its own coherent CODIAK process and knowledge
base; and each unit is running its CODIAK processes concurrently, not only
with all of its sibling and cousin units -- but also with larger units in
which it is embedded, and with smaller units that are part of its own makeup.
Furthermore, there are many valuable organizational units that cut across
the organizational structure - such as a corporate-wide task force - and
each of these units also needs a coherent CODIAK process and knowledge base.
And beyond that, significant working relationships will be going on with
external organizational units, such as trade associations, professional
societies, consultants, contractors, suppliers, special alliance partners,
customers, regulatory agencies, and standards groups. Each such "external"
unit needs to have a coherent CODIAK knowledge domain; all such domains
will have some knowledge elements and evolutionary dynamics that are mutual
with those of many other units in the enterprise's total CODIAK environment.
Figure 9 Org Units CODIAK Process Nested Within Other Org Efforts
So, consider the much extended sense of concurrency and inter-dependency
arising from the above picture: the CODIAK processes of all of the inter-dependent
organizational units within the larger enterprise are going on concurrently;
and further, among these concurrently active processes there is a great
deal of mutual involvement with parts of the whole knowledge base.
It is easy to realize that significant parts of what the smaller group
works with, as being in its external environment" intelligence collection,
will actually be shared-access knowledge from other domains within the enterprise
- from other's dialog, from their external intelligence, or from their finished
or evolving knowledge products.
Then the entire enterprise has a collective CODIAK domain, with knowledge
elements that to some extent will be actually in a "whole-enterprise"
domain, but where much of what lies in the collective enterprise domain
is an active part of the CODIAK domains of subordinate organizational units
within the enterprise.
And further, consider that as the availability of highly effective online
CODIAK support becomes widespread, suppliers, contractors and customers
will engage in a non-trivial degree of CODIAK-domain sharing with the enterprise.
One needs only a brief glance at the supplier network of Figure 10 to realize
the magnitude of critical, interoperable CODIAK processes and shared CODIAK
knowledge domains that will prevail when (or if) suitable groupware becomes
Figure 10 Islands In Supplier Hierarchy Of A Major Aircraft Program
Would Be Very Costly
This is representative of the scale of global challenge that I think
faces the groupware marketplace.
The foregoing dictates some very significant requirements for any groupware
system that attempts to support the CODIAK processes of our future, high-performance
organizations. Immediately apparent is the need for very flexible, wide-area
sharing of pieces of the knowledge base. What has only recently begun to
be generally apparent is the associated need for a new way of thinking about
the nature of the knowledge packages we have called "documents."
This above requirement for flexibly arranged sharing of essentially arbitrary
knowledge chunks provides a very strong argument for documents becoming
built from modular-concept nodes with arbitrary inter-node linking - hypertext.
So, how (and when) will the marketplace learn enough and be cooperative
enough to develop truly effective OHS standards? The prospects for achieving
truly high levels of performance in larger organizations and institutions
pretty much await that day.
This question is a significant part of what an effective bootstrapping
strategy needs to address.
6 OPEN HYPERDOCUMENT SYSTEM (OHS): FOR GENERIC CODIAK SUPPORT
My early assumption, amply borne out by subsequent experience, is that
the basic supporting technology for future high-performance knowledge work
will be an integrated system based upon multi-media hyperdocuments.
Furthermore, there will be critical issues of interoperability within
and between our organizations and their knowledge domains. The ever-greater
value derived from online, interactive work within a hyperdocument environment
will require a significantly higher degree of standardization in document
architecture and usage conventions than heretofore contemplated.
It is inevitable that this service be provided by an "open system"
of hyperdocuments and associated network and server architectures. The basic
arguments for this Open Hyperdocument System (OHS) are presented in Ref-5;
and the hyperdocument system features described below are assumed by me
to be strong candidates for requirements for the eventual OHS whose evolution
will be so critical to the productivity of industries and nations.
Following is a brief general description of the system design that has
evolved from the conceptual orientation described in this paper, through
the experience of many years and trial events. Please note that the term
"system" is very important here.
Shared Files/Documents- the most fundamental requirement. Generalized
file sharing is to be available across the entire global domain in which
any online collaborative working relationship is established (e.g., world-wide).
Mixed-Object Documents - to provide for an arbitrary mix of text,
diagrams, equations, tables, raster-scan images (single frames or live video),
spread sheets, recorded sound, etc. all bundled within a common "envelope"
to be stored, transmitted, read (played) and printed as a coherent entity
called a "document."
Explicitly Structured Documents - where the objects comprising
a document are arranged in an explicit hierarchical structure, and compound-object
substructures mav be explicitly addressed for access or to manipulate the
Global, Human-Understandable, Object Addresses - in principle,
every object that someone might validly want/need to cite should have an
unambiguous address, capable of being portrayed in a manner as to be human
readable and interpretable. (E.g., not acceptable to be unable to link to
an object within a "frame" or "card.")
View Control of Objects' Form, Sequence and Content- where a structured,
mixed-object document may be displayed in a window according to a flexible
choice of viewing options especially by selective level clipping (outline
for viewing), but also by filtering on content, by truncation or some algorithmic
view that provides a more useful portrayal of structure and/or object content
(including new sequences or groupings of objects that actually reside in
other documents). Editing on structure or object content directly from such
special views would be allowed whenever appropriate.
The Basic "Hyper" Characteristics - where embedded objects
called links can point to any arbitrary object within the document, or within
another document in a specified domain of documents - and the link can be
actuated by a user or an automatic process to "go see what is at the
other end," or "bring the other-end object to this location,"
or 'execute the process identified at the other end." (These executable
processes may control peripheral devices such as CD ROM, video-disk players,
Hyperdocument "Back-Link" Capability - when reading a hyperdocument online, a worker can utilize information about links from other objects within this or other hv erdocuments @ p
that point to this hyperdocument - or to designated objects or passages
of interest in this hyperdocument.
Link Addresses That Are Readable and Interpretable by Humans - one
of the "viewing options" for displaying/printing a link object
should provide a human-readable description of the "address path"
leading to the cited object; AND, the human must be able to read the path
description, interpret it, and follow it (find the destination "by
hand" so to speak).
Personal Signature Encryption - where a user can affix his personal
signature to a document, or a specified segment within the document, using
a private signature key. Users can verify that the signature is authentic
and that no bit of the signed document or document segment has been altered
since it was signed. Signed document segments can be copied or moved in
full without interfering with later signature verification.
Hard-Copy Print Options to Show Addresses of Objects and Address Specification
of Links so that, besides online workers being able to follow a link-citation
path (manually, or via an automatic link jump), people working with associated
hard copy can read and interpret the link-citation, and follow the indicated
path to the cited object in the designated hard-copy document.
Also, suppose that a hard-copy worker wants to have a link to a given
object established in the online file. By visual inspection of the hard
copy, he should be able to determine a valid address path to that object
and for instance hand-write an appropriate link specification for later
online entry, or dictate it over a phone to a colleague.
Hyperdocument Mail- where an integrated, general-purpose
mail service enables a hyperdocument of any size to be mailed. Any embedded
links are also faithfully transmitted - and any recipient can then follow
those links to their designated targets that may be in other mail items,
in common-access files, or in "library" items.
The Hyperdocument "Journal System" - an integrated
library-like system where a hyperdocument message or document can be submitted
using a submittal form (technically an email message form), and an automated
"clerk" assigns a catalog number, stores the item, notifies recipients
with a link for easy retrieval, notifies of supercessions, catalogs it for
future searching, and manages document collections. Access is guaranteed
when referenced by its catalog number, or "jumped to" with an
appropriate link. Links within newly submitted hyperdocuments can cite any
passages within any of the prior documents, and the back-link service lets
the online reader of a document detect and "go examine any passage
of a subsequent document that has a link citing that passage.
Access Control- Hyperdocuments in personal, group, and
library files can have access restrictions down to the object level.
External Document Control (XDoc) - (Not exactly a "hyperdocument"
issue, but an important system issue here.) Documents not integrated into
the above online and interactive environment (e.g. hard-copy documents and
other records otherwise external to the OHS) can very effectively be managed
by employing the same "catalog system" as for hyperdocument libraries
- with back-link service to indicate citations to these "offline"
records from hyperdocument (and other) data bases. OHS users can find out
what is being said about these "XDoc" records in the hyperdocument
The overview portrayal in Figure 11 shows the working relationships between
the major system elements described above. Note the shared catalog service
that supports use of the journal and External Document services.
Figure 11 An Open Hyperdocument System (OHS): For Basic Collaborative
Details of features and designs for well-developed prototypes of some
of the above may be found in Ref-6, Ref-7 and Ref-8.
7 FOUR GENERAL GROUPWARE ARCHITECTURAL REQUIREMENTS
Besides the aforementioned Hyperdocument Mail and Hyperdocument Library
features that depend upon special larger-scale architectural features, there
are at least four other important tool-system capabilities that are very
important to wide-area groupware services such as being considered here:
Global and Individual Vocabulary Control- somewhat new
in the history of computer services are issues regarding the evolution and
use of a common "workshop vocabulary" among all the users of the
forthcoming "global knowledge workshop." Common data dictionaries
have been at issue, of course, but for a much more limited range of users,
and for a more limited and stable vocabulary than we will face in the exploding
Our own architectural approach (see Ref-6, Ref-9 and Ref-10) has been
to introduce into every user-interface environment a common Command-Language
Interpreter (CLI) module that derives the user's available operations (verbs)
as applied to the available classes of objects (nouns) from a grammar file
(individualized if desired with respect to the size and nature of the verbs
and nouns utilized from the common vocabulary). The CLI interprets user
actions, based upon the contents of the currently attached grammar file,
and executes appropriate actions via remote procedure calls to a common
application program interface of the "open system environment."
Each of us knowledge workers will become involved in an ever richer online
environment, collaborating more and more closely within an ever more global
"knowledge workshop," with multi-organizational users of widely
divergent skills and application orientations who are using hardware and
software from a wide mix of vendors.
Without some global architectural capability such as suggested above,
I can't see a practical way to support and control the evolving global "workshop
vocabulary" in a manner necessary for effectively integrating wide-area
Multiplicity of Look-and-Feel Interface Choices - Based
upon the same Command-Language Interpreter (CLI) architecture as above,
a "look-and-feel interface" software module would be located between
the CLI and the window system. Providing optional modules for selected look-and-feel
interface characteristics would serve an important practical as well as
There would be a basic constraint necessary here. When working interactively,
no matter what particular look-and-feel style is being used, a user has
a particular mental model in mind for the significance of every menu item,
icon, typed command, or "hot, command-key combination" employed.
The necessary constraint needed here is that the resulting action, via
the interface module that is being employed for this user, must be produced
through the underlying execution of processes provided by the Command Language
Interpreter module as derived from use of common-vocabulary terms. And the
users should learn about their tools and materials, and do their discussing
with others about their work, using the underlying common-vocabulary terms
no matter what form of user interface they employ.
Besides relaxing the troublesome need to make people conform to a standard
look and feel, this approach has a very positive potential outcome. So far,
the evolution of popular graphical user interfaces has been heavily affected
by the "easy to use" dictum. This has served well to facilitate
wide acceptance, but it is quite unlikely that the road to truly high performance
can effectively be traveled by people who are stuck with vehicular controls
designed to be easy to use by a past generation.
As important classes of users develop larger and larger workshop vocabularies,
and exercise greater process skill in employing them, they will undoubtedly
begin to benefit from significant changes in look and feel. The above approach
will provide open opportunity for that important aspect of our evolution
toward truly high performance.
Shared-Window Teleconferencing- where remote distributed
workers can each execute a related support service that provides the "viewing"
workers with a complete dynamic image of the "showing" worker's
window(s). Used in conjunction with a phone call (or conference call), the
parties can work as if they are sitting side-by-side, to review, draft,
or modify a document, provide coaching or consulting, support meetings,
and so on. Control of the application program (residing in the "showing"
worker's environment) can be passed around freely among the participants.
Generic provision of this service is discussed in Ref-6.
Inter-Linkage Between Hyperdocuments and Other Data Systems - for
instance, a CAD system's data base can have links from annotations/comments
associated with a design ob ect that point to relevant specifications, requirements,
arguments, etc. of relevance in a hyperdocument data base - and the back-link
service would show hyperdocument readers which passages were cited from
the CAD data base (or specified parts thereof).
Similarly, links in the hyperdocuments may point to objects within the
CAD bases. And, during later study of some object within the CAD model,
the back-link service could inform the CAD worker as to which hyperdocument
passages cited that object.
8 THE CODIAK PROCESS SUPPORTED BY AN OHS
With the above tool capabilities, together with well-developed methods
and other humansystem elements as discussed in section 1.2, the organization's
capability infrastructure could support the following types of online CODIAK
Note that the following online interactions are designed to work even
if the users are in different organizational units, in different organizations,
using different application packages on different workstations (assuming
access to the data is not barred by the stringent privacy features, naturally).
The real test of an OHS is when you can click on a link you received via
email from someone in a different organization, jumping directly to the
passages cited, and then comfortably maneuver through the "foreign"
knowledge domain, possibly jumping up a level with an outline view to see
the context of the given passage, following other links you find there,
and so on, without having to fumble through unfamiliar processes.
Intelligence Collection: Now an alert project group, whether classified
as an A, B, or C Activity, can keep a much enhanced watchful eye on its
external environment, actively surveying, ingesting, and interacting with
it mostly online. Much of the external intelligence is now available in
hyperdocument, multimedia form, having been captured in an OHS Journal facility.
When I send you an email to let you know about an upcoming conference, I
can cite the sessions I think you'd be interested in, and you can click
on the enclosed citation links to quickly access the cited passages (taking
advantage of hypertext links and object addressability). When I do a search
through the Journal catalogs to research a question for the proposal I am
writing, I can see who has cited the material and what they had to say about
it. If the material is offline (i.e. in XDoc), I can quickly discover where
it is stored and how to obtain a copy, probably requesting it via email.
If the material is online, I can access it instantly, usually starting with
a top-level outline view of the document's titles (taking advantage of the
OHS document structure and custom viewing features), possibly setting a
simple filter to narrow the field, then quickly zooming in on the specific
information I require. I can quickly build an annotated index to the intelligence
documents, or objects within those documents, that I want to keep track
of. I can share with you a macro I wrote to trap certain incoming intelligence
items and reformat them in a certain way, and you could fire this up in
your own environment to work off your pet keywords (taking advantage of
the common-vocabulary architectural feature). All the intelligence collected
is easily integrated with other project knowledge.
Dialog Records: Responding effectively to needs and opportunities
involves a high degree of coordination and dialog within and across
project groups. In an OHS environment, most of the dialog will be conducted
online via the journal. Email would be used mostly for "throw-away"
communiqués, such as meeting reminders. All memos, status reports,
meeting minutes, design change requests, field support logs, bug reports,
and so on, would be submitted to the Journal for distribution. Asynchronous
online conferencing would be supported by the Journal, with each entry tagged
and cataloged for easy future reference. Document exchange would be a matter
of submitting the document to the Journal with a comment such as "Here's
the latest version - please note especially the changes in Section G, differences
are listed in File Y" including links to that section and that file
for easy access. The reviewers would click on the links, and proceed to
review the document. To make a comment, the reviewer would click on the
object in question, and enter the comment, such as "Replace with 'Xyz',"
or "Watch out for inconsistencies with Para G4! " with a link
to the passage in G4. The author then gets back the indexed comments, and
has many options for quickly reviewing and integrating them into the document.
Such dialog support will obviate the need for many same-time meetings.
Same-time meetings, when needed, would be greatly enhanced by an OHS.
The dialog motivating the meeting would already be in the Journal. Agenda
items would be solicited, and the agenda distributed via the journal. At
the meeting, the agenda and real-time group notes can be projected on a
large screen, as well as displayed on each participant's monitor (using
the "shared screen" feature), and any participant can point to
the displayed material (e.g. using a mouse). Controls can be passed to any
participant to scribble, type, or draw on this virtual chalkboard. Any presentation
materials and supporting documents can be instantly retrieved from the knowledge
base for presentation. All resulting meeting documents, along with references
to supporting documents cited, would subsequently be submitted to the Journal
for immediate access by all authorized users.
In addition, tools will soon become generally available for flexibly
contributing, integrating, and interlinking digitized speech into the OHS
knowledge base. Early tools would be available for speaker recognition,
for special-word recognition, and even for basic transcription to text -
and for installing and following links between modules as small as a word
embedded in a long speech string. This will greatly enhance the development,
integration, and application of dialog records. More elegant tools will
follow, and as human conventions and methods evolve to make effective use
of the technology, the quantity and completeness of recorded dialog will
become much more significant.
Knowledge Product: Throughout the life cycle of the project, the
online OHS knowledge product will provide a truly comprehensive picture
of the project at hand. Intermediate project states, including supporting
intelligence and dialog trails, can be bundled as document collections in
the journal for document version management. All knowledge products will
be developed, integrated, and applied within an OHS, with concurrent contributions
from many diverse and widely distributed users. These users can also work
as if sitting side by side, reviewing a design, marking up a document, finalizing
the changes, etc. (using the shared screen feature). Finding what you need
among the thousands of project documents will be a simple matter of clicking
on a link (provided by the Journal catalogs, or by your project's indices),
and zooming in and out of the detail, or by having someone else "take
you there" (using the shared screen feature). Accountability is absolute-
journal submittals are guaranteed to be authentic, and each object can be
tagged by the system with the date and time of the last write, plus the
user who made the change. Documents can be signed with verifiable signatures.
Everyone is but one quick "link hop" away from any piece of
knowledge representation anywhere in the whole knowledge collection. Smart
retrieval tools can rapidly comb part or all of the collection to provide
lists of "hit links" with rated relevance probabilities.
Conventions for structuring, categorizing, labeling and linking within
their common knowledge domain will be well established and supportive of
a high degree of mobility and navigational flexibility to experienced participants
- much as residents get to know their way effectively around their city
if they get much practice at it.
As a group adapts its ways of working to take better advantage of a tool
system such as projected here, the classes of knowledge objects will grow,
as will the functions available to operate upon them-and that growth will
be paralleled by the concurrent evolution of an ever richer repertoire of
the humans' "workshop knowledge, vocabulary, methodology and skills."
There is tremendous potential here, and many methods, procedures, conventions
organizational roles to be developed in close association with the tools.
And, if the OHS is to be open, there is much deep exploration to
be done into different application domains, such as Computer-Supported Cooperative
Work (CSCW), organizational learning, Total Quality Management (TQM), Enterprise
Integration (El), program management, Computer-Aided Software Engineering
(CASE), Computer-Aided Engineering (CAE), Concurrent Engineering (CE), organizational
memory, online document delivery and CALS, and so on. This will require
many advanced pilots, as will be discussed further on.
9 RECAP: THE FRAMEWORK TO THIS POINT
To this point in the paper, we have -outlined steps in the development
of a strategy to provide a high-leverage approach toward creating truly
We considered the concept of the organization's capability infrastructure
upon which any of the organization's effectiveness must depend.
Further, what enables humans to exercise this infrastructure of capabilities
is an Augmentation System, which is what provides the humans with
all capabilities beyond their genetically endowed basic mental, motor and
perceptual capabilities. It was useful to divide the Augmentation System
into two sub-systems, the Human System and the Tool System. "Organic
style co-evolution" among the elements of our Augmentation System has
been the process by which it evolved to its current state.
New technologies are introducing an unprecedented scale of improvement
in the Tool System part of the Augmentation System. This promises that subsequent
co-evolution of our Augmentation Systems will likely produce radical qualitative
changes in the form and functional effectiveness of our capability infrastructures,
and hence of our organizations.
Very large and challenging problems are envisioned in pursuing potential
benefits of such changes, towards truly high-performance organizations.
A strategy is sought to provide an effective approach.
It would be profitable to consider early focus on improving the organizational
improvement process so that further improvements can be done more effectively.
To help with this analysis, the ABC categorization of improvement-,process
was established. And the thesis was developed that the CODIAK set
of knowledge capabilities - the concurrent development, integration, and
application of knowledge - is important to all three types of activities.
Therefore, if CODIAIK improvement was concentrated upon early, the result
could improve the first and second derivatives of the return on future improvement
An Open Hyperdocument System (OHS) would be a key "Tool System"
development towards improving general and widespread CODIAK capabilities
within and between organizations. And creating a truly effective OHS would
in itself be an extremely challenging and global problem for our groupware
So, high-performance organizations: great opportunities, interesting
concepts, tough challenges. What next regarding strategy?
10 C COMMUNITY: HIGH-PAYOFF BOOTSTRAPPING OPPORTUNITY
Returning to the basic ABC Model in Figure 4, we can make a few useful
observations toward a next step in strategy development. This model will
be useful even if the Bootstrapping approach is not followed; it is valuable
to become explicit about differentiating responsibilities, functions and
budgets between the two levels of improvement activity (B and C).
If explicit C roles are designated and assumed, basic issues will soon
arise for which the C- Activity leaders find it valuable to compare experiences
and basic approaches with their counterparts in other organizations. For
instance, what budgeting guidelines and targets make sense for these improvement
activities? How much can it help the B Activity to document the way things
are done now? What role should pilot applications play? How large an improvement
increment, for how big a group, does it make sense to try for a pilot? How
much "instrumentation" of a pilot group - before, during, and
after transition - to measure the value of the effort? These are all relevant
to making the B Activity more effective.
So let us consider formalizing and extending the above type of cooperation
among improvement activities, especially the C Activities. In the mid-60s
I began to think about the nature and value of communities of common interest
formed among different improvement activities. This led me very early to
build explicit planning into the bootstrap strategy for forming improvement
In Ref-11 (1972), 1 presented the concept of a "community knowledge
workshop" -outlining the tools we had developed for supporting it (including
many of the hyperdocument system capabilities outline above), and described
the three basic CODIAK sub-domains: recorded dialog, intelligence collection,
and what I then called the "handbook" (or knowledge products).
After the ABC Model emerged in the framework, this evolved into a special
emphasis on an important launching phase, for forming one or more special
bootstrapping C Commitnities as shown in Figure 12.
Figure 12 C ACTIVITIES JOINING FORCES
The value of such a cooperative activity can be very high - we'll unveil
some of that later. First, there are some other questions that naturally
arise which need to be addressed. An early and common pair of comments are:
"I can't imagine sharing things with my competitors, there is so much
about what we do that is proprietary;" and, "If they aren't in
the same business, I don't see what useful things there would be that we
About proprietary matters: The A Activity of each organization may be
very competitive, with considerable proprietary content. The B Activity
of each would tend to be less so having quite a bit that is basic and generic.
The C Activity of each would be much less involved in proprietary issues,
and much more in basic, generic matters. So even competitors could consider
cooperating, "out of their back doors" - "while competing
like hell out of our front doors," as a trend that seems to be appearing
among companies heavily into Total Quality Management and pursuit of the
Malcolm Baldridge Award.
About being in very different business: Again, their B Activities will
be much less different, and their C Activities surprisingly alike in important
basic and generic issues.
Now, consider how a C Community could operate if it had the basic hyperdocument
tools described above. For several decades, my colleagues and I have had
such a system available, so all of our scenarios began there, using that
system and calling it our "OHS, Model 1" - or //OHS-l."
And how would an ideal bootstrapping C Community operate? Its earliest
focus would be on augmenting its own CODIAK capability. Using OHS-1 to do
its work; making an important part of its work at first be to establish
requirements, specifications and a procurement approach for getting a set
of rapidly evolving prototype hyperdocument systems (e.g. OHS-2, -3, etc.),
to provide ever better support for serious pilot applications among the
C Community participants.
The Community's basic knowledge products could be viewed as dynamic electronic
handbooks on "how to be better at your improvement tasks," with
two customer groups: its B-Activity customers; and the C Community itself.
Pooling resources from the member organizations enables a more advanced
and rapidly evolving prototype CODIAK environment, which serves two very
1. It provides for the Community getting better and better at its basic
2. It provides advanced experience for its rotating staff of participants
from the member organizations. They thus develop real understanding about
the real issues involved in boosting CODIAK capability - this understanding
being absorbed by "living out there in a real, hard-working CODIAK
Note that it would be much more expensive for each member organization
to provide equivalent experience by operating its own advanced pilot. Also
the amount of substantive knowledge product developed this way would be
very much more expensive if developed privately.
An important feature: once the Community stabilizes with effective groupware
tools, methods and operating skills, the participants from the respective
member organizations can do most of their work from their home-organization
sites. This provides for maintaining the organizational bonding which is
very important in effective C and B activities.
This home-site residency also facilitates the all-important "technology
transfer" from the C Community into its customer B Activities. And,
while considering the issue of "technology transfer," note that
a strong feature of an augmented CODIAK process is the two-way transfer
of knowledge. Developing dialog with the B clients via joint use of the
hyperdocument system not only facilitates directly this two-way knowledge
transfer, but provides critically important experience for the B people
in the close witnessing of how advanced CODIAK processes work.
To characterize the value of facilitating this two-way transfer, consider
Figure 13, which highlights the basic importance of improved CODIAK processes
in the organization's improvement activity. The "l, 2, 3" points
all are basic to the CODIAK process. As augmented CODIAK capabilities make
their way up from C to B and into A, the over-all improvement process can't
help but improve. And also, note that when the A Activity for this organization,
as well as those for its customers, become based on interoperable CODIAK
processes, the dynamics of the whole business will begin to sparkle.
Figure 13 BOOTSTRAPPING: STRATEGIC INVESTMENT CRITERIA
Now consider Figure 14, and note that the indicated types of knowledge
flow are basic to the CODIAK processes, and that augmenting those processes
for the C Community directly boosts one of its core capabilities. Conversely,
Figure 15 emphasizes the previous basic point of the naturalness for enhanced
CODIAK to improve this outflow, and highlights again the basic bootstrapping
value that is obtained from early focus on these CODIAK processes.
Figure 14 CORE C-COM CAPABILITY IS TO INTEGRATE, ANALYZE, AND PORTRAY
MULTIPLE-SOURCE CONTRIBUTIONS TO ITS KNOWLEDGE BASE
Figure 15 PARTNER ORGS GET UNIQUE VALUE FROM FUTURE-MODE CCOM ACCESS
In the organizational improvement domain, there are several immediately
apparent large and explicit issues for which a lone organization would need
to consider a multi-party alliance. An immediate such issue, from the bootstrapping
point of view, is to procure appropriate groupware systems that can support
advanced pilot applications. Other large sized issues have to do with "exploration
and outpost settlements."
Relative to the options opening to our organizations for transforming
into new states, there is a very large, unexplored, multi-dimensioned frontier
out there. Both its dimensionality and its outer boundaries are expanding
faster and faster. To really learn about that frontier, in order to decide
where we would want to "settle our organizations," we must somehow
do a great deal of basic exploration work. We also need to establish a significant
number of outpost settlements in promising places so as to find out ahead
of time what it would be like to really live and work there. (Translate
"outposts" into "advanced pilot groups.")
Yet we are launching very few exploratory expeditions and developing
very few significant outposts.
From the viewpoint that I have acquired, there is a great need for such
explorations and trial settlements. Much of my motivation for advocating
such as C Communities, bootstrapping, CODIAK and OHS pursuits, etc., is
to find a strategy for exploring and settling that territory. It is almost
like a military strategy: "first we get a firm settlement here in
CODIAK territory; then with that as a base, we encircle the OHS and C
territories; when we get those under reasonable control, we will be in a
most advantageous posture to pour through the rest of the B and C Improvement
Territories to get the whole area under control and ..."
As the C Community and its working relationship with its "B customer"
matures, there can be integrated into the substance of their joint efforts
an ever larger sphere of involvement with the whole set of issues of organizational
Potential customers for augmented CODIAK capabilities can be seen everywhere
in today's global society: e.g., all of the "Grand Challenges"
earmarked in the U.S. for special support. Essentially every professional
society will eventually operate this way; as will legislative bodies and
government agencies, and university research programs.
In short, our solutions to every other challenging problem that is critical
to our society will become significantly facilitated by high-performance
CODIAK capabilities. Provides a stimulating challenge for the groupware
community, doesn't it?
In closing, I would like to re-emphasize the comments in Section 1.4
about paradigms. I am convinced that cultivating the appropriate paradigm
about how to view and approach the future will in the pursuit of high-performance
organizations be the single most critical success factor of all.
[Note: The Bootstrap Institute has developed basic plans
for several scales of C-Community launching - a medium-sized consortium
approach on the one hand, and a more conservative, organic evolution approach
on the other hand. Interested inquiries are invited-]
Ref-1: Engelbart, D.C. 1962. Augmenting Human Intellect:
A Conceptual Framework, Summary Report, Stanford Research Institute,
on Contract AF 49(63-8)-1024, October, 134 pp.
Ref-2: Engelbart, D.C. 1963. A Conceptual Framework for
the Augmentation of Man's Intellect. Vistas in Information Handling,
Howerton and Weeks (eds), Washington, D.C.: Spartan Books, pp. 1-29.
Republished in Greif, I. (ed) 1988. Computer Supported Cooperative Work:
A Book of Readings, San Mateo, CA: Morgan Kaufmann Publishers, Inc.,
Ref-3: Engelbart, D.C. 1988. The Augmented Knowledge Workshop.
Goldberg, A. [ed], 1988. A History of Personal Workstations, New
York: ACM Press, pp. 185-236.
Ref-4: Engelbart, D.C. and Lehtman, H.G. 1988. Working
Together, BYTE Magazine, December, pp. 245-252.
Ref-5: Engelbart, D.C. 1990. Knowledge Domain Interoperability
and an Open Hyperdocument System. Proceedings of the Conference on Computer-Supported
Cooperative Work, Los Angeles, CA, October 7-10, pp. 143-156. (AUGMENT,132082,).
Republished in Berk, E. and Devlin, J. [eds] 1991. Hypertext / Hypermedia
Handbook, New York: Intertext Publications, McGraw-Hill, pp. 397-413.
Ref-6: Engelbart, D.C. 1982. Toward High Performance Knowledge
Workers. OAC'82 Digest, Proceedings of the AFIPS Office Automation
Conference, San Francisco, CA, April 5-7, pp. 279-290. (AUGMENT,81010,).
Republished in Greif, I. (ed) 1988. Computer Supported Cooperative Work:
A Book of Readings, San Mateo, CA: Morgan Kaufmann Publishers, Inc.,
Ref-7: Engelbart, D.C. 1984. Collaboration Support Provisions
in AUGMENT. OAC '84 Digest, Proceedings of the 1984 AFIPS Office
Automation Conference, Los Angeles, CA, February 20-22, pp. 51-58. (OAD,2221,).
Ref-8: Engelbart, D.C. 1984. Authorship Provisions in AUGMENT.
COMPCON '84 Digest, Proceedings of the COMPCON Conference, San Francisco,
CA, February 27 - March 1, pp. 465-472. (OAD,2250,). Republished in Greif,
I. (ed) 1988. Computer Supported Cooperative Work: A Book of Readings,
San Mateo, CA: Morgan Kaufmann Publishers, Inc., pp. 107-126.
Ref-9: Irby, C.H. 1976. The Command Meta Language System.
AFIPS Conference Proceedings, NCC Vol. 45, Montvale, NJ: AFIPS Press.
Ref-10: Watson, R.W. 1976. User Interface Design Issues
for a Large Interactive System. AFIPS Conference Proceedings, Vol.
45, Montvale, NJ: AFIPS Press, pp. 357-364. (AUGMENT,27171,).
Ref-11: Engelbart, D.C. 1972. Coordinated Information Services
for a Discipline- or Mission-Oriented Community. Proceedings of the Second
Annual Computer Communications Conference, San Jose, CA, January 24,.
Republished in Grimsdale, R.L. and Kuo, F.F. (eds) 1975. Computer Communication
Networks, Leyden: Noordhoff. (AUGMENT,12445,).
Ref-12: Grenier, R., Metes, G. 1992. Enterprise Networking:
Working Together Apart. Digital Press. (Very relevant general treatment;
special emphasis given to "Capability-Based Environment" along
the lines outlined in this paper.)
Ref-13: Parunak, H.V.D. 1991. Toward Industrial Strength Hypermedia, Hypertext Hypermedia Handbook, Kerk, E. and Devlin, J. (eds), New York: McGraw Hill, pp. 381395. (Provides very useful considerations relevant to requirements for the Open Hyperdocument System as discussed in this paper.) [an error occurred while processing this directive]