Abstract1

1 Introduction2

1.2 Capability Infrastructure and its Augmentation System2b

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.2b1

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.2b2

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).2b3

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

2b4

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.2b5

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.2b6

And, along with these foregoing perceptions, another factor popped into the scene to create a very significant effect on my emergent framework.2b7

1.4 The Underlying Importance of Paradigms2d

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?3a

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.3b

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).3c

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).4a

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. 4c

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:5a

The answer was a clear "Yes!" A core set of knowledge-related capabilities rapidly emerged as the prime candidate. 5b

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.)5c

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.5d

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.5f

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:6a

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.6b

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. 6c

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). 6d

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). 6e

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).6g

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. 6i

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. 6j

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.6k

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.6l

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).6m

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). 6n

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.6p

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.6q

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."6r

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.6s

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.6t

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.6u

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.6v

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.6w

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.6y

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.6z

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.6aa

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.6ab

This is representative of the scale of global challenge that I think faces the groupware marketplace.6ad

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.6ae

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.6af

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

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

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

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

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).7e

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

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

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.")7h

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

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.)7j

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

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).7l

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

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

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

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

ACCESS CONTROL - Hyperdocuments in personal, group, and library files can have access restrictions down to the object level.7q

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

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

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

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:8a

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.8b

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.8c

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>.8d

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).8e

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. 9a

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.9b

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.9c

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.9d

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. 9e

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.9f

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.9g

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."9h

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.9i

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.10a

We considered the concept of the organization's capability infrastructure upon which any of the organization's effectiveness must depend.10b

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.10c

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.10d

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.10e

It would be profitable to consider early focus on improving the organizational improvement process so that further improvements can be done more effectively.10f

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.10g

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.10h

So, high-performance organizations: great opportunities, interesting concepts, tough challenges. What next regarding strategy?10i

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).11a

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.11b

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. 11c

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).11d

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.11e

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."11g

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.11h

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.11i

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."11j

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.11k

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:11l

It provides for the Community getting better and better at its basic "C Activity;"11l1
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."11l2

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.11m

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.11n

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.11o

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.11p

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.11r

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

11r1

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

11r2

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."11s

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.")11t

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 ..."11u

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.11v

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.11w

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?11x

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.
11y

[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.]11z

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.12a

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. 12b

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,)12c

Ref-4. Engelbart, D.C. and Lehtman, H.G. 1988. Working Together", BYTE Magazine, December, pp. 245-252. 12d

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.12e

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.12f

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,). 12g

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.12h

Ref-9. Irby, C.H. 1976. The Command Meta Language System. AFIPS Conference Proceedings, NCC Vol. 45, Montvale, NJ: AFIPS Press. (AUGMENT,27266,)12i

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,). 12j

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,).12k

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.)12l

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.)12m