Modularity Design Rules for Architecture Development: Theory, Implementation, and Evidence from the Development of the Renault–Nissan Alliance “Common Module Family” Architecture

Abstract

In this paper, we propose a set of rules for developing modular architectures. We first consider the well-known concept of “Design Rules” advanced by Baldwin and Clark. We then propose a broader conceptualization called “Modularity Design Rules” that is derived from later studies of the strategic, managerial, and organizational processes that must also be undertaken to implement successful modular development projects. We elaborate the critical role that the proposed Modularity Design Rules play in strategically grounding, organizing, and managing modular architecture development processes. We also identify key roles that top management must fulfill in supporting implementation of the proposed rules. We then provide evidence in support of the proposed Modularity Design Rules through a case study of the Renault–Nissan Alliance’s successful development and use of a modular “Common Module Family” architecture between 2009 and 2014. We then suggest some important implications of the Modularity Design Rules for open innovation processes in new product development.

1. Introduction

Beginning in the 1990s, a new stream of management research began to investigate how the architectures a firm adopts for its product designs may affect its product strategies, management processes, and organization designs [1,2,3,4,5,6,7,8,9]. More recently, a parallel stream of macro-level economic research has also suggested that the product architectures adopted by firms may significantly affect both the vertical structure of an industry and the nature of the competitive and cooperative dynamics among firms in an industry [10,11,12,13,14].

Research in this stream has established rather conclusively that use of modular product architectures can substantially shorten development times, increase the speed to market, reduce development and production costs, increase product variety, and enable cooperative interactions among the participants in an industry, leading to heightened rates of market development and technological change for firms with modular architecture development capabilities [5,14,15,16]. Research has also shown that achieving the advantages obtainable from modular architectures, however, requires that managers understand and be willing to adopt new kinds of market strategies, management processes, development processes, and organizational structures that differ quite fundamentally from practices followed in traditional new product development [11,12,17,18] and from derivative practices such as “overlapping problem solving” [19].

Most notably, modular architecture development processes require much higher levels of architectural definition and organizational discipline (in developing a defined architecture) than are typically maintained in conventional NPD processes. Research suggests that the greatest challenge to both strategic and technical managers of firms converting from traditional product development processes to modular development processes is likely to come from the need to adequately define the strategic mission, component structure, and interfaces between components of a new architecture as the first step in a modular architecture development process, rather than letting a new architecture evolve and emerge during component development, as is typically the case in traditional product development processes [17,20,21].

Adequately defining a new architecture before beginning component development processes requires both (i) defining how the new architecture can most advantageously be decomposed into functional components (“strategic partitioning” of the architecture) and (ii) defining the interfaces between components to enable a strategically intended range of configurability of components within the product architecture [6,17]. As we elaborate further below, defining a new architecture to this extent as a first step in a development process requires specific kinds of interactions between senior managers who will use the new architecture to carry out product market strategies, on the one hand, and technical managers who need to develop components and interfaces capable of providing the functionalities and strategic flexibilities desired from the new architecture on the other [4,17,18]. The central proposition of this paper is that these essential upstream managerial interactions and subsequent development activities need to be carried out within a clear framework of specific rules for governing and guiding a firm’s processes for developing modular architectures.

In their well-known ex post study of the technical structure of the IBM System 360 computer architecture, Baldwin and Clark [1] used the term Design Rules to refer to technical design practices that should be followed to create a product architecture with technically decoupled components that enable configuration of component variations within the architecture. At the same time and subsequently, using “real-time” research methods to investigate ongoing modular development processes, Sanchez [17,20,21] argued that modular architectures cannot be developed successfully through traditional development processes and practices, and that new rules and new roles are required to govern and guide a firm’s strategic, organizational, and managerial processes for developing modular architectures.

In this paper, we undertake to extend prior research into rules applicable to modular architecture development processes by elaborating a formalized set of “Modularity Design Rules” (“MDRs”) that identify specific strategic, managerial, and organizational practices that we suggest are essential to achieving success in modular architecture development processes. In so doing, we also identify what we believe are the most significant challenges to be met by managers in converting their organizations from traditional development practices to modular strategies and development processes consistent with the proposed MDRs [17,20,21].

We also undertake to lend support to the validity and importance of the proposed MDRs by reporting some of the key findings of a multi-year, longitudinal study of the Renault–Nissan Alliance (RNA)’s successful initiative to create a “Common Module Family” (CMF) modular architecture that would be the basis for achieving significant cost reductions in their vehicles while maintaining distinctive brand identities and the requisite product variety. We suggest that the RNA’s success in creating the CMF modular architecture that was eventually used for more than 50 product models was made possible by RNA management’s recognition of the importance of the MDRs that we propose here and by their successful implementation in the RNA’s CMF development process.

Our discussion is structured in the following way:

In Section 2, we compare the essentially technical concept of Design Rules suggested by Baldwin and Clark [1] with the managerial and organizational perspectives on rules for modular architecture development processes proposed by Sanchez [17].

In Section 3, we elaborate our proposed set of Modularity Design Rules and explain both the theoretical basis for and practical considerations motivating each rule.

In Section 4, we suggest some essential roles for senior managers in implementing the proposed MDRs.

In Section 5, we present some key aspects of our case study of the Renault–Nissan Alliance’s development of the first “Common Module Family” architecture intended to serve as the basis for a range of Renault and Nissan vehicle models.

Section 6 summarizes what we suggest are the key findings from our case study, highlighting the various aspects of the RNA’s successful modular development initiative incorporating the MDRs that we propose here.

Section 7 offers concluding comments.

2. ”Design Rules” Reconsidered

In addition to noting the potential strategic benefits of using modular architectures in product market competition, some management researchers in the mid-1990s also observed that many firms using modular product designs appeared to have adopted new kinds of organizational forms and processes to support their development of modular product architectures [3,4,6]. By the late 1990s, some researchers began to investigate in greater depth the processes that firms might use to create modular architectures. In 2000, two key studies appeared with some answers to that question.

In 2000, Baldwin and Clark published their well-known book Design Rules, based largely on their study of the technical structure of the 1960s IBM System 360 computer’s modular architecture. Adapting the Design Quality Matrix [22] used in Total Quality Management as a graphic tool for relating specific parts of product designs to consumer preferences, Baldwin and Clark developed a “Design Structure Matrix” (“DSM”) to identify the intended functional interactions of components within a product design. They then applied their DSM tool to the analysis of the IBM System 360’s modular computer architecture. Their DSM analysis of the IBM System 360 showed that certain components were technically isolated or “decoupled” from other key components, thereby enabling both technically independent, “decoupled” processes for developing the components and subsequent reconfiguration of component variations within the architecture to meet differing customer requirements for computing.

