Discussion Paper Series

AGISSS
Gakushuin University
No. 2020-2
Modularity Design Rules for Architecture Development:
Theory, Implementation, and Evidence

Ron SANCHEZ, Tomoatsu SHIBATA

Association of Gakushuin International Social Sciences Studies
1-5-1 Mejiro, Toshima-ku, Tokyo 171-8588 JAPAN1

Modularity Design Rules for Architecture Development:
Theory, Implementation, and Evidence

Ron Sanchez, PhD
Copenhagen Business School
Kilevej 14A - 3rd Floor
DK-2000 Frederiksberg, Denmark
email: sanchez@cbs.dk

Tomoatsu Shibata, PhD
GAKUSHUIN University, Japan
1-5-1, Mejiro, Toshima-ku, Tokyo, 171-8588, Japane-mail : shibatatomoatsu@gmail.com

Abstract
In this paper we propose a set of rules for developing modular architectures. We
extend the technical concept of "Design Rules" advanced by Baldwin and Clark(2000) and propose a set of normative "Modularity Design Rules" derived from
subsequent research into the strategic, managerial, and organizational processes thatmust be also undertaken to implement successful modular development projects. We
then provide support for the proposed Modularity Design Rules through a case studyof the Renault-Nissan Alliance's successful development and use of a modular"Common Module Family" architecture.

Key Words: Design Rules, Architectures, Modularity, Product Development.

2

INTRODUCTION
Beginning in the 1990s, a major new stream of management research began toinvestigate how the architectures a firm adopts for its product designs may affect thekinds of strategies a firm may pursue in its product markets (Garud and Kumaraswamy
1995; Sanchez 1995, 1999; Sanchez and Mahoney 1996; Robertson and Ulrich, 1998;
Shibata, Yano and Kodama, 2005; Shibata, 2009). Research in this stream establishedrather conclusively that use of modular architectures may enable firms to significantly
reduce overall development times and costs, increase speed to market, and increase
product variety (Langlois and Robertson 1992; Sanchez 1995, 1999, 2008; Sanchez and
Mahoney 1996; Chesbrough and Kusunoki 2001; Worren, Moore and Cardona 2002;
Sanchez and Hang 2017).
A number of firms in a variety of industries have successfully developed modular
architectures and achieved significant strategic benefits thereby, but many other firms
have failed to develop or use modular architectures successfully. Some researchers who
have studied both successful and unsuccessful modularity initiatives in firms havesuggested that new kinds of management processes and organization structures are
required to achieve success in developing modular architectures (Sanchez 2000; Sanchez
and Collins 2001).
These new kinds of processes and structures differ fundamentally from practices
typically used in conventional new product development (NPD) processes, as well asfrom practices like "overlapping problem solving" (Clark and Fujimoto 1991) that try to
improve the speed of conventional NPD processes (Sanchez 2000, 2008; Sanchez andCollins 2001; Colfer and Baldwin 2010). As a consequence, both technical and strategic
managers are likely to face significant challenges in understanding and implementing
new management processes and organization structures in converting their firms fromconventional NPD processes to modular development processes.
In conventional NPD processes, technical managers are typically focused on
developing new kinds of components for next-generation products, while the interfacesthat must connect the new components under development are (necessarily) allowed to"evolve" during component development processes. In implementing modular

3
development processes, however, technical managers are likely to be challenged because
modular development processes require fully specifying, freezing, and adhering tointerface specifications as the first step in modular development processes -- i.e., before
beginning development of new components. Fully specifying component interfaces
before beginning component development, however, creates an "information structure"(Sanchez and Mahoney 1996) that can enable a firm and its suppliers to undertake
concurrent component development processes that can significantly reduce overall
development times.
For their part, strategic managers are likely to be challenged by the need toadequately define the strategic objectives for each new modular product architecture
before beginning modular development processes (Sanchez 2000, 2013, 2015).
Adequately defining the strategic objectives for a new architecture is essential todetermining (i) the most advantageous strategic partitioning of the new architecture intofunctional components and (ii) the most effective specifications of interfaces between
components -- both of which are needed to create a modular architecture that can
provide a strategically intended range of product variations and upgrades derived fromthe configurability of components within the new modular architecture (Sanchez and
Mahoney 1996; Sanchez 2000).
Moreover, as we elaborate below, to create a new modular architecture, technicaland strategic managers must also interact through a specific sequence of informationexchanges and decision-making steps. These information flows and decision-making
processes form the core of the new management processes and supporting organization
structures that we propose are essential to successful creation of modular architectures.
In their well-known study of the technical structure of the IBM System 360
computer architecture, Baldwin and Clark (2000) concluded that certain essentially
technical "Design Rules" must be followed in order to create a modular productarchitecture. At the same time and subsequently, using "real-time" research methods toinvestigate efforts by firms in a number of industries to implement modular development
processes, Sanchez (2000, 2013, 2015) proposed that managing modular development
processes requires following certain "new rules and new roles" that differ fundamentallyfrom management practices in conventional NPD.

