International C2 Journal: Issues
Vol 1, No 1 (2007)
Enterprise Command, Control,
and Design:
Bridging C2 Practice
and CT Research
Abstract
As the metaphorical mind of the enterprise, command and control (C2) involves thinking, planning, sensing, responding, organizing, directing, and monitoring, and hence is comprised largely of activities in the cognitive and social domains. As such, C2 has represented a critical aspect of military planning and execution for millennia, and time-tested approaches to C2 in military organizations and processes remain prevalent in current practice. In contrast to these venerable approaches to military practice, however, scholarly research in the C2 domain remains divergent, and a noticeable chasm exists between well-established research and continuing C2 practice. This is particularly the case with research in the area of long- and well-established Contingency Theory (CT). Using terms appropriate for this audience, the central premise of CT is that no single enterprise design is ideal for all missions, environments, and contexts. Because military organizations have been and will continue to be required to undertake complex missions in a variety of diverse and challenging environments and contexts, one would expect to see C2 approaches that have, in the language of complexity, requisite variety, and that enable, in the language of C2 approaches, enterprise agility. At the very least, one would expect the military to be exploring non-traditional approaches to C2 vigorously, and one would expect for it to be making rapid progress. Further, given the abundant theoretical and empirical CT research available for guidance, one would expect leaders and policy makers to redesign high-performance enterprises to fit shifting mission, environmental, and contextual circumstances better. Instead one sees that remarkably homogeneous, hierarchical, traditional, and often ill-fitting C2 approaches predominate the practice. The problem is that few CT scholars understand current C2 practice sufficiently well to apply such research directly, and few C2 researchers, analysts, leaders, and policy makers understand CT research sufficiently well to take advantage of the corresponding enterprise design opportunities. Even the fundamental terms used by members of the CT and C2 communities differ. This expository article takes four important steps toward bridging the chasm between C2 practice and CT research: (1) it summarizes the central tenets of CT in terms that can inform C2; (2) it bridges several key terminological gaps between the CT and C2 communities; (3) it highlights state-of-the-art C2 research that develops new CT knowledge for enterprise design; and (4) it outlines a research agenda that can guide both established and emerging scholars toward effective application to address practical C2 issues. As such, this article can inform the CT researcher as well as the C2 practitioner, and it elucidates a path for applying future CT research to C2 practice.
Introduction
The term command and control (C2) is used in the U.S. military to describe organizations and processes associated with planning, directing, coordinating, and controlling the accomplishment of combat and other missions (e.g., see DoD JCS 2007). As the metaphorical mind of the enterprise, C2 involves thinking, sensing, responding, organizing, and monitoring also, and hence is comprised largely of activities in the cognitive and social domains (see Alberts et al. 2001). As such, C2 has represented a critical aspect of military planning and execution for millennia, and time-tested approaches to C2 in military organizations and processes remain prevalent in current practice.
Although the term C2 is associated most traditionally with military organizations and processes, it is important to understand that C2 is not limited to military enterprises. Every enterprise—for-profit corporations, government agencies, non-profit organizations, and military units—requires C2 for direction and performance. For instance, nearly every publicly traded corporation has organizations and processes associated with C2—albeit with different names (e.g., corporate strategy, market planning, business intelligence, competitive tactics, organizational structuring, task assignment, performance monitoring). The same applies to government agencies, non- profit organizations, and other enterprise forms—again, albeit with different names (e.g., government policy, constituency understanding, organizational assessment, and so forth). Nonetheless, given the primary audience of this journal, we focus on military C2 here.
In contrast to the venerable approaches to military enterprise practice noted above, scholarly research in the C2 domain remains divergent. Notwithstanding scholarly work dating back to the seventies and before that addresses military C2 directly (e.g., see DSB 1978), considerable scholarly research has been ongoing in other domains (e.g., Decision Making, Leadership, Management, Organization Studies, Social Psychology) that can inform both the research and practice of military C2. The problem here is that most military C2 researchers do not appear to build firmly upon the scholarly literature in these other, applicable domains (cf. Alberts and Hayes 2003), and it is rare for scholars in these other domains to focus on military C2 (cf. Hutchins 1995). Indeed, a noticeable chasm exists between well-established research in the cognitive and social domainsand continuing C2 practice. Consider, for example, how the concept sensemaking has been and is being developed separately by scholars outside (e.g., see Weick 1995) and inside the military C2 focal domain (e.g., see Alberts and Hayes 2006, 8). Notwithstanding some research by “outside” scholars that focuses on the military (e.g., see Weick and Roberts 1993), such scholars do not appear to have ever been invited into the inside of military C2 practice and policy making; hence concepts such as sensemaking are being developed and refined by “outside” scholars without much input from or consideration of military C2.
Likewise, “inside” scholars within the military (e.g., see CCRP 2007) do not appear to have drawn upon “outside” scholarship in their independent conceptualization of concepts such as sensemaking. As the story is told:
Actually our CCRP [Command & Control Research Program] use of “sensemaking” goes back quite a bit and was independently developed from Weick – it came out of a Joint Staff request that we help operational folks “make sense out of a situation” – we held a workshop and “coined” the term “sensemaking” in the workshop report – by the way our view of sensemaking is somewhat different in what it includes and how it defines components – but the point is – we were not and still are not well connected to the research that was independently going on in the cognitive and social domains – the many groups of researchers were going it alone since they did not interact with one another (Alberts 2007).
Similar stories can be told regarding other concepts (e.g., situational awareness) that are developed principally—and independently—by “inside” scholars. Such concepts appear only rarely in scholarly “outside” journal publications (e.g., see Sonnenwald and Pierce 2000). This is the case even though they relate closely to “outside” concepts (e.g., vigilant EIS; see Walls et al. 1992), the latter of which appear almost never in “inside” publications.
Although some scholars seek to bridge the chasm between well- established research in the cognitive and social domainsand continuing C2 practice (e.g., see Levchuk et al. 1999; Nissen 2005; Orr and Nissen 2006; Gateau et al. 2007), such research does not appear prominently in the mainstream “outside” literature, which represents a primary source of reward and recognition in the scholarly academic community. This is particularly the case with research in the area of long- and well-established Contingency Theory (CT) that dates back over 50 years.
Using terms appropriate for this audience, the central premise of CT is that no single enterprise design is ideal for all missions, environments, and contexts (see Donaldson 2001). Where missions, environments and contexts remain stable, understandable, and predictable over time, organizational adaptation and incremental change can refine an enterprise’s C2 approach to achieve and maintain excellent fit (i.e., appropriate to ensure good enterprise performance). This was the case for NATO in the Cold War mission- environmental context, for instance, where enterprise C2 organizations and processes developed to address a single, relatively symmetric and known threat.
Alternatively, where missions, environments, and contexts are not stable, understandable, or predictable over time, organizational adaptation and incremental change are often insufficient to maintain even adequate fit (i.e., unable to ensure even acceptable enterprise performance). This is arguably the case for the U.S. military in the Global Terror mission-environmental context, for instance, where enterprise C2 organizations and processes struggle still to address the many, relatively asymmetric, and emergent threats.
As noted with the concepts above, here the concept fit is well- entrenched in the “outside” literature (esp. CT), but it does not appear prominently within military C2 publications. Likewise, the CT notion of maintaining fit incrementally over time is referred to via different terminology in “inside” publications (e.g., incremental improvement, non-disruptive innovation; Alberts 2007), and military C2 publications do not appear to draw from or build upon long- and well-established CT. Further, somewhat recent concepts apparent from the “inside” literature (e.g., disruptive innovation, transformational change) appear to recognize the inadequacy of incremental change to maintain fit with abruptly shifting environmental conditions, but as above, they do not appear to draw from or build upon CT.
Because military organizations have been and will continue to be required to undertake complex missions in a variety of diverse, challenging, and unpredictable environments and contexts, one would expect to see C2 approaches that have, in the language of complexity, requisite variety (e.g., see Ashby 1960), and that enable, in the language of C2 approaches, enterprise agility (e.g., see Alberts and Hayes 2003). At the very least, one would expect the military to be exploring non-traditional approaches to C2 vigorously, and one would expect for it to be making rapid progress. Although the military is clearly looking toward non-traditional approaches (e.g., network- centric warfare, effects-based planning, distributed operations), progress appears to be uncomfortably slow, and as above, it does not appear to be informed well by the robust and extensive literature developed through “outside” scholarship.
Further, given the abundant theoretical and empirical CT research available for guidance (e.g., see the excellent review and extensive list of references in Donaldson 2001; see the integrated model and extensive list of references in Scott 2003; see the direct C2 domain application and focused list of references in Gateau et al. 2007), one would expect leaders and policy makers to redesign high-performance enterprises to fit shifting mission, environmental, and contextual circumstances better. Instead one sees that remarkably homogeneous, hierarchical, traditional, and often ill-fitting C2 approaches predominate the practice.
The problem here is that few CT scholars understand current C2 practice sufficiently well to apply such research directly. Likewise, few C2 researchers, analysts, leaders, and policy makers understand CT research sufficiently well to take advantage of the corresponding enterprise design opportunities. Even the fundamental terms used by members of the CT and C2 communities differ. For instance, the “outside” CT literature refers principally to organizations when discussing design, but the idea of designing organizations does not appear prominently in “inside” publications, and there is little evidence that “inside” scholars even address an organization’s design as an independent variable (e.g., subject to decision making, under some control). Likewise, the “inside” C2 literature refers to enterprises when discussing C2 approaches (e.g., Alberts and Hayes 2006; 2007), but only a dearth of the (clear) linkages with organizational design can be found in either literature. Indeed, integrating these two, divergent literatures represents the focus of scholarly research that has begun emerging only comparatively very recently (e.g., see Nissen 2005; Orr and Nissen 2006; this present article), yet remains a compelling and challenging task.
This expository article takes four important steps toward bridging the chasm between C2 practice and CT research: (1) it summarizes the central tenets of CT in terms that can inform C2; (2) it bridges several key, terminological gaps between the CT and C2 communities; (3) it highlights state-of-the-art C2 research that develops newCT knowledge for enterprise design; and (4) it outlines a research agenda that can guide both established and emerging scholars toward effective application to address practical C2 issues. As such, this article can inform the CT researcher as well as the C2 practitioner, and it elucidates a path for applying future CT research to C2 practice.
Nonetheless, there are limits to the amount of progress that can be made through a single article such as this, and hence limits to how much of the chasm between CT research and C2 practice can be bridged via this single study. It remains for other researchers—both “inside” and “outside” the military C2 community—to build upon the progress made through this present study, and to publish related articles that continue bridging the chasm.
In the balance of this article, we summarize key background information pertaining to Contingency Theory, and then outline the principal dimensions of enterprise design with a CT perspective. We illustrate in turn the enterprise design approach via state-of-the- art techniques associated with computational enterprise modeling and experimentation, and then conclude with key findings, implications, conclusions, and suggestions for future research along the lines of this investigation.
Background
In this section, we summarize important background material on CT. Using terms and concepts that appear centrally and prominently in the scholarly CT literature, we expose the unfamiliar reader to them—while reminding the familiar reader also—and we devote considerable space to articulating three very illustrative— albeit simplistic—CT models. Each of these models illustrates how design knowledge embedded within a theoretical model can be used to organize best in the context of a particular contingency (i.e., a critical consideration). The idea is for the reader to understand the fundamentals of CT sufficiently well to appreciate the power and potential of its application to military C2 via enterprise design, but also to understand the limitations of CT research to date in terms of effective C2 application.
We begin by summarizing the roots of CT briefly. We then outline the classic, two-dimensional CT models of Perrow and Duncan to illustrate how analysis of organizational technology and environment, respectively, can be used to identify the best fitting organizational form.[2] In terms of enterprise design, identifying an appropriate organizational form represents an extremely important step. By “form,” we refer to the high-level design and structure of an organization. This involves design decisions such as: centralization of power, authority, and information flows; formalization of roles and jobs; differentiation in terms of hierarchical levels and specialized units, departments, and functions; nature and degree of task interdependence; methods of coordination; and others.
Indeed, selecting an appropriate organizational form—with its attendant design decisions—may represent the most important enterprise design step, for the choice of organizational form tends to dominate other enterprise design decisions that one makes. Nonetheless, enterprise design involves more than simply selecting an appropriate organizational form—important as this step may be— and the set of design decisions pertaining to organizational form represents only one of multiple enterprise design elements, all of which must be considered and analyzed in an integrated manner. We address this latter point in the enterprise design section that follows this background discussion.
CT Roots
For more than a half century, Contingency Theory has retained a central place in management and organization research. Beginning with the seminal works by Burns and Stalker (1961), Woodward (1965), Lawrence and Lorsch (1967), and others, management and organization theories have been guided by the understanding that no single enterprise design is best in all circumstances. Rather, an array of various contingency factors (e.g., enterprise age, environment, size, strategy, technology) have been shown to impact enterprise performance and hence competitive advantage. Thus, the competitive performance of an enterprise is dependent upon how well it is designed to fit (i.e., be appropriate for) its contingency factors (Leweling and Nissen 2007).
Indeed, myriad empirical studies (e.g., Argote 1982; Donaldson 1987; Hamilton and Shergill 1992, 1993; Keller 1994; cf. Mohr 1971; Pennings 1975) have confirmed and reconfirmed that poor organizational fit degrades enterprise performance, and many diverse organizational forms (e.g., Bureaucracy, see Weber 1947; M- Form, see Chandler 1962; Clan, see Ouchi 1981; Network, see Miles and Snow 1978; Platform, see Ciborra 1996; Virtual, see Davidow and Malone 1992) and configurations (e.g., Machine Bureaucracy, Simple Structure, Professional Bureaucracy, Divisionalized Form, Adhocracy, see Mintzberg 1979) have been theorized to enhance fit across alternate contingency factors. For instance, both technology and environment have been studied extensively as particularly powerful contingency factors (e.g., Burns and Stalker 1961; Galbraith 1973, 1977; Harvey 1968; Woodward 1965), which have direct influence over the most appropriate organizational form.
Perrow’s Model
This first description of a two-dimensional CT model, although it is relatively simplistic, equips us to appreciate how design knowledge embedded in a theoretical model can be used to organize best for a particular contingency (i.e., to achieve the best fit): technology in this case.
In Perrow’s (1967) classic work, the contingency organizational technology—“actions that an individual performs upon an object with or without the aid of tools or mechanical devices in order to make some change in that object” (p. 195)—is analyzed to identify the most appropriate organizational form. Here, organizational technology is characterized in terms of two independent dimensions: task variability and problem analyzability. Task variability pertains to the number or frequency of exceptional cases encountered in the work, which can be viewed also in terms of perceived familiarity of the technology. Perrow labels the two polar values for this dimension “routine” and “high”; for clarity, we use more simply the labels “low” and “high” in this article. Technology with relatively low task variability would be associated with a manufacturing assembly line, for instance, where very little variation in work tasks exists and very few exceptions are encountered. Alternatively, relatively high task variability might be associated instead with technology used for management consulting, for instance, where every set of customer needs and corresponding organizational responses would be expected to differ.
Problem analyzability pertains to the structured nature of search required to solve work problems, which can be viewed also in terms of how routine the analysis of such problems is perceived to be. Perrow labels the two polar values for this dimension “analyzable” and “ill- defined”; for clarity, we use more simply the labels “structured” and “unstructured” in this article. Structured problems have routine and well-understood problem-solving approaches established in the organization. Many diagnostic tests performed by automobile mechanics conform to this characterization, for instance. Unstructured problems, by contrast, can require novel search to even identify one or more appropriate problem-solving approaches. Strategic planning in an enterprise conforms to this characterization, for instance.
Table 1. Technological Contingency Relationships.
(adapted from Perrow 1967)
Problem analyzability: |
Structured |
Unstructured |
Low |
Routine |
Craft |
High |
Engineering |
Nonroutine |
These two dimensions are orthogonal, and combining them creates a four-cell table of contingencies, with a different organizational form theorized to fit best in each; that is, analysis of organizational technology in terms of these two dimensions is used to identify the most appropriate organizational form. This is characterized in Table 1 via our adaptation of the corresponding contingency design knowledge. Task variability is dichotomized via two rows of the table, and problem analyzability is split into two columns. Entries in the four cells of the table prescribe the preferred organizational form for each joint contingency. For instance, where task variability is low and problem analyzability is structured, the contingency relationship suggests that a form called Routine Organization would represent the best fit with such technology. A routine organizational form might be found in a mass-production manufacturing firm, for example. As another instance, where task variability is high but problem analyzability remains structured, the Engineering Organization would be most appropriate in terms of technological fit. As suggested by the name, an engineering organizational form would be found where technological artifacts (e.g., aircraft, buildings, computers) are designed and developed, for example.
The other two organizational forms in the table follow accordingly, and pertain to contexts in which problem analyzability of the technology is unstructured. Where task variability is low (and problem analyzability is unstructured), the contingency relationship suggests that a form called Craft Organization would represent the best fit with such technology. As suggested by the name, a craft organizational form might be found where custom products or services are provided, for example. Instead, where task variability is high (and problem analyzability is unstructured), the contingency relationship suggests that a form called Nonroutine Organization would represent the best fit with such technology. Advanced research and development organizations would correspond well to this characterization, for example.
It is important to understand that each of the four organizational forms included in the table represents a general class, within which myriad different, specific instances can be developed. Nonetheless, as noted above, selecting the appropriate class represents an extremely important design step. Consider by analogy four general classes of aircraft: space shuttle, fighter-attack jet, cargo jet, and ultra light. Clearly, no single class of aircraft would offer the best performance across all mission-environmental contexts (e.g., a space shuttle could not land on an aircraft carrier; an ultra light could not fly into space; a cargo jet could not fit into the trunk of a family car), and selecting the most appropriate class represents an extremely important design step. Indeed, if an inappropriate class is selected (e.g., space shuttle for attack missions from an aircraft carrier), then the designer can do little to overcome this poor decision. The same applies to selection of the most appropriate class of organizational form in terms of enterprise design: if an inappropriate class is selected (e.g., Routine Organization for unstructured, high variability technology), then the designer can do little to overcome this poor decision.
The central point is that the technology contingency can be characterized according to two independent dimensions, and based upon design knowledge embedded within the model, the best-fitting organizational form, as a class, can be identified through analysis of the four corresponding cells of Table 1. Because selection of an appropriate organizational form tends to dominate the enterprise design process, this represents an extremely important step. By articulating four alternate organizational forms that correspond to the two technology contingency dimensions, scholars have facilitated the process of enterprise design: the leader or policy maker can use the design knowledge formalized via this table to select the most appropriate organizational form for a given—or shifting—technology.
This being said, clearly the simple, two-dimensional model described here provides inadequate descriptive power and fidelity to apply directly to the C2 domain. Operational C2 practice in the field requires more than just two relatively high-level dimensions to describe with good fidelity, and good fidelity description represents a critical step in organizing for effective C2. Still, this description begins to elucidate how design knowledge embedded in even a simple theoretical model can be used to guide organization for a particular contingency: technology in this case.
Duncan’s Model
This next description of a two-dimensional CT model is relatively simplistic also, but as above, it equips us to appreciate how design knowledge embedded in a theoretical model can be used to organize best for a particular contingency (i.e., to achieve the best fit): environment in this case.
In Duncan’s (1979) early work, the contingency organizational environment is analyzed to identify the most appropriate organizational form. Similar to the manner described above for Perrow’s model of organizational technology, here organizational environment is characterized in terms of two independent dimensions: complexity and change. Complexity pertains to the relative number and similarity of factors in the environment that must be considered by organizational leaders. A relatively simple environment might be represented well by that surrounding a lower level production department within the operating core of a manufacturing firm, for instance: it needs to consider only adjacent departments such as Materiel (e.g., for input materials) and Marketing (e.g., for orders), and it can focus principally on a single issue (esp. production). Alternatively, a relatively complex environment might be represented instead by a city planning department, for instance: it must consider inputs from a large and diverse cross section of stakeholders (e.g., residents, business owners, environmentalists) and issues (e.g., crime, pollution, traffic, tax revenues, legislation, education).
Change in turn pertains to the relative stability of environmental factors that must be considered by organizational leaders. In a relatively static environment, the kinds of factors noted in either example above (e.g., input materials from the Materiel Department, crime and pollution issues confronting planners) would remain roughly the same across time, whereas in a relatively dynamic environment, such factors would vary longitudinally. As with the technological framework above, these two dimensions are orthogonal, and combining them creates a four-cell table of joint contingencies, with a different class of organizational form theorized to fit best in each. This is characterized in Table 2.
Table 2. Environmental Contingency Relationships.
(adapted from Duncan 1979)
Complexity: |
Simple |
Complex |
Static |
Functional |
Decentralized |
Dynamic |
Mixed Functional |
Mixed Decentralized |
Where the environment is simple and static, for instance, a Functional Organization is called for as the class offering best fit. The Functional Organization class is characterized generally by specific departments or like units of workers possessing relatively homogeneous skills (e.g., in engineering, marketing, accounting) and performing relatively similar kinds of work (e.g., engineering, marketing, accounting tasks). Alternatively, where the environment is simple but dynamic, the Mixed-Functional Organization is called for as the class offering best fit. This Mixed-Functional Organization is similar in most respects to its Functional Organization counterpart. The key difference centers on the existence and extent of lateral relations (e.g., for communication and coordination between functional departments such as Marketing, Engineering, and Manufacturing). Lateral relations can range in formality and complexity from direct contact between functional managers, for instance, on the simple end, through formal liaison positions and cross-functional teams as an intermediate approach, to relatively complex matrix-organization structures (e.g., see Galbraith 1977).
The other organizational forms in the table follow accordingly, and pertain to contexts in which the organizational environment is complex. Here, however, the contingency model includes an additional consideration: the extent to which the environment can be segmented into separate, nearly independent parts (e.g., different geographical regions, product lines, market areas). Where segmentation in a static, complex environment can be achieved, a Decentralized Organization is called for as the class offering best fit. The Decentralized Organization class is characterized by relatively autonomous units operating in different segments. Companies that split into multiple product divisions or strategic business units, government agencies that organize into geographical offices, religious denominations that empower individual churches to operate independently, and like enterprises conform to many characterizations of decentralized forms in this class.
Alternatively, for reasons similar to those noted above for the simple environment, in a dynamic, complex environment (again, where segmentation can be achieved), a Mixed-Decentralized Organization (i.e., Decentralized Organization with lateral relations) corresponds best as a class to the contingency. Hence a fundamental difference can be seen between the simple and complex (segmented) environment: some kind of functional organization (e.g., with or without lateral relations) is called for in the former case, whereas some kind of decentralized organization (again, with or without lateral relations) is called for in the latter case.
Where the environment is complex but cannot be segmented, the best fitting classes of organizational forms correspond exactly to those in the simple environment (i.e., Functional Organization in the static environment, Mixed-Functional Organization in the dynamic one). Because these cells repeat those shown for a simple environment above, and hence offer nothing new to the discussion, we omit them from the table.
As above, the central point is that the environment contingency can be characterized according to two independent dimensions, and based upon design knowledge embedded within the model, the best fitting organizational form, as a class, can be identified through analysis of the four corresponding cells of Table 2. As above also, because selection of an appropriate organizational form tends to dominate the enterprise design process, this represents an extremely important step. By articulating four alternate organizational forms that correspond to the two environment contingency dimensions, scholars have facilitated the process of enterprise design: the leader or policy maker can use the design knowledge formalized via this table to select the most appropriate organizational form for a given—or shifting—environment.
As above, this being said, clearly the simple, two-dimensional model described here provides inadequate descriptive power and fidelity to apply directly to the C2 domain. Here too, operational C2 practice in the field requires more than just two, relatively high-level dimensions to describe with good fidelity, and good fidelity description represents a critical step in organizing for effective C2. Still, this description continues to elucidate how design knowledge embedded in even a simple theoretical model can be used to guide organization for a particular contingency: environment in this case.
The astute reader is undoubtedly asking him or herself about combining these two models; that is, what if the enterprise designer combines both the technology and environment contingencies to select an appropriate organizational form? Although such combination increases the complexity of the design process appreciably (e.g., increasing the number of alternate organizational forms to be considered fourfold: from 22 = 4 to 24 = 16), it represents a straightforward extension. Indeed, as we discuss enterprise design more specifically in the next section, we show how relatively large numbers of contingency dimensions are integrated into the design process.
Enterprise Design
In terms of military C2, the central notion of enterprise design involves determining the best C2 approach for a given mission-environmental context. Hence enterprise design can be thought of as a structured and rational method to determine the best C2 approach. As such, enterprise design contrasts clearly with extant, popular, and simple methods such as trial and error (e.g., simply making what appear to be the best decisions at a given time, and watching to see how well they turn out), imitation (e.g., simply copying the approach employed by some other military, government, commercial, non- profit, or other enterprise), or inertia (e.g., simply staying with an existing C2 approach because it is familiar and has worked relatively well in the past). In contrast, by drawing from design knowledge embedded within CT models, enterprise design is driven by theory. Through integrated analysis of multiple contingency dimensions, it can enable better enterprise designs than are attainable generally via other, less structured and rational methods.
In the previous section we focus on selecting the best organizational form, for this decision tends to dominate the enterprise design process. However, as noted above, organizational form represents only one of several design elements that must be considered. Drawing from the Leavitt Diamond (Leavitt 1965), for example, we understand how other design elements such as work processes, personnel systems and technologies must be designed also for appropriateness in a given mission-environmental context. Indeed, identifying the most appropriate organizational forms, work processes, people and technologies represents an integrated design problem: not only must each element be designed to fit well with the mission-environmental context at hand, but all of the various elements must also be arranged to fit well with one another. This is the essence of enterprise design.
Returning to our aircraft-design analogy, one must do more than simply select the most appropriate class of aircraft for a particular mission (e.g., space shuttle for trips to the International Space Station); the nature of the engines (e.g., solid-rocket boosters, orbital thrusters), fuselage (e.g., thermal tiles, small wings), payload (e.g., robotic arm, zero-gravity scientific experiments), and other elements must be designed to fit well with the mission-environmental context at hand, and they must also be arranged to fit well with one another. This is the essence of aircraft design.
This section focuses on approaching the enterprise design problem rationally and through the use of state-of-the-art computational tools. We first define the object of our design activity: the enterprise. We then summarize the implications of the rational view that we maintain via a design perspective. The discussion turns next to a higher dimensionality CT model, which reveals how the comparatively simple, two-dimensional CT models from above have been extended to reflect 14 dimensions. The discussion reveals also, however, that even a 14-dimensional model remains somewhat simplistic in terms of practical C2 application, yet it highlights the implications of both dimensional orthogonality and complexity in terms of enterprise design. Finally, we introduce computational modeling and experimentation as an approach to ameliorate the problem of inadequate model dimensionality coupled with very large design spaces. This takes us to the state of the art in applying CT to C2, and equips the reader to appreciate the insightful enterprise design illustration presented in the subsequent section.
Enterprise Defined
Because many people use the term enterprise differently, we begin by defining the term in this section. Drawing first from the C2 literature, Alberts and Hayes (2006, 34) do not define enterprise per se, but they discuss the enterprise in terms of “…an entity or association of entities,” and they focus on “command and control (or management) of a given undertaking.” These same authors (2007, 14) describe the enterprise in terms of “… both military forces and civil organizations” also. Like most military C2 researchers, these authors refer implicitly to enterprises as being relatively large in terms of size (e.g., large numbers of people and tasks). Drawing next from the sociology of organizations literature, Scott (2003, 129-132) discusses various levels of collectivities (e.g., individuals, groups, organizations, populations, fields) in a manner that provides for considerable range of description, and that allows for wide variation in terms of size. Combining these descriptions, and with a focus on design, in this article we define enterprise as:
| an organized collectivity of human action focused on a substantial undertaking (e.g., greater than can be accomplished by a single individual). |
As such, we use this term to subsume other types of collectivities, including non-profit organizations, business firms, multinational corporations, organizational departments, military units, task forces and coalitions, government agencies, unions, guilds, sports teams, churches, families, and even social movements. Hence this definition may appear to be somewhat broader than that of Alberts and Hayes (e.g., including business firms, churches, families), but it is consistent in that these types of collectivities would fall neatly into their term civil organizations.
Further, although this definition could include potentially dyads, triads, and even very small groups of people, the corresponding design issues would be trivial when compared to relatively large collectivities—particularly coalitions of potentially different military, government, commercial, non-profit and other organizations working together as an enterprise (e.g., consider a combined or joint task force). Hence we do not imply—or rule out—any particular enterprise size with this definition, but the context in which enterprise design offers the greatest potential is consistent with extant military C2 research: where enterprises are relatively large, and their missions and environments are relatively complex.
Likewise, this definition is consistent with Scott’s levels of analysis, for it extends up to the level that Scott refers to as organizational sets, but does not include higher levels such as populations, fields, industries, nations, cultures or societies. With this, the enterprise represents a relatively broad, common, and high-level concept, and our usage here can be grounded in both the C2 and organizations literatures (i.e., familiar to “inside” and “outside” researchers, respectively).
Design as a Rational Perspective
When drawing from the management and organizations literatures as above, some views of organizational fit and performance place enterprise leaders in a relatively passive position (e.g., relatively powerless), whereas others outline definitive, rational steps that (knowledgeable and empowered) leaders can take to improve organizational fit. When discussing enterprise design—as a method to determine the best C2 approach—it is useful to situate the corresponding design steps in terms of these divergent views, for such situating can help “inside” and “outside” researchers to communicate effectively.
In the former view, organizational ecologists (e.g., see Hannan and Freeman 1977; Aldrich 1979) suggest that certain organizational forms have inherently better or poorer fit with their environments—at certain periods in time—than other forms do, and hence some forms will perform better in such environments than others will. In this view, enterprise leaders have negligible influence over the environment, and have limited capability to transform the enterprise to reflect a different design. Hence there is little that can be done to address the misfit situation. Here, an organizational form (and indeed a “population” of organizations sharing similar forms) that becomes inferior in terms of environmental fit is destined to extinction, and the most prudent action that an enterprise leader can take is to either continue cashing his or her checks until the enterprise dies, or switch to lead a competing, better fitting organizational form. Many military C2 leaders and policy makers appear to accept their current organizational form (e.g., centralized, hierarchical, bureaucratic) as fixed. Such leaders and policy makers would be described adequately by this view, and by neglecting organizational form as an enterprise design decision, they miss the opportunity to affect enterprise performance—and hence competitive advantage—through a well-fitting organizational form.
Alternatively, in the latter view, contingency theorists (e.g., see Burton and Obel 1998; Donaldson 2001; others cited above) indicate that leaders can and should take action to bring misfit enterprises into better fit with their environments. In this view, leaders can influence the environment via enterprise performance, have the capability to effect enterprise transformation, and can transition between two or more different organizational forms. Hence there is much that can be done to address the misfit situation. In this view, an enterprise with a particular organizational form that becomes inferior in terms of environmental fit can be redesigned and changed (i.e., “transformed” in military C2 parlance) to improve fit, and the most prudent action that an enterprise leader can take is to lead the redesign and change efforts to create a better fitting organizational form. Continuing with our example from above, a leader or policy maker who redesigns the enterprise—or, more commonly, who authorizes and guides enterprise redesign by subordinates—to fit shifting mission, environmental, and contextual circumstances better, for example, would be described adequately by this view. Clearly, in this article we adopt the latter perspective, and outline how enterprises can be designed—and redesigned—to fit well in the context of whatever contingencies they encounter.
By emphasizing design as such, we take an inherently rational view of the enterprise (Scott 2003). The argument is that such collectivity can be described usefully in terms of aggregate, goal- directed behaviors, and that leaders can arrange the design elements of an enterprise (e.g., organization structures, work processes, personnel systems, technologies) in a purposeful manner that improves fit with one or more contingencies (e.g., mission, environment, others). As a design science (van Aken 2004), we are discussing a method that is prescriptive and that represents the same kind of purposeful, goal-driven, problem-solving activity associated broadly with the design of aircraft, buildings, computers, information systems, and other artifacts (Hevner et al. 2004): it “is concerned with how things ought to be, with devising structure to attain goals” (Simon 1996, 133).
Enterprise design addresses the purposeful actions that enterprise leaders can take to improve fit with respect to various mission-environmental contexts. Even though enterprise design addresses animate, thinking, non-deterministic collectivities of people—which differ clearly from the parts and artifacts associated with design of aircraft, buildings, computers, information systems, and the like—such collectivities can be analyzed prescriptively, through purposeful, goal- driven, problem-solving activities.
Simon (1996, 111) elaborates on design:
| The intellectual activity that produces material artifacts is no different fundamentally from the one that prescribes remedies for a sick patient or the one that devises a new sales plan for a company or a social welfare policy for a state. Design, so construed, is the core of all professional training; it is the principal mark that distinguishes the professions from the sciences. Schools of engineering, as well as schools of architecture, business, education, law, and medicine, are all centrally concerned with the process of design. |
Mintzberg (1979, 65) elaborates further in the context of organizations: “… design means turning those knobs that influence how the organization functions—how material, authority, information, and decision processes flow through it.” When a C2 leader or policy maker effects changes in how material, authority, information, and decision processes flow through an enterprise, he or she is engaged in enterprise design, and when such a leader or policy maker seeks to transform an enterprise to correct a misfit situation, he or she is adopting a rational design perspective that can be understood by the CT researcher.
Higher Dimensionality Design
Building upon the rational design perspective characterized above, as well as the simple, two-dimensional CT models described in the previous section, Burton et al. (2006) outline a step-by-step design method that applies well to the enterprise. Extending the former two-dimensional models extensively, these scholars describe design in terms of 14 dimensions (e.g., goals, strategy, structure, process, people), which increase the power and C2 applicability of CT-based enterprise design considerably. Unlike the comparatively very simple models from above, modeling in 14 dimensions provides much greater descriptiveness and fidelity to characterize operational C2 in the field.
Extending the prior models further, this method also equips us to appreciate how design knowledge embedded in a theoretical model can be used to organize best for a set of contingencies (i.e., to achieve the best fit): goals, strategy, structure, process, people, and nine others in this case. However, in contrast with using design knowledge embedded within the comparatively simple, two-dimensional, theoretical models described above, trying to leverage such design knowledge characterized via 14 dimensions becomes a very complex activity. Hence enterprise design power and C2 applicability comes at the price of complexity.
Table 3 summarizes the 14 dimensions articulated by Burton et al. (2006) from above, and it includes dimensional values corresponding to four different, high-level enterprise designs (i.e., labeled “Design 1,” “Design 2,” “Design 3,” “Design 4”). As with the simple, two-dimensional models above, each dimension represents a design consideration. For instance, the first dimension goal pertains to what the leader or policy maker is seeking to accomplish via the enterprise. As an extension to the simple models from above, both of which include only two possible values for each dimension, this model specifies four alternate values for each dimension. Specifically, the four goal values pertain to the leader’s or policy maker’s relative emphasis on enterprise efficiency and effectiveness: (a) one class of goals would place relatively high emphasis on effectiveness; (b) another would emphasize efficiency instead; (c) a third would seek to achieve both goals simultaneously; and (d) a fourth would seek to achieve neither goal. These are the dimensional values listed in Row 1 of the table.
Such enterprise goals would correspond, respectively, for instance, to: (a) a developing enterprise caught in a particularly volatile and hostile environment, in which it seeks efficacy and is comparatively less concerned about cutting costs; (b) an established enterprise enjoying a relatively stable and predictable environment, in which it seeks price leadership through low costs; (c) an enterprise that is required to compete in terms of innovation (i.e., effectiveness) and price (i.e., efficiency) simultaneously; and (d) a complacent enterprise such as a monopoly, which has little incentive to pursue either efficacy or efficiency. Hence in this model, one step of design involves identifying the high-level goal of the enterprise, and different enterprise designs are theorized to fit different goals relatively better or worse than others.
Table 3. Enterprise Design Dimensions.
(adapted from Burton et al. 2006)
Design Dimension |
Design 1 |
Design 2 |
Design 3 |
Design 4 |
|
|
|
|
|
Goal |
Effectiveness |
Efficiency |
Both |
Neither |
Strategy |
Prospector |
Defender |
Analyzer |
Reactor |
Environment |
Locally Stormy |
Varied |
Turbulent |
Calm |
Form |
Divisional |
Functional |
Matrix |
Simple |
Complexity |
Flat |
Tall |
Symmetric |
Blob |
Geographic dist |
Multidomestic |
International |
Transnational |
Global |
Knowledge exch |
Cellular |
Informated |
Network |
Ad-hoc |
Task Design |
Fragmented |
Complicated |
Knotty |
Orderly |
People |
Laboratory |
Factory |
Office |
Shop |
Leadership Style |
Leader |
Manager |
Producer |
Maestro |
Climate |
Developmental |
Internal |
Rational Goal |
Group |
Coordination |
Market |
Machine |
Mosaic or Clan |
Family |
Information sys |
People |
Data |
Relationship |
Event |
Incentives |
Bonus |
Skill Pay |
Profit Sharing |
Personal Pay |
The same applies to the other 13 dimensions summarized in the table. For instance the second dimension strategy includes four alternate values as listed in Row 2 of the table (i.e., “Prospector,” “Defender,” “Analyzer,” “Reactor”; see Miles and Snow 1978). As above, one step of design involves identifying and understanding the high-level strategy of the enterprise, and different enterprise designs are theorized to fit different strategies relatively better or worse than others.
Further, the goals and strategies of an enterprise are clearly interrelated, hence the two dimensions must be considered together. Here, the effectiveness goal is theorized to fit best with the Prospector strategy, and so forth with the other goals and strategies listed in Rows 1 and 2 of the table. The same applies also to the dimension enterprise environment (i.e., the goal “Effectiveness” fits best with the strategy “Prospector,” which in turn fits best with the environment “Locally Stormy”). Moreover, as above, the organizational form labeled “Divisional” fits best with the dimensional values “Effectiveness,” “Prospector” and “Locally Stormy”, and such a pattern of fit follows for all 14 dimensions included in the table. In the end, once someone has specified values for all 14 of these dimensions, he or she has rendered a high-level enterprise design.
To reiterate, notice that both the Perrow and Duncan models conceptualize contingent design knowledge in terms of only two dimensions (i.e., task variability and problem analyzability, complexity and change), whereas this Burton model conceptualizes it via fourteen dimensions. Hence this latter and more recent model is much more comprehensive than either of the two prior models is, and by including design dimensions such as enterprise environment and task design in Table 3, this latter model effectively subsumes both the Perrow and Duncan models. The central point is that 14 different contingency dimensions from the CT literature are integrated into a single model, and based upon design knowledge embedded within the model, the best fitting enterprise design can be identified through analysis of Table 3.
Dimensional Orthogonality Effects
A key limitation of the Burton theoretical model arises in terms of interrelationships between the 14 design dimensions summarized in Table 3. Recall that the models developed by Perrow and Duncan presume orthogonal (i.e., independent) dimensions. Specifically, in both of the prior models, the combination of two, orthogonal dimensions—each with two possible dimensional values—produces four (i.e., 22 = 4) alternate classes theorized to provide the best fit with the technology or environment contingency, respectively. In this respect, the design space (i.e., set of all possible design alternatives) for either model includes four classes (e.g., Routine, Craft, Engineering, or Nonroutine organization in the Perrow model; Functional, Mixed Functional, Decentralized, or Mixed Decentralized Organization in the Duncan model).
Alternatively, notice from Table 3 how, in the Burton model, the 14 design dimensions are not presumed to be orthogonal. Rather, all 14 dimensions of the Burton model are presumed to covary uniquely and hence to be collinear. Indeed, as theorized in this model, the effectiveness goal, for instance, fits only with the Prospector strategy, which fits only with the Locally Stormy environment, which fits only with the Divisional configuration, and so forth through the whole list of 14 design dimensions and values listed in the “Design 1” column of Table 3. Likewise, the Efficiency goal, as another instance, fits only with the Defender strategy, which fits only with the Varied environment, which fits only with the Functional configuration, and so forth through the whole list of 14 design dimensions and values listed in the “Design 2” column of Table 3; the same applies to the design dimensions and values listed under the “Design 3” and “Design 4” columns.
Because all 14 design dimensions are presumed to covary uniquely, despite the presence of 14 dimensions, the corresponding design space includes only four classes (i.e., those labeled “Design 1,” “Design 2,” “Design 3,” and “Design 4”). This renders a design space no larger than those pertaining to the two-dimensional models. Even though the 14 dimensions of this theoretical model enable much greater descriptiveness and fidelity for application to C2 practice, the model’s presumed dimensional non-orthogonality constrains the design space beyond reasonable argument; that is, the model is too simplistic with this presumption.
In contrast to the presumed dimensional non-orthogonality of Burton’s model, if we draw more directly from the two-dimensional models above, and apply their same, orthogonal view of contingency dimensions to the Burton model, then the design space grows exponentially to include over 268 million (i.e., 414 = 268,435,456) different designs; that is, if each of the 14 dimensions is treated independently, and each can take on four values, then over a quarter billion different designs could be described via this theoretical model. This creates a different problem than those of inadequate descriptiveness and fidelity (i.e., ascribed to the two- dimensional models) or overly constrained design space (i.e., ascribed to the 14-dimensional, non-orthogonal model): the 14- dimensional, orthogonal model becomes intractable for design purposes. A quarter billion represents a huge number of different enterprise designs to articulate, evaluate, and choose from. Hence a major challenge of higher dimensionality design pertains to the enormous design spaces involved.[3]
Nonetheless, this set of 14 dimensions is well-rooted in the CT literature; it provides much greater descriptiveness and fidelity to characterize operational C2 in the field; and it equips us to appreciate how design knowledge embedded in a theoretical model can be used to organize best for a set of contingencies (i.e., to achieve the best fit): goals, strategy, structure, process, people, and nine others in this case. This increases the power of CT research to inform and guide C2 practice. To reiterate from above, however, the price of power and C2 applicability is complexity, with this potentially huge design space presenting a problem for enterprise design. As described below, our use of computational modeling and experimentation helps to ameliorate this problem.
Computational Modeling and Experimentation
Computational modeling and experimentation have been described as a “bridge method” (Nissen and Buettner 2004) that spans the chasm between analytical and laboratory methods and their field- research counterparts. It combines some of the best aspects of each method (e.g., internal validity and reliability from analytical and laboratory research, external validity and generalizability from field research), and enables one to leverage the power of computational models to explore even very large design spaces. Briefly, the process begins with some computational environment that enables the representation and emulation of various enterprise designs and behaviors. After the important step of validation—ensuring that the emulated behavior and performance of computational models match those of corresponding enterprises in the field—one can develop and calibrate models to characterize any number of different enterprise designs.
Notice the similarity between this approach and the manner in which many complex, physical artifacts are designed today. For instance, before building an aircraft to perform some mission, the designer will generally create virtual prototypes of various classes of aircraft (e.g., space shuttle, fighter-attack, cargo jet, others) via computational modeling, and then analyze the comparative behavior and performance of each computationally. Because such computational models have been validated and shown to reflect the behavior and performance of physical aircraft in flight, one has considerable confidence that results of different computational aircraft designs will compare well to the corresponding physical counterparts in flight.
For another instance, before building a bridge across some chasm, the designer will generally create virtual prototypes of various classes of bridges (e.g., suspension, arch, truss, others) via computational modeling, and then analyze the comparative behavior and performance of each computationally. Because such computational models have been validated and shown to reflect the behavior and performance of physical bridges in the field, one has considerable confidence that results of different computational bridge designs will compare well to the corresponding physical counterparts spanning chasms. The same approach applies to the design of computers, houses, automobiles, factories, ships, and myriad other complex physical artifacts. Our use of computational modeling and experimentation for enterprise design builds upon the success of virtual prototyping for design in these other domains.
Drawing from our discussion above, for example, one could develop a computational model for each of Burton’s four enterprise designs (e.g., Design 1, Design 2), or for any other enterprise design that can be specified in terms of the computational model. Continuing with these examples for simplicity, one could then compare the relative behavior and performance of each computational enterprise model across a variety of different mission-environmental contexts, and analyze the comparative behavior and performance of each computationally. The best fitting design would correspond to the one exhibiting superior performance. Notice a contrast here. Burton’s CT model has theoretical design knowledge embedded within it: four alternate designs (e.g., Design 1, Design 2) that are theorized to provide the best fit and hence performance; alternatively, running the computational model establishes empirical design knowledge: linkages that are established between any number of enterprise designs and their relative performance.
Further, because computational models can execute very quickly, a great many different enterprise designs can be examined across a great many different mission-environmental contexts within a relatively short period of time. This enables one to evaluate many different enterprise designs within the design space, and to home in relatively quickly on those that offer superior performance. Further, each computational model can be varied discretely—one model parameter and one design dimension at a time—through a series of controlled experiments to determine which design dimensions exert the greatest influence over particular performance factors of interest. This is the basis of computational experimentation: controlled experiments using computational models of enterprises to learn which design dimensions are most influential over performance. In some cases, the number of influential design dimensions can be reduced to a relatively small set, which contracts the effective design space considerably.
For instance, when examining the design space associated with the Burton model—even when extending its 14 dimensions to presume orthogonality, and hence to increase the design space to include over a quarter billion different designs—computational experimentation may reveal that only three, say, of the fourteen are highly influential over performance. By focusing principally on just these three, one can effectively reduce the design space to a very tractable number (43 = 64) of different designs. Notice how this represents a dramatic reduction from the 268 million designs estimated above with respect to this same Burton model (again, presuming orthogonality), yet it suggests a far richer enterprise design space than that articulated by Burton (i.e., comprised of only four designs). In essence, computational modeling and experimentation enable one to prune huge regions of the design space, and hence remove them from consideration.
Then, by looking specifically at how each model parameter affects enterprise behavior and performance, one can work backward, in a goal-directed manner, from the kinds of performance characteristics needed to be effective (and/or efficient) in a particular mission-environmental context to the specific arrangement of corresponding design elements to achieve the best fitting enterprise design. In other words, the enterprise leader or policy maker could examine the contingency dimensions that exist or are anticipated to exist with the greatest impact on enterprise performance, and in turn design or redesign the enterprise to fit such contingencies well. Notice how this effectively integrates CT with a computational enterprise design approach.
Further, as above with the design of physical artifacts, where the computational models have been validated and shown to reflect the behavior and performance of operational enterprises in the field, one has considerable confidence that results of different computational enterprise models will compare well to the corresponding counterparts in operation. Hence the enterprise leader or policy maker can have considerable confidence that an enterprise design shown to be effective (and/or efficient) through analysis of computational experimentation will prove to be similarly effective (and/or efficient) when implemented via an operational enterprise in the field.
Illustrative Research
In this section, we motivate and outline illustrative research that pushes the state of the art in enterprise design as characterized above. We begin by motivating this research, and placing it in context with the three CT models and rational design approach discussed in the preceding sections. We then summarize how six archetypal, enterprise designs are parameterized via computational models, and describe how the behavior and performance of each is emulated using our computational environment to assess the comparative performance across two different mission-environmental contexts (i.e., contingencies). To reiterate from above, unlike the theoretical CT models described above, this establishes empirical linkages between different enterprise designs and their relative performance with respect to alternate contingencies.
Research Motivation and Context
An illustrative research exemplar can be found in recent work by Gateau et al. (2007). Building upon prior work to understand and compare the relative behavior and performance of alternate enterprise designs (e.g., Hierarchy and Edge; see Nissen 2005; Orr and Nissen 2006) in a C2 context, these researchers use a relatively well-validated[4] computational modeling environment to represent the structures and behaviors of five archetypal, enterprise designs (e.g., Machine Bureaucracy, Professional Bureaucracy, Adhocracy; see Mintzberg 1979), as well as Alberts’ and Hayes’ (2003) conceptualization of the Edge as a sixth design.
Drawing from our introduction of computational modeling and experimentation above, the idea is to understand the comparative performance of each enterprise design (i.e., as a class), across a variety of mission-environmental contexts (i.e., contingencies), and hence to map out the design space in terms of model parameters, enterprise performance, and contingencies. Notice that mapping the design space essentially creates a new CT model empirically. In a manner analogous to using the theoretical design knowledge embedded within the Perrow, Duncan and Burton models above, the enterprise leader or policy maker could refer to this empirical map of the design space to match the best enterprise design to a given—or shifting—set of contingencies. Hence this research builds directly upon and extends the kind of long- and well-established CT work described above, and it effectively integrates CT with a computational enterprise design approach.
Further, this illustrative research extends enterprise modeling considerably beyond even the 14 dimensions included in the Burton model. The computational modeling environment enables specification and analysis of enterprise designs and contingencies via roughly 100 different model parameters, which is equivalent to a 100-dimensional model. With this, we begin to overcome a lingering limitation of the CT models discussed above, and to enable much, much greater descriptiveness and fidelity for practical C2 application. Nonetheless, every model represents an abstraction of reality, so even with 100 dimensions, certain details of operational C2 practice must necessarily be excluded from any particular model—even a high-dimensional computational one. The key is to capture the most important details of C2 practice in such models, and to abstract away the ones that are less important. There is considerably more art than science to modeling and abstraction along these lines, and applying such art to the C2 domain remains at the edge of our state of the art at present, which is why the research described in this section is so illustrative.
As suggested above, in specifying the six enterprise designs, computational model parameters for each enterprise design are mapped explicitly to theoretical design dimensions conceptualized by Mintzberg (1979) and Alberts and Hayes (2003). The However, these latter models are largely descriptive, and hence lack the kind of prescriptive linkages between contingencies and designs that are prevalent in the CT models. In other words, although these latter models can be used to describe operational C2 organizations and processes better than the CT models above can, they do not contain the same kind of design knowledge embedded in them, and cannot be used to prescribe best-fitting contingent designs like the CT models do. Thus, we gain greater model descriptiveness and fidelity for representing C2 practice, but we lose theoretical guidance to inform the kind of rational and structured enterprise design method outlined above.
This helps to motivate the research illustrated here: it seeks to develop the kind of design knowledge embedded in extant CT models, and to articulate such design knowledge via descriptive, high- fidelity, theoretically grounded, computational models based on research by Mintzberg and Alberts and Hayes. Because such computational models reflect very high dimensionality (e.g., 100 model parameters), the corresponding design spaces are enormous. For instance, consider including only “high,” “medium,” and “low” dimensional values for 100 model parameters: the design space would explode to 3100 (i.e., 5.15 x 1047)! Our use of computational modeling and experimentation provides an approach to rendering even such enormous design spaces more tractable, and as we develop CT models from maps of such design spaces, we will be able increasingly to employ the kind of rational and structured enterprise design method outlined above. This represents the focus of research illustrated here.
Computational Model Parameterization
Parameterization of the six, archetypal models is summarized in Table 4 for discussion and reference. The three structural factors (i.e., organization, communication, work) in Column 1 derive directly from our prior computational experiments (i.e., Nissen 2005; Orr and Nissen 2006); the Mintzberg design parameters in Column 2 derive directly from Mintzberg (1979, 1980); and the model parameters in Column 3 serve to specify each of our computational models uniquely.
Table 4. Model Parameterization – Archetypal Enterprise Designs.
(adapted from Gateau et al. 2007)
For further comparison with the three CT models described above (i.e., as developed by Perrow, Duncan, and Burton et al.), notice that this model is specified in considerably greater detail. This enables one to represent any given enterprise via very fine-grain models, and with so many model parameters to work with, the many various details and idiosyncrasies of different operational enterprises in the field can be represented with considerable fidelity.
Returning to Table 4, the first Mintzberg design parameter is labeled “Decentralization” in Column 2, and corresponds to the computational model parameter labeled “Centralization” in Column 3. Column 4 summarizes the value of this parameter (i.e., “Low”) specified for the Edge enterprise design, and contrasts with the value (i.e., “High”) specified for the Machine Bureaucracy, the latter of which is shown to correspond very closely to the Hierarchy form described by Alberts and Hayes. Similarly, the second Mintzberg design parameter is labeled “Formalization of Behavior” in Column 2, and corresponds to the computational model parameter labeled “Formalization” in Column 3. Column 4 summarizes the value of this parameter (i.e., “Low”) specified for the Edge enterprise archetype, and contrasts with the value (i.e., “High”) specified for the Machine Bureaucracy. The same applies to the Edge and Machine Bureaucracy in terms of the other model parameters listed in the table, and the other four, archetypal, enterprise designs summarized in Columns 6–9. To preserve continuity for the non-modeler, we proceed now to discuss the comparative behavior and performance of these six designs. Please see Gateau et al. (2007) for model details.
Behavior and Performance
After specification of these six enterprise models, the behavior and performance of each is emulated using our computational environment to establish a baseline set of results. As controls, and as can be verified in Table 4 above, each model is specified with equivalent work tasks, difficulties, staff sizes, and capabilities across all six enterprise archetypes. For instance, notice that the model parameter labeled “Operations Position (ST)” reflects a level of exactly 13,000 people across all six enterprise classes, and that the parameter labeled “Skill Level” reflects the level “Med” (i.e., average capability) across all six. Such controls enable us to concentrate only on the effect of different enterprise designs, and to avoid conflation of effects associated with the kinds of work and personnel involved. Indeed, the vast majority of various model parameters are held constant for control.
In addition to the controls summarized above, the mission-environmental context is held constant for all six enterprises as well. In this baseline case, we utilize some additional computational model parameters (i.e., not summarized in Table 4) to specify the mission- environmental context as one corresponding generally to the kind of stable and predictable, industrial age, military environment associated with the Cold War era. Hence each of the six enterprise designs is assessed in terms of its performance—and thus fit—with respect to this industrial age, Cold War, mission-environmental context (i.e., contingency set). This enables us to evaluate the comparative fit of the alternate enterprise designs.
Table 5. Performance Summary - Cold War Context.
Performance |
Machine |
Edge |
Simple |
Professional |
Divisionalized |
Adhocracy |
Cycle time |
161 |
150 |
168 |
154 |
157 |
346 |
Residual |
0.39 |
0.77 |
0.31 |
0.35 |
0.47 |
0.77 |
Table 5 summarizes the results for this Cold War mission-environmental context via two performance measures: cycle time and residual errors. Cycle time pertains directly to the speed with which the enterprise is able to accomplish a given mission in this Cold War context. Residual errors pertain to one aspect of mission risk (i.e., the fraction of mission work performed with errors that remain uncorrected at mission completion); the idea is that the more errors that remain uncorrected, the greater the chances of one or more of them representing a critical error that jeopardizes the mission as a whole. Clearly, lower cycle time values (i.e., faster performance) are preferred to higher ones, and lower error values (i.e., fewer uncorrected errors) are preferred to higher ones. Notice that the Edge enterprise design has the best cycle time performance (150 days), and the Adhocracy has the worst (346 days). However, the Edge (and the Adhocracy) exhibits the worst residual errors performance (0.77), and the Simple Structure exhibits the best (0.31). Hence the Edge enterprise involves a tradeoff for leaders and policy makers: it is relatively fast but error-prone with respect to other enterprise designs. Where speed is important, and errors can be tolerated, then the Edge appears to represent an appropriate enterprise design, but where speed is less important, and errors need to be minimized, then a different design would be suggested by the results.
Notice that the venerable Machine Bureaucracy (i.e., Hierarchy), which characterizes current military C2 organizations and processes well, offers a favorable combination of good performance across both measures (i.e., cycle time = 161, residual errors fraction = 0.39). Although the residual errors fraction is somewhat higher than that of the Simple Structure, it remains much lower than that of the Edge design, and the Machine Bureaucracy is faster than the Simple Structure is. Hence, in this Cold War mission-environmental context, the classic Machine Bureaucracy appears to represent a relatively good enterprise design choice. Thus, the computational model results reinforce the prudence of longstanding military C2 practice via this enterprise design that has been employed throughout the Cold War era.
After running the models and collecting these performance results for the Cold War mission-environmental context, we then emulate the behavior and performance of the exact same, six enterprise designs in a less certain, less familiar, more demanding, twenty- first century, Global War on Terror, mission-environmental context. This results in a second set of performance data, which can be compared both with the baseline set noted above and across the six enterprise designs. As above, the results enable us to identify the best fitting enterprise designs in terms of the more demanding twenty-first century context.
Table 6. Performance Summary – Global War on Terror Context.
Performance |
Machine |
Edge |
Simple |
Professional |
Divisionalized |
Adhocracy |
Cycle time |
313 |
220 |
375 |
342 |
308 |
446 |
Residual |
0.36 |
0.78 |
0.30 |
0.57 |
0.45 |
0.77 |
Table 6 summarizes results for this Global War on Terror mission- environmental context, and uses the same two performance measures as summarized in Table 5 above. Notice that the Edge design continues to exhibit the best cycle time performance (220 days), and in this mission-environmental context, it is much faster than the other enterprise designs are. Although such Edge cycle time performance is worse in this latter, more demanding mission-environmental context than it is in the former, Cold War context (i.e., 220 vs. 161 days), its performance degradation (47% increase) is nowhere near as severe as that experienced by the Machine Bureaucracy (94%), Simple Structure (123%), Professional Bureaucracy (122%), or Divisionalized Structure (96%). Hence the Edge design demonstrates that it is comparatively more robust to shifting mission-environmental contexts than these other enterprise designs are.
Alternatively, notice that the Edge design continues to exhibit the worst residual errors performance (0.78) of all these enterprises. As above, the Simple Structure exhibits the lowest error fraction (0.30), and as above, the venerable Machine Bureaucracy offers a relatively balanced combination of cycle time (313) and residual errors (0.36) performance. Hence the decision regarding the most appropriate enterprise design to fit this Global War on Terror mission-environmental context is similar to the one above pertaining to its Cold War counterpart: where speed is important, and errors can be tolerated, then the Edge appears to represent an appropriate enterprise design, but where speed is less important, and errors need to be minimized, then a different design would be suggested by the results.
Notice, however, that although the Machine Bureaucracy continues to provide balanced performance in terms of both cycle time and residual errors, unlike the Cold War case above, here in the Global War on Terror context, its cycle time performance (313 vs. 220 days) is much worse than that of the Edge enterprise design. For the Machine Bureaucracy to represent the superior enterprise design in this context, speed (i.e., as measured by cycle time) would have to be considered very unimportant to leaders and policy makers. Where asymmetric threats remain elusive and dynamic, the prudence of such consideration would be questionable: in some mission-environmental contexts, an enterprise may be forced to move very quickly—even though making many errors—in order to be effective.
This offers directly applicable, CT design guidance for the enterprise leader or policy maker. Through examination of these computational model results, we gain considerable insight into the comparative performance of six distinct enterprise designs as they operate in two distinct mission-environmental contexts. Using relatively high-fidelity computational models of the enterprise designs, we provide representations with comparatively very good descriptive power for practical C2 application, which represents a noteworthy extension to extant CT models, and hence a contribution of the present research. Further, by mapping the design space pertaining to these six archetypal enterprise designs and these two contrasting mission-environmental contexts, we develop new, empirical CT knowledge that can be used to identify the best enterprise design for a given—of shifting—set of contingencies.
Additionally, by measuring performance via two different metrics, the enterprise leader or policy maker gains new capability to select the most appropriate design, based not only on the contingent nature of the mission-environmental context, but also dependent upon the relative importance of mission speed versus residual errors. This represents a contribution of new CT-C2 design knowledge that emerges through computational modeling and experimentation. Such theoretically grounded—yet applied and empirical—enterprise design knowledge to inform the practice of C2 has never been published before the Gateau et al. (2007) article, and such capability to provide CT insight into important C2 practice is unprecedented in either “inside” or “outside” research.
Conclusion
As the metaphorical mind of the enterprise, command and control involves thinking, planning, sensing, responding, organizing, directing, and monitoring, and hence is comprised largely of activities in the cognitive and social domains. As such, C2 has represented a critical aspect of military planning and execution for millennia, and time-tested approaches to C2 in military organizations and processes remain prevalent in current practice. In contrast to these venerable approaches to military practice, however, scholarly research in the C2 domain remains divergent, and a noticeable chasm exists between well-established research and continuing C2 practice.
This is particularly the case with research in the area of long- and well-established Contingency Theory. Using terms appropriate for this audience, the central premise of CT is that no single enterprise design is ideal for all missions, environments, and contexts. Because military organizations have been and will continue to be required to undertake complex missions in a variety of diverse and challenging environments and contexts, one would expect to see C2 approaches that have, in the language of complexity, requisite variety, and that enable, in the language of C2 approaches, enterprise agility. At the very least, one would expect the military to be exploring non-traditional approaches to C2 vigorously, and one would expect for it to be making rapid progress.
Further, given the abundant theoretical and empirical CT research available for guidance, one would expect leaders and policy makers to redesign high-performance enterprises to fit shifting mission, environmental, and contextual circumstances better. Instead one sees that remarkably homogeneous, hierarchical, traditional, and often ill-fitting C2 approaches predominate the practice. The problem is that few CT scholars understand current C2 practice sufficiently well to apply such research directly, and few C2 researchers, analysts, leaders, and policy makers understand CT research sufficiently well to take advantage of the corresponding enterprise design opportunities. Even the fundamental terms used by members of the CT and C2 communities differ.
This expository article takes four important steps toward bridging the chasm between C2 practice and CT research. First, it summarizes the central tenets of CT in terms that can inform C2. Describing key background theoretical results from CT over the past half century, we illustrate how CT can inform enterprise design to address key contingencies such as technology (e.g., via the Perrow model) and environment (e.g., via the Duncan model), and we illustrate the extension through a 14-dimensional set of contingencies (e.g., via the Burton model).
Through this discussion, we explain how design knowledge embedded within theoretical models can be used to organize best for a particular contingency (i.e., to achieve the best fit), yet we highlight the limitations (esp. in terms of inadequate descriptiveness and fidelity of the two-dimensional models, unreasonably constrained the design space of the 14-dimensional model) of such relatively simplistic models. We also discuss the building blocks of enterprise design, and explain how computational modeling and experimentation can help to ameliorate the challenges of high-dimensional design spaces. This equips the C2 leader and policy maker to appreciate the power and applicability of CT to C2 practice, and it helps the CT scholar to appreciate some aspects of the C2 domain better.
Second, the article bridges several key terminological gaps between the CT and C2 communities. We reveal how concepts such as sensemaking and situational awareness are treated differently by researchers “inside” and “outside” of the military C2 domain, and we help to explain some of the historical and other bases for such differential treatment. We explain how the central premise of CT research can be applied to C2 practice, and articulate how the concept fit from the CT literature can be applied to C2 concepts such as incremental improvement and transformational change. This kind of linkage between literatures can help scholars from both “inside” and “outside” communities to enrich their dialog and enhance intercommunity research.
Further, we explain how C2 applies well beyond the military domain, and we establish some intercommunity research linkages between CT concepts such as organizations and design and rough C2 counterparts such as enterprises and C2 approaches, linkages that have not been made clear previously. We also draw from both the C2 and CT literatures to develop a definition for enterprise that itself helps to bridge the chasm, and we explain how understanding the implications of a rational design perspective can be helpful to the C2 leader and policy maker. Additionally, by introducing concepts such as orthogonality and design space, we help the C2 leader and policy maker to interpret the results of CT research studies better, and to appreciate both the power and complexity of enterprise design once high- fidelity, high-dimensionality models are developed.
Third, this article highlights state-of-the-art C2 research that develops new, empirical CT knowledge for enterprise design via computational modeling and experimentation. Summarizing current research to model and examine the behavior and performance of six archetypal enterprise designs across contrasting mission-environmental contexts, we illustrate how the corresponding computational models are rooted firmly in established theory, and how they provide great fidelity in terms of specifying and manipulating a diverse variety of enterprise designs. For instance, we summarize a set drawn from over 100 model parameters used to specify the six enterprise designs, and we show both how they draw directly from theory and how they are varied across each different design. This provides sufficient detail for the CT scholar to understand how theoretical concepts are being operationalized to specify computational enterprise models, and for the C2 leader or policy maker to understand the kinds of design elements that affect enterprise behavior and performance.
Additionally, we describe how a computational experiment is set up to compare the multidimensional performance of all six enterprise designs across a contrasting set of mission-environmental contexts: one associated with the Cold War era, another representing the Global War on Terror. Results of this computational experiment map out some key regions of the enterprise design space. They indicate how the most appropriate enterprise designs depend upon which measures of performance are deemed most important by leaders, policy makers, and other stakeholders, in addition to how well any particular enterprise design fits a given—or shifting—set of contingencies. This offers directly applicable CT design guidance for the enterprise leader or policy maker, in addition to the contribution of new CT-C2 design knowledge that emerges through such computational modeling and experimentation.
Fourth, this article outlines a research agenda that can guide both established and emerging scholars toward effective application to address practical C2 issues. Now that we have the computational modeling tools available, substantial effort is required to represent the structures and emulate the behaviors of diverse enterprises in the field. This will be important to calibrate models to mirror details of the myriad different enterprise designs reflecting practice in the field, and can be used to assemble, analyze, and catalog an array of diverse enterprise designs. Each such detailed design can be examined within the perspective of its corresponding class (e.g., design archetype) in the enterprise design space, and the cumulative learning attainable via such examination should be highly informative in terms of refining enterprise design as a rational and structured method.
Further, given the mixed results from our computational models in terms of comparative performance with respect to cycle time and residual errors, research is needed to understand better why the Edge design exhibits much greater error levels than many of the other enterprise designs do, as well as why the Edge is able to operate with greater speed—particularly in more demanding mission- environmental contexts—than the others are. With such understanding, the CT researcher will be able to explain comparative performance differences better, and the C2 leader and policy maker will be able to decide more prudently upon the most appropriate enterprise design for a particular mission-environmental context. Other performance measures (e.g., rework, coordination, backlog) are available for comparison across different enterprise designs and mission-environmental contexts as well.
Moreover, these performance results suggest that some kinds of hybrid enterprise designs (e.g., part Edge, part Machine Bureaucracy) may serve well to capitalize on the inherent speed of the Edge design while ameliorating the negative effects of its high error levels. Building upon the present research, for instance, one could experiment with hybrid computational models to examine their relative performance, and to identify which model parameters contribute toward both high-speed and low-error enterprise performance. The enterprise leader or policy maker could then test such hybrid design—perhaps on a small scale or in a training environment—in the field to assess its promise for large-scale implementation.
Additionally, substantial hypothesis testing of propositions developed by the computational models can be conducted on the operational enterprises that such models represent. Where a particular enterprise is performing relatively poorly in some mission-environmental context, for instance, enterprise leaders can strive to transform the enterprise to reflect a different design—in particular, a design identified via analysis of virtual prototypes. Performance of the resulting enterprise design can then be compared both with that of its operational predecessor in the field and with its virtual counterparts represented by computational models. This can provide a rich, cross-validated set of virtual and operational prototypes for analysis.
Further, this enterprise design research suggests rich potential for extension to focus on the process of enterprise change. That is, similar to the manner in which this present research uses computational models via virtual prototypes to identify the best fitting enterprise design, an extension to this work can use computational models of enterprise change processes to identify the best fitting approach to enterprise transformation. In other words, after using computational models to identify the best enterprise design for a particular context, such models may prove useful also to identify the best approach to changing from one enterprise design to another. This lies currently beyond the state of the art, yet it represents an exciting and active avenue for continued research along these lines.
Finally, even the basics of enterprise design—much less as informed and enabled by computational modeling and experimentation— remain confined largely to the research university and laboratory at present. To get the associated knowledge into the repertoires of enterprise leaders and policy makers, researchers need to adjust their classroom curricula and pedagogy to incorporate the principles and tools associated with enterprise design as a rational, integrated design problem. This suggests that curricula across several different professional schools (esp. Business and Engineering) will require re-examination, and that the bases of courses taught within such curricula will benefit through inclusion of the kinds of state-of- the-art knowledge and tools described in this article.
Despite these multiple contributions to new knowledge—particularly this substantial effort to bridge the chasm between CT research and C2 practice—there are limits to the amount of progress that can be made through a single article such as this, and hence limits to how much of the chasm can be bridged via this single study. It remains for other researchers—both “inside” and “outside” the military C2 community—to build upon the progress made through this present study, and to publish related articles that continue bridging the chasm.
For those on the “inside,” it is particularly important to embrace the theoretical models that have been developed and refined over the decades. It is all too common—and ignorant—for some C2 leader or policy maker to use his or her practical experience (yes, coupled often with substantial education as well) to “brainstorm” models, often with myriad, non-orthogonal variables and dimensions that are either redundant with or inferior to well-established models, variables, and dimensions that have been developed and refined through cumulative, peer-reviewed research recorded in the academic literature. Developing redundant models is arguably a waste of time and energy, particularly where such models are inferior to those articulated clearly in the extant academic literature. The C2 leader or policy maker needs only to consult such literature to become informed. The exposition of this article—coupled with the list of references below—provides excellent pointers to important places in the literature to begin.
For those on the “outside,” it is particularly important to embrace the practice of C2, including the messy details that defy descriptive and fidelity representation via simplistic models. It is all too common—and ignorant—for some CT researcher or other academic to use his or her scholarship (yes, coupled often with substantial practical experience as well) in attempts to apply models, often with unrealistic, theoretical assumptions and relationships that are either irrelevant to or incorrect for established practice in the field. Attempting to apply irrelevant models is arguably a waste of time and energy, particularly where such models are incorrect in terms of characterizing the structure, behavior, or performance of real-world C2 in practice. The CT researcher or other academic needs only to get out of the office and into the field to observe C2 organizations and processes, and into joint academic-practitioner symposia to interact with C2 leaders, policy makers, and professionals directly in order to become informed. The exposition of this article—coupled with the theoretically grounded models above—provides an excellent basis for such field research and joint interaction to begin. This represents an exciting time to be involved with enterprise design.
Footnotes
- The research described in this article is funded in part by the Command & Control Research Program, Center for Edge Power.
- Throughout this background section, we use the term organization extensively instead of enterprise. This is consistent with most of the scholarly literature that we cite and draw from. We introduce and define the enterprise, and relate it to the organization, in the next section.
- As a note, the NATO SAS-050 study produced a C2 conceptual model that many find useful with hundreds of variables and non-orthogonal variables related to C2 approach and performance.
- We say “relatively well-validated” here, because although this modeling environment has been validated extensively in multiple domains (esp. engineering projects), our adaptation to the C2 domain is relatively recent, and the corresponding validation activities are ongoing still.
References
- Alberts, D.S. personal communication, April 25, 2007.
- Alberts, D.S., J.J. Garstka, R.E. Hayes, and D.T. Signori. 2001. Understanding information age warfare. Washington: CCRP.
- Alberts, D.S., and R.E. Hayes. 2003. Power to the edge: Command ... control ... in the information age. Washington: CCRP.
- Alberts, D.S., and R.E. Hayes. 2006. Understanding command and control. Washington: CCRP.
- Alberts, D.S., and R.E. Hayes. 2007. Planning: Complex endeavors. Washington: CCRP.
- Aldrich, H.E. 1979. Organizations and environments. Upper Saddle River, NJ: Prentice Hall.
- Argote, L. 1982. Input uncertainty and organizational coordination in hospital emergency units. Administrative Science Quarterly 27(3): 420-434.
- Ashby, W.R. 1960. An introduction to cybernetics. London: Chapman & Hall.
- Burns, T., and G.M. Stalker. 1961. The management of innovation. London: Havistock.
- Burton, R.M., G. DeSanctis, and B. Obel. 2006. Organizational design: A step-by-step approach. Cambridge, UK: Cambridge University Press.
- Burton, R.M., and B. Obel. 1998. Strategic organizational diagnosis and design: Developing theory for application. Boston: Kluwer.
- Chandler Jr., A.D. 1962. Strategy and structure: Chapters in the history of the American industrial enterprise. Cambridge, MA: MIT Press.
- CCRP, Command and Control Research Program. 2007.
http://www.dodccrp.org/index.html (accessed 29 April 2007)
- Ciborra, C.U. 1996. The platform organization: Recombining strategies, structures, and surprises. Organization Science 7(2): 103-118.
- Davidow, W.H., and M.S. Malone. 1992. The virtual corporation. New York: Harper Business.
- DoD JCS. U.S. Department of Defense Dictionary of Military Terms.
http://jitc.fhu.disa.mil/jitc_dri/pdfs/jp1_02.pdf (accessed March 2007)
- Donaldson, L. 1987. Strategy and structural adjustment to regain fit and performance in defence of contingency theory. Journal of Management Studies 24(1): 1-24.
- ———. 2001. The contingency theory of organizations. Thousand Oaks, CA: SAGE Publications.
- DSB, United States. 1978. Defense Science Board, Task Force on Command and Control Systems. Report of Defense Science Board Task Force on Command and Control Systems. Washington: Office of the Under Secretary of Defense Research and Engineering.
- Duncan, R.B. 1979. What is the right organization structure? Organizational Dynamics Winter 1979: 59-79.
- Galbraith, J.R. 1973. Designing complex organizations. Boston: Addison-Wesley Longman Publishing Co., Inc.
- ———. 1977. Organization design. Reading, MA: Addison-Wesley Publishing.
- Gateau, J.B., T.A. Leweling, J.P. Looney, and M.E. Nissen. 2007. Hypothesis testing of edge organizations: Modeling the C2 organization design space. Paper presented at the 12th International Command & Control Research & Technology Symposium in Newport, RI.
- Hamilton, R.T., and G.S. Shergill. 1992. The relationship between strategy-structure fit and financial performance in new zealand: Evidence of generality and validity with enhanced controls. Journal of Management Studies 29(1): 95-113.
- ———. 1993. The logic of New Zealand business: Strategy, structure and performance. Auckland, New Zealand: Oxford University Press.
- Hannan, M.T., and J. Freeman. 1977. The population ecology of organizations. American Journal of Sociology 82: 929-964.
- Harvey, E. 1968. Technology and the structure of organizations. American Sociological Review 33(2): 247-259.
- Hevner, A.R., S.T. March, J. Park, and S. Ram. 2004. Design science in information systems research. MIS Quarterly 28(1): 75-105.
- Hutchins, E. 1995. Cognition in the wild. Cambridge, MA: MIT Press.
- Keller, R.T. 1994. Technology-information processing fit and the performance of R&D project groups: A test of contingency theory. The Academy of Management Journal 37(1): 167-179.
- Lawrence, P.R., and J.W. Lorsch. 1967. Organization and environment: Managing differentiation and integration. Boston: Harvard Business School Press.
- Leavitt, H.J. 1965. Applying organizational change in industry: Structural, technological and humanistic approaches. In Handbook of Organizations, ed. J. March. Chicago: Rand McNally. 1144-1170.
- Levchuk, Y.N., K.R. Pattipati, and D.L. Kleinman. 1999. Analytic model driven organizational design and experimentation in adaptive command and control. Paper presented at the 12th International Command & Control Research & Technology Symposium in Newport, RI.
- Leweling, Tara A., and Mark E. Nissen. 2007. Defining and exploring the terrorism field: Toward an intertheoretic, agent-based approach. Journal of Technology Forecasting and Social Change 74: 165-192.
- Miles, R.E., and C.C. Snow. 1978. Organizational strategy, structure, and process. New York: McGraw-Hill.
- Mintzberg, H. 1979. The structuring of organizations. Englewood Cliffs, NJ: Prentice-Hall.
- ———. 1980. Structure in 5’s: A synthesis of the research on organization design. Management Science 26(3): 322-341.
- Mohr, L.B. 1971. Organizational technology and organizational structure. Administrative Science Quarterly 16(4): 444-459.
- Nissen, M.E. 2005. Hypothesis testing of edge organizations: Specifying computational C2 models for experimentation. Paper presented at the 10th International Command & Control Research Symposium in McLean, VA.
- Nissen, M.E., and R. Buettner. 2004. Computational experimentation: Bridging the chasm between laboratory and field research in C2. Paper presented at the 2004 Command and Control Research and Technology Symposium in San Diego, CA.
- Orr, R.J., and M.E. Nissen. 2006. Hypothesis testing of edge organizations: Simulating performance under industrial era and 21st century conditions. Paper presented at the 11th International Command and Control Research and Technology Symposium in Cambridge, UK.
- Ouchi, W.G. 1981. Theory Z: How American business can meet the Japanese challenge. Reading, MA: Addison-Wesley.
- Pennings, J.M. 1975. The relevance of the structural-contingency model for organizational effectiveness. Administrative Science Quarterly 20(3): 393-410.
- Perrow, C. 1967. A framework for comparative analysis of organizations. American Sociological Review 32: 194-208.
- Pigeau, R. and C. McCann. 2002. Re-conceptualizing Command and Control. Canadian Military Journal 3(1): 53-64.
- Scott, W.R. 2003. Organizations: Rational, natural, and open systems. Upper Saddle River, NJ: Prentice-Hall.
- Simon, H.A. 1996. Sciences of the artificial. Cambridge, MA: MIT Press.
- Sonnenwald, D.H. and L.G. Pierce. 2000. Information behavior in dynamic group work contexts: interwoven situational awareness, dense social networks and contested collaboration in command and control. Information Processing & Management 36(3): 461-479.
- Thompson, J. D. 1967. Organizations in action: Social science bases in administrative theory. New York: McGraw-Hill.
- van Aken, J.E. 2004. Management research based on the paradigm of the design sciences: The quest for field-tested and grounded technological rules. Journal of Management Studies 41(2): 219-246.
- Walls, J., G. Widmeyer, and O. El Sawy. 1992. Building an information system design theory for vigilant EIS. Information Systems Research 3(1): 36-59.
- Weber, M. 1947. The theory of social and economic organization. trans. A.M. Henderson and Talcott Parsons; ed. Talcott Parsons. London: Free Press of Glencoe, Collier-Macmillan.
- Weick, K.E. 1995. Sensemaking in organizations. Thousand Oaks, CA: Sage.
- Weick, K.E. and K.H. Roberts. 1993. Collective mind in organizations: Heedful interrelating on flights decks. Administrative Science Quarterly 38: 357-381.
- Woodward, J. 1965. Industrial organization: Theory and practice. New York: Oxford University Press.