Baldwin and Clark proposed that the DSM for a modular product architecture not only revealed the ex post technical decoupling of components within an architecture, but also implied a set of ex ante “Design Rules” for creating technical decoupling among components during the architecture development process. In effect, Baldwin and Clark argued that an organization seeking to create a modular design should create and then follow a set of design rules that explicitly seek to technically decouple specific components in order to make the new design configurable (i.e., modular).

Contemporaneous with and subsequent to Baldwin and Clark’s [1] development of their essentially technical notion of Design Rules, other researchers began to examine in greater depth various organizational and managerial processes involved in creating modular architectures. Concurrent with the publication of Baldwin and Clark’s historical study, and based on several “real-time” studies of ongoing modular development processes in Philips, General Electric, Chrysler, and other firms, Sanchez [17] proposed that design rules for guiding the technical design of modular architectures, such as those noted by Baldwin and Clark [1], can only be implemented effectively if a firm is also following other rules governing the strategic, organizational, and managerial processes that must be undertaken to initiate and guide modular development processes. In effect, Sanchez [17] argued that technical design rules revealed through DSM analyses are only the most readily visible tip of an iceberg, and that a broader and deeper set of “new rules and new roles” for organizing and managing modular development processes underlie and enable the use of technical design rules in a modular development process.

In the next section, we draw on and extend this broader perspective to elaborate a set of Modularity Design Rules (MDRs) for governing the organizational and managerial processes essential in developing modular architectures. The ten MDRs discussed in the body of this paper are summarized in

Table 1. Summary of Modularity Design Rules.

MDR No.	Modularity Design Rule
I. Before Component Development
1	A new modular architecture must be developed using only proven component designs whose system behaviors are well understood and whose interface specifications can therefore be reliably defined.
2	Technical development of new technologies and new types of component based on new technologies must be carried out independently of modular architecture development processes.
3	A firm’s strategic and technical managers must determine through joint consultations the functionalities and other desired attributes to be provided by a new modular architecture.
4	Strategic managers must provide technical managers with a clear prioritization of the strategic benefits sought from a new architecture.
5	Once strategic managers commit to a given slate of strategic objectives and priorities for the various functionalities and other attributes to be provided by a new architecture, the list of development objectives and priorities must be “frozen” and not allowed to change during the ensuing architecture development process.
6	Strategic and technical managers must jointly agree on how the new modular architecture will be “strategically partitioned” into functional components.
7	Interfaces between the components in a modular architecture must be defined to allow the substitution of a strategically desired range of component variations into the architecture—without requiring compensating for changes in the designs of other components in the architecture.
II. During Component Development
8	The specific strategic partitioning of a new architecture into functional components decided prior to beginning detailed component development must be strictly followed throughout the component development process.
9	Once the interfaces are specified for a new architecture, the interfaces must be frozen and not allowed to change during ensuing processes for developing components for the new architecture.
III. After Initial Component Development
10	The strategic partitioning and interface specifications used to create a new product architecture must be maintained throughout the period of commercial use of the architecture.

below.

3. Modularity Design Rules

We begin our elaboration of rules for managing modular architecture development processes by making a critical distinction between “technical modularity” and “strategic modularity” in product designs. We then divide our elaboration of Modularity Design Rules (“MDRs”) into (i) rules that apply to strategic, organizational, and managerial processes to be undertaken before beginning technical development of the components to be used in an architecture (Section 3.2), (ii) rules that apply most critically during the technical development of components (Section 3.3), and (iii) rules that apply after the technical development of components and during the commercial use of the architecture (Section 3.4).

The MDRs that we elaborate here are drawn from more than 25 years of “real-time action research” [4,17,20,21] into numerous firms’ processes for creating modular product architectures in the automotive, aircraft, consumer electronics, information technology, manufacturing equipment, office equipment, home appliance, personal health care, medical equipment, confections, financial services, health services, and travel industries, as well as from multi-year longitudinal studies [8,9] of modular development processes in a number of Japanese firms.

3.1. Technical Modularity “Versus” Strategic Modularity

Sanchez [20] observes that although many products today exhibit some degree of modularity in their designs, there are important differences in what modularity is intended to accomplish in different product designs, as well as in the development processes through which different firms have sought to introduce modularity into their product designs. On this basis, Sanchez [20] distinguishes two different kinds of modularity in product architectures:

Technical modularity exists when at least some interfaces between components in a product design have been specified to allow the substitution of two or more component variations into the design without requiring compensating for design changes in components “on the other side” of the interfaces. Technical modularity is often created through routine engineering processes that seek to reduce the development cost of a design by re-using industry standard or pre-existing component designs and/or interface specifications. For example, engineering designers often adopt industry standard bolt patterns as interfaces for attaching various kinds of wheel and pulley hubs, or industry standard electronic interfaces (such as USB interfaces) for connecting digital devices.

By contrast, strategic modularity is created through a strategically motivated architecture development process in which the decomposition of the architecture into functional components and the specification of the interfaces between components are both designed to create specific forms of strategic flexibility in the product architecture [4]. For example, the component structure and interfaces in an architecture may be designed with a primary objective of allowing for a wide range of component variations to be used in configuring a strategically desired range of product variations.

The Modularity Design Rules (MDRs) that we elaborate here apply to processes for creating strategic modularity in a product architecture; that is, to firm processes whose intention is to create a modular product architecture with specific forms of strategic flexibility intended to directly support a firm’s product strategies. Moreover, the MDRs elaborated below are explicitly normative in nature. They are not intended to describe what firms may do in trying to use modularity in their product architectures. Rather, the MDRs are rules that identify critical strategic, organizational, and managerial issues that we suggest have to be recognized and addressed in developing strategically modular architectures, and to propose specific ways in which those issues can be managed successfully.

The MDRs proposed here are derived both from modularity theory and from the authors’ extensive observations and analyses of successful and unsuccessful attempts to develop modular architectures in a wide variety of firms. Only a few firms known to the authors have clearly recognized the need for a broad set of rules for managing modular development processes such as the MDRs we elaborate here, and even fewer firms have had the managerial and organizational capacity to implement modular development processes that adhere to these rules. However, such firms and processes do exist, as we note below, and we suggest that these firms’ successes in creating and using modular architectures lend support to the validity of the MDRs we elaborate below.

The most architecturally advanced firms known to the authors in fact use alternative possibilities for future modular architectures as drivers of their long-term strategic capability development processes [18]. Thus, we suggest that firms that have the managerial and organizational capacity to implement these MDRs in strategically motivated modular development processes may be able to derive a substantial competitive advantage over other firms with lesser abilities to implement the MDRs elaborated here.

