Douglas C. Engelbart Bootstrap Institute June 1992 (AUGMENT,132811,)

---

First published in GroupWare ’92: Proceedings of the GroupWare ’92 Conference, San Jose, CA, August 3–5, 1992, Morgan Kaufmann Publishers.

Available from the Doug Engelbart Institute: permalink · HyperScope · scanned original PDF.

---

Abstract

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 Introduction

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 tools.

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

Figure 1. Augmented Capabilities -- with higher levels depending upon lower levels. [ Figure 1 shows a Capability Infrastructure made up of Human System elements -- such as peoples' paradigms, organization, procedures, customs, methods, language, attitudes, skills, knowledge and training -- as well as Tool System elements -- such as media, portrayal, viewing, study, retrieval, manipulation, computing, communications. ]

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 Human System.

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:

huge changes are likely, and really significant improvements are possible;

surprising qualitative changes may be involved in acquiring higher performance; and

there might actually be an effective, pragmatic strategy for pursuing those improvements.

In developing a basic, scalable 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 paradigms.

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 changes.

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

Figure-2. Co-Evolution is a capability that warrants serious high-level attention! [ Figure 2 shows the Capability Infrastructure from Figure 1, with its Human System and Tool System, with a particular high-level capability prominently highlighted and labelled '"Capability to Improve--needs a prominent and explicit role! ]

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

Figure-3: Simple organization model showing explicit provision for improvement. [ Figure 3 shows an organization with activity A representing the core business activity (i.e. product R&D, manufacturing , marketing, sales, operations...), supported by activity B representing the activity of improving A. B should be a permanent continuous improvement activity. Note that B is improving A's Human-Tool Augmentation System. ]

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 A-Activity clients, or improving how pilot operations are managed.

Figure-4

Figure 4. Here is a userful way to characterize the goals of B and C Activities. [ Figure 4 shows organization from Figure 3, with A and B activities, with an added C activity which is the activity of improving B activities. B is further characterized as improving product-cycle time and quality, and C as improving improvement-cycle time and quality. ]

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 B Capability?

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 you wish.)

We are assuming 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

Figure 5. Extra bootstrapping leverage. [ Figure 5 shows the same organization with B boosting A and C boosting B. Added are two feedback loops to illustrate B's output boosting itself as well as A, and C's output boosting itself as well as B. C's output highlighted with the text "Investment criteria: going after the point of greatest leverage -- a high-performance knowledge-work capability launched by C boosts A, B, and C." ]

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 improve.

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 planning, 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, community, 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 environment (which could be outside of, or within, the same organization).

Figure-6

Figure 6. Every viable oraganizational unit requires basic knowledge processes. [ Figure 6 shows an organization unit in the form of a circle of constituent individuals and/or teams or departments, with lines interconnecting them all with each other representing continuous exchange and communication. The organizational unit is interacting with its external environment, scanning for and ingesting intell, as well as continuously analyzing, digesting, integrating, collaborating, developing, applying, and re-using an evolving knowledge base. This is the CODIAK process. ]

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

Figure 7. The CODIAK process -- collaborative, dynamic, continuous. [ Figure 7 itemizes the evolving knowledge base within three categories: (1) Dialog Records: memos, status reprts, meeting mintes, decision trails, design rationale, change requests, commentary, lessons learned, ... (2) External Intelligence: articles, books, reports, papers, conference proceedings, brochures, market surveys, industry trends, competition, supplier information, customer information, emerging technologies, new techniques... (3) Knowledge Products: proposals, plans, budgets, legal contracts, milestones, time lines, design specs, product descriptions, test plans and results, open issues... ]

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 so on.

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

Figure 8. Example: Knowledge domains of a manufacturing organization. [ Figure 8 shows the organizational unit with its constituents in a circle with interconnecting lines, the constiuents labeled for a manufacturing organization with Management, Marketing, Finance, Legal, Procurement, Subcontractors, Suppliers, Quality, Manufacturing, Engineering, Joint-Venture Partners, and Customers. Beneath this image is the text '"Enterprise Integration: interoperability within and across knowledge domains'". ]

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 sub-domains.

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 CODIAK processes within the larger enterprise. Each of the multiply-nested organizational units needs 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

Figure 9. Organizational unit's CODIAK process nested within other organizational efforts. [ Figure 9 shows the organization as one big organizational unit, whose sub-parts are each themselves whole organizational units, each with its own CODIAK process going on, with its evolving knowledge base of Recorded Dialog, Intelligence Collection, and Knowledge Products. ]

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 widely available.

Figure-10

Figure 10. Islands in supplier hierarchy of major aircraft program would be very costly. [ Figure 10 shows as example the organizational unit of a major aircraft program involving 2,000-3,000 people. This program sits at the top of a supplier hierarchy of 1st, 2nd, and 3rd tier suppliers -- up to 6,000 companies -- with communication channels running up and down the hierarchy representing collaboration and coordination on tasks and specfications, change orders, contractual matters, progress tracking, and developing products. ]

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 may be explicitly addressed for access or to manipulate the structural relationships.

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, etc.)

HYPERDOCUMENT "BACK-LINK" CAPABILITY - when reading a hyperdocument online, a worker can utilize information about links from other objects within this or other hyperdocuments 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 world.

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

Figure 11. An Open Hyperdocument System (OHS): For basic collaborative knowledge work. [ Figure 11 shows the knolwedge environment provided by open hyperdocument systems would include Shared Files, '"Throw-Away'" Email, Journal/Library, and External Docs (XDOC). Documents are shown in these four areas, with hyperlinks between documents in different areas. '"Hyperdocument'" is defined as providing flexible linkages to any object in any multi-media file; '"Open'" is defined as providing vendor-independent access to the hyperdocuments within and across work groups, platforms, and applications. ]

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 groupware world.

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 groupware services.

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 evolutionary need.

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 object 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 human-system elements as discussed in section 1.2, the organization's capability infrastructure could support the following types of online CODIAK scenarios.

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" communiques, 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 (EI), 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 high-performance organizations.

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 CODIAK improvement was concentrated upon early, the result could improve the first and second derivatives of the return on future improvement investments.

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 marketplace.

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 communities.

In <Ref-11> (1972), I 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 Communities as shown in Figure-12.

Figure-12

Figure 12. C Activities Joining Forces. [ Expanding on the ABC activities of the organization, Figure 12 shows several organizations, each with A, B, and C activities, joining together at the C level to form a collaborative C Community to work on common challenges, such as improve the CODIAK process, pursue the enabling OHS technology, and improve the improvement capability, within an advanced pilot environment. The output of the C Community boosts the B activities within the member organizations, and also feeds back to boost the C activities. The feedback loop is highlighted with the text '"Bootstrapping Leverage: boosted by its own products--continuously augmented Human-Tool Systems'". ]

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 could share."

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-1."

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 important purposes:

It provides for the Community getting better and better at its basic "C Activity;"

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 frontier."

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 "1, 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

Figure 13. Bootstrapping: strategic investment criteria. [ Figure 13 shows the ABC model of the organization from Figures 3 and 4, with '"Selecting capabilities for C to improve that serve A and C, as well as B, offers special investment leverage. Start with these 3 most-basic capabilities: (1) doing group knowledge work; (2) transfer results up the line to respective 'customers'; (3) integrate information coming down the line from respective 'customers'. Note that capabilities 2 and 3 depend on 1. ]

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

Figure 14. Core C-Community capability is to integrate, analyze, and portray multiple-source contributions to its knowledge base. [ Figure 14 shows the C Community from Figure 12 with contributions to its knowledge base coming from multiple sources: (a) from their B & A activities: lessons leaned, requirements, design dialog, needs and possibilities; (b) from external environment: trends, products, trials, theories, events...'"intelligence'"; (c) from internal C Communigy: lessons learned, needs and possibilities, design, ... ]

Figure-15

Figure 15. Partner organizations get unique value from future-mode C-Community access and dialog. [ Figure 15 shows the C Community from Figure 12 with Value coming out of the C Community in the form of: (1) Direct experience with an advanced pilot activity--which is doing intensive real work that the partner organizations guide toward maximum value to them; (2) Direct, online access to C-Community knowledge products; (3) Continuous dialog to enrich the pilot experience and transfer C-Community knowledge products. ]

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 improvement.

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.]

References

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., pp. 35-65.

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. (AUGMENT,101931,)

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., pp. 67-78.

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. (AUGMENT,27266,)

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. 381-395. (Provides very useful considerations relevant to requirements for the Open Hyperdocument System as discussed in this paper.)