Discussion Paper No. 80
Modularity Design Rules forArchitecture Development:
Theory, Implementation, and Evidence
from Development of the Renault-Nissan Alliance"Common Module Family" Architecture

Ron Sanchez
Tomoatsu Shibata
April, 2018

Data Science and Service Research
Discussion Paper

Center for Data Science and Service Research
Graduate School of Economic and Management
Tohoku University27-1 Kawauchi, Aobaku
Sendai 980-8576, JAPANModularity Design Rules for Architecture Development:
Theory, Implementation, and Evidence from Developmentof the Renault-Nissan Alliance "Common Module Family" Architecture
Ron Sanchez, PhD
Copenhagen Business School
Kilevej 14A - 3rd Floor
DK-2000 Frederiksberg, Denmark
email:

sanchez@cbs.dk

Tomoatsu Shibata, PhD
TOHOKU University, Japan
27-1, Kawauchi, Aoba-ku, Sendai, Miyagi-Pref., 980-8576, Japane-mail : shibatatomoatsu@gmail.com

Abstract:
In this paper we propose a set of rules for developing modular architectures. We firstconsider the well-known concept of "Design Rules" advanced by Baldwin and Clark(2000). 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 instrategically 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.
Key Words: Design Rules, Architectures, Modularity, Product Development.

1Modularity Design Rules (v.7 April 2018)

2

INTRODUCTION
Beginning in the 1990s, a new stream of management research began toinvestigate how the architectures a firm adopts for its product designs may affect its
product strategies, management processes and organization designs (Henderson and
Clark 1990; Garud and Kumaraswamy 1995; Sanchez 1995, 1999; Sanchez and Mahoney
1996; Robertson and Ulrich, 1998; Shibata, Yano and Kodama, 2005; Shibata, 2009).
More recently, a parallel stream of macro-level economic research has also suggested thatthe product architectures adopted by firms may significantly affect both the verticalstructure of an industry and the nature of the competitive and cooperative dynamics
among firms in an industry (Chesbrough and Kusunoki 2001; Sanchez 2008; Colfer andBaldwin 2010; Sanchez and Mahoney 2013; Sanchez and Hang 2017).
Research in this stream has established rather conclusively that use of modular
product architectures can substantially shorten development times, increase speed tomarket, 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 (Langlois and Robertson, 1992; Worren, Moore
and Cardona 2002; Sanchez 1999; Sanchez and Hang 2017). Research has also shownthat achieving the advantages obtainable from modular architectures, however, requiresthat 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(Sanchez 2000, 2008; Sanchez and Collins 2001; Colfer and Baldwin 2010) and fromderivative practices such as "overlapping problem solving" (Clark and Fujimoto 1991).
Most notably, modular architecture development processes require much higher
levels of architectural definition and organizational discipline (in developing a definedarchitecture) than are typically maintained in conventional NPD processes. Researchsuggests 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,

Modularity Design Rules (v.7 April 2018)

3

component structure, and interfaces between components of a new architecture as thefirst step in a modular architecture development process, rather than letting a newarchitecture evolve and emerge during component development, as is typically the casein traditional product development processes (Sanchez 2000, 2013, 2015).
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 (Sanchez and
Mahoney 1996; Sanchez 2000). As we elaborate further below, defining a newarchitecture to this extent as a first step in a development process requires specific kindsof 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 (Sanchez 1995, 2000;
Sanchez and Collins 2001). 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 (2000) used the term Design Rules to refer totechnical design practices that should be followed to create a product architecture withtechnically decoupled components that enable configuration of component variations
within the architecture. At the same time and subsequently, using "real-time" researchmethods to investigate ongoing modular development processes, Sanchez (2000, 2013,2015) argued that modular architectures cannot be developed successfully throughtraditional 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 tomodular architecture development processes by elaborating a formalized set of

Modularity Design Rules (v.7 April 2018)4"Modularity Design Rules" ("MDR") that identify specific strategic, managerial, andorganizational practices that we suggest are essential to achieving success in modular
architecture development processes. In so doing, we also identify what we believe are themost significant challenges to be met by managers in converting their organizations fromtraditional development practices to modular strategies and development processes
consistent with the proposed MDRs (Sanchez 2000, 2013, 2015).
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's (RNA) 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 requisite
product variety.1 We suggest that RNA's success in creating the CMF modular
architecture that was eventually used for more than 50 product models was madepossible by RNA management's recognition of the importance of the MDR that we
propose here and by their successful implementation in RNA’s CMF development process.
Our discussion is structured in the following way:
In Section 1 we compare the essentially technical concept of Design Rules
suggested by Baldwin and Clark (2000) with the managerial and organizational
perspectives on rules for modular architecture development processes proposed by
Sanchez (2000).
In Section 2 we elaborate our proposed set of Modularity Design Rules and explain
both the theoretical basis and practical considerations motivating each rule.

1 The case study whose key findings are reported here was launched through extensive interviews