3.2. Modularity Design Rules: Prior to Starting Component Development

Although much research on modularity has been focused on the processes firms use to develop components for their modular architectures [1,6], our research suggests that component development processes actually occupy a late and relatively predictable stage in successful processes for creating modular architectures. As we elaborate below, once the strategically critical attributes of a new modular architecture have been decided as the first step in a modular architecture development process, the technical development of components that will meet the strategic requirements for a new modular architecture should be a fairly routine undertaking.

We therefore begin this discussion by elaborating the MDRs that apply to the key strategic, managerial, and organizational processes that need to be in place in order to define adequately the strategic flexibilities desired from a new product architecture and that therefore must precede and then guide processes for developing components for a new architecture.

(Note: the numbering of the MDRs below is intended primarily to provide a means of referring to specific MDRs in our discussion, and is not intended to denote a strict sequential order of application in a modular architecture development process. In fact, most of the MDRs apply through more than one stage of development and some apply throughout all stages in the development and commercialization of a new modular architecture).

MDR No. 1:

A new modular architecture must be developed using only proven component designs whose system behaviors are well understood and whose interface specifications can therefore be reliably defined.

We begin our list of MDRs with one of the least understood—and most commonly misunderstood—rules for developing modular architectures. A modular architecture is modular precisely because it uses components that are technically independent (or “decoupled” from) other components in the architecture. In order to technically decouple components within an architecture, a firm’s developers must know how the components will behave when used in a given kind of product design—i.e., their system properties—and be able to define interface specifications between components such that changes in the design of a given component will not require compensating for changes in the designs of other components in the architecture. This technical decoupling of components brings a number of benefits that are fundamental to modular architectures, including the ability to develop components concurrently—resulting in faster development times—and the ability to substitute a range of component variations freely within an architecture to configure new product variations [3,4].

Defining interfaces that can achieve technical decoupling of components within a modular architecture cannot be done reliably with new kinds of components whose system properties are not yet well understood (e.g., components based on new, unproven technologies). Thus, a bedrock principle of modular development processes is that new modular architectures can only incorporate components whose system behaviors (in that type of product architecture) are already well understood—and whose interfaces are therefore reliably specifiable.

A common misunderstanding about MDR No. 1 is that restricting development of modular architectures to using only well-understood, proven component designs will limit the ability of new modular architectures to introduce innovative new products based on new technologies and new kinds of components. This misunderstanding overlooks the highly disruptive effects and consequential delays that result when a firm tries to develop an architecture that includes technologically new components whose interfaces cannot be reliably specified. Research has shown that as much as 80% of the total development time can be wasted in repeatedly redesigning other components as errors and omissions in initial interfaces for unproven components are discovered during development [18].

By contrast, when technically new components are developed and proven “offline”, as proposed formally in MDR No.2 below, then well-understood components with reliably specifiable interfaces can be developed in parallel processes and made available to next-generation architecture development projects. Studies have shown that some firms have been able to significantly accelerate their innovation processes by “fast cycling” through rapid development of successive generations of new architectures that incorporate technically new components only after the components have been adequately understood and proven to have reliably specifiable interfaces [6,23].

MDR No. 2:

Technical development of new technologies and new types of component based on new technologies must be carried out independently of modular architecture development processes.

For the reasons stated under MDR No.1 above, firms should not try to resolve technical uncertainties about new kinds of components as part of modular architecture development processes. Rather, new kinds of components should be investigated and developed through parallel, decoupled component development processes (see the discussion of “Decoupled Architectural Learning” from Figure 2c in Sanchez and Mahoney [6]). These “offline” development processes should be focused on developing components for next-generation and future-generation architectures identified through a firm’s strategic planning and capability development processes [24].

In effect, adopting modular architecture development processes requires a key change from the traditional processes linking research and development (R + D) and new product development (NPD), as suggested in Figure 1. Instead of letting development of new architectures include processes for developing new kinds of components for which research has only provided a “proof of concept”, modular architecture development processes require that new kinds of components suggested by a “proof of concept” from R + D should be developed “offline” in parallel development processes until interfaces for each new type of component can be reliably specified (“proof of component”).

Once new kinds of component designs have been developed and their system properties determined with confidence, new component designs and their attendant interface specifications can be released into a “design library” of proven component designs that are then available for use in developing next-generation modular architectures.

MDR No.3:

A firm’s strategic and technical managers must determine through joint consultations the functionalities and other desired attributes to be provided by a new modular architecture.

Because a strategically modular product architecture is essentially a technical creation with a strategic mission, the functionalities and attributes that are strategically desired from a new modular architecture must be communicated by strategic managers to technical managers, who must in turn provide strategic managers with their assessments of what functionalities and attributes can currently be provided by the proven component designs available to the firm in developing a next-generation architecture. Through an interactive dialogue, strategic and technical managers must jointly decide the specific components and interfaces to be used in the new architecture and the resulting functionalities and attributes the new architecture can be developed to provide. These consultations between strategic and technical constitute an essential first step in initiating a strategically motivated modular architecture development process.

MDR No.4:

Strategic managers must provide technical managers with a clear prioritization of the strategic benefits sought from a new architecture.

The many strategic flexibilities obtainable from a modular architecture make it possible to achieve a variety of strategic benefits through one architecture development process, including increasing product variety (by substituting component variations), rapidly upgrading product performance (by technologically upgrading key components), reducing production costs (by using industry standard and/or common components), reducing development costs (by using components already developed by other firms), and increasing the speed to market (through parallel development processes, re-using existing components, and/or involving more partners in developing new components), among others. While it may well be possible to obtain several or all of these benefits of modularity to some degree in a single architecture, technical constraints are likely to require trade-offs to be made among the potentially available benefits in developing an architecture.

In order for technical managers to strategically optimize a modular architecture during development, strategic managers must provide technical managers with a strategically prioritized ranking of the modularity benefits sought from a new architecture. Without a clear set of priorities from strategic mangers, the technical trade-offs made during development are unlikely to be strategically coherent or effective in providing the kind of modular architecture sought by strategic managers.

MDR No. 5:

Once strategic managers commit to a given slate of strategic objectives and priorities for the various functionalities and other attributes to be provided by a new architecture, the list of development objectives and priorities must be “frozen” and not allowed to change during the ensuing architecture development process.

Allowing the functionalities and performance levels to be delivered by a new product to be a “moving target” is highly disruptive to any product development process, whether modular or non-modular. To preserve the advantages of the higher development speed and/or parallel and distributed development of components that are obtainable with modular architectures, changes in strategic goals for an architecture cannot be allowed after the development of a new architecture has begun. Instead, firms should develop an ability to keep up with changes in market requirements by “fast cycling” through successive generations of modular architectures, each of which can be developed relatively quickly when goals for each new architecture are not allowed to change during development.

MDR No. 6:

Strategic and technical managers must jointly agree on how the new modular architecture will be “strategically partitioned” into functional components.

The way in which a new architecture is decomposed into functional components will significantly affect the kinds of strategic benefits a modular architecture can provide. For example, in some cases it may be possible to lower unit production costs by combining two or more functions into one “compound” component, but doing so may increase the costs and time required to change any of the functions contained within the compound component design, thereby limiting the ability of a firm to configure product variations within the architecture.

Thus, once the strategic benefits to be sought from a new architecture have been clearly prioritized, technical managers must evaluate and then communicate to strategic managers the extent to which alternative ways of decomposing or “strategically partitioning” the new architecture into functional components would affect the new architecture’s ability to deliver the prioritized strategic benefits sought from the architecture. Strategic and technical managers must then agree on the optimal approach to partitioning an architecture into functional components given current strategic objectives and technical constraints.

MDR No. 7:

Interfaces between the components in a modular architecture must be defined to allow the substitution of a strategically desired range of component variations into the architecture—without requiring compensating for changes in the designs of other components in the architecture.

The specification of component interfaces in conventional NPD processes is often treated as a relatively unimportant technical detail. As a result, interfaces between components are often allowed to “evolve as needed” during conventional NPD processes or are simply deferred to the last stages of a development process.

In modular architecture development processes, however, interfaces between components must be fully specified before beginning detailed development of components for a new architecture. Both the ability to develop component designs in parallel (concurrent component development) and to design component variations that can be freely substituted into an architecture without having to make compensating changes to the designs of other components depend on having stable, fully specified interfaces throughout the architecture development process.

In some cases, a firm may be able to use an “industry standard” interface that allows for a broad range of readily available component variations to “plug and play” in a new architecture, such as a HDMI interface on a visual display and other electronics devices [25]. Alternatively, a firm may design a set of proprietary interfaces that allow for a range of proprietary and/or industry standard components to be used in its architecture, such as Apple has often used for connecting video devices to its laptops.

While even simple interfaces may enable a wide range of component variations to be introduced into an architecture, there are always technical limits to the range of component variations that can be used with any interface. Thus, strategic and technical managers must agree on the range of component variations to be accommodated by each interface in an architecture before specifying the interfaces to be adhered to throughout the architecture development process.

3.3. Modularity Design Rules: During Detailed Component Development

As suggested earlier, if the preceding MDRs have been followed throughout the processes leading up to the beginning of detailed component development, then the subsequent processes for developing specific component variations for a new architecture should become relatively routine. However, achieving the strategic benefits sought from a modular architecture, both during and after development, depends on a firm’s ability to maintain two critical forms of organizational discipline during detailed component development processes, as addressed by MDR No. 8 and MDR No.9 below.

MDR No. 8:

The specific strategic partitioning of a new architecture into functional components decided prior to beginning detailed component development must be strictly followed throughout the component development process.

The strategic partitioning of a new architecture into functional components prior to beginning development of the components for the architecture (see MDR No. 6) is intended to provide a component structure that best supports the intended strategic uses of a new architecture. While one might hope that component developers are fully aware of and respect the strategic reasons for a particular strategic partitioning, that may not always be the case in every organization. It is possible (and the authors have indeed observed) that well-intended component designers may take it upon themselves to change the way a new architecture has been strategically partitioned, usually for what appear to them to be eminently sensible “technical reasons”.

For example, component designers may think it would “save cost” to combine two or more components into a single compound component design—when unbeknownst to them, doing so would limit the ability of the firm to carry out its intended strategy by limiting or eliminating the ability to introduce component variations into the new architecture. Thus, strict organizational discipline is required to assure that the strategic partitioning of components decided prior to the beginning of development is the set of components that component developers actually develop.

MDR No. 9:

Once the interfaces are specified for a new architecture, the interfaces must be frozen and not allowed to change during ensuing processes for developing components for the new architecture.

Because a modular architecture is a system of components that must function together physically (or purely logically, in the case of software architectures), even simple and seemingly innocuous changes in interface specifications during development may create unintended changes in the interactions between components that may not have been anticipated by—and may therefore disrupt—any ongoing component development processes. While it is common practice in conventional NPD to allow changes in interfaces between components during component development, the rapid, concurrent, and possibly distributed development of components in a modular development process depends on maintaining a consistent set of interface specifications to assure a stable technical environment for developing the component variations intended for a new architecture.

A further, very important strategic benefit of strictly adhering to initial interface specifications during component development is that doing so will quickly reveal how capable a development organization is of specifying interfaces so that a given component will perform as intended in a new architecture. When interfaces can be changed by developers during component development, it is likely that managers will be unable to detect any inability or limitations of developers to define adequate interface specifications for a new architecture. Thus, requiring developers to specify interfaces that must be adhered to throughout component development provides a key means for managers to evaluate the technical capabilities of their organization’s developers (note that the managerial visibility into developers’ capabilities that results from requiring developers to fully specify interfaces at the beginning of architecture development processes may be seen as threatening by some developers, who may seek to resist fully specifying interfaces in various ways, including through claims of “impossibility”).

3.4. Modularity Design Rules: After Component Development

Two aspects of modular architectures are also critical to maintain after components have been developed and a new architecture has been put into commercial use, as addressed by MDR No. 10 below.

MDR No. 10:

The strategic partitioning and interface specifications used to create a new product architecture must be maintained throughout the period of commercial use of the architecture.

Once a new architecture is “released” for commercial use, organizational responsibility for the architecture is often transferred from development engineers to engineers charged with “maintaining” the architecture. Unless this new group of engineers is fully informed about the strategic purpose for the architecture and the strategic reasons behind the architecture’s strategic partitioning and interface specifications, they may begin to make well-intended technical changes to the architecture’s component structure and/or interfaces. Such changes may, however, have very undesirable consequences.

Maintenance engineers may try to undertake the same kinds of “cost-saving” changes to the component structure of an architecture that component developers might think it would be desirable to undertake during development. For example, maintenance engineers may decide that integrating components that have been decoupled for strategic reasons would save costs or improve performance. However, this and other kinds of changes to an architecture could limit the ability to introduce variations of the affected components during the commercial lifetime of the architecture. Similarly, changes intended to “simplify” or otherwise modify interfaces may impose limitations on the configurability of an architecture already in commercial use. Thus, as a general rule, managers should monitor the activities of engineers responsible for maintaining an architecture to make sure that no changes are made to components or interfaces that could affect the reliability or configurability of the architecture are made after the development of the architecture.

Moreover, free-lanced changes to interfaces during the commercial lifetime of an architecture may make it impossible for both strategic and technical managers to ascertain how effective the originally specified interfaces for the architecture have been in delivering the configurability and reliability they were designed to provide. As Toyota has learned and incorporated into its Toyota Production System, the ability to determine exactly what was done by whom—and then to link that information to the subsequent performance of a finished product—is essential in identifying assembly task definitions and individual workers in need of improvement [26]. Analogously, the ability to link specific development decisions and individual developers to the subsequent performance of the components they have designed is essential to improving both individual skills and organizational capabilities in developing effective modular architectures [17,18,27].

4. Key Management Challenges in Adopting Modular Architectures

The implementation of the ten Modularity Design Rules elaborated in the preceding section is likely to pose very significant challenges to senior and mid-level managers, especially those seeking to lead their organizations in a transition from traditional development practices to modular architecture development processes. We next identify what we suggest are likely to be the key challenges to be met by managers in making this transition.

4.1. Willingness to Learn

For an organization to make a transition to the well-defined and organizationally disciplined modular strategies and development processes indicated by our Modularity Design Rules requires that its managers—especially its senior managers—be willing and able to learn a new way of thinking and managing that is profoundly different from conventional management practices, especially in (but not limited to) new product development and product strategies. Given the extent to which adoption of modular strategies is likely to affect virtually every aspect of an organization and its processes, it is simply not sufficient for senior managers to ask mid-level and technical managers to learn about modularity and to delegate to them the task of implementing modularity strategies and development processes.

The effective implementation of modular strategies in a firm’s product markets requires that senior managers be willing to invest their time and intelligence in developing a deep understanding of modularity’s new way of approaching and serving markets [5]. Such major changes in firm strategies will not be possible unless the firm’s senior managers are willing and able to provide the intellectual leadership needed to understand and support the firm’s transition to modular strategies and processes.

Managers in many—perhaps even most—organizations may fail to understand the nature, depth, and scope of the organizational changes required to adopt modular strategies and processes, and as a result they would be very likely to fail in trying to implement what they think are modular strategies. Perhaps the most perverse organizational outcomes, however, are likely to occur when senior management demands—but fails to fully understand, support, and monitor—a transformation to modular strategies and processes. In such cases, mid-level managers and technical managers who have yet to understand and accept modularity strategies and practices may make some superficial changes to conventional NPD practices—while assuring senior managers that they are now doing “modularity”.

For example, one of the co-authors knows of an automobile company in Europe that regularly professes to be following modularity practices—but the firm does not define its vehicles’ interfaces strategically or even in a modular way (MDR No. 7), does not freeze interfaces during development (MDR No. 9), and does not adhere to defined interfaces during the commercial use and maintenance of the architecture (MDR No. 10). As a result, the firm routinely faces many costly problems of recently designed components not fitting or working properly when vehicles are being assembled. Because of these problems, many senior managers in the firm have become convinced that “modularity does not work”(!). This unfortunate but wholly avoidable outcome is the direct result of senior management’s unwillingness to invest their time and intelligence in (i) learning what modularity actually means and (ii) supporting their firm’s transition to modularity by assuring that the processes implemented by the firm’s mid-level managers in fact conform to the meaning of and requirements for modular development processes.

4.2. Willingness to Become Involved

As indicated by several of the Modularity Design Rules, the development of modular architectures intended to support clearly defined product strategies requires that strategic managers responsible for product lines directly and intensively consult with the technical managers who must develop modular architectures for their product lines.

In many firms, channels and processes for intensive consultations between strategic managers and technical managers about market needs and technical possibilities for serving those needs simply do not exist. Moreover, in many organizations, especially larger ones, senior managers have become increasingly focused on managing costs affecting their firm’s financial performance, and may be quite unclear as to how various product functions, features, and performance levels may affect the perceived value of their products in the eyes of customers.

To fulfill their role in making a transition to modular product strategies and development processes, strategic managers must be willing to “become involved”—i.e., to engage in extensive discussions with their firm’s marketing and technical managers as to current and emerging market preferences and available technical possibilities for serving those preferences through modular architectures and product strategies.

4.3. Willingness to Change

As suggested by several of the Modularity Design Rules, the transition from conventional to modular product strategies and development practices typically requires major organizational transformations—in task allocations, authority distributions, information flows, and performance measures and evaluations [11]. The scope and depth of the organizational changes required to implement modular strategies effectively are simply beyond the authority typically vested in mid-level managers to undertake. Thus, achieving the significant organizational changes required to adopt modular development processes will require that a firm’s senior managers be willing to initiate significant organization change. As Sanchez [21] has suggested, modularity is not for the timid.

4.4. Willingness to Lead

Perhaps the most critical challenge in firms considering a transition to modular product strategies is the need for senior managers to be willing to fulfill an essential senior management leadership role in making this transition.

Any major change in an organization entails substantial risks—risks of failure, wasted resources, and loss of managerial reputation due to inadequately defined or misdirected initiatives, insufficient commitment and motivation, inadequate capability, unforeseen difficulties, etc. Leading major organization change requires that senior managers accept the ownership of those risks—and then urge the organization forward and support its many changes. As one manager who launched the organizational transformation to modularity in his firm once said to one of the co-authors,

“I did not know at the beginning of this process how it would all turn out.

But I did know that if it succeeded, I would praise my employees and give them all the credit—and if it failed, I alone would take the hit.”

5. Renault–Nissan Alliance’s Transition to A “Common Module Family” Modular Architecture

We now report some key results of a multi-year, longitudinal study by this paper’s co-authors of the Renault–Nissan Alliance’s (RNA) adoption of a modular “Common Module Family” (CMF) architecture intended to serve as the basis for more than 50 vehicle models. Our study examined both the modular vehicle architecture developed by the RNA and the managerial and organizational changes made by the RNA’s senior management to initiate and support the transition to modular development processes.

In the following discussion, we suggest why the RNA adopted the CMF modular architecture to support its global strategy and how the changes in management and organization processes undertaken by the RNA to support development of the CMF modular architecture directly reflect the Modularity Design Rules we elaborate here. We also suggest how RNA management met the challenges of leading a transition to the modular development processes described in Section 3.

5.1. Modularity in the RNA’s Global Strategy

The global automotive industry has historically faced both very substantial sunk costs for product development and production tooling, on the one hand, and rapidly rising demand for more differentiated models and even for mass-customized products, on the other. In this regard, it was perhaps inevitable that at least some major automobile producers would turn to modular product architectures to seek new possibilities for reducing costs while increasing product variety. The use of modular “platform” architectures adopted by Volkswagen in the early 1990s, for example, sought to lower product costs substantially while enabling greater product variety, and has been extensively reported [28]. More recently, however, the Renault–Nissan Alliance, formed in March 1999 by the French producer Renault and the Japanese producer Nissan, has undertaken an ambitious program to use a new modular architecture to substantially reduce product costs while offering an expanded range of sport utility vehicle (SUV) models in their global markets.

In February 2012, Mr. Carlos Ghosn, then President and Chairman of the RNA, announced the existence of a “4 + 1 Common Module Family” (CMF) program whose intent was to create a modular vehicle architecture that would achieve substantial vehicle cost reductions while serving as the basis for more than 50 SUV models for the Renault and Nissan brands. The “4 + 1” refers to the strategic partitioning of the new CMF modular vehicle architecture into four large body modules (engine compartment, front underbody, rear underbody, and cockpit) and one electrical/electronics module (also known as the electronic vehicle architecture, or “EVA”).

As suggested in Figure 2, the indicated variations in the four main body modules could be “mixed and matched” to produce visually distinct models within four families of vehicle types, identified as multi-purpose vehicles (MPVs), sport utility vehicles (SUVs), conventional sedans (SEDs), and smaller hatch-back vehicles (H/Bs). The variations in the combinable big modules shown in Figure 1 can in principle provide 2 × 3 × 3 × 3 = 54 distinct body shapes for at least that many different product models produced under the Renault and Nissan brands.

The strategic motivation for the CMF modular architecture was to enable configuration of a range of vehicles with different designs and functionalities while greatly increasing the commonality of body parts and components, thereby achieving both greater product variety and lower costs through large-scale production and assembly of common body modules and related components. The cost savings to be achieved through mass production of common modules and components were then to be invested in improving the environmental and safety performance of the RNA’s vehicles—two aspects of vehicles that were becoming increasingly important sources of competitive advantage in major automotive markets around the world.

The first CMF-based model introduced to the market was the Nissan X-Trail that began mass production in the autumn of 2013. Subsequently, more than 1.6 million CMF-derived vehicles (composed of two types of Nissan X-Trail vehicles and 10 Renault SUV models) were brought to market by mid-2017. At least 56% component commonality (cost basis) between Renault and Nissan vehicles was achieved—with a resulting overall 30% reduction in development and production costs per vehicle—while maintaining the distinctiveness of Renault and Nissan vehicle designs and expanding the number of distinct product models available to each firm in the RNA global product portfolio.

During the CFM architecture development process, RNA managers came to believe that the “optimal extent of commonality” to be sought through the CFM architecture would lie somewhere between 50% and 75% commonality of components in vehicle models derived from the CFM architecture. Their conclusion was that more than 75% component commonality would result in vehicles that would not be adequately differentiated from each other in the market, while less than 50% component commonality would not achieve the full extent of component cost reductions available through the CMF architecture.

5.2. Launch of the CMF Initiative

The CMF initiative announced by Carlos Ghosn in February 2012 had actually been launched internally in September 2009 jointly at Renault’s design centers near Paris, France, and Nissan’s R + D center near Tokyo, Japan. Much of the first year of the initiative was spent identifying how the two firms’ development structures and processes would have to change from their then traditional, model-focused development processes to a new architecture-focused process that could serve the market strategies and incorporate the technical resources of the two companies working together.

The development of new management and organization processes for developing the CMF architecture was driven by the pointed and ongoing monitoring of the project’s progress by Carlos Ghosn personally and by the assignment of responsibility for the CMF architecture initiative to several senior executives within both Renault and Nissan. Selection of staff from various areas of the two companies for participation in the CMF project was communicated as an important form of personal recognition and as an opportunity to play a key role in shaping the RNA of the future. All told, more than 200 people were selected and charged with creating not just the first CMF for the RNA—but also with creating the management and organizational processes that would unite the two companies in defining and developing CFM architectures that would be the shared basis for their future strategies.

5.3. New Organization Structures and Management Processes for Strategic Partitioning of the CMF Modular Architecture

The approach the CMF team took to defining new management and organizational processes for developing the first CMF architecture mirrored the logical sequence of technical decisions that would have to be made in order to define and develop any CMF modular architecture that would be effective in supporting the RNA’s prioritized goals for the architecture. The CMF team therefore focused first on creating new organizational structures and management processes for defining the component structure (i.e., the strategic partitioning) of the CMF architecture.

As we have noted, effective strategic partitioning of a strategically modular architecture requires extensive consideration of strategic, marketing, and technical factors affecting the products to be derived from the architecture. At the launch of the CMF project, no organizational structures or processes existed within Renault or Nissan to support such an undertaking. Beginning in September 2009, the CMF team leaders therefore focused on defining the new organizational structures and processes that they believed they would need in order to decide how the CMF architecture could best be strategically partitioned.

The strategic mission of the CMF architecture had been clearly articulated by the RNA’s top management: the new CMF modular architecture was to enable substantial per unit cost reductions through large-scale production of common modules to be shared across several and perhaps all models, while at the same time supporting the distinctiveness of the Renault and Nissan brands and at least the current range of product variety offered by each brand. Given these clear priorities for the new architecture, the CMF team recognized that defining the optimal strategic partitioning of the architecture would require new forms of intensive consultations between marketing staff and technical staff from the two companies.

The CMF team also knew that if staff from the two areas of expertise or from the two companies could not agree on what partitioning would be optimal, someone would have to have overall responsibility and authority for deciding the strategic partitioning to be adopted. The CMF team therefore instituted the organization structure shown in Figure 3 to manage the strategic partitioning of the CMF architecture.

In the organization structure shown in Figure 3, the Chief Vehicle Engineer (CVE) is responsible for all the technical aspects of the vehicles configured within the CMF architecture to be developed, while responsibility for market analysis and planning for the vehicles to be derived from the new architecture is vested in the Chief Product Specialist (CPS). Overseeing the process of deciding how best to strategically partition the CMF architecture is the Program Director (PD), who has authority to decide the specific market goals for the CMF architecture, the types of vehicles the architecture will support, and the number of vehicle variations that will be leveraged from the architecture. Moreover, all these marketing variables were to be decided within specific expectations for financial performance set by the RNA’s top management for the CMF architecture. These three senior managers (drawn from both Renault and Nissan) were charged with managing both the development of the CMF architecture and the subsequent configuring of individual models within the CMF architecture.

After extensive consultations, the CMF management team decided that an architecture strategically partitioned into four big body modules and one electrical/electronic module would most effectively serve and support the strategic priorities for the new architecture (See Figure 2). (The CMF architecture includes common interfaces for attaching all roof panels, but specific roof designs were reserved to be added later and designed specifically for each product model to enhance product differentiation.) A “module manager” was appointed for each of the 4 + 1 big modules. The module managers were made responsible for the designs of their module, for subsequent performance improvements for their module, and for the compatibility of the components used within each module.

The 4 + 1 “big modules” adopted by the CMF team as the first level of strategic partitioning of the CMF architecture each contained significant numbers of components. To achieve scale economies from use of common components, the CMF team had to further strategically partition each of the four big modules to define the specific kinds of components that would be used in each module and to identify the components that could be used in common across product models in the CMF architecture. The CMF team soon realized that three issues would have to be managed in deciding which components within each CMF module would be used in common across all or many product models and which would be specific to individual models or brands.

First, the market requirements affecting a number of components were quite different in Renault’s and Nissan’s main markets of Europe, Asia, and North America, so trade-offs would have to be made between using standard components across the three regions to increase scale and reduce unit costs, on the one hand, and allowing region-specific component variations to locally adapt vehicles to meet regional market preferences and requirements, on the other. Second, many kinds of components Renault and Nissan had historically used had different kinds of design solutions (referred to as “Technical Policies” within Nissan), and thus the two firms had different ways of locating and otherwise integrating various components into their vehicle architectures. Third, each company had their own distinctive ways of designing major elements of their vehicle architectures, such as designs of the “crash cage” for protecting passengers in a collision, the general arrangement of the engine compartment, and the positioning of driver and passenger seats within a vehicle.

In some instances, differences in the component functionalities and design solutions sought by Renault’s and Nissan’s development staffs could be resolved by purely technical means. Nevertheless, some disagreements about component designs reflected underlying differences in marketing objectives, production capabilities, or other factors that could not be resolved by technical staff alone. Each component whose functionality and design could not be agreed on between the two firms or between marketing and technical staffs was identified as a “Road Block” (“RB” for short). Identified RBs were, in effect, the manifestations of significant organizational or strategic differences between two companies that would have to be resolved by senior managers before the two companies could begin to create a vehicle architecture with substantial component commonality. New management processes would have to be created to manage decisions about common components to be used by the two companies in the CMF architecture.

In all, by November 2009 more than 800 component RBs were identified across the 4 + 1 big modules. To resolve the 800+ RBs, senior RNA management established a new management process composed of a Joint Steering Committee (JSC) for each of the five big modules (see Figure 4). Each JSC was composed of senior managers from both firms and reported directly to the senior executives of both firms. The JSC for each big module then assigned CMF team members and other RNA staff with relevant marketing and technical expertise to work together in “Upstream Strategic Focus Teams” (USFTs) to resolve each component RB. In all, 76 USFTs were created to resolve Road Blocks for specific types of components.

Importantly, the JSC also promulgated a “new rule” requiring that no development work on any component could begin until all RBs for that component had been resolved and approval for the component had been received from the JSC for the part of the CMF architecture that incorporated each component. For their part, the JSCs coordinated with the Cross-Company Team of senior executives from both firms to assure that each technical solution accepted for an identified RB would be effective in supporting each firm’s marketing strategy. In total, more than 1500 employees from Renault and Nissan participated in 76 USFTs focused on resolving component RBs.

The RNA’s senior management also established Joint Steering Committees (JSCs) staffed by senior managers from the two firms to resolve cross-company issues arising in the detailed development of each of the 4 + 1 modules, as well as a JSC to coordinate the two firms’ marketing plans for models derived from the first CMF architecture.

Using this new organizational structure and management process, the full list of 800+ component RBs and a number of big module and marketing issues were resolved in the 15 months between September 2009 and December 2010, after which full-scale development of components was finally allowed to proceed.

5.4. New Processes for Involving Suppliers in CMF Architecture Development

Developing the CMF architecture and producing a range of CMF vehicle models with high levels of component commonality required significant changes in both Renault’s and Nissan’s relationships with their suppliers. Prior to the development of the CMF architecture, both firms developed and purchased components for individual vehicle models. By standardizing on common components, the production volumes for each component used in the CMF architecture increased dramatically—from typical single-model lots of approximately 100,000 units to more than 1,700,000 units for all CMF models. The shift from small lots of many component variations to large lots of common components meant that the RNA’s interactions with its suppliers had to change from arm’s-length contracting with many suppliers to close cooperation with fewer but larger suppliers.

Recognizing the need for new kinds of interactions and processes with suppliers, the CMF team began to build new kinds of relationships with their suppliers—at both strategic and operational levels—in the early stages of CMF development. The cooperative relationships the CMF team developed at the strategic level involved sharing sensitive market information and cost targets with suppliers, so that suppliers could make better decisions in allocating their own resources to development and production activities supporting the CMF architecture.

Similarly, at the operational level, closer cooperative relationships were built so that the CMF architecture development process could both provide more complete information to suppliers and more effectively draw on the expertise of suppliers. For example, suppliers received much more information than previously about projected production volumes and expected model variations, and were in turn asked to propose component designs that would increase possibilities for component sharing across anticipated models.

5.5. Processes for Specifying and Controlling Interfaces during and after Development

As in any modular architecture, the interfaces between the CMF’s big modules and between their respective sets of components determined the ease with which—and thus the extent to which—the big modules can be mixed and matched to configure different product models, as well as the extent to which the components used in each module can be used in common across product models. Accordingly, the 76 USFTs created to develop suitable modules and components for the CMF architecture were also charged with specifying interfaces for their module or component that would enable as many components as technically possible to become common components within the CFM architecture.

The USFTs were also responsible for assuring that the interfaces specified for each CFM module and related components remained “frozen” (standardized) and were adhered to during module and component development processes. Given the deep experience and accumulated knowledge in both Nissan and Renault relevant to the 4 + 1 modules and related components, computer simulation technology could be used both to develop modules and components and to confirm the suitability of the interfaces between modules and components during development.

6. Modular Design Rules in the RNA’s Development of Its CMF Modular Architecture

We think it is appropriate to note that the RNA’s success in developing its new Common Module Family modular architecture was remarkable in a number of respects. For one, the highly successful CMF development process was the result of a first effort by Renault and Nissan to create a modular architecture that would serve the diverse requirements for their individual brands of vehicles in the Asian, European, and North American markets. Moreover, the CMF project was not a small-scale “pilot project” intended to test the feasibility of using a common modular architecture for the two firms’ products. On the contrary, the CMF project was specifically charged with creating a common vehicle architecture that would be the basis for the projected production of nearly two million vehicles whose costs of production would run into tens of billions of USD. In addition, the CMF project had to find a way to bring together two firms with very different traditions in vehicle development, design, and marketing—and somehow found a way to enable the two firms to work together in creating a common vehicle architecture that would serve the interests of both firms well.

Perhaps the daunting nature and scale of the task facing the CMF team—coupled with the lack of any pre-existing management processes or organizational structures in either company for accomplishing such a task—left the CMF team no choice but to invent a radically new way of working in order to begin the development of a common modular architecture. In any event, we suggest that the management processes and organization structures implemented by the RNA’s senior management and the CMF team reflect the Modular Design Rules elaborated in Section 3 to a remarkable extent.

At the launch of the CMF project, the RNA’s senior management gave essential strategic direction to the CMF development process by providing a clear statement of prioritized strategic goals for the CMF architecture (MDR No. 4). Moreover, the strategic goals given by top management for the CMF architecture remained the same throughout the CMF development process (MDR No. 5).

To achieve the strategic goal of substantially reducing unit costs through use of common components (while maintaining brand distinctiveness and the requisite product variety), the CMF team was composed of both marketing strategy and technical staffs that worked directly with each other and that were supported by and reported directly to the RNA’s strategic-level managers (MDR No. 3).

The first task undertaken by the CMF team was deciding the component structure (strategic partitioning) of the CMF architecture to be developed (MDR No. 6). In order to provide a stable technical structure for the new architecture to be developed, the strategic partitioning of the CMF architecture into 4 + 1 “big modules” and then into the components that would be used within each module was maintained throughout the CMF development commercialization process (MDR No. 8).

After the strategic partitioning of the CMF architecture was decided, the interfaces between the 4 + 1 modules and between their respective components were defined and frozen to enable concurrent development of components (MDR No. 9). The defined interfaces were maintained through the component development phase both for standard components that would be used across many or all product models within the CMF architecture to achieve cost reductions and for components that would be “mixed and matched” within the CMF architecture to create product variations (MDF No. 7).

Once the strategic partitioning of the CMF architecture was accomplished and the interfaces between the 4 + 1 modules and between their respective components were defined, then—and only then—were detailed component development processes allowed to begin, both for components for the initial vehicle models to be derived from the CMF architecture and for components for new models to follow. Only after completing development of the 4 + 1 modules and related components were various vehicle models configured using the fully developed 4 + 1 modules and related components for the CMF architecture (MDRs No. 1, 2, and 10).

We also note that throughout the CMF architecture creation process, the RNA’s senior management demonstrated their willingness to perform the top management roles that we have suggested (in Section 4 are essential to achieving success in any strategic modular architecture development process: (i) to be willing to learn a significantly new way of setting strategies and of managing strategic processes; (ii) to be willing to become personally involved in directly supporting the strategically important modular architecture initiatives; (iii) to be willing to undertake significant change in their respective organization’s management processes and organizational structures in order to implement the new way of working; and (iv) to be willing to provide essential strategic leadership by sponsoring—and bearing the risk of—a modular architecture development initiative that would lay the foundation for their two companies’ futures.

7. Modular Design Rules in Open Innovation Processes

The MDRs we have elaborated here provide a logically necessary sequence of decisions and policies that together create an information and decision structure [6] that is essential for achieving coordination of any development process for the creation of a modular product architecture, whether the process takes place within a firm, between the partners in an alliance, or among the participants in an open innovation process [29,30,31,32].

At the beginning of an open innovation process, MDRs Nos. 1 and 2 require that the components to be used in the open innovation process must have already been developed and proven before being introduced into the open innovation process. MDR Nos. 3 and 5 require that the functionalities to be provided by the new product architecture and their technical solutions must be selected and then frozen (not allowed to change subsequently), and MDR No. 4 requires that the strategic benefits to be delivered by the new architecture are also clearly prioritized. MDR No. 6 follows logically from the prior five MDRs and determines which kinds of components will be stable in the new architecture, and which new component variations will be needed in the new architecture—and therefore which kinds of components can be invited and proposed in the open innovation process. MDR No. 7 then defines and freezes the interfaces between the components in the new architecture. These first seven MDRs therefore define the essential boundaries for innovating the new architecture that in turn determine the kinds of solutions that the open innovation process can then pursue.

MDRs No. 8 and 9 are policy rules that essentially bring consistency to and impose discipline on the open innovation process, so that the innovation processes can be focused on the components in the new product architecture that need to be new and innovative.

MDR no. 10 provides a stable technical framework for a new product architecture that enables open-ended continuation of open innovation processes during the commercial lifetime of the product architecture.

8. Conclusions

The normative model of Modularity Design Rules for modular architecture development processes that we elaborate here reflects nearly two decades of theory development and empirical research into modularity and modular architecture strategies [4,5,6,13,16,25]. These modular development processes are fundamentally different from the practices followed in traditional approaches to managing new product development. They also differ fundamentally from related development models such as “Overlapping Problem Solving” [19], which Sanchez and Mahoney [6] characterize as essentially an effort to compress and thereby accelerate traditional development processes.

Because modular development processes are a relatively recent evolution in our understanding of how products can be developed, in management research or management practice there is not yet a common consistent understanding of how modular development processes need to be managed and organized. Baldwin and Clark’s [1] Design Rules was an early effort to delve into modular development processes by suggesting that achieving technical decoupling among components in an architecture would be facilitated by decoupling the organizational processes for developing such components.

In this discussion, we have sought to elaborate an expanded notion of “Modularity Design Rules” that go beyond Baldwin and Clark’s essentially technical perspective on Design Rules to present an interrelated set of managerial and organizational rules that we suggest must be understood and followed in order to implement successful processes for developing modular architectures of strategic importance to an organization. We have also suggested that the top managements of firms have essential roles that they must fulfill in supporting the adoption and implementation of Modular Design Rules.

We have sought to provide some empirical evidence in support of the Modular Design Rules and essential top management roles elaborated here by reporting a case study of an initiative by the Renault–Nissan Alliance to create a “Common Module Family” modular architecture of major strategic importance to the two firms that make up the Alliance. We suggest that the notable findings that can be derived from our case study are that: (i) all ten of the Modular Design Rules that we propose here were in fact recognized as necessary and followed by the RNA’s senior management and the CMF development team in their highly successful development of the CMF modular architecture; and (ii) top management of the Alliance demonstrated their willingness to perform the four senior management roles that we suggest are also essential to achieving success in a strategic modular development process.

There are obvious limits to what can justifiably be inferred from a single case study, even one reporting a remarkable achievement such as this one does, and thus we do not suggest that the “single data point” that we have reported in our case study provides conclusive evidence in support of our propositions. Rather, we suggest that the empirical contribution of this paper is to add another case study to ongoing research suggesting that successful creation of strategically significant modular architectures requires following specific managerial and organizational processes and rules for governing those processes, and that top management must play an active role in giving strategic direction to and actively supporting development processes for such architectures.