4
In this paper, we elaborate a formal set of Modularity Design Rules ("MDRs") that
identify specific strategic, managerial, and organizational practices that we suggest are
essential to achieving success in modular development processes. We also undertake tolend some measure of empirical support to the proposed MDRs by reporting some key
findings from a multi-year longitudinal study of the Renault-Nissan Alliance's (RNA)highly successful initiative to create a "Common Module Family" (CMF) modular
architecture.1 We suggest how RNA's success in creating the CMF modular architecture
followed largely from (i) RNA management's realization of the need for new kinds ofmanagement processes and organization structures, and (ii) RNA's implementation of
new management processes and organization structures that closely mirror the MDRs we
propose here.
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 modular architecture development processes proposed by Sanchez(2000).
In Section 2 we elaborate our proposed set of 10 Modularity Design Rules andexplain both the theoretical basis and practical considerations motivating each rule.
In Section 3 we present an overview of longitudinal study of Renault-Nissan
Alliance's development of its first "Common Module Family" modular architecture.
Section 4 summarizes the key findings from our case study that we believe
lend support to the Modularity Design Rules we propose here.
Section 5 offers concluding comments.

1 We note that the CMF modular architecture development process undertaken jointly by Renault

and Nissan precedes by several years the recent disagreements between Renault and Nissan overownership interests and a possible effort by Renault to take over Nissan.

5

1. "DESIGN RULES" RECONSIDERED
In the mid-1990s some management researchers began to observe that somefirms using modular product designs successfully had adopted new kinds of management
processes and organizational forms to support their development of modular productarchitectures (Garud and Kumaraswamy 1995; Sanchez 1995; Sanchez and Mahoney1996). In 2000, two key studies offered some early insights into the nature of thedevelopment processes that firms could use to create modular architectures.
In 2000 Baldwin and Clark published their well-known book Design Rules, basedlargely on their historical study of the technical structure of the 1960s IBM System 360
computer's modular architecture. Adapting the Quality Function Deployment matrix
used in Total Quality Management (Hauser and Clausing 1988), Baldwin and Clarkdeveloped a "Design Structure Matrix" ("DSM") for identifying the interactions among
components within a product design. Their DSM analysis showed that certain
components in the IBM System 360 were intentionally isolated or "decoupled" technicallyfrom other components -- thereby enabling the introduction of component variations toconfigure a range of product variations for meeting different customer requirements forcomputing. Baldwin and Clark then proposed a set of "Design Rules" for creating
technical decoupling among components during the architecture development process.
Concurrently, based on several "real-time" studies of ongoing modular
development processes in Philips, General Electric, Chrysler, and other firms, Sanchez(2000) proposed that achieving success in creating modular architectures requires new
approaches to organizing and managing development processes. In effect, Sanchez(2000) argued that the technical design rules revealed through DSM analyses in themanner proposed by Baldwin and Clark (2000) can only be implemented successfully
when a firm has first adopted a set of "new rules and new roles" for organizing andmanaging modular development processes.
In the next section, we draw on and extend this broader perspective to elaborate a
set of 10 Modularity Design Rules (MDRs) for carrying out the organization andmanagement of modular development processes.

6

2. MODULARITY DESIGN RULES (MDRs)
We begin our elaboration of new rules for managing modular architecturedevelopment processes by making a critical distinction between "technicalmodularity" and "strategic modularity" in product designs. We then elaborate the 10
MDRs in three categories: (i) rules that apply to strategic, organizational, andmanagerial processes to be undertaken before beginning technical development of
the components to be used in an architecture (Section 2.2), (ii) rules that apply mostcritically during the technical development of components (Section 2.3), and (iii)
rules that apply after the technical development of components and during thecommercial use of the architecture (Section 2.4).
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 firms' product designs, as well as
in the development processes through which different firms have sought tointroduce modularity into their product designs. On this basis, Sanchez (2013,
p.209) 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
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 new design by re-using pre-existing or "industry
standard" component designs and/or interface specifications. For example,
engineering designers often adopt industry-standard bolts and bolt patterns forconnecting various kinds of components, and industry-standard electronic interfaces(like USB interfaces) for connecting digital devices.
By contrast, strategic modularity is created through a strategically motivatedarchitecture development process in which the strategic partitioning of the

7architecture 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 and interfaces in an architecture may be designed with a primaryobjective of allowing a wide range of component variations to be freely used inconfiguring a strategically desired range of product variations.
The MDRs that we elaborate here apply to firm processes whose intention is tocreate strategically modular product architectures with specific forms of strategic
flexibility intended to directly support a firm's product strategies. Note also that the
MDRs that we elaborate below are not intended to describe all the various ways thatfirms have tried to develop modular product architectures. Rather, the MDRs
elaborated here are normative rules for ordering the strategic, organizational, andmanagerial processes that we propose are essential to the successful developmentof strategically-motivated modular architectures.
The normative MDRs proposed here are derived both from modularity theory
and from observations and analyses of successful and unsuccessful attempts todevelop modular architectures in a wide variety of firms an industries.2 This
research suggests that very few firms are likely to recognize the need for a broad
new set of rules for managing modular development processes like the MDRs weelaborate here. Moreover, even fewer firms are likely to have the managerial andorganizational capacity to implement modular development processes that adhere
to these rules. However, such firms and processes do exist, as we note below, andwe suggest that these firms' successes in creating and using modular architectures
lend support to the validity of the MDRs we elaborate below.

2 The MDRs that we elaborate here are drawn from more than 25 years of "real-time action

research”2 into numerous firms' processes for creating modular product architectures in theautomotive, aircraft, consumer electronics, information technology, manufacturing equipment, officeequipment, home appliance, personal health care, medical equipment, food confections, financial
services, health services, and travel industries (Sanchez 1995, 2000, 2013, and 2015), as well as frommulti-year longitudinal studies of modular development processes in a number of Japanese firms(Shibata et al. 2005; Shibata 2009).

8
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 relatively late and predictable stage insuccessful processes for creating modular architectures. As we elaborate below,
once the strategic objectives, strategic partitioning of components, and interface
specifications for a new modular architecture have been decided, the technicaldevelopment of components for a new modular architecture may not only beundertaken concurrently, but should also be a fairly routine exercise.
We therefore begin this discussion by elaborating the MDRs that apply to the
key strategic, managerial, and organizational processes that need to be undertaken
in order to define adequately the strategic objectives for a new product architecture-- and that therefore must precede and then guide processes for developing thecomponents for a new architecture.3
MDR No. 1:
A new modular architecture must be developed using only proven component
designs whose system behaviors are well understood and whose interfaces cantherefore be reliably specified.
We begin our list of MDRs with one of the least understood rules fordeveloping modular architectures. A modular architecture is modular precisely
because it uses component designs that are technically independent (or "decoupled"from) other component designs in the architecture. In order to technically decouple
component designs within an architecture, a firm's developers must know how eachkind of component will behave when used in the intended product architecture – i.e.,the system behaviors of each component. Only when a component's system
3 The numbering of the MDRs is intended to provide a way to refer to specific MDRs in our discussion.

It is not intended to denote a strict sequential order of application of the MDRs 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 and commercialization of a
new modular architecture.

9
behaviors are well understood can developers define interface specifications for thecomponent such that introducing a range of variations of the component into thearchitecture will not require compensating changes in the designs of othercomponents in the architecture. This technical decoupling of components confers anumber of strategic benefits that are fundamental to modular architectures,
including the ability to develop components concurrently, resulting in fasterdevelopment times, and the ability to "plug and play" components within a modular
architecture -- i.e., to substitute a range of component variations freely within anarchitecture to configure new product variations (Garud and Kumaswamy 1995,
Sanchez 1995).
Defining interfaces that enable technical decoupling of components within amodular architecture cannot be achieved with new, unfamiliar kinds of components
whose system properties are not yet well understood (e.g., components based onnew, unproven technologies). Thus, a bedrock principle of modular development
processes is that new modular architectures should only incorporate components
whose system behaviors (in the inteded type of product architecture) are alreadywell understood -- and whose interfaces can therefore be reliably specified.
A common misunderstanding about MDR No. 1 is the belief that restricting
development of modular architectures to incorporating only well-understood,
proven component designs will limit the ability of firms to introduce innovative new
products with new technologies embodied in new kinds of components. Thismisunderstanding overlooks the highly disruptive effects and consequential delays
that result in conventional development processes 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 total development
time can be expended in repeatedly redesigning other components as errors andomissions in the evolving interfaces for unproven component designs 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 such well-understoodcomponents with reliably specifiable interfaces can be introduced into next-

10
generation architecture development projects. Studies have shown that some firms
have been able to radically accelerate their overall innovation processes by "fastcycling" through rapid development of successive generations of new architectures - a process that is possible only when each new generation of architecture
incorporates technically new components only after their system behaviors havebeen adequately investigated and reliable interfaces can be specified (Sanchez and
Mahoney 1996; Sanchez 2004).
MRD No. 2:
Development of new technologies and new types of component designs based on
new technologies must be carried out independently of and prior to their use in a newmodular architecture development process.
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.4 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 from 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 then be developed “off line” inparallel development processes until their system behaviors are understood andinterfaces for each new type of component can be reliably specified (“proof of
4 See discussion of "Decoupled Architectural Learning" from Figure 2(c) in Sanchez and

Mahoney (1996), p71-72.

11
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

Once new kinds of component designs have been developed and their systemproperties determined with confidence, the new component designs and theirattendant interface specifications can be released into a "design library" of provencomponent 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 modular architecture is essentially a technical creation with astrategic mission, technical managers and strategic managers must work closely
together to define next-generation modular architectures. The functionalities andattributes that are strategically desired from a new modular architecture must be12communicated by strategic managers to technical managers, who must in turnprovide strategic managers with their assessments of what functionalities andattributes can be provided by the current design library of proven component
designs available to the firm in developing a next generation architecture. Throughan interactive dialogue, strategic and technical managers must jointly decide thecomponents and interfaces that can reliably be used in the new architecture andtherefore the resulting functionalities and attributes the new architecture canprovide. These consultations between strategic and technical managers constitutethe essential first step in initiating a new 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.
A number of strategic benefits may be obtainable from a new modular
architecture, 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 alreadydeveloped by other firms), and increasing speed to market (through concurrent
component development processes, re-using existing components, and/or involving
more partners 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 potentially available benefits in developing a new architecture.
In order for technical managers to know how to strategically optimize amodular architecture during development, strategic managers must provide
technical managers with a strategically-prioritzed ranking of the modularity
benefits to be sought from a new architecture. Without a clear set of priorities fromstrategic mangers, any technical trade-offs that technical managers may be forced tomake during development are unlikely to be strategically coherent or to result in a
new architecture that can provide the kind and degree of strategic benefits sought

13from the next-generation architecture.
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 newmodular architecture, the strategic 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 architecture to be a "moving target" has been shown to be highly disruptive
to any product development process, whether modular or non-modular. To
preserve the key advantage of using concurrent and distributed development
processes for components in developing modular architectures, changes in thestrategic benefits desired from a new 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” throughsuccessive 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 (Sanchez 2013, 2015).
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. Most fundamentally, components that will be sources ofperceived variety in differentiating products should be kept separate and technicallydecoupled from other components, so that design variations of those components
can be developed and freely introduced into a new architecture. By contrast,
components whose functionalities don't have to change may become "cost drivers"
when using common components across all or many product models may lead toeconomies of scale or increased buyer power. In some cases, common components

14
may be combined into subassemblies of "core components" or even integrated
components designs that combine several functions.
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 strategically partitioning
the new architecture into functional components would affect the newarchitecture's ability to deliver the prioritized strategic benefits sought from thearchitecture -- and at what cost of development and production. Strategic andtechnical managers must then agree on the optimal approach to partitioning anarchitecture into functional components, given current strategic objectives andtechnical constraints for the next-generation architecture.
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 primary emphasis in conventional NPD processes is typically on
developing new components, while the specification of workable interfaces between
components is often treated as a relatively unimportant (or "uninteresting")
technical detail. As a result, interfaces between components are often allowed to“evolve as needed" during conventional NPD processes or are simply deferred to thelast stages of a development process.
In modular architecture development processes, however, interfaces between
components must be fully specified before beginning development of specificcomponent variations for a new modular architecture. Both the ability to develop
initial component designs in parallel (concurrent component development) andsubsequently to design component variations that can be freely substituted into anarchitecture depend on having stable, fully specified interfaces for the architecture.
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" in15
a 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 component development processes.
2.3 Modularity Design Rules: During Detailed Component Development
As suggested earlier, if MDRs No. 1 to No. 7 have been followed in thearchitecture development process leading up to the launch of detailed component
development, then the processes for developing specific component design
variations for a new architecture should become relatively routine. However,achieving the strategic benefits sought from a modular architecture, both during andafter development, depends on a firm's ability to maintain two critical forms oforganizational discipline during detailed component development processes, as
addressed by MDRs No. 8 and 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

16
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."
Once the strategic partitioning of the architecture into functional components
is agreed, however, any changes in the component structure of the new architecture
would be highly disruptive to ongoing component development processes -- for thesame reasons stated under MDR No. 5 for freezing the strategic benefits to be soughtfrom a new architecture. Thus, strict organizational discipline is required to assurethat the strategic partitioning of components agreed by strategic and technicalmanagers prior to the beginning of detailed component development is in fact theset of components that developers actually develop.
MDR No. 9:
Once the interfaces are specified for the components in a new architecture, theinterfaces must be frozen and not allowed to change during ensuing processes fordetailed development of specific component designs for the new architecture.
A modular architecture is a system of components in which the interfaces thatare specified between components will largely determine whether the components
function together reliably. If not fully and properly specified, the interactions
between the components in any system may generate aberrant behaviors.5 As aresult, even simple and seemingly innocuous changes in interface specifications
during or after development of detailed component designs may create
unanticipated, unintended, and usually undesired changes in the ways thecomponents interact within the architecture.
While it is common practice in conventional NPD to allow changes in interfaces
between components during component development, the concurrent and possibly
distributed development of components in a modular development processes
5 Sanchez (1999) identifies 8 kinds of interfaces to be specified in physical product architectures,with closely analogous kinds of interfaces in process architectures and organization architectures.

17depends on maintaining a consistent set of interface specifications that assure astable technical environment for developing the component variations intended fora new architecture.
A further, very important strategic benefit of strictly adhering to initialinterface specifications during detailed component development is that doing so willquickly reveal how capable an organization is of specifying interfaces that will
enable all the components in a new architecture to perform as intended. Wheninterfaces can be changed by developers during component development, it
becomes highly problematic, if not impossible, to determine whether developers
have been able to adequately define the interface specifications needed for a newarchitecture at the beginning of a modular architecture development process. Thus,
requiring developers to specify and then adhere strictly to interfaces throughout
detailed component development provides a key means for managers to evaluate
the technical capabilities and commitment of their organization'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 visibility into developers’ capabilities that results from requiring developers to fully specify andadhere to interfaces during detailed component development processes may be seen as threatening
by some developers, who may seek to resist fully specifying an freezing interfaces in various ways,
including through claims of “impossibility.” In such cases, it may be useful to keep in mind that
"impossibility" results from a lack of either knowledge or volition. If a developer genuinely lacks theknowledge to specify the interfaces for a new component, then the component should be investigatedfurther through the "off line" development process for new kinds of components. If the"impossibility" appears to be volitional, however, managers may need to seek to achieve a closeralignment of the motivation of the developer with goals of the organization.

18
Once a new architecture is developd and put into commercial use,organizational responsibility for the architecture is often transferred fromdevelopment engineers to engineers charged with "maintaining" the architecture.
Unless this new group of engineers is fully informed about the strategic purpose forthe 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. Suchchanges may, however, have very undesirable consequences.
Maintenance engineers may try to make the same kinds of "cost-saving"changes to the component structure of an architecture that component developers
sometimes want to make 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 ofchanges to components and their interfaces could lead to unexpected behaviors ofcomponents within the architecture, or could limit the ability to introduce
component variations 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 theoriginal components or interfaces, lest they affect the reliability or configurability 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 tocontinuously improving assembly task definitions and in identifying individual
workers in need of more training (Spear and Bowen 1999). Analogously, the ability

19
to link the component designs and interface specifications provided by specificdevelopers to the subsequent performance of the architecture is essential toidentifying individual and organizational capabilities that need to be improved indeveloping effective modular architectures (Sanchez 2000, 2005; Sanchez andCollins 2001).

3. RENAULT-NISSAN ALLIANCE'S TRANSITION TO A "COMMON MODULE
FAMILY" MODULAR ARCHITECTURE
We now provide an overview of a multi-year longitudinal study by this paper's coauthors of the Renault-Nissan Alliance's (RNA) development of a modular "Common
Module Family" (CMF) architecture.7
The ambitious strategic objectives articulated by RNA strategic managers for the
CMF architecture were two-fold: First, the CMF architecture was to achieve a targeted
30% reduction in per-vehicle costs through extensive use of common components acrossmodel variations. Second -- and equally important -- the CMF architecture was to enable
the configuration of more than 50 Renault and Nissan branded product models with
distinctive brand identities and readily apparent functional and stylistic differences. Our
study examined both the modular vehicle architecture developed by RNA and the
managerial and organizational processes implemented by RNA senior management tosupport the transition from conventional NPD to modular development processes.
In the following discussion, we summarize the strategic motivation for RNA toadopt the CMF modular architecture and the changes in management processes and

7 The longitudinal case study whose key findings are reported here included extensive interviews

with key Nissan and Renault-Nissan Alliance (RNA) executives and managers between
November 2012 and August 2013, with periodic follow-up interviews through 2017. 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 their generous cooperation in gathering detailed information on theprocesses initiated by RNA for the development of the CFM modular architecture, and in
confirming our interpretations of data provided by sources within RNA. We also thank Mr.
Yamamoto for reviewing several draft versions of the findings reported here.

20
organization structure undertaken by RNA to support development of the CMF modular
architecture.
3.1 Modularity in RNA's Global Strategy
The global automotive industry has historically faced both increasingly substantial
sunk costs for product development and production tooling, on the one hand, and rapidly
rising demand for more differentiated models and more frequent introductions of newmodels, on the other. Given these two conflicting pressures, it was perhaps inevitable thatat least some major automobile producers would turn to modular product architectures
to seek new possibilities for reducing costs while increasing product variety.
The modular "platform" architectures adopted by Volkswagen in the early 1990s,
for example, both sought and achieved substantially lower product costs while also
adding new product models and increasing the "refresh rate" of its platform models, as
has been extensively reported (Pandremenos et al. 2009). The Renault-Nissan Alliance,
formed in March 1999 by the French producer Renault and the Japanese producer Nissan,
pursued similar objectives through an ambitious initiative to create a new modular
vehicle architecture.
In February 2012, Mr. Carlos Ghosn, then President and Chairman of RNA,announced the launch of a "4+1 Common Module Family" (CMF) program whose generalintent was to create a modular vehicle architecture that would achieve substantial vehicle
cost reductions while providing an expanded range of models for the Renault and Nissanbrands. The "4+1" refers to the strategic partitioning of the new CMF modular vehiclearchitecture into four large body modules (engine compartment, front underbody, rearunderbody, 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21distinct body shapes for different product models produced under the Renault and Nissanbrands.

Figure 2: “Big Modules” in “Common Module Family” (CMF) Architecture(Source: Renault-Nissan Alliance)

The specific strategic objectives for the first stage of RNA's conversion to the CMF
modular architecture were (i) to achieve at least a 30% reduction in per vehicle
production costs through large-scale production and assembly of common bodymodules and components, while (ii) also enabling configuration of an expanded
range of Sport-utility vehicles (SUVs) vehicles with distinctly different designs. The
cost savings to be achieved through cost reductions for common modules andcomponents were then to be invested in improving the environmental and safety
performance of 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-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22
10 Renault SUV models) were brought to market by mid-2017. The CMF architecture
achieved at least 56% component commonality (cost basis) between Renault andNissan SUV vehicles -- and thereby realizing the targeted 30% reduction in
production costs per vehicle, as well as substantial reductions in development cots -while maintaining the distinctiveness of Renault and Nissan vehicle designs andexpanding the number of distinct product models available to each firm in the RNA
global product portfolio.8
3.2 Launch of the CMF Initiative
The CMF initiative announced by Carlos Ghosn in February 2012 wasconceived 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 conventional, model-focused development
processes to a new modular 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 ofspecific responsibilities for the CMF architecture initiative to several several senior
executives within both Renault and Nissan. Moreover, selection of staff from various
areas of the two companies for participation in the CMF project was communicatedas an important form of personal recognition and as an opportunity to play a keyrole in shaping the RNA of the future. All told, just over 200 people were selected
8 During the CFM architecture development process, RNA managers came to believe that the"optimal extent of commonality" of components to be sought through the CFM architecture
would lie somewhere between 50% and 75% commonality of components in all 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.

23
and charged with creating not just the first CMF for RNA -- but also with creating the
new management and organizational processes that would unite the two companies
in defining and developing the CFM architecture that would be the common basis
for their future strategies.
3.3 New Organization Structures and Management Processes for
Strategic Partitioning of the CMF Modular Architecture
As we have noted in Section 2, once the prioritized strategic objectives for a
new modular architecture have been defined, the first step in the modular
architecture development process is to determine the most effective strategic
partitioning of functional components to support the prioritized strategic objectives
for the new modular architecture. The CMF project team recognized that deciding
the most effective strategic partitioning of the architecture would require extensive
consultations between the two firms' marketing and technical managers -- but thatno structures or processes existed within Renault or Nissan for jointly making sucha critical decision. Beginning in September 2009, the CMF team leaders therefore
focused on defining the new organizational structures and management processes
that they believed they would need in order to decide how to partition the the CMF
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 each of the two companies. The CMF teamalso recognized that if staff from the two areas of expertise and/or from the twocompanies 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 organization structure adopted by the CMF team to support the strategic
partitioning of the CMF architecture is shown in Figure 3. In this structure, the Chief
Vehicle Engineer (CVE) is responsible for all the technical aspects of the vehicles
configured within the new CMF architecture, while responsibility for market
analysis and planning for the vehicles to be derived from the new architecture is24vested in the Chief Product Specialist (CPS). Overseeing this structure and its
decision process process is the Program Director (PD), who in the absence ofagreement between the CVE and CPS, has the authority to interpret the specificmarket goals for the CMF architecture, to decide the range of vehicles thearchitecture will support, and to set the number of vehicle variations to beleveraged from the architecture. These three senior managers (drawn from both
Renault and Nissan) were jointly charged with managing both the development of
the CMF architecture and the subsequent configuring of individual models within
the CMF architecture.

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)

Using this structure to carry out essential consultations, the CMF
management team eventually decided that an architecture strategically partitioned
into four big body modules and one electrical/electronic module would mosteffectively serve and support the strategic priorities for the new architecture (SeeFigure 2). A "module manager" was then appointed for each of the 4+1 big modules.
The module managers were made responsible for the design and development of

25
their module, for subsequent performance improvements for their module, and forthe compatibility of all the components used within their 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 the desired scale economies from extensive use of common
components, the CMF team had to further strategically partition each of the 4 big
module to define the specific kinds of components to be used in each module and to
identify which components 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 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 production costs, on the one hand, andallowing region-specific component variations to locally adapt vehicles to meetregional market preferences and requirements, on the other. Second, for many kindsof components Renault and Nissan had historically used different kinds of design
solutions (referred to as "Technical Policies" within Nissan). As a result, the two
firms had different ways of locating and otherwise integrating various components
within their respective 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 generalarrangement of the engine compartment, and the positioning of driver andpassenger 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 bypurely technical solutions. 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

26
component whose functionality and design could not be agreed between the two
firms or between marketing and technical staffs was therefore identified as a "RoadBlock" ("RB" for short). Identified RBs were, in effect, the manifestations ofsignificant technical or strategic differences between two companies that would
have to be resolved by senior managers before the two companies could begin tocreate a vehicle architecture with substantial component commonality. The CMF
team realized that new management processes would have to be created to makedecisions about the common components to be used by the two companies andremove each Road Block to creating the CMF architecture.
Within a few months, more than 800 component RBs were identified acrossthe 4+1 big modules. To resolve the 800+ RBs, senior RNA management establisheda new management process composed of a Joint Steering Committee (JSC] for eachof the five big modules (see Figure 4). Each JSC was composed of senior marketingand technical managers from both firms and reported directly to the senior
executives of both firms. The JSC for each big module then assigned CMF teammembers and other RNA staff with relevant marketing and technical expertise towork together in "Upstream Strategic Focus Teams” (USFTs) to resolve eachcomponent RB. In all, 76 USFTs were created to resolve Road Blocks for specifictypes of components, and more than 1500 employees from Renault and Nissan
participated in 76 USFTs focused on resolving component RBs.
Importantly, the JSC promulgated a "new rule" that no development work on
any component could begin until all RBs for that component had been resolved andapproval for the component type had been received from the JSC responsible for thepart of the CMF architecture that incorporated each component. For their part, theJSCs coordinated with the Cross-Company Team of senior executives from bothcompanies who were tasked with assuring that each technical solution accepted for
an identified RB would be effective in supporting each firm’s marketing strategy.
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 to27
coordinate the two firms' marketing plans for models derived from the first CMF
architecture.

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)

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 for the CFM architecture was 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

28
components for individual vehicle models. By standardizing on common
components to be used in all or many vehicle models, the production volumes foreach component used in the CMF architecture increased dramatically -- from typicalsingle-model component lots of 50,000 to 100,000 units to more than 1,700,000
units for components used in all CMF models. The shift from small lots of many
component variations to large lots of relatively few common components meantthat 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 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 that would be effective insupporting 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.
3.5 Processes for Specifying and Controlling Interfaces During and After
Development
As in any modular architecture, the interfaces between the CMF 's 4+1 big
modules and between each module's respective set of components determined theease with which -- and thus the extent to which -- the big modules could be mixed
and matched to configure different product models, as well as the extent to which

29
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 tobecome common components within the CFM architecture. For example, the CMF
architecture defined common interfaces for attaching all roof panels, but some roof
panels that were important in differentiating specific product models could bedesigned later as long as they conformed to the roof attachment interface.
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 technical 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 checkthe suitability of the interfaces between modules and components during
development.

4. MODULAR DESIGN RULES IN RNA'S DEVELOPMENT OF THE CMF
MODULAR ARCHITECTURE
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 firsteffort by Renault and Nissan to create a modular architecture that would serve thediverse requirements for their individual brands of vehicles in the Asian, European, andNorth 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

30
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
find 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, for this discussion the most noteworthy aspect of the
management processes and organization structures implemented by RNA senior
management and the CMF team is how extensively they embodied the Modular Design
Rules that we propose in Section 2.
At the launch of the CMF project, for example, RNA senior management provided aclear 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 objectives of substantially reducing unit costs through useof common components while maintaining brand distinctiveness and requisite productvariety, 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 development task undertaken by the CMF team was deciding thecomponent 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 andfrozen to enable concurrent development of components (MDR No. 9). The definedinterfaces were maintained through the component development phase both for31standard components that would be used across many or all product models within the
CMF architecture and for component variations 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. This rule applied to both components for the initial vehicles models to be derived
from the CMF architecture and for future 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, RNA senior
management demonstrated their willingness to perform the top management leadershiproles that we suggest here are essential to achieving success in any modular architecturedevelopment process: RNA's senior and middle managers were willing to learn asignificantly new way of setting product strategies and managing development processes.
They were willing to become personally involved in directly monitoring and supporting
the modular architecture initiative. They were willing to undertake significant change intheir respective organization's management processes and organizational structures inorder to implement the new modular way of working. And they were willing personallyto bearing the risk of supporting a new modular architecture development process thatwould lay the foundations for their two companies' futures.

32

6. CONCLUSIONSThe 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 strategies and modular
architecture development processes (Sanchez 1995, 1999; Sanchez and Mahoney1996, 2013; Sanderson and Uzumeri 1997; Worren, Moore and Cardona 2002). This
research strongly suggests that successful modular development processes arefundamentally different from the practices widely used in organizing and managing
conventional new product development. They also differ fundamentally from
related development models such as "Overlapping Problem Solving" (Clark andFujimoto 1991), which Sanchez and Mahoney (1996) characterize as essentially aneffort 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" to present an interrelated set of rules for management
processes and organizational structures that we suggest must be understood andfollowed in order to implement processes for successfully developing modular
architectures. We have also noted that senior managers have essential roles thatthey must fulfill in supporting the implementation of modular development
processes.
We have also drawn on our study of the Renault-Nissan Alliance successful
initiative to create a "Common Module Family" modular architecture to provide

33
some empirical evidence in support of the Modular Design Rules we have proposed.
Our case study shows that all ten of the Modular Design Rules that we propose here
were in fact recognized as necessary and followed by RNA senior management andthe CMF development team in their highly successful development of the CMF
modular architecture.
There are obvious limits to what can justifiably be inferred from a single casestudy, even one reporting such a remarkable achievement as this one does. We
therefore do not suggest that the "single data point" that we have reported in ourcase study 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 development of modular architectures
requires implementing specific managerial processes and organization structuresthat should be designed and implemented in accordance with the set of Modularity
Design Rules that we propose here for governing those processes and structures.

34

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.

35
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.
Hauser, J.R, and D. Clausing (1988). The House of Quality. Harvard Business Review,May 1988, 3-13.
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.

36
Sanchez, Ron (1999). Modular architectures in the marketing process. Journal ofMarketing, Vol. 63 (special issue 1999), 92-111.
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.

37
Sanchez, Ron and Joseph T. Mahoney (2013). Modularity and economic
organization: Concepts, theory, observations, and predictions, pp. 383-399 in
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.