conducted with key Nissan and Renault-Nissan Alliance (RNA) executives and managers
between November 2012 and August 2013. We would like to thank in particular Mr. Hideyuki
Sakamoto, at the time Corporate Vice President of Nissan Motor Co., Ltd., and Mr. Hiroyoshi
Yamamoto, at the time General Manager in charge of the RNA executive office, for theirgenerous cooperation through extended interviews and in supporting the gathering of detailed
information on the processes initiated by RNA for the development of the CFM modular
architecture. Additional data and perspectives were obtained through subsequent e-mailexchanges with Mr. Yamamoto, as well as from publicly available sources. We also thank Mr.
Yamamoto for reviewing draft versions of the case.

Modularity Design Rules (v.7 April 2018)

5

In Section 3 we suggest some essential roles for senior managers in implementing
the proposed MDR.
In Section 4 we present some key aspects of our case study of 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 5 summarizes what we suggest are the key findings from our casestudy, highlighting the various aspects of RNA's successful modular development
initiative incorporating the MDRs that we propose here.
Section 6 offers concluding comments.

Modularity Design Rules (v.7 April 2018)6

1. "DESIGN RULES" RECONSIDERED
In addition to noting the potential strategic benefits of using modular
architectures in product market competition, some management researchers in the mid1990s also observed that many firms using modular product designs appeared to haveadopted new kinds of organizational forms and processes to support their developmentof modular product architectures (Garud and Kumaraswamy 1995; Sanchez 1995;
Sanchez and Mahoney 1996). By the late 1990s, some researchers began to investigate ingreater 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, basedlargely on their study of the technical structure of the 1960s IBM System 360 computer's
modular architecture. Adapting the Design Quality Matrix (Clausen 1989) 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 thecomponents and subsequent reconfiguration of component variations within thearchitecture 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, butalso 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 thenfollow a set of Design Rules that explicitly seek to technically decouple specificcomponents in order to make the new design configurable (i.e., modular).

Modularity Design Rules (v.7 April 2018)7

Contemporaneous with and subsequent to Baldwin and Clark's (2000)
development of their essentially technical notion of Design Rules, other researchersbegan 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(2000) proposed that design rules for guiding the technical design of modular
architectures, such as those noted by Baldwin and Clark (2000), 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 (2000) argued that technical design rules
revealed through DSM analyses are only the most readily visible tip of an iceberg, andthat 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 amodular development process.
In the next section, we draw on and extend this broader perspective to elaborate a
set of Modularity Design Rules (MDR) for governing the organizational and managerial
processes essential in developing modular architectures.

Modularity Design Rules (v.7 April 2018)8

2. MODULARITY DESIGN RULES
We begin our elaboration of rules for managing modular architecturedevelopment processes by making a critical distinction between "technicalmodularity" and "strategic modularity" in product designs. We then divide ourelaboration 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 2.2), (ii) rules that apply most critically during the technical development ofcomponents (Section 2.3), and (iii) rules that apply after the technical developmentof components and during the commercial use of the architecture (Section 2.4).
The MDR that we elaborate here are drawn from more than 25 years of "realtime action research”2 into numerous firms' processes for creating modular productarchitectures in the automotive, aircraft, consumer electronics, information
technology, manufacturing equipment, office equipment, home appliance, personal
health care, medical equipment, confections, financial services, health services, andtravel industries, as well as from multi-year longitudinal studies3 of modular
development processes in a number of Japanese firms.
2.1 "Technical Modularity" versus "Strategic Modularity"
Sanchez (2013) observes that although many products today exhibit somedegree of modularity in their designs, there are important differences in what
modularity is intended to accomplish in different product designs, as well as in thedevelopment processes through which different firms have sought to introduce
modularity into their product designs. On this basis, Sanchez (2013, p.209)
distinguishes two different kinds of modularity in product architectures:

2 This “real-time action research” is reported in Sanchez 1995, 2000, 2013, and 2015 in thelist of references.
3 The longitudinal studies are reported in part in Shibata et al. 2005 and Shibata 2009 in thereferences.

Modularity Design Rules (v.7 April 2018)9Technical 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
design changes in components "on the other side" of the interfaces. Technicalmodularity is often created through routine engineering processes that seek toreduce the development cost of a design by re-using industry standard or preexisting 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 electronicinterfaces (like USB interfaces) for connecting digital devices.
By contrast, strategic modularity is created through a strategically motivatedarchitecture 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 (Sanchez 1995). For example, the component structure andinterfaces in an architecture may be designed with a primary objective of allowing awide 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 toprocesses for creating strategic modularity in a product architecture -- that is, tofirm processes whose intention is to create a modular product architecture withspecific forms of strategic flexibility intended to directly support a firm's productstrategies. 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 intheir product architectures. Rather, the MDR are rules that identify critical strategic,organizational, and managerial issues that we suggest have to be recognized andaddressed in developing strategically modular architectures, and to propose specificways in which those issues can be managed successfully.
The MDRs proposed here are derived both from modularity theory and fromthe authors' extensive observations and analyses of successful and unsuccessfulattempts to develop modular architectures in a wide variety of firms. Only a few

Modularity Design Rules (v.7 April 2018)10

firms known to the authors have clearly recognized the need for a broad set of rules
for managing modular development processes like the MDRs we elaborate here, andeven 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.4 Thus, we suggest that firms that have the managerial andorganizational capacity to implement these MDRs in strategically motivatedmodular development processes may be able to derive substantial competitive
advantage over other firms with lesser abilities to implement the MDRs elaborated
here.
2.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 (Baldwin and
Clark 2000, Sanchez and Mahoney 1996), our research suggests that component
development processes actually occupy a late and relatively predictable stage insuccessful 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, thetechnical development of components that will meet the strategic requirements fora 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 inorder to define adequately the strategic flexibilities desired from a new productarchitecture -- and that therefore must precede and then guide processes fordeveloping components for a new architecture.
(Note: The numbering of the MDR below is intended primarily to provide a
4 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 (Sanchez and Collins 2001).

Modularity Design Rules (v.7 April 2018)11means of referring to specific MDRs in our discussion, and is not intended to denotea strict sequential order of application in a modular architecture development
process. In fact, most of the MDRs apply through more than one stage ofdevelopment and some apply throughout all stages in the development andcommercialization 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 mostcommonly misunderstood -- rules for developing modular architectures. A modular
architecture is modular precisely because it uses components that are technicallyindependent (or "decoupled" from") other components in the architecture. In orderto 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 requirecompensating 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 substitutea range of component variations freely within an architecture to configure new
product variations (Garud and Kumaswamy 1995, Sanchez 1995).
Defining interfaces that can achieve technical decoupling of components
within a modular architecture cannot be done reliably with new kinds ofcomponents 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) arealready well understood -- and whose interfaces are therefore reliably specifiable.

Modularity Design Rules (v.7 April 2018)12

A common misunderstanding about MDR No. 1 is that restricting developmentof 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. Thismisunderstanding overlooks the highly disruptive effects and consequential delays
that result when a firm tries to develop an architecture that includes technologicallynew components whose interfaces cannot be reliably specified. Research has shownthat as much as 80% of total development time can be wasted in repeatedly
redesigning other components as errors and omissions in initial interfaces forunproven components are discovered during development (Sanchez and Collins
2001).
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 madeavailable to next-generation architecture development projects. Studies have shownthat some firms have been able to significantly accelerate their innovation processes
by "fast cycling" through rapid development of successive generations of newarchitectures that incorporate technically new components only after thecomponents have been adequately understood and proven to have reliably
specifiable interfaces (Sanchez and Mahoney 1996; Sanchez 2004).
MRD No. 2:
Technical development of new technologies and new types of component basedon new technologies must be carried out independently of modular architecturedevelopment 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

13

Modularity Design Rules (v.7 April 2018)

processes.5 These “off-line” 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 (Sanchez2012).
In effect, adopting modular architecture development processes requires a key
change rom the traditional processes linking research and development (R+D) andnew product development (NPD), as suggested in Figure 1. Instead of letting
development of new architectures include processes for developing new kinds ofcomponents for which research has only provided “proof of concept,” modular
architecture development processes require that new kinds of components
suggested by “proof of concept” from R+D should be developed “off line” in paralleldevelopment processes until interfaces for each new type of component can bereliably specified (“proof of component”).

Traditional New Product Development:“Proof of Concept”
For New Kinds ofComponents
R+D

New Kinds of Components Developed
During New Product Development

Modular Architecture Development:“Proof ofConcept”
R+D“Off-line” Component
Development“Proof ofComponent”

Architecture
Development

Figure 1: Traditional versus Modular Processes for Developing New Kinds of Components

5 See discussion of "Decoupled Architectural Learning" from Figure 2(c) in Sanchez and

Mahoney (1996), p71-72.

Modularity Design Rules (v.7 April 2018)14

Once new kinds of component designs have been developed and their systemproperties determined with confidence, new component designs and their attendantinterface 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 newmodular architecture.
Because a strategically modular product architecture is essentially a technicalcreation with a strategic mission, the functionalities and attributes that are
strategically desired from a new modular architecture must be communicated bystrategic managers to technical managers, who must in turn provide strategic
managers with their assessments of what functionalities and attributes cancurrently be provided by the proven component designs available to the firm indeveloping a next generation architecture. Through an interactive dialogue,
strategic and technical managers must jointly decide the specific components andinterfaces to be used in the new architecture and the resulting functionalities andattributes the new architecture can be developed to provide. These consultations
between strategic and technical constitute an essential first step in initiating astrategically motivated modular architecture development process.
MDR No.4:
Strategic managers must provide technical managers with a clear prioritizationof the strategic benefits sought from a new architecture.
The many strategic flexibilities obtainable from a modular architecture make itpossible to achieve a variety of strategic benefits through one architecturedevelopment process, including increasing product variety (by substituting
component variations), rapidly upgrading product performance (by technologicallyModularity Design Rules (v.7 April 2018)15

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 speed to market (through paralleldevelopment processes, re-using existing components, and/or involving morepartners in developing new components), among others. While it may well bepossible to obtain several or all of these benefits of modularity to some degree in asingle architecture, technical constraints are likely to require trade-offs to be madeamong 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 technicalmanagers with a strategically prioritzed ranking of the modularity benefits soughtfrom a new architecture. Without a clear set of priorities from strategic mangers, thetechnical trade-offs made during development are unlikely to be strategicallycoherent or effective in providing the kind of modular architecture sought bystrategic managers.
MDR No. 5:
Once strategic managers commit to a given slate of strategic objectives andpriorities for the various functionalities and other attributes to be provided by a newarchitecture, the list of development objectives and priorities must be "frozen" and notallowed 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 greater
development speed and/or parallel and distributed development of componentsthat are obtainable with modular architectures, changes in strategic goals for an
architecture cannot be allowed after 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 eachnew architecture are not allowed to change during development.

Modularity Design Rules (v.7 April 2018)16

MDR No. 6:
Strategic and technical managers must jointly agree 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 havebeen clearly prioritized, technical managers must evaluate and then communicate tostrategic 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 toallow the substitution of a strategically desired range of component variations into thearchitecture -- without requiring compensating changes in the designs of othercomponents in the architecture.
The specification of component interfaces in conventional NPD processes isoften 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Modularity Design Rules (v.7 April 2018)17

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 makecompensating 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 thatallows a broad range of readily available component variations to "plug and play" ina new architecture, such as a HDMI interface on a visual display and otherelectronics devices (Sanderson and Uzumeri 1997). Alternatively, a firm may design
a set of proprietary interfaces that allow a range of proprietary and/or industry
standard components to be used in its architecture, such as Apple has often used forconnecting 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 theinterfaces to be adhered to throughout the architecture development process.
2.3 Modularity Design Rules: During Detailed Component Development
As suggested earlier, if the preceding MDRs have been followed throughout theprocesses leading up to the beginning of detailed component development, then thesubsequent processes for developing specific component variations for a newarchitecture 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

Modularity Design Rules (v.7 April 2018)18

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 isrequired to assure that the strategic partitioning of components decided prior to thebeginning 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), evensimple 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Modularity Design Rules (v.7 April 2018)19

conventional NPD to allow changes in interfaces between components duringcomponent development, the rapid, concurrent, and possibly distributed
development of components in a modular development processes depends on
maintaining a consistent set of interface specifications to assure a stable technicalenvironment for developing the component variations intended for a newarchitecture.
A further, very important strategic benefit of strictly adhering to initialinterface specifications during component development is that doing so will quickly
reveal how capable a development organization is of specifying interfaces so that agiven component will perform as intended in a new architecture. When interfaces
can be changed by developers during component development, it is likely thatmanagers 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 theirorganization's developers.6
2.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.

6 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.”Modularity Design Rules (v.7 April 2018)20

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 ofengineers is fully informed about the strategic purpose for the architecture and thestrategic reasons behind the architecture's strategic partitioning and interface
specifications, they may begin to make well-intended technical changes to thearchitecture'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 cost 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 thearchitecture. Similarly, changes intended to "simplify" or otherwise modify
interfaces may impose limitations on the configurability of an architecture alreadyin commercial use. Thus, as a general rule, managers should monitor the activities ofengineers 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 development of the architecture.
Moreover, free-lanced changes to interfaces during the commercial lifetimeof 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 toprovide. 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 (Spear and Bowen 1999). Analogously, the ability to link specificdevelopment decisions and individual developers to the subsequent performance ofModularity Design Rules (v.7 April 2018)21

the components they have designed is essential to improving both individual skills
and organizational capabilities in developing effective modular architectures(Sanchez 2000, 2005; Sanchez and Collins 2001).

Modularity Design Rules (v.7 April 2018)22

3. KEY MANAGEMENT CHALLENGES IN ADOPTING MODULAR ARCHITECTURES
The implementation of the ten Modularity Design Rules elaborated in thepreceding section is likely to pose very significant challenges to senior and mid-level
managers, especially those seeking to lead their organizations in a transition fromtraditional development practices to modular architecture development processes.
We next identify what we suggest are likely to be the key challenges to be met bymanagers in making this transition.
3.1 Willingness to Learn
For an organization to make a transition to the well-defined andorganizationally 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 theextent 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 todelegate to them the task of implementing modularity strategies and development
processes.
The effective implementation of modular strategies in a firm's productmarkets requires that senior managers be willing to invest their time andintelligence in developing a deep understanding of modularity's new way of
approaching and serving markets (Sanchez 1999). 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'stransition to modular strategies and processes.
Managers in many -- perhaps even most -- organizations may fail tounderstand the nature, depth, and scope of the organizational changes required toModularity Design Rules (v.7 April 2018)23

adopt modular strategies and processes, and as a result they would be very likely tofail in trying to implement what they think are modular strategies. Perhaps the mostperverse organizational outcomes, however, are likely to occur when senior
management demands -- but fails to fully understand, support, and monitor -- atransformation 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 toconventional NPD practices -- while assuring senior managers that they are now
doing "modularity."
For example, one of the co-authors knows of an automobile company inEurope 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 notadhere to defined interfaces during the commercial use and maintenance of thearchitecture (MDR No. 10). As a result, the firm routinely faces many costly
problems of recently designed components not fitting or working properly whenvehicles are being assembled. Because of these problems, many senior managers in
the firm have become convinced that "modularity doesn't 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 assuringthat the processes implemented by the firm's mid-level managers in fact conform to
the meaning of and requirements for modular development processes.
3.2 Willingness to Become Involved
As indicated by several of the Modularity Design Rules, the development ofmodular architectures intended to support clearly defined product strategies
requires that strategic managers responsible for product lines directly andintensively consult with the technical managers who must develop modular
architectures for their product lines.

Modularity Design Rules (v.7 April 2018)24

In many firms, channels and processes for intensive consultations between
strategic managers and technical managers about market needs and technicalpossibilities for serving those needs simply do not exist. Moreover, in manyorganizations, especially larger ones, senior managers have become increasingly
focused on managing costs affecting their firm's financial performance, and may bequite 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 anddevelopment processes, strategic managers must be willing to "become involved" -i.e., to engage in extensive discussions with their firm's marketing and technicalmanagers as to current and emerging market preferences and available technicalpossibilities for serving those preferences through modular architectures andproduct strategies.
3.3 Willingness to Change
As suggested by several of the Modularity Design Rules, the transition fromconventional to modular product strategies and development practices typicallyrequires major organizational transformations -- in task allocations, authority
distributions, information flows, and performance measures and evaluations(Sanchez 2008). The scope and depth of the organizational changes required to
implement modular strategies effectively are simply beyond the authority typicallyvested 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 (2015) has suggested, modularity is not for the timid.
3.4 Willingness to Lead
Perhaps the most critical challenge in firms considering a transition tomodular product strategies is the need for senior managers to be willing to fulfill an
essential senior management leadership role in making this transition.

Modularity Design Rules (v.7 April 2018)25

Any major change in an organization entails substantial risks -- risks offailure, 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 -- andthen 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 didn't 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."Modularity Design Rules (v.7 April 2018)26

4. 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
RNA and the managerial and organizational changes made by RNA senior management toinitiate and support the transition to modular development processes.
In the following discussion, we suggest why RNA adopted the CMF modular
architecture to support its global strategy and how the changes in management andorganization processes undertaken by RNA to support development of the CMF modular
architecture directly reflect the Modularity Design Rules we elaborate in Section 2. We
also suggest how RNA management met the challenges of leading a transition to modular
development processes described in Section 3.
4.1 Modularity in RNA's Global Strategy
The global automotive industry has historically faced both very substantial sunkcosts 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 (Pandremenos et al. 2009). More recently, however, the RenaultNissan 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 ofsport utility vehicle (SUV) models in their global markets.

Modularity Design Rules (v.7 April 2018)27

In February 2012, Mr. Carlos Ghosn, then President and Chairman of 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 andNissan 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 theelectronic 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 ofvehicle 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.

Figure 2: “Big Modules” in “Common Module Family” (CMF) Architecture(Source: Renault-Nissan Alliance)Modularity Design Rules (v.7 April 2018)28

The strategic motivation for the CMF modular architecture was to enableconfiguration of a range of vehicles with different designs and functionalities while
greatly increasing commonality of body parts and components, thereby achieving
both greater product variety and lower costs through large-scale production andassembly of common body modules and related components. The cost savings to beachieved through mass production of common modules and components were thento be invested in improving the environmental and safety performance of RNA'svehicles -- two aspects of vehicles that were becoming increasingly importantsources of competitive advantage in major automotive markets around the world.
The first CMF-based model introduced to the market was the Nissan X-Trailthat 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 wasachieved -- with a resulting overall 30% reduction in development and production
costs per vehicle -- while maintaining the distinctiveness of Renault and Nissanvehicle designs and expanding the number of distinct product models available toeach firm in the RNA global product portfolio.7
4.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 andprocesses would have to change from their then traditional, model-focused
7 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 eachother in the market, while less than 50% component commonality would not achieve thefull extent of component cost reductions available through the CMF architecture.

Modularity Design Rules (v.7 April 2018)29

development processes to a new architecture-focused process that could serve themarket strategies and incorporate the technical resources of the two companies
working together.
The development of new management and organization processes fordeveloping the CMF architecture was driven by the pointed and ongoing monitoringof the project's progress by Carlos Ghosn personally and by the assignment ofresponsibility for the CMF architecture initiative to several senior executives withinboth 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 RNA -- but also with creating the management andorganizational processes that would unite the two companies in defining anddeveloping CFM architectures that would be the shared basis for their future
strategies.
4.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 andorganizational processes for developing the first CMF architecture mirrored thelogical 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
RNA's prioritized goals for the architecture. The CMF team therefore focused first on
creating new organizational structures and management processes for defining thecomponent 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 technicalfactors 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 teamleaders therefore focused on defining the new organizational structures andModularity Design Rules (v.7 April 2018)30

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
RNA top management: the new CMF modular architecture was to enable substantial
per unit cost reductions through large-scale production of common modules to beshared across several and perhaps all models, while at the same time supporting thedistinctiveness 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 newarchitecture, 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 fromthe 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 andplanning 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 ofvehicles the architecture will support, and the number of vehicle variations that willbe leveraged from the architecture. Moreover, all these marketing variables were to
be decided within specific expectations for financial performance set by RNA top
management for the CMF architecture. These three senior managers (drawn fromboth 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.

31

Modularity Design Rules (v.7 April 2018)

PD - Program Director

CPS - Chief Product Specialist

CVE - Chief Vehicle Engineer

ManagerEngine Compartment
ModuleManager
Cockpit Module

Manager
Front Underbody
ModuleManager
Rear Underbody
ModuleManager
Electronic Vehicle
Architecture (EVA)

Figure 3: Organization Structure for Strategic Partitioning and Development of CMF Architecture(Source: Renault-Nissan Alliance)

After extensive consultations, the CMF management team decided that anarchitecture 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 werereserved to be added later and designed specifically for each product model toenhance product differentiation.) A "module manager" was appointed for each of
the 4+1 big modules. The module managers were made responsible for the designsof their module, for subsequent performance improvements for their module, andfor 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 ofcomponents. To achieve scale economies from use of common components, the CMF
team had to further strategically partition each of the 4 big module to define thespecific kinds of components that would be used in each module and to identify thecomponents that could be used in common across product models in the CMF

Modularity Design Rules (v.7 April 2018)32

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 incommon across all or many product models and which would be specific toindividual 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 thethree 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, for many kinds ofcomponents Renault and Nissan had historically used 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 ofdesigning major elements of their vehicle architectures, such as designs of the"crash cage" for protecting passengers in a collision, the general arrangement of theengine compartment, and the positioning of driver and passenger seats within avehicle.
In some instances, differences in the component functionalities and design
solutions sought by Renault's and Nissan's development staffs could be resolved bypurely 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. Eachcomponent whose functionality and design could not be agreed 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 tobe resolved by senior managers before the two companies could begin to create avehicle 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.

33

Modularity Design Rules (v.7 April 2018)
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 ofsenior managers from both firms and reported directly to the senior executives ofboth firms. The JSC for each big module then assigned CMF team members and otherRNA 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.

RENAULT-NISSAN ALLIANCE
Director’s Office

CCT – Cross Company Team(senior executive level)

ACM - Alliance Commodity Meeting(senior executive level)

Proposed Solutions
To Road Blocks
Assure Proposed Solutions
To Road Blocks Work Well
For Both Companies’
Market Strategies

Proposed
Solutions

JSC #1
Joint Steering Committee
for Components
JSC #2
Joint Steering Committee
for CMF Architecture
JSC #3
Joint Steering Committee
for EVA(Electronic Vehicle Architecture)
JSC #4
Joint Steering Committee
for Market Strategy

Identify Road Blocks
and Propose Solutions

Approved Solutions
To Road Blocks

Accepted
Solutions

USFT
Upstream Strategic
Focus Teams(For Technical Solutions
to Common Components)
USFT #1
USFT #2
USFT #3.
.
.
USFT #75
USFT #76

Figure 4: Management Process for Resolving “Road Blocks” in Development of CMF Architecture(Source: Renault-Nissan Alliance)

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

Modularity Design Rules (v.7 April 2018)34

part, the JSCs coordinated with the Cross-Company Team of senior executives fromboth firms to assure that each technical solution accepted for an identified RB would
be effective in supporting the each firm’s marketing strategy. In total, more than
1500 employees from Renault and Nissan participated in 76 USFTs focused on
resolving component RBs.
RNA 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 tocoordinate the two firms' marketing plans for models derived from the first CMF
architecture.
Using this new organizational structure and management process, the full listof 800+ component RBs and a number of big module and marketing issues wereresolved in the 15 months between September 2009 and December 2010, after
which full-scale development of components was finally allowed to proceed.
4.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 inboth Renault's and Nissan's relationships with their suppliers. Prior to thedevelopment 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 ofapproximately 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 RNA's interactions with its suppliers had to change fromarm'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

Modularity Design Rules (v.7 April 2018)35

development. The cooperative relationships the CMF team developed at thestrategic 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 inturn asked to propose component designs that would increase possibilities forcomponent sharing across anticipated models.
4.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 withwhich -- 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 thecomponents 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 tobecome common components within the CFM architecture.
The USFTs were also responsible for assuring that the interfaces specified foreach CFM module and related components remained "frozen" (standardized) andwere 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 theinterfaces between modules and components during development.

Modularity Design Rules (v.7 April 2018)36

5. MODULAR DESIGN RULES IN RNA'S DEVELOPMENT OF ITS CMF
MODULAR ARCHITECTURE
We think it is appropriate to note that 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 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 acommon vehicle architecture that would be the basis for projected production of nearly
two million vehicles whose costs of production would run into tens of billions of US
dollars. In addition, the CMF project had to find a way to bring together two firms withvery 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 vehiclearchitecture that would serve the interests of both firms well.
Perhaps the daunting nature and scale of the task facing the CMF team -- coupledwith the lack of any pre-existing management processes or organizational structures ineither company for accomplishing such a task -- left the CMF team no choice but to inventa radically new way of working in order to begin development of a common modular
architecture. In any event, we suggest that the management processes and organization
structures implemented by RNA senior management and the CMF team reflect theModular Design Rules elaborated in Section 2 to a remarkable extent.
At the launch of the CMF project, RNA senior management gave essential strategic
direction to the CMF development process by providing a clear statement of prioritizedstrategic 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 substantial reducing unit costs through use ofcommon components (while maintaining brand distinctiveness and requisite productModularity Design Rules (v.7 April 2018)37

variety), the CMF team was composed of both marketing strategy and technical staffs thatworked directly with each other and that were supported by and reported directly to
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 toprovide a stable technical structure for the new architecture to be developed, thestrategic partitioning of the CMF architecture into 4+1 "big modules" and then into thecomponents 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 andfrozen to enable concurrent development of components (MDR No. 9). The definedinterfaces were maintained through the component development phase both forstandard 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 theinterfaces between 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 vehicles models to be derived from the CMF
architecture and for components for new models to follow. Only after completingdevelopment 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, RNA senior
management demonstrated their willingness to perform the top management roles that
we have suggested (in Section 3) 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

Modularity Design Rules (v.7 April 2018)38

respective organization's management processes and organizational structures in orderto 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.

Modularity Design Rules (v.7 April 2018)39

6. Conclusions
The normative model of Modularity Design Rules for modular architecturedevelopment processes that we elaborate here reflects nearly two decades of theory
development and empirical research into modularity and modular architecture
strategies (Sanchez 1995, 1999; Sanchez and Mahoney 1996, 2013; Sanderson andUzumeri 1997; Worren, Moore and Cardona 2002). These modular development
processes are fundamentally different both 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" (Clark and Fujimoto 1991), which Sanchez and Mahoney (1996)
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 (2000) Design Rules was an early effort to delve into modular development
processes by suggesting that achieving technical decoupling among components inan architecture would be facilitated by decoupling the organizational processes fordeveloping 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 technicalperspective on Design Rules to present an interrelated set of managerial andorganizational rules that we suggest must be understood and followed in order toimplement successful processes for developing modular architectures of strategic
importance to an organization. We have also suggested that the top managements offirms have essential roles that they must fulfill in supporting the adoption andimplementation of Modular Design Rules.
We have sought to provide some empirical evidence in support of theModular Design Rules and essential top management roles elaborated here by

Modularity Design Rules (v.7 April 2018)40

reporting a case study of an initiative by the Renault-Nissan Alliance to create a"Common Module Family" modular architecture of major strategic importance tothe two firms that make up the Alliance. We suggest that the notable findings thatcan 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 RNA
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 casestudy, 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 casestudy provides conclusive evidence in support of our propositions. Rather, wesuggest that the empirical contribution of this paper is to add another case study toongoing 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.

Modularity Design Rules (v.7 April 2018)41

REFERENCES
Baldwin , Carlisss Y., and Kim B. Clark (1997). Managing in the Age of Modularity.
Harvard Business Review, Vol.75 , No.5.
Baldwin , Carlisss Y., and Kim B. Clark (2000). Design Rules: The Power of Modularity,
Vol.1, Cambridge, MA: MIT Press.
Brusoni, Stefano, Andrea Prencipe and Keith Pavitt (2001). Knowledge
Specialization, Organizational Coupling, and the Boundaries of the firm: Why Do
Firms Know More Than They Make? Administrative Science Quarterly, Vol. 46,
December, 597-621.
Brusoni, Stefano, Andrea Prencipe (2006).Making design rules: a multidomain
perspective. Organization Science, Vol. 17, 179-189.
Brusoni, Stefano and Andrea Prencipe (2001). Unpacking the Black Box ofModularity: technologies, Products and Organizations. Industrial and Corporate
Change, Vol. 10, No. 1, 179-205.
Chesbrough, Henry W. and Ken Kusunoki (2001). The Modularity Trap: Innovation,
Technological Phase Shifts and the Resulting Limits of Virtual Organization, I.
Nonaka and D. Teece, Eds., Managing Industrial Knowledge, London: Sage Press.
Christensen, Clayton and Raynor (2003). The Innovator's Solution, Harvard Business
School Press, Boston, Massachusetts.
Clark, K. B., and Fujimoto, T. (1991). Product development performance: Strategy,organization, and management in the world auto industry. Boston, MA: Harvard
Business School Press.
Colfer, L., and Baldwin, C. Y. (2010). The mirroring hypothesis: Theory, evidence andexceptions. Harvard Business School Finance Working Paper, (10-058).
Eisenhardt, K. (1989) Building theories from case study research. Academy ofManagement Review, 14, 532-550.

Modularity Design Rules (v.7 April 2018)42

Eisenhardt, K. M., and Tabrizi, B. N. (1995). Accelerating adaptive process: Productinnovation in the global computer industry. Administrative Science Quarterly, 40,
84-110.
Fine, Charles (1998). ClockSpeed: Winning Industry Control in the Age of
Temporary advantage. Reading, Massachusetts: Perseus Books.
Garud, R., and Kumaraswamy, A. (1995). Technological and organizational designs
for realizing economies of substitution. Strategic Management Journal, 16(S1),93-109.
Glaser, B.G. and Strauss, A.L. (1967) The Discovery of Grounded Theory: Strategies for
Qualitative Research, Aldine Pub. Co., Chicago.
Henderson, R and K. Clark (1990). Architectural innovation: The reconfiguration ofexisting product technologies and the failure of established firms. Administrative
Science Quarterly, March, pp9-30.
Iansiti, M. (1998). Technology integration. Boston, MA: Harvard Business School
Press.
Iansiti, Marco and Jonathan West (1997). Technology Integration: Turning Great
Research into Great Products. Harvard Business Review, May-June.
Langlois, Richard N., and Paul L. Robertson (1992). Networks and Innovation in amodular system: Lessons from the microcomputer and stereo component
industry. Research Policy, 21, 297-313.
Pandremenos, J., Paralikas, J., Salonitis, K., & Chryssolouris, G. (2009). Modularity
concepts for the automotive industry: a critical review. CIRP Journal of
Manufacturing Science and Technology, 1(3), 148-152.
Park, Jin-Kyu, and Young K. Ro (2013). Product Architectures and Sourcing
Decisions. Journal of Management Vol. 39 No.3, 814-845.
Robertson, David and Ulrich, Karl (1998). Planning for Product Platform. Sloan
Management Review, Summer.
Sanchez, Ron (1995). Strategic flexibility in product competition. Strategic
Management Journal, Vol. 16 (summer special issue), 135-159.
Sanchez, Ron (1999). Modular architectures in the marketing process. Journal ofMarketing, Vol. 63 (special issue 1999), 92-111.

Modularity Design Rules (v.7 April 2018)

43

Sanchez, Ron (2000). Modular architectures, knowledge assets, and organizational
learning: New management processes for product creation. International Journalof Technology Management, Vol. 19 (6), 610-629.
Sanchez, Ron (2004). Creating modular platforms for strategic flexibility. Design
Management Review, Vol. 15 (1), 58-67.
Sanchez, Ron (2005). ’Tacit knowledge’ versus ‘explicit knowledge’ approaches toknowledge management practice, pp. 191-203 in The Handbook of the Knowledge
Economy, David Rooney, Greg Hearn, and Abraham Ninan, editors, Los Angeles:
Edward Elgar.
Sanchez, Ron (2008). Modularity in the mediation of market and technology change.
Int.J.Techonology Management,Vol.42,No.4,pp.331-364.
Sanchez, Ron (2012). Architecting organizations: A strategic dynamic contingency
perspective. Research in Competence-Based Management, Volume 6, 7-48.
Sanchez, Ron (2013). Building real modularity in automotive design, development,
production and after service. International Journal of Automotive Technology andManagement, Vol.13, No.3, 204-236.
Sanchez, Ron (2015). The Essential Leadership Role of Senior Management in
Adopting Architectural Management and Modular Strategies (AMMS), with
Perspectives on Experiences of European Automotive Firms. Journal of Science
Policy and Research Management, 2-28.
Sanchez, Ron, and Robert P. Collins (2001). Competing—and learning—in modular
markets. Long Range Planning, Vol. 34 (6), 645-667.
Sanchez, R. and Hang, C.C. (2017). Modularity in new market formation: Lessons fortechnology and economic policy and competence-based strategic management.
Research in Competence-Based Management, Vol. 8, 131-165.
Sanchez, R. and J. Mahoney (1996). Modularity, flexibility, and knowledge
management in product and organization design. Strategic management journal,
Vol. 17 (Winter special Issue), pp. 63-76.
Sanchez, Ron and Joseph T. Mahoney (2013). Modularity and economic
organization: Concepts, theory, observations, and predictions, pp. 383-399 inModularity Design Rules (v.7 April 2018)44

Handbook of Economic Organization: Integrating Economic and Organization
Theory, Anna Grandori, editor, Los Angeles: Edward Elgar.
Sanderson, S. W. and Uzumeri, M. (1997). Managing product families. Irwin
Professional Pub.
Salvador, Fabrizio and Veronica Villena (2013). Supplier integration and NPD
outcomes. Journal of Supply Chain Management, Vol.49 No.1, 87-113.
Shibata, Tomoatsu, Masaharu Yano, and Fumio Kodama(2005). Empirical analysis ofevolution of Product Architecture. Research Policy, Vol.34, pp.13-31.
Shibata, Tomoatsu (2009).Product innovation through module dynamics. Journal ofEngineering and Technology Management, Vol.26, pp.46-56.
Siggelkow, N. (2007) Persuasion with Case Studies. Academy of Management Journal,
50, 20-24.
Simon, Herbert A. (1981). The Science of the Artificial (2nd Edition). Cambridge,
Mass: MIT Press.
Spear, S., and Bowen, H. K. (1999). Decoding the DNA of the Toyota production
system. Harvard Business Review, 77(5), 96-106.
Takeuchi, H., and Nonaka, I. (1986). The new new product development game.
Harvard Business Review, (1986,January-February), 137-146.
Ulrich, Karl (1995). The role of product architecture in the manufacturing firm.
Research Policy, 24, pp. 419-440.
Worren, N., Moore, K., and Cardona, P. (2002). Modularity, strategic flexibility, andfirm performance: A study of the home appliance industry. Strategic
Management Journal, Vol. 23 (12), 1123-1140.
Yin, R. (1994). Case Study Research: Design and Methods, second edition. Sage
Publications Inc.