The push towards modularity in mili-tary organizational structures is an exten-sion of the goal for military transforma-tion in the post-Cold War period. Modu-larity is thought to be effective in provid-ing the agility to quickly deploy and sus-tain forces involved in missions around the world, and develop forces with great flexibility that can be “tailored” to spe-cific mission types. Yet a consensus on how this type of organizational design is to be accomplished has not been reached. Advanced militaries — including the United States, Canada, France, etc. — are all heading in similar yet different directions in regards to the concept of modularity.

Most of the practical knowledge about modularity comes from advances in the computing industry.1 Starting from developments in modular product design, generalized theories of modularity have been applied across a number of fields including physics, chemistry, biology, social science, neuroscience and of course organizational design. This final application has spun off whole fields of management research dealing with “Complex Adaptive Systems” and “stra-tegic flexibility.”

This study will examine the funda-mental principles of modularity as it is presented in the literature. Each of the major principles described below are a large dedicated research field unto them-selves. The purpose is to introduce these concepts in a holistic fashion and begin to apply them in a military context. Thus this study serves as a broad map plotting the major contours in the field of modu-lar systems design to act a gateway for further research in the pursuit of military modularization.

By analysis of various models of military modularity, through the lens of specific modular systems design princi-

ples, this study endeavors to illuminate the fundamentals of modularity by ex-ample. The analysis examples presented in the examples are by no means exhaus-tive, and many real-world problems such as personnel issues (ie. recruitment, re-tention, promotion, etc.) are left to the operational researchers that will imple-ment a modular system in the future. What the models explored should illus-trate is that modularity is not necessarily binary, but can be represented by a whole spectrum of possibilities. Certain princi-ples may have to be loosely obeyed or outright ignored to develop a functional organization for the real world. That said, the final section of the study will propose a military modular organization that strictly adheres to the principles of modular design. Hopefully, the principles presented in this work will be observed by those intending to reform their mili-tary organizations.

Why modularity?In a rapidly changing environment,

an organization must be flexible. A modular firm can quickly link the re-sources and capabilities of many organi-zations to deal with a changing environ-ment flexibly.2 Modularity endows the ability for parallel work; since modules are largely independent from one another a module can be repaired or upgraded without impacting the rest of the system. Thus a modular system is tolerant of uncertainty, meaning that elements of a modular system's design can be changed after the fact. This makes modular sys-tem designs “future proof,” and an ideal structure for organizations in an unpre-dictable environment. Furthermore, modularity allows for rapid innovation. In a decentralized network of modules conducting parallel work, many alternate approaches to a complex problem can be

tested simultaneously. There are also more entry points for new ideas in a modular system. Thus, a modular system can progress and improve faster than a closed, vertically integrated system.3

The recent push for modularity in military circles follows the modular evo-lution that has been taking place in the business sector for the past few decades. A recent survey conducted by the META Group asked 308 subjects about their opinion on becoming an “adaptive or-ganization,” defined as an organization that is “flexible and dynamically change-able, in both business processes and technology.”4 The survey showed that firms feared falling behind competitors, and saw adaptive solutions as a method to reduce costs and increase revenues. 57% of firms surveyed intended to be-come an adaptive organization. Another 23% had instituted broad initiatives to become more adaptive, and 13% consid-ered themselves already adaptive. Only 7% of firms covered in the survey had no plan to become adaptive.

The military intends to take full ad-vantage of the benefits of flexibility. The Canadian Forces’ concept of the Army of Tomorrow requires a “fluid force struc-ture" that may be "configured as required to meet a specific mission or aim.”5 A forced tailored to a specific mission is high level concept not only for Canada, but for Australia and New Zealand future forces as well.6 The French began to transform their forces in 1996 disbanding standing divisional organizations and replacing them with four two-star EMF (État Major des Forces) force headquar-ters staffs, capable of controlling two to four brigades.7 The US Army modular redesign is intended to address “the need for a more responsive, deployable, joint, and expeditionary force,” but also aims at providing a larger pool of deployable

Chad KOHALYK Fundamentals of Modularity

1 Baldwin and Clark (1997), pp. 160.2 Sanchez and Mahoney (1996), pp. 68.3 Langlois and Robertson, pp. 84.4 META Group, pp. 2.5 Godefroy, pp. 54.6 See DLSC Figure 1.7 Pengelley (2000).

1

Alternative force structures for the future

Fundamentals of Modularity

units.8 With a larger number of smaller units, the US can deploy and rotate units in a parallel fashion without detriment to the overall strategic mission. In the post-Cold War era it is natural that advanced military forces would aim to follow the business world in developing flexible organizations. But the military has a long tradition of rigid hierarchy, and moving to a modular system design will be a more difficult experience than the busi-ness world.

What is modularity?Modularity is a set of principles for

managing complexity. The world is full of complex systems from organisms and ecosystems to electronics and social sys-tems. One way to manage these systems is to group elements together into smaller subsystems. Herbert Simon argued that “complexity frequently takes the form of hierarchy.”9 He saw hierarchical organ-izational structures everywhere: cells, tissues, atoms, molecules, planetary sys-tems, galaxies, businesses, governments, universities, books, music and technol-ogy. A modular system on the otherhand, while it may resemble a hierarchy, does not have an authoritative structure. In a formal organization each subsystem will have a “boss” responsible for those be-low and answering to those above. In a modular system subsystems are not nec-essarily subordinate.

Modularity is a special form of sys-tems design in that it intentionally cre-ates components that have a high degree of independence. It emphasizes the parts of a system over the system as a whole. Modules interact with one another on a weak basis known as “loose coupling.” Since interdependence between subsys-tems is minimal, the system as a whole will not suffer if some subsystems are damaged or are being upgraded. Simon used a parable to illustrate the concept of decomposability.

The story, a favourite of modularity researchers, has two watchmakers named Hora and Tempus. Their very fine

watches were highly sought after, thus Hora and Tempus were constantly inter-rupted by constant calls from new cus-tomers during their work. The watches were complex affairs made from about 1000 parts each. Tempus’s watch design was highly integrated, so much so that if he was interrupted during assembly — say, to answer the phone — it immedi-ately fell to pieces. Hora on the other-hand, had designed his components to be put together in subassemblies of about ten parts each, which would then be combined into a larger subassembly. Ten of these larger subassemblies would then constitute the entire watch. Hence, when Hora put down a partially assembled watch to answer the phone, he only lost a small part of his work. Consequently Hora could assemble his watches in a fraction of the time it took Tempus.10

The interdependency of Tempus’s watch design caused his watches to fall apart, where as Hora’s decomposable design proved resilient in the face of disruption. Furthermore, based upon Simon's work, Langlois states:11

In a nondecomposable system, the successful operation of any given part is likely to depend on the characteristics of many other parts throughout the system. So when such a system is missing parts (because it is not finished, for example, or because some of the parts parts are damaged), the whole ceases to function and the system becomes evolutionary shark bait. In a decomposable system, by contrast, the proper working of a given part will de-pend with high probability on the characteristics of other parts within the subassembly — but will depend with relatively lower probability on the characteristics of parts outside of the assembly.

Furthermore, Langlois points out that in a nondecomposable system any com-

ponent that fails will cause a total sys-tem breakdown, thus increasing the in-centive to ensure every part is of the highest quality, resulting in higher costs. Bottlenecks and inconsistencies within a nondecomposable system are also highlighted.12 If the effectiveness of a component depends on the design of another, the system needs to be redes-igned to minimize this dependency, pos-sible by combining the components.13

Interdependency in mechanical struc-tural designs is similar to information transmission — or communication — in formal organizational structures or social systems. An example would be organiz-ing teams for a project. If the project tasks are partitioned in a decomposable manner, each research and development team will work in parallel without much communication between teams. This is the basis of object-oriented approach to computer programming.

If the project is not organized in a decomposable manner interdependency will be high as each team will constantly have to be receiving and processing in-formation about what every other team is doing. To illustrate this point Langlois gives the example of the IBM System/360 project manager who “insisted on a conscious attention to interdependencies and a high level of communication among all participants.” Copies of a pro-ject workbook, which constantly had to be maintained, were distributed so each worker could determine how changes elsewhere would impact his or her part of the overall project. Soon the work-book was five feet thick, with daily changes measuring 2 inches of paper. Technology came to the rescue and the team changed to microfiche to maintain the project work, yet this didn't solve the problem of excessive time managing information rather than developing the software. The lesson is that “a nonde-composible system incurs high commu-nications cost.”14

David Parnas invented a key concept in solving interdependency issues be-

Chad KOHALYK Fundamentals of Modularity

8 Feickert, pp. 2 and 13.9 Simon (1962), pp. 16.10 Ibid, pp. 19.11 Langlois (2000), pp. 5.12 Ibid, pp. 13.13 Simon (1962), pp. 41.14 Ibid, pp. 6-7.

2

tween teams working on a project called "information hiding."15 He argued that modularization of large projects should not be based on a simple flow chart ap-proach, but should concentrate on mini-mizing interdependencies. If knowledge is hidden within a module, that knowl-edge cannot affect other parts of a system and therefore need not be communicated to the rest of the system. Thus a project is ideally decomposed into a series of task modules that have no interdepend-encies. Furthermore, each module is not privy to the inner-workings of every other module. Only the function of an individual module's task is known. This result combines with all other module results to create the completed project.

Design principlesBaldwin and Clark took the experi-

ences of IBM and developed a set of general principles for modular systems design.16 Designers decompose a system into modules by partitioning information into visible design rules and hidden de-sign parameters. The visible design rules (or visible information) have three categories:17

• An architecture, which specifies what modules will be part of the system and what their functions will be.

• Interfaces that describe in detail how the modules will interact, including how they fit together and communicate.

• Standards for testing a module's conformity to the design rules, and measuring performance relative to other modules

These visible design rules must be shared widely across a modular system. The hidden design parameters on the other hand, are decisions that do not af-fect the design beyond the local module. This information need not be shared, and thus permits flexibility as the parameters can be chosen late and changed often.

Thus in an ideal modular system each module must conform to the visible de-sign rules, but the actual structure/design of individual modules is not important.

An illustrative example of such a system would be a company manufactur-ing a product that outsources the con-struction of components to contractors. The company relates the required func-tion of the component, how the module must interface with the rest of the sys-tem, and any standards that must be obeyed. Manufacturers give the suppliers the interface specifications and encour-age the suppliers to design the compo-nents as they see fit. Although some col-laboration may take place, the underlying design parameters of the component are hidden information.18 The company is not concerned with the inner workings of the component (or the contractor’s or-ganizational structure for that matter) as long as it can complete its function and adhere to all the standards necessary. If a second contractor developing a compo-nent with the same function and interface makes the component smaller and/or faster, the company may replace the first contractor without a hitch in production. Alternatively, the company could even keep the first contractor in reserve in case of supply chain problems or other disasters.

Firms that provide services, rather than tangible products, will modularize their service outlets creating more com-petitive, specialized service while cutting costs. Instead of providing all banking services across every branch at high cost, financial institutions will focus certain services where they are most likely to be accessed. This type of market-dependent service optimization offers a high degree of expertise in key areas which can be altered or upgraded without changes needed across every single branch, which would be costly to implement.

One final principle for designing modular systems is encapsulation. In decomposing a system finding the opti-mal encapsulation boundaries can be

extremely challenging. How far down the hierarchy does one devolve auton-omy? This question must be answered by the system architecture.

Current model analysisIn the post-Cold War era militaries

have felt the need to restructure their forces to deal with the current and future security environment. America, Britain, Canada, Australia and New Zealand share a common outlook on the future security environment. ABCA planners see themselves as having to “operate within an environment that spans from peace to war” include some of the fol-lowing characteristics:19

• Irregular warfare will be more prominent

• Conflicts will be more protracted• Emphasis on non-state as opposed

to state actors will increase• Threats will be more transnational

and cross border in character• Defeating armed forces will be less

significant than affecting an oppo-nents will and resolve

• Operations in complex terrain will increase

• The focus on humanitarian and reconstruction requirements, as part of stabilization operations will rise

• The use of non-scripted strategies and tactics to overcome problems, especially in a networked envi-ronment, will gain in importance

• All levels of command and indi-viduals will be networked

In such an unpredictable environ-ment, reforming force structure to lever-age the inherent flexibility of a modular organizational design seems a logical conclusion. In the following sections we will examine the US and Canada’s push for modularity, and determine how well the proposals adhere to the design prin-ciples discussed above. The following analysis is not exhaustive and only cov-

Chad KOHALYK Fundamentals of Modularity

15 Parnas (1972).16 Baldwin and Clark (1997), pp. 151.17 Baldwin and Clark point out that in the literature some writers refer to the visible design rules as a whole as either “the architec-ture,” “the interfaces” or “the standards.” In the examples presented below I will adhere to the terminology developed by Baldwin and Clark.18 Langlois (2000), pp. 38.19 See DLSC’S "The ABCA Future Concept."

3

ers the surface attributes of each system. The intention is to apply the design prin-ciples in a military context and exem-plify the spectrum of modularity includ-ing what degree both countries plan to take their modular design.

Modularization of the US ArmyThe US Army is well down the path

of modularizing its forces. Since World War II the Army has been organized into divisions. The division is the largest permanently-organized combat unit and is made up of some 10,000 to 18,000 personnel. Divisions are made up of three brigades of 3,000 to 5,000 soldiers and a number of smaller support units. The Army’s inability to quickly and ef-fectively deploy such a large organiza-tion as the division has drawn much criticism.20 Calls were made for a redes-ign of the Cold War-focused Army, and led to the decision to decompose Army organizational structure down to the bri-gade level. In 2003 the Army decided to push ahead in a modular redesign of it’s force structure with the goal of fully transforming its land forces by FY2009. This transformation will affect over 100,000 active and reserve personnel.21

The redesign will transform the Army’s eight brigade designs into three brigade Units of Action (UA) — Ar-moured, Infantry and Stryker. These UAs will replace the division as the primary component of the US Army. These three types of UA will be augmented by “Sup-port Units of Action” which can range in size from a brigade to a platoon (30 sol-diers). The Army has identified five types of support UAs including: aviation; sustainment; maneuver enhancement; fires; and reconnaissance, surveillance and target acquisition.22 Also, UAs could have access to Army aviation units of action as the mission requires, helping to devolve corps assets to the lowest levels. Every element of the UA will linked to a networked battle command system. The structure of each UA is as follows:23

Armoured UA(approximately 3,800 soldiers)

• One Brigade Troops Battalion in-cluding the UA staff; military po-lice (MP) and security platoons; a signal company; a military intelli-gence company; and a joint fire coordination cell (to coordinate Air Force, Navy, and Marine Corps fires in support of the UA);

• One Armed Reconnaissance Bat-talion consisting of three recon-naissance troops and one surveil-lance troop and a forward support company;

• Two Combined Arms Battalions with two tank companies and two mechanized infantry companies in each battalion as well as an engi-neer and a forward support com-pany each;

• One Fires Battalion consisting of a target acquisition cell, and two batteries of self-propelled artillery and a forward support company; and

• One Support Battalion.

Infantry UA(approximately 3,000 soldiers)

• One Brigade Troops Battalion in-cluding the UA staff; a military police (MP) platoon; a signal com-pany; an intelligence company, an engineer company; and a joint fires cell;

• One Reconnaissance, Surveillance, and Target Acquisition (RSTA) Battalion with both motorized and dismounted reconnaissance units, a surveillance unit including ground radars, sensors, and unmanned aerial vehicles; and a forward sup-port company;

• Two Infantry Battalions consisting of three rifle companies and one combat support company each; and a forward support company capa-ble of moving one company by truck;

• One Strike Battalion consisting of a target acquisition platoon, an unmanned aerial vehicle unit, and

two batteries of towed artillery; a forward support company; and

• One Support Battalion consisting of a transport platoon capable of

• moving almost an entire infantry battalion by truck.

Striker UA(approximately 4,000 soldiers)

• A headquarters company, a signal company, and a military intelli-gence company;

• Three Stryker Motorized Infantry Battalions with one headquarters and three Stryker motorized infan-try companies each;

• A Reconnaissance and Surveil-lance Battalion;

• An Artillery Battalion; • An engineer company; • An anti-tank company; and • A Support Battalion.

All of these UAs, both combat and support, will be combined under a Unit of Employment (UE) — a special headquarters unit formed from the cur-rent division headquarters. Each UE will have the capability to command up six UAs including combat and support units. The new staff structure allow brigades to conduct operations on their own, by vir-tue of the commander’s intent, enabling a commander to carry out more decentral-ized operations.24

The US Army’s modularization seems to be fairly developed along the spectrum of modularity vis-à-vis the de-sign principles of modular systems de-sign. The system architecture has deter-mined the need for three types of mod-ules and their functions. Though how modules interact with one another is un-clear, each module (UA) must interface with a UE in the same way. Besides equipment specifications and possibly personnel requirements (for deployment considerations), the standards for meas-uring a module’s performance are un-clear from the accessible data. The only design principle that the US Army is in direct violation of is hidden design pa-rameters. Each module exhibits a highly specific structure as determined by a

Chad KOHALYK Fundamentals of Modularity

20 Feickert (pp. 3) notes that, “Many experts consider the Army’s 1999 controversial Task Force Hawk deployment to Kosovo and Albania as the event that triggered the Army’s transformation. ... The most often cited criticism was that it took the Army more than 30 days to deploy 28 Apache attack helicopters from their bases in Germany to Albania and when they finally arrived, they were unable to conduct combat operations due to training and equipment deficiencies.”21 Ibid, pp. 20.22 Ibid, pp. 7.23 From the Congressional Research Service’s report on the Army’s Modularization, Feickert, pp. 8-10.24 Steele (2004).

4

central authority. This will adversely impact the organization’s flexibility, as any changes will have to be implemented across the entire system as defined by policy. Furthermore, the architecture-defined modules functions may be too general, though the support UA’s exhibit a much more specialized approach (as well as looser restrictions on hidden de-sign parameters such as size of unit).

Canada’s Army of TomorrowModularity is much less defined in

the Canadian Forces, but is one of the enabling concepts for Canada’s Army of Tomorrow project even if in the very early stages of conceptualization.25 One proposal for a “Tactical Self-Sufficient Unit” (TSSU) groups capabilities based

on the Canadian Army’s five operating functions: Command, Act, Shield, Sense and Sustain. (diagram below)

The base unit of organization (ie. module) is a uniform TSSU — of an unspecified size — which contains a broad range of specialized information. This is in contrast to the US model which has developed three optimized units of action that provide a particular combat function. Canada’s modularity has the advantage to “be configured as required to meet a specific mission or aim, allow-ing the commander to only take what he/she needs for a given task without com-promising the overall integrity of the combined effects that TSSUs can de-liver.” Unfortunately this is a misunder-standing of the principle of decompos-ability. Modules should not be split up,

as they are by definition the base build-ing blocks of a larger system. In the Army of Tomorrow’s Force Employment concept document modular structure “should be designed to strengthen cohe-sion [and] discipline.” Rending the base unit of organization would negatively impact cohesion.

The TSSU model violates some of the design principles for modular sys-tems. The architecture does not specify a function for the module. Devolving the base unit of organization to the five op-erating functions could achieve the con-figuration requirements sought, and sat-isfy the architecture design rule. Inter-faces are not specifically addressed in this model, but like the US Army design Canada intends to link all units through a Network to “achieve situational under-standing through a Common Operation Picture.”26 Standards for measurement are also not addressed. Like the US Army model the TSSU has specified internal parameters. The TSSU has an advantage here, as it has specified only functions and not structure. Specific numbers of soldiers etc. are not defined, which conforms with the principle of hidden information. This also supports the argument to devolve the encapsula-tion of the module below the level of the TSSU, possibly to the operating func-tions or lower.

A model proposalWhat would an organizational model

that strictly conformed to the modular systems design principles illustrated

Chad KOHALYK Fundamentals of Modularity

25 Godefroy, pp. 54.26 Ibid, pp. 34.

5

above? Using the Canadian Forces as a test I will present a thumbnail sketch to explore some of the broad design choices that could be made. First we will begin with the visible design rules: architec-ture, interfaces and standards.

Visible design rulesThe architecture would determine the

functions of each module. Currently the Canadian Forces are organized into dif-ferent services (Air Force, Navy, Army) with specific capabilities. Instead of or-ganizing along the lines of capability, modules have to be formed based on function. A good example of this is Spe-cial Operations Forces. Special Opera-tions might represent the most modular organization in the Western military sphere, not only in their manner of task-based organization, but also in their in-teractions with other units in the field. SOF are formulated and trained to pro-vide a specific function including uncon-ventional warfare, counter-terrorism, reconnaissance, direct action and foreign internal defense. This example could be followed in designing the architecture for a fully modular conventional force. Rather than air, land or sea capabilities, certain mission types such as direct ac-tion, force protection, civil affairs etc. would become the new basis for organi-zation. The point is to design modules that do a specific job well, rather than module that can do every job with medi-ocrity. This is similar to what the US has done, with it’s Infantry, Armoured and Stryker Units of Action, but taken further along the spectrum of modularity. Mis-sions with a high market value, such as direct action, will require a number of modules providing that service. Other functions may only require a small num-ber of modules providing that service. Some modules might be tasked with a function for a specific region of the world. Theoretically there could be doz-ens of functions served by hundreds of modules.

Standards for performance (measures of effectiveness) would be instituted to determine whether or not a module is improving or providing satisfactory serv-ice. This provides healthy market compe-tition between modules, and also pro-vides a tracking system for innovation.

Furthermore, certain equipment and training standards will have to be insti-tuted to maintain flexibility in the face of disruption.27

Various types of interfaces will also have to be developed. A centralized command interface — as instituted by the US Army’s Units of Employment — may offset command and control issues. Other types of interfaces can and should be instituted. Each module should not necessarily have only one type of inter-face. Some modules may have more in-terface types than other modules. The number of interfaces does not have to be uniform, but the type of interface should be standardized and kept to a minimum to avoid confusion. Some examples of interface rules include how two modules work in conjunction in absence of that control element, or how modules share knowledge across the system without overtaxing knowledge management processes.

Hidden design parametersThe principle of hidden information

holds that the modules need to minimize interdependency by keeping certain knowledge hidden. This knowledge can-not affect the rest of the system, and therefore need not be communicated. The structure of each module is part of that hidden information. As each module must provide a specific and specialized service — in the interest of efficiency — each module should not be restricted by architecturally defined standards on characteristics such as size or capability. Here is where the explicit structure of the US Army’s UAs violates the modularity design principles. Yet the UAs also pro-vide an excellent example in showing

that uniformity has no place in modular-ity. The combat and support UAs are of all different sizes. Encapsulation may be different among modules. Unfortunately, due to the nature of the service organiza-tion of the US military, the modules have been limited in terms of capability.

Currently the Canadian Forces are organized into three major services and a number of guilds within the Army that reflect a centralization of capability (see diagram above).28

Functions cross capabilities. In a strictly modular system modules will require whatever capability is necessary to complete their function. For example direct action may require close air sup-port or joint fires support from naval platforms. Under the design principles it is illogical to separate these capabilities into different modules, as they are highly dependent on one another.29 Thus they need to be rolled into one module, and train together. Function-based modules will draw on capabilities across the serv-ices, will replicate other modules and be of varying sizes (see diagram next page).

In the diagram above, Module A pro-vides a full spectrum direct action func-tion that utilizes a joint fires capability from both air and sea. Modules B and K provide similar functions but are lighter, possibly rapid attack modules. Modules G and H provide similar functions across a short span of the capabilities spectrum, namely Engineers and Infantry. These could be reconstruction teams, and num-ber only a few dozen soldiers. Module D could provide a sea-based power projec-tion function. Note that this diagram is for illustrative purposes, and modules designed in this matter need not be con-

Chad KOHALYK Fundamentals of Modularity

27 Sheffi, Chapter 11 pp. 183-193.28 I leave special operations forces out of this diagram because in general military modular reform targets conventional forces. Fur-thermore, special forces tend to be quite modular inherently due to their task-focused orientation.29 This lesson has also been learned by US Special Operations Forces. The lack of special operations pilots during Operation Eagle Claw is considered one of the prime reasons for failure. Subsequently, United States Special Operations Command (USSOCOM) was designed with an integrated air capability with pilots who trained to SOF standards. See Marquis for more on USSOCOM.

6

tiguous. A module combining Navy + Infantry + Air Force is entirely conceiv-able. Furthermore, more specialized ca-pabilities within the guilds could also be first order capabilities under a modular system.

By developing modules across the major capabilities of the Canadian Forces new capabilities could be formed in new and inventive ways, demonstrat-ing the innovation inherent in decentral-ized modular systems.

Once a modules is created, its mem-bers must train together constantly, per-fecting their function. Various modules with the same function might innovate in novel ways, developing new strategies and tactics for completing their function more efficiently. Joint exercises between modules of the same function, or mod-ules of different functions as part of a task force will be conducted to exercise inter-module interface protocols.

In order to increase effectiveness, social and task cohesion, modules will be longterm structures requiring personnel on a longterm basis. Personnel will be posted to a module for most of their ca-reer. This way the strong ties among module members will engender strong leader/follower relationships, and fur-thermore soldiers will have a more stable home life, empowering them further.

This model proposal is by no means exhaustive and is meant to be a broad take on what a strictly modular military might look like. Following are only two of the many issues that need to be con-sidered when transforming the military into a 21st century organization.

Strategic lift presents a design prob-lem. Should it be part of it’s own mod-ule, providing that function for a number

of other modules? Or should it be inte-grated into individual models them-selves? This is the decision of the system architecture, which defines the identity/function of the individual module. If a certain module’s role is as a rapid de-ployment unit, strategic lift is part of its identity and should be logically included into that module. If a module’s function is not highly dependent on strategic lift (eg. reconstruction teams) then they could be serviced by an exclusively air-capable module specifically tasked with the function of strategic lift.

This goes against the Cold War era logic of cutting overall costs by consoli-dating capabilities and preventing each service from, for example, having its own air capability. With a fully modular design there will no longer be an over-arching air service, and replicating air capability across a number of modules is good for resiliency as it provides redun-dant capacity in case of disruption.30

Information sharing is also an obsta-cle that needs to be overcome. Modular systems design endeavors to decompose tasks in such a manner than they reduce the need for communications between modules, lowering interdependencies and reducing communications costs. This counters basic tenets of Network En-abled Operations (NEOps). NEOps is a common high-level operating concept across a number of western allies which attempts to achieve a networked force with a high degree of information shar-ing, increasing situational awareness leading to novel collaboration and self-synchronization.

As Simon (1962) noted the interac-tions within subsystems will far out-weigh interactions between subsystems.

A highly internally networked module is a desirable thing, but inter-module networking will be determined by inter-face rules. The Soldier Information Re-quirements (SIREQ) Technology Dem-onstration Project has shown the bene-fits of increased situational awareness through networked information systems on a small scale, but larger scale ex-perimentation may be necessary. Com-panies like Dell, UPS and Toyota con-tinuously transmit information through-out their organizations, but this infor-mation is targeted at management staff, rather than the lowest individual.31 To prevent “stove pipes” of information, interface rules governing information sharing will have to be worked out, a

task that will be much easier once interdependency-free modules are de-signed.

Attaining a modular force structureTransforming the Canadian Forces

into a modular structure resembling the above model will be nothing short of revolutionary. Considering the character-istics of the future security environment, Canada’s military would be well-served by the flexibility afforded by a modular organizational structure. One strategy for ensuring a more evolutionary transfor-mation could be assigning, or having a bid system for modules. Functions that need to be provided (for example, in Af-ghanistan) could be advertised and bid upon by current regiments and battalions one by one. Over time a modularity tip-ping point will be reached, allowing the rapid modularization of the remaining force structure. There will of course be some extra infrastructure and training costs as units that take on certain func-tions may need to transfer or develop certain capabilities such as airstrips and vehicles.

Before assigning task-functions a well thought out blueprint for modularity will need to be hammered out. This plan should include a well designed architec-ture, specifying what modules will be part of the system and what their func-tions will be; interfaces defining how modules will interact; and standards including methods of evaluation for per-formance measuring of modules. Encap-sulation, or how far down the military hierarchy designers want to decompose the system will also need to be hashed out. Each of these could be tested in simulated environments to find the right

Chad KOHALYK Fundamentals of Modularity

30 Sheffi, pp. 175-179.31 Ibid. pp. 255-258.

7

balance of module size, function and interaction patterns.

One important lesson is not to be-come distracted by the explicit structure of individual modules. The highly sought after characteristic of flexibility requires that modules not be strictly defined. Modules need room to develop, innovate and evolve when necessary in the chang-ing environment. This is critical to the strategic flexibility of the organization.

Sanchez and Mahoney argue that during the modular development process the key is to specify and standardize in-

terfaces since it is these rules that deter-mines the flexibility of the architecture to configure new variations, allowing a system to respond to the changing environment.32 Furthermore, these inter-faces not only determine intrafirm inter-action, but also interfirm and institutional interactions.33 In consideration of these levels of analysis modules should be designed to interact with one another as they would interact with modules in an instituional environment such as a NATO-led battlegroup. This is especially relevant for a smaller power such as

Canada, which will most likely be op-erating within an alliance setting. Of course, this sort of interoperability — the ability of our modules to combine with the modules of diverse nations — intro-duces a whole new level of complexity in designing a modular national force structure.

The next stage in exploring modular-ity in the Canadian Forces should be a close examination of the interface design principle, as well as appropriate man-agement strategies for capable command and control in the age of modularity. ■

Chad KOHALYK Fundamentals of Modularity

32 See Sanchez (2003) pp. 381 and Sanchez and Mahoney pp. 75.33 Garud and Kumaraswamy, pp. 58.

8

Cited Works

Augier, Mie and H.A. Simon. "The Architecture of Complexity — Commentary." Managing the Modular Age: Architectures, Networks, and Organizations (2003):38-44.

Baldwin, Carliss L. and Kim B. Clark. "Managing in an Age of Modularity." Managing the Modular Age: Architectures, Networks, and Organizations (2003 [1997]):149-160.

Baldwin, Carliss L. and Kim B. Clark. "Managing in an Age of Modularity — Com-mentary." Managing the Modular Age: Architectures, Networks, and Organizations (2003):161-171.

Berkowitz, Bruce. The New Face of War: How the War Will be Fought in the 21st Century. New York. Free Press, 2003.

Brister, Bernard J. "Canadian Special Operations Forces: A Blueprint for the Fu-ture." Canadian Military Journal, Autumn 2004: 29-38.

DeSario, George. "Task force modularity/force stabilization." Armor, Sept-Oct 2004.

Feickert, Andrew. U.S. Army's Modular Redesign: Issues for Congress. Congres-sional Research Service, 6 January 2005.

Garud, Raghu and Arun Kumaraswamy. "Technological and Organizational Designs for Realizing Economies of Substitution." Managing the Modular Age: Architectures, Networks, and Organizations (2003):45-68.

Garud, Raghu and Arun Kumaraswamy. "Technological and Organizational Designs for Realizing Economies of Substitution — Commentary." Managing the Modular Age: Architectures, Networks, and Organizations (2003):68-77.

Godefroy, Andrew (ed.). "The Army of Tomorrow: Assessing Concepts and Capabili-ties For Land Operations Evolution." Directorate of Land Strategic Concepts, King-ston, Ontario. May 2006. [Unpublished]

_. "The ABCA Future Concept." Directorate of Land Strategic Concepts, Kingston, Ontario, 31 Mar 06 Draft. [Unpublished]

Grossman, Elaine M. "Critique of Army Redesign Proves Highly Contentious Inside Service." InsideDefense.com reproduced on Defense and the National Interest 2 Mar 2006. <http://www.d-n-i.net/grossman/army_redesign.htm> accessed on 20 Aug 2006.

Heyman, Charles. "Special forces and the reality of military operations in Afghani-stan." Jane's Information Group. 05 November 2001. <http://www.janes.com/defence/land_forces/news/jwa/jwa011105_1_n.shtml> accessed 8 Aug 2006.

Langlois, Richard. "Modularity in Technology and Organizations." Network Institu-tional Theory, Research Paper no. 1/100. February 2000.

Langlois, Richard N. and Paul L. Robertson. "Networks and Innovation in a Modular System: Lessons from the Microcomputer and Stereo Component Industries." Managing the Modular Age: Architectures, Networks, and Organizations (2003):78-100.

Marquis, Susan. Unconventional Warfare: Rebuilding U.S. Special Operations Forces. Washington: Brookings, 1997.

META Group. The Adaptive Organization: An Examination of On Demand Comput-ing. Metagroup survey summary, May 2004.

Murdock, Clark. "An assessment of the 2006 QDR." Center for Strategic and Inter-national Studies. 4 Feb 2006. <http://www.csis.org/component/option,com_csis_progj/task,view/id,502/> ac-cessed 10 Aug 2006.

Parnas, David L. "On the Criteria for Decomposing Systems into Modules," Com-munications of the ACM. 15 (12):1053-1058 (December, 1972)

Pengelley, Pupert. "French Army in profile: hollow force to hard core." Jane's Infor-mation Group. 31 May 2000.

Sanchez, Ron and Joseph T. Mahoney. "Modularity, Flexibility, and Knowledge Management in Product and Organization Design." Strategic Management Journal 1996 (Winter Special Issue): Vol. 17: 63-76 .

Sanchez, Ron. "Modularity, Flexibility, and Knowledge Management in Product and Organization Design — Commentary." Managing the Modular Age: Architectures, Networks, and Organizations (2003):380-389.

Schilling, Melissa A. "Toward a General Modular Systems Theory and its Applica-tion to Interfirm Product Modularity." Managing the Modular Age: Architectures, Networks, and Organizations (2003):172-202.

Schilling, Melissa A. "Toward a General Modular Systems Theory and its Applica-tion to Interfirm Product Modularity — Commentary." Managing the Modular Age: Architectures, Networks, and Organizations (2003):203-214.

Sheffi, Yossi. The Resilient Enterprise: Overcoming Vulnerability for Competitive Advantage. Cambridge, MA: MIT Press, 2005.

Simon, H.A. "The Architecture of Complexity." Managing the Modular Age: Architec-tures, Networks, and Organizations (2003[1962]):15-38.

Steele, Dennis. "Fielding modularity and using it in the fight." Army, Sept 2005.

Tucker, David and Christopher J. Lamb. "Restructuring Special Operations Forces for Emerging Threats." Strategic Forum, January 2006: No. 219.