Annals of Business Administrative Science 7 (2008) 1–18
Available at www.gbrc.jp

Online ISSN 1347-4456 Print ISSN 1347-4464©2008 Global Business Research Center

A Generation-Selection Process of Product Architecture:
A Case of Development of the Firmware in Digital MFP

Mitsuhiro FUKUZAWA
Graduate School of Economics, the University of Tokyo
E-mail: mifukuzawa5@gmail.com

Abstract: In this article, we focus on the firmware development process that has recently
become larger and more complex in the context of digitalization. From a case study involving
the development of the firmware for a digital multifunction peripheral (MFP), the firmware
architecture have changed alongside the change in organizational structure. As a result, somesuggestions are made for the generation and selection process of a product architecture
suitable for multi-functionalization, as well as for the ideal form of interdepartmental
coordination in an organization. Moreover, the limits of the existing arguments about thedevelopment of product architecture are revealed and a new viewpoint is proposed toinvestigate the dynamics of product architecture.
Keywords:

product

architecture,

firmware,digitalization,

multi-functionalization,interdepartmental coordination, digital MFP

firmware. Because of this, the scale and complexity

1. Introductionof the firmware has increased. Concurrently, theRecently, in many product areas such as information

development cost of the firmware has come to occupy

household appliances, portable devices, automobiles,

a large portion in the whole product development

and industrial instruments, there has been an increase

cost. This has placed an urgent need for an efficientin the functions realized by the firmware1 or by thefirmware development. For example, a high-end

interaction

model automobile, which can be defined as a typicalbetweenthe

hardwareandthemachine product, is now equipped with around a1

It can also be called embedded software, but in this article,
we use the term firmware.

hundred electronic control units (ECU, each1

Fukuzawa

consisting of a microcomputer and its firmware),provide good multi-functionalization? What kind ofwhich are used to realize numerous functions. In

organization is suitable then, in order to accomplishorder to ensure that these functions have a highcoordination and integration of these firmware

quality, it is important that multiple ECUs arecomponents?

controlled comprehensively, which is an urgent task

To answer these questions, in this article, we firstfor automobile manufacturers and parts suppliers.
In

existingarguments

about

define the characteristics of a product systemproduct

described by the correspondence between a) the

development and product architecture management

product functions and firmware components, b) the(Aoshima & Takeishi, 2001; Baldwin & Clark, 2000;

firmware components themselves, and c)

Fujimoto, 2001; Henderson & Clark, 1990; Ulrich,firmware components and CPU as the “firmware

1995), hardware components have attracted most ofarchitecture.” We then consider a case involving thethe attention. Therefore, an insufficient number ofdevelopment

product architecture studies have considered both themultifunction peripheral (MFP), released by Ricoh

hardware and firmware. In addition, in the field ofLtd., which has been used to realize multiple

software engineering, software development models

functions for many years. Our point of view ishave been studied (Tatsumoto, 2002), but there has

different from the existing argument, which considers

been insufficient study on the influence thata change in the product architecture as a kind of

embedded software has on the product architecture as

environment that requires manufacturing firms toa whole.

adapt. Our view is, however, that a change in the

However, the influence of the firmware on the

of

the

firmware

for

a

the

digitalproduct architecture can be seen as the result of an

product architecture increases as the firmware usedorganization

for a product increases in size and importance (Kato,architecture. From this point of view, we pay attention

2002; Shintaku, Ogawa, & Yoshimoto, 2006). To

to the changes in the firmware architecture and theefficiently

provideaselectingadifferent

product

product

with

good

changes in the ideal method of interdepartmentalisimportanttocoordination in the organization developing thesedevelop methods for selecting the functions toarchitectures. Thereby, we can offer a way to perform

incorporate

the product development activity more effectively

multi-functionalization,

into

the

coordinating/integratingitproduct
theseandfunctions.

for
In

a

and efficiently.

digitalized product, application software, middleware,and an operating system (OS) corresponding to eachfunction are necessary. How should these firmware
components be coordinated/integrated, in order to2

Generation-selection process of product architecture“a change in the product architecture” is recognized

2. Existing argument about productas a kind of “environmental change” to which thearchitecture and its limits

organization should respond. For example, as for the

Arguments about product architecture have involved

claim “that the organization strategy of the modular

the relationship between the function and structure oftype is suitable for the product architecture of thea product (Aoshima & Takeishi, 2001; Baldwin &modular type” in Kusunoki and Chesbrough (2001),

Clark, 2000; Fujimoto, 2001; Ulrich, 1995). It has

the focus of the argument is fixed on the kind of

been shown that there are some constant conformity

organization

relations between the type of product architecturearchitecture. This reflects the point of view that the(integral type or modular type) and the ideal

product architecture is recognized as a certain

organizational

development“environment” to which an organization must

(interdepartmental coordination or a division of labor

adapt. As a result, it is not sufficiently clear what kind

between companies) (Aoshima & Takeishi, 2001;

of mutual adjustment has to be made in an

Fine, 1998; Fujimoto, 2001; Kusunoki & Chesbrough,organization to make the product architecture

2001; Sanchez & Mahoney, 1996; von Hippel, 1990).

modular. Going to extremes, it has only been

Furthermore, it is pointed that the productdiscussed whether an organization of a certain typearchitecture changes dynamically with progress overcan adapt to a certain product architecture. The

time, so that it generally shifts from an integral type toexisting arguments do not recognize an observeda modular type (Baldwin & Clark, 2000), or, inchange in the product architecture as the result of ancontrast, that it shifts from a modular type to anorganization making a decision to adopt a different

integral type (Fine, 1998; Kusunoki & Chesbrough,product architecture. Accordingly, the process by2001). Existing studies focused on mainly twowhichoccasions that the product architecture changes, thatarchitecture has been disregarded. Thus, under thisis, when the function that is going to be realized bypoint of view, it is difficult to make useful suggestions

the product changes (Henderson & Clark, 1990), andon how a company should act when changing

when the technology used for a product changes

simultaneously the product architecture and the(Kusunoki & Chesbrough, 2001). However, neitherorganization.

structure

for

its

approach has provided sufficient investigation intoansuitablefororganizationamodularchanges

its

product

product

Therefore, we adopted the point of view that “anthe process used by a company when changing theorganization

selectsa

product

product architecture.

architecture.” We observed casesofproduct

proactively

As above, when the existing argument about thearchitecture shift to consider “what kind of intention

product architecture are analyzed, it is thought thatthe organization held when moving to a different
3

Fukuzawa

Figure 1. Investigation area covered in this article

focused architecture
hardwareview point

product architecture→organization

firmwaremost of existing
study

organization→product architecture

this article

Source: Author.

product architecture” and “what kind of organization

existing studies about product architecture, attention

was suitable for realizing such a change.” When we

has been given to the architecture of the hardware andtake this point of view and reinterpret the productthe response of an organization to the product’s

architecture framework, the following three points

architectural change as given. In contrast, in thismust be considered. First, behind the observed

study, we give attention to the architecture of the

product architecture, a series of decisions must takefirmware and the process by which an organization

place about how to combine the necessary functions

selects the product architecture.

and components. Secondly, only the change in the
product architecture is observable ex post in a market,

3. A case study: Development of theand behind such a change, certain decision making is
generated. Then, a series of processes wherein afirmware for the digital MFP by Ricoh

particular architecture is selected take place over3.1. Object and method

time. Finally, after the selection and manufacturing ofNowadays, multiple functions, such as copying,a specific architectural product, yet another productfaxing, printing, scanning, and network function arearchitecture can be generated and selected. In

offered in a single digital MFP. However, this has notparticular, here we consider how these processes arealways been the case. Through trial and error, theinfluenced

number of feasible functions gradually increased (i.e.,byinterdepartmental

coordination,

product concepts, and available resources.

multi-functionalization) as a means of market

Figure 1 shows the position of this study based

differentiation.

on the above-mentioned argument. In many of the

In order to integrate multiple

functions in a single product, it was important to4

Generation-selection process of product architecture

determine a method to allocate the firmware

period, six firmware architectures were developed,

components that controlled each function and to let

the IMAGIO 320/420 (1987), IMAGIO MF530

them work in harmony. However, existing arguments(1991), IMAGIO MF150 (1993), ASAP architecturethat the firmware facilitates the modular product(about 1994), NAD architecture (about 1998), andarchitecture (Kato, 2002; Shibata, Genba, & Kodama,

GW architecture (2001). These architectures can be

2002; Shintaku, et al., 2006), analyzed the individual

roughly classified into two types. One involves

firmware components but overlooked the design

application software, an OS, and a CPU on a circuit

concept behind firmware as a group. Thus, in thisboard where multi-functionalization can be added byarticle, we consider the change in the firmware

the addition of a board (ASAP architecture and GW

architecturearchitecture). The other is a method that copes with

and

the

desirable

style

of

interdepartmental coordination.

the addition or deletion of functions in the application

This case study is based on multiple interviews

layer by operating multiple application software on

with the software engineers developing the digital

one OS (IMAGIO 320/420, IMAGIO MF530,

MFP at Ricoh in 2005,2 along with Ricoh internal

IMAGIO MF150, and NAD architecture).

information; the “Ricoh Technical Report,” andRicoh

Corporate

History

Editing

3.2. Product architecture of the digital MFP

Committee(1996). We chose digital MFP as the subject of our

The digital MFP is comprised of both hardware (i.e.,analysis for the following reasons: a) The role of themechanical components and electronic circuits) andfirmware is more significant in digital MFP thoughfirmware, working together to provide various

both hardware and firmware are incorporated. b) It is

functions. The main differences of a digital MFP froma representative product that shifted from an analog

an analog copier are, a) the firmware is heavily

method to a digital method at the same time

involved in the processing function, 3 b) multiple

multi-functionalization was pushed forward. c) It is afunctions as a fax machine, printer, and scanner, for

product that had already seen a remarkable increase inexample, are offered in one machine, 4 c) there is

the scale of the firmware by the early 1990s.

3

In the beginning of the 1970s, an analog circuit was used
to control the amount of light that comes in from thelight source and a relay was used for sequencecontrol. Although these systems were highly precise andcomplex, they were replaced by microcomputers andfirmware control. The characteristics of microcomputer
control are as follows: a) capable of carrying out
complicated operation, b) easy to program on-demand
functions, c) hardware defects discovered in the latter
half of the systems design stage can be modified byfirmware. Microcomputer and firmware control wereadopted widely because of these advantages, and thedevelopment of the firmware became increasingly
important.
4
The biggest problems facing digitization were

We start our analysis from 1987, when IMAGIO
320/420, which was Ricoh’s first integrated type
digital MFP was released, and up to 2001, when
IMAGIO Neo350/450 was released. During this2

Interviews were performed four times in 2005. On
September 20 (three hours), October 11 (three hours),
October 24 (four hours), and November 29 (questions
and answers in e-mails).

5

Fukuzawa

Figure 2. Product architecture of digital MFPa) Description focused on hardwareb) Description focused on hardware and firmware

functionsfunctionscopying

printingfax

scanning

scanning

fax

printing

copying

copy
APL

printer
APL

fax
APL

scannerAPL

firmwaremiddle ware

NIC/Telscanner

printerOS

NIC/Telprinterscanner

hardware components

hardware components

Source: Author.

roughly a division between the engine5 unit and theconstitute the fax function; and the printer6 is also

controller unit.

used for the print function (Figure 2a). However, each

When we examine the hardware and describe theof these functions is not realized exclusively withproduct architecture of a digital MFP, it can be seen

these hardware components, but with the interlocking

that each product function and hardware component

actions of the hardware components and firmware

have a one-on-many correspondence. For example,

components used to control them.

the interlocking movements of the printer and scannerIn the digital MFP, the firmware components andconstitute the copying function; the interlocking

productfunctionsmovements of the printer, scanner, and phone line

correspondence.

For

have
example,aone-on-one
thecopying

application software supports the copying function,colorization and multi-functionalization. Because in thecase of an analog copier, the copying function is
performed by a large number of functional parts withcomplicated mechanical linkages, and it is thought thatthe degree of integrity in the product architecture is high.
5
Generally, the “engine” in digital MFP refer to theprinter. The scanner is called scanner engine.

the fax application supports the fax function, thescanner application supports the scanning function,
6

6

To use digital MFP as a network scanner and a network
printer, an NIC (Network Interface Card) is necessary.

Generation-selection process of product architecture

and the printer application supports the print function

development at Ricoh into four phases.

(Figure 2b). The middleware compiles the functions
that are common to these applications, and the OS is3.3.1. Before ASAP architecture developmentused as a firmware component to make adjustments

Before the ASAP architecture (i.e., IMAGIO 320/420,

between tasks. When we describe the product

IMAGIO MF530, and IMAGIO MF150), productarchitecture by the firmware, we

clear

development was carried out individually in different

modularization in the total product (Figure 2b). In

functional units such as the copier (or a digital MFP)

contrast, when we describe the product architecture

division,by the hardware, we can observe characteristics of andivision. Accordingly, firmware for each function

integral type. In such a product that has a

was developed separately. 7 Mutual adjustment wascomplicatedrelation,

little considered between different groups, because

development becomes extremely redundant if one

idiosyncratic divisional cultures had existed and thewish to leave each component’s development

technical language differed among each group. In

independent. Otherwise, an organization could

addition, the leader in the development of theperform

firmware architecture of

totalfunction-component

optimization

throughseeintricatefax

division,

these

and

modelsprinter

werecoordination effort in an extremely integrated

engineers from the copier division. As a result, theframework. Or if a manufacturing firm wished to

firmware architecture became centered on the

reduce such bizarre complexity, one should change

copying function.

the assignment function given to each hardware
component, which is a hardware-centric solution. Yet,

3.3.2. Development and failure of the ASAP

a firmware-centric solution is mostly adopted inarchitecture

practice where the arrangement and coordination ofBecausefirmware components would be manipulated. In thismulti-functionalization were promoted, the firmware

approach the firmware architecture becomes a crucial

in digital MFP grew in scale and complexity. This

point of argument, and thus, it is essential that we

made firmware development even more difficult andalso consider the steps taken by the organization topushed forward the development of the ASAP

accomplish this task.

architecture, which had started from 1992. Since thehigherperformanceandproject leader was a printer engineer, the ASAP
3.3. Firmware development activity at Ricoh7

Figure 3 shows a schematic representation of thetransition in the firmware architecture of Ricoh’s
digital MFP. In this section, we divide the firmware
7

According to the organizational chart that is listed in eachyear’s version of the “Securities Report” for Ricoh Ltd.,and the positions and posts given for the writers ofarticles in each year’s version of the “Ricoh Technical
Report,” different divisions were involved in thedevelopment of a copier (a MFP), fax, and printer(including a scanner) from 1986 to 2000.

Fukuzawa

Figure 3. Transition of firmware architecture of digital MFP in Ricoha) IMAGIO 320/420
FAX
board

COPY
APL

PTR
APL

FAX
APL

OS

OS

OS

CPU

CPU

CPU

COPY
board

system enhancement unit
FAX
APL

COPY
APL

OS
OS

OR

CPU

CPU

OR

engine control board

engine control board
printer engine

PTR
APL

attachment

PTR
board

attachment

COPY
board

b) IMAGIO MF530

scanner engine

printer engine

scanner enginec) IMAGIO MF150
FAX
board

COPY
APL

PTR
APL

FAX
APL

OS

OS

OS

CPU

CPU

CPU

d) ASAP architecture
controller board

attachment

PTR
board

COPY
board

COPY
APL

PTR
APL

SCN
APL

FAX
APL

NRP
APL

OS
CPU

ASAP I/F（engine I/F）
engine controlboard
engine control board
printer engine

printer engine

scanner enginef) GW architecturee) NAD architecture

controller board

PTR
board

FAX
board

SCN
board

COPY
APL

PTR
APL

FAX
APL

SCN
APL

OS

OS

OS

OS

CPU

CPU

CPU

CPU

COPY
board

scanner engine

COPY
APL

PTR
APL

SCN
APL

…

etc.

aplication I/F （GW-API）
platform
COMMON SERVICES
UNIX OSCPU
engine control board
printer engine

engine I/F
engine control board

scanner engine

printer engine

scanner engine

Source: Interview by author and “Ricoh Technical Report.”architecture was developed based on an orientation

breaking away from the conventional copy-functionthat was different from previous models. The ASAP

centered design. Furthermore, though firmware

architecture placed each function in parallel,components in each model had been standardized by8

Generation-selection process of product architecture

then, standardization between multiple models had

was insufficient.

not been aimed at. Therefore, by standardizing
firmware components between models, it was

3.3.3. Going back to the past architecture

expected that development cost, quality, andLearning from the lessons of the ASAP architecture,lead-time will improve.

the NAD architecture was developed under a project

However, because until then, the firmware toleader from the copier division. In this case, therealize each function had been developed with little

architecture was a throwback to what had alreadymutual coordination between groups, it was difficult

existed, that is, it was developed independently in

to integrate them to function adequately on one OS,

each group from the OS to an application rather thanand coordinating between groups were far fromtrying to achieve standardization between theeasy. The most particular problem was that Ricoh’s

firmware components. Reverting from the ASAP

original OS for the ASAP architecture had beenarchitecture to the NAD architecture aimed atdeveloped independently from all divisional groups,

reducing mutual coordination costs between various

and the disclosure of information about the OS

divisions necessary if an entirely new architectureinterface was seriously delayed. This resulted in each

was to be developed. However, the following

group developing an OS and unique application

problems existed with this architecture. First, it wassoftware on their own. The original plan failed to let

weak in networking performance. Second, themultiple functions perform in parallel on one

development cost increased because the amount of

OS. Consequently, the first ASAP architecture

hardware increased. Finally, a firmware had to bemachines were basic copiers neither realizing OS

developed each time a new model is released

standardization

because standardization between past architecturesnorapplication

softwarecompatibility between the models.

or firmware components was not realized.

We would like to point the following causes forthe failure of the ASAP architecture. First, it was not

3.3.4. Development of the GW architecture

sufficiently understood at Ricoh that the firmware

The development of the GW architecture began withplays

achieving

the launch of a project team called the GW-PT in

multi-functionalization, so that scarcely enough1998. This was the first time that a project team wasdevelopment resources, such as engineers andorganized to develop the firmware architecture atbudget, were allocated. Second, although close

Ricoh. In developing the GW architecture, a large

mutual coordination between groups was necessary

number of engineers were consulted, learning fromto develop the ASAP architecture, this was

the failure of the ASAP architecture, and morelacking. Finally, the processing speed of the CPU

development resources were spent. Because, in the

the

heavy

role

in

9

Fukuzawa

NAD architecture, the firmware to realize eachthe development of Ricoh’s digital MFP, the approachfunction was developed separately in different

waveredorganizational divisions, each group developed anarchitectures (Figure 4). The first uses a circuit board

application and an OS, and there were many

where an application software, an OS, and a CPU arefunctional overlaps. In contrast, the GW architecture

mounted, where new functions are realized by thewas developed under a leadership of the GW-PT

addition of a board. The other method copes with anproject team that facilitated close coordination

addition or deletion of a function by manipulating theamong each division. This approach succeeded insoftware program in the application layer on a single

extracting the common functions realized by the

OS. The former intends partial optimization of eachfirmware as “a platform,” and enabled this platformfunction, so the demand on the processing speed ofused commonly between multiple models. The

the CPU is low and the performance of each function

structure of the GW architecture resembles the ASAP

is optimized, but it is so redundant that the parts costarchitecture, but the approach taken in theirrises and is unsuitable for realizing “a unified

development differed, and this difference affected thefunction” as a digital MFP (Figure 4a). The latter has

success of the development (Table 1).

the goal of total optimization of each function. It is

betweentwo

different

firmwaresuitable for realizing a unified function as a digital
3.4. Wavering of the firmware architecture

MFP and the parts cost can be reduced, but it is also

and the factors involved

necessary to provide a high-power CPU and to

When multi-functionalization was pushed forward indevelop each firmware component under close

Table 1. Comparison of the development activities between the ASAP and GW
ASAP architecture

GW architecture

littlehugeorganization

small team in a division

GW project teamproject leader

printercopierdeveloped by a person
original OS
original debugging tool

developed by group (at least ten people)
UNIX OSpublic debugging tool

Delayed→failure of standardization between
functions→failure of same timing release

Facilitated→success of standardization between
functions→success of standardization between models

resource

development of OS

information sharing(interdepartmental
coordination)
Source: Author.

10

Generation-selection process of product architecture

Figure 4. Wavering of firmware architecture of digital MFPa) Changing the board (set of CPU,OS, and application

COPY

PTR

FAX

b) Changing only the application year

GW
SCN

NAD

COPY
board

PTR
board

FAX
board

SCN
board

COPY
APL

PTR
APL

FAX
APL

SCN
APL

OS

OS

OS

OS

CPU

CPU

CPU

CPU

COPY

PTR

controller board

ASAP

COPY
APL

PTR
APL

IMAGIO
MF150

FAX
APL

SCN
APL

OS
CPU

IMAGIO
MF530

engine I/F

engine control board

printer engine

SCN

FAX

engine control board
printer engine

scanner engine

scanner engine

IMAGIO
320/420

digitalization / multi-functionalization
Source: Author.

mutual coordination between functions (Figure

performance, product concept, and the level of4b). In the ASAP and GW architectures, theinterdepartmental coordination in the organization.

modularization of the firmware architecture isadvanced by the interdependency between the

3.4.1. Performance of the CPUcomponents (i.e., construction and rearranging of the

Because at first the clock speed of the controller CPU

OS, middleware, and the application interface).

used for the digital MFP was merely tens ofWavering between two kinds of architectures as

megahertz, it was impossible to conduct parallelin this case does not suggest whether a productprocessing between multiple firmware components

architecture is classified as the integral type or thewhile realizing the target performance. Later, in themodular type, but suggests the importance to pay

GW architecture, the CPU clock speed improved

attention to the difference in viewpoint and

up to several hundred megahertz allowing parallelorientation when determining the interdependency

processing between large-scale software which

between the components to realize a modular typerealizes multiple functions.

architecture. We can examine three factors that

However, it cannot necessarily be said that theaffected the choice between the architectures: CPU

improvement in the processing speed of the CPU
11

Fukuzawa

converge into a particular type of

firmwarecopier that can do other things.” In the GW

architecture. This is because the performance of thearchitecture, the product concept of the ASAP

CPU used in the product may not be good enough forarchitecture

the increasing amount of information that the productaccomplished, and more integrated functions wasengineer requires. And even if the CPU did meet therealized.

requirements, the project is likely to fail if the

was

more

straightforwardly

Thus, even though the term “digital MFP” canorganizational capability was lacking.

be applied to each of these products, they are different
in terms of the functions integrated into one machine

3.4.2. Product concept

and under what kind of design concept. This appears

Through the product development activities in Ricoh,

as a difference in the firmware architecture, that is,

the product concept for the digital MFP evolved fromwhether it is a copy-function centric type or a parallel“a copier that can do other things” (IMAGIO 320/420,

type that emphasizes integrated functions.

IMAGIO MF530, IMAGIO MF150, and NAD
architecture) to “an office appliance equipped with

3.4.3.

functions to process various information in an office”

product development organization(theConventionally,ASAParchitecture

and

the

GW

Interdepartmental

coordination

firmwarewasindeveloped

architecture). With IMAGIO 320/420, two functionsindividually at each functional division such as awere offered in one machine. This was the first step tocopier (an MFP) division, fax division, printerperform “multi-functionalization,” but it was viewed

division, or scanner division. However, a specialized

as attaching an additional function to “a copier.”organization was later established to develop the

Following this, with IMAGIO MF530 and IMAGIO

firmwarearchitecture

MF150, multi-functionalization was pushed forward

coordination

among

to a greater extent, but there was still no fundamentalorganizational shift took considerable amount ofchange in the product concept. On the other hand, intime

the ASAP architecture, “the fusion” of each function

coordination between groups until then, and thewas intended. This was a change in product concept

importance of the firmware architecture developmentfrom “a copier that can do other things” to “awas not sufficiently recognized at Ricoh. These

multifunctional office appliance.” In place of this,problems occurred for the following reasons: a)withalthoughbecause the product development organization was

multi-functionalization was intended as in the

hardware-centered and b) because a section of the

IMAGIO 320/420, the IMAGIO MF530, and theexisting core business (i.e., the copier team)

IMAGIO MF150, the product concept reverted to “adeveloped the firmware architecture, and it little

the

NAD

architecture,

12

because

there

under
different

had

been

close

mutualdivisions.

This

littlemutualGeneration-selection process of product architecture

occurred to bring in a total optimization point of viewarchitecture is built to best suit the organizational

into the design. 8 Expressing the former plainly, abenefits as well. Consequently it is necessary tohierarchy dominated the office that ranked thechange the organization in order to shift to a different

mechanical engineer at the top, followed by the

product architecture.

electronics engineer and the software engineer. The
firmware development team was regarded as a minor
group

and

was

allowedlittle4. Discussion

development

resources. Generally, the development cost of the

4.1. A product architecture generation andfirmware was not accounted for in the productselection processdevelopment cost, and even if it was, it was treated as

Because the firmware increased in scale andpart of the cost for the ROM installed in the product.

complexity

asaresultofdigitalized

Because the hardware and copier section were

multi-functionalization and integration, most of thethe center of the corporate organization at Ricoh,

interdependency issues between functions and

IMAGIO 320/420, IMAGIO MF530, IMAGIO

components

MF150, and NAD architecture were developed with adevelopment stage. This made the selection of the

focus on the copying function under the concept of “afirmware architecture synonymous with the selection

copier that can do other things.” On the other hand,of the product architecture. We consider that thethe ASAP architecture and the GW architecture were

wavering between the two firmware architectures, as

designed as parallel architectures under the productdescribed in the Ricoh case, was a series of processes

concept of “a multifunctional office appliance,”seeking for the most fit product architecture for thewithin organizations that are not copy-function

digital MFP. In the case of the ASAP architecture,

centered (i.e., the project was lead by the printeralthough the CPU capacity was insufficient, andivision in the case of ASAP architecture and anarchitecture in which multiple applications operate on

individual project team in the case of GW

one OS was selected. To fully enable this architecture,architecture). This suggests that because the core

it was necessary to sort out firmware components that

product function and concept design are formed

could be standardized by close mutual coordination

withinbetween functional divisions, but the attempt

the

given

organization,

theproduct

concentrated

on

the

firmwarefailed. Then in the following NAD architecture, the8

Mutual coordination between groups were lacking, andmeaningless source codes were generated. Furthermore,because many man-hours were necessary to execute theintegration tests between the firmware components,
people were inclined to seek a way of not having tochange the architecture that has proved good in themarket place. Therefore, the product architecture has notbeen reviewed thoroughly.

design reverted to an architecture that excluded closemutual coordination between divisions. We can saythat these facts suggest that the degree of “thedifferentiation” between groups was high, but the13

Fukuzawa

degree of “the integration” was low (Lawrence &found the ideal organizational structure that realizes

Lorsch, 1967). In other words, when the ASAP

coordination between different groups. Therefore, thearchitecture was developed, the organization at

product architecture that an organization “should

Ricoh was fixed to the traditional differentiation andchoose” reflects the organizational structure, productintegration that were copy-function centered. Withinconcept, and available resource at that time. Thisthat organization, they were incapable to makeselection process cannot be fully explained withinnecessary mutual coordination between functional

the framework of the existing argument that “andivisions that was required to realize the intended

organization adapts itself to a given change in the

product architecture. In contrast, when the following

product architecture.”NADarchitecturewasdeveloped,

a productarchitecture that reflects the existing organizational

4.2. Lessons from the case of Ricoh

structure was chosen. Taking a lesson from these

The copier had been the main business of Ricoh for a

failures, the GW architecture finally succeeded inlong time that maintained a high market share sincerealizingforthe analog copier, and development organizations

multi-functionalization. This, involved a major

were lead by the copier division. As a result, a

update in CPU capacity that enabled parallel

copy-function centric architecture was conceived. It

operationanseems that many companies face the same problem

organizational shift in which an independent teamwhen they try to develop a new product architecture

producessuited for multi-functionalization, because the

an

of

close

architecture

multiplefit

applications,mutualcoordination

andbetweenfunctional divisions.

ongoing

The case discussed in this article can becorebusiness

limit

their

way

of

thinking. What kind of countermeasures should theseinterpreted as follows: Although there were alreadycompanies adopt?

two architectures that Ricoh could have adopted, a

From this case study, it is suggested that a teamlack in hardware performance made only one of themof engineers specialized in each function needs totechnicallyfollowing

coordinate between groups in developing a firmwareinterpretation seems more likely to explain what wasarchitecture suitable for multi-functionalization. To

really taking place behind the decision making at that

this end, first, it is necessary to spend resources totime:developThe

possible.

wavering

However,

betweenthetwofirmwarethefirmwarearchitecture

in

large

architectures was observed because in the days whenquantities. Second, the product concept must beeach architecture was developed, there were no clear

reworked without being bound by the philosophy ofstandards to decide which was good. Thus, they could

the core business. Finally, a hardware development

but seek the answer through trial and error until theycentric organization needs to be rejected, and14

Generation-selection process of product architectureengineers (both hardware and firmware) withas a kind of modularization. The important point istechnical knowledge about each function shouldthat to drive modularization with an unconventional

work in close coordination.

orientation, it is necessary to create a new specificcomponent that manages the interdependencies
between the components. And also the organizational

5. Conclusionarchitecture must be an integral type with a

5.1. Summary

knowledge (integrated knowledge) to grasp the

In this article, we investigated a case involving theinterdependencies from the total optimization point offirmware development of a digital MFP. By

view. This presents the following dilemma: if andigitalization and introduction of the firmware, theorganization is going to run a development activity

original single-function analog copier evolved intoand operation under the existing modular type

an appliance that added several functions to merearchitecture, it is necessary for the organization tocopier, and then to the sophisticated digital MFP

become modular (Aoshima and Takeishi, 2001; Fine,

offering variety of functions. During the process, the1998; Fujimoto, 2001; Kusunoki and Chesbrough,firmware architecture went back and forth between

2001; Sanchez and Mahoney, 1996; von Hippel,

two opposed conceptions. The case revealed the1990). However, to advance into a new form ofprocess for a generation and selection of a productmodularization, the integrated knowledge held by anarchitecture and the difficulties faced by a company

integrated organization is necessary. Organizationsin the development of the firmware. Furthermore, weface this dilemma not because the productwere able to present a solution to overcome thearchitecture changes, but because organizations

problem. As for the distinct problems in thechange the product architecture at their will.

development of a digitalized product, some adverse
effects were shown from the hardware-centric nature

5.2.

Towardcompetitionof the development organization, along with thecapability

importance of action to integrate the knowledge thatdevelopment

lay scattered through the organization, which is

In the product area affected by digitization, thenecessary for the development of a firmware.

competitive focus of companies has shifted from theoffirmware

based

on

the

architecture

Because a common application interface was

hardware to the firmware in regards of architectural

built at the OS and middleware level, and theexcellence. Conventionally, the makeup of an

independency of each functional elements wasorganization was based mainly on the hardware

maintained, the development activity for the ASAP

development, and the firmware development wasarchitecture and the GW architecture can be regarded

treated as trivial. Now, the firmware grew in capacity
15

Fukuzawaand sophistication, so that the firmware design

Acknowledgements

decides the whole product architecture. It is
important to integrate the know-how and knowledge

The author would like to thank Junjiro Shintaku,

accumulated by different development groups in the

Hirofumi Tatsumoto, Koichi Ogawa, and Tetsuo

firmware design, and an organizational framework

Yoshimoto for comments on earlier drafts. The authorthat enables this is crucial. This will become more

would also like to extend sincere gratitude todifficult when the area of the integration activity

engineers at Ricoh Ltd. for research cooperation.

spreads across different companies. Furthermore, it isThis article is a translated version of an originalnecessary to not only cope with the observed changes

articlein the product architecture, but to also build aM. (2008) Seihin akitekucha no sentaku purosesu,

competitive strategy to develop an efficient productSoshiki Kagaku, 41 (3), 55–67, with minor revision.

publishedinJapaneseas

Fukuzawa,architecture. A firm should create a competitive
circumstance that is advantageous to the company by

References

designing product architecture proactively.

Aoshima, Y., & Takeishi, A. (2001). Akitekucha to iu
5.3. Limitations and future researchkangaekata

The argument in this article is based on a single casearchitecture]. In T. Fujimoto, A. Takeishi, &study so it is unclear to what extent the results should

Y. Aoshima (Eds.), Bijinesu akitekucha [Businessbe applied to other companies and industries. Thus, inarchitecture: Strategic planning of product, process,futureandresearch,

itisnecessarytoconduct

comparative studies of competing firms in the samedevelopment

organizations,producethesedifferences.

In

(pp.

of

27–70).

product

Tokyo:

Baldwin, C. Y., & Clark, K. B. (2000). Design rules,

andVol.1: The power of modularity. Cambridge, MA:

product strategies between companies, and the factors
thatorganization]

concept

Yuhikaku. (In Japanese)

industry to investigate the differences in firmware
architectures,[The

MIT Press.

addition,

Fine, C. H. (1998). Clock speed. Cambridge, MA:

comparative studies across industries, as for example

Basic Books.

in the automobile industry and the copier industry,

Fujimoto, T. (2001). Akitekucha no sangyoron [Thewill be necessary. Furthermore, we wish toarchitecture based analysis of industry]. In

investigate the relationship between the firmware

T. Fujimoto, A. Takeishi, & Y. Aoshima (Eds.),architecture

Bijinesu

andtheproduct

development

performance of manufacturers in future research.

akitekucha[Businessarchitecture:

Strategic planning of product, process, andorganization] (pp. 3–26). Tokyo: Yuhikaku. (In16

Generation-selection process of product architecture

Japanese)
Henderson,

architecture]. Tokyo: Hakutoshobo. (In Japanese)
R.

M.,

&

Clark,

Shintaku,J.,

Ogawa,

K.,&

Yoshimoto,

K. B. (1990). Architectural innovation: The

T. (2006). Hikaridisuku sangyo no kyousouto

reconfiguration of existing product technologies

kokusaiteki kyougyou moderu [Competition in theand the failure of established firms. Administrative

opticalScience Quarterly, 35(1), 9–30.

collaboration model] In K.

Kato, H. (2002). Mojurariti doraiba [The modularity

disk

industry

andinternational
Sakakibara, &S. Koyama (Eds.), Inobeshon to kyousouyuui

driver]. Akamon Management Review, 1(8),[Innovation

633–641. http://www.gbrc.jp/journal/amr/AMR1-(pp. 82–121). Tokyo: NTT Press. (In Japanese)andcompetitive

advantage]

Sanchez, R., & Mahoney, J. T. (1996). Modularity,

8.html (In Japanese)
Kusunoki, T., & Chesbrough, H. W. (2001). Seihin

flexibility, and knowledge management in productakitekucha no dainamikku shifuto: Bacharu soshiki

and organization design. Strategic Management

no otoshiana [The dynamic shift of product

Journal, 17(S1), 63–76.

virtual

Tatsumoto, H. (2002). Sofuto kaihatu purosesu

organization]. In T. Fujimoto, A. Takeishi, &moderu to seihin zokusei [The process model ofY. Aoshima (Eds.), Bijinesu akitekucha [Businesssoftwarearchitecture: Strategic planning of product, process,attribute]. Akamon Management Review, 1(4),and

309–336. http://www.gbrc.jp/journal/amr/AMR1-

architecture:The

organization]

problem

(pp.

of

a

263–285).

Tokyo:

Yuhikaku. (In Japanese)
Lawrence,P.

development

andproduct

4.html (In Japanese)
R.,&

Lorsch,Ulrich, K. (1995). The role of product architecture in

J. W. (1967). Organization and environment:

the manufacturing firm. Research Policy, 24(3),Managing differentiation and integration. Boston:

419–440.

Harvard University Press.
Ricoh

Corporate

Historyvon Hippel, E. (1990). Task partitioning: An
Editing

Committee

innovation process variable. Research Policy,(Eds.). (1996). Road to IPS Ricoh: 60 years of

19(5), 407–418.

technology. Tokyo: Ricoh Ltd.
Shibata, T., Genba, K., & Kodama, F. (2002). Seihin[Received September 29, 2008; accepted October 6, 2008]

akitekucha no shinkaron [Evolution of product17

Fukuzawa

18

ABAS: Annals of Business Administrative ScienceVol. 7 December 2008

CHIEF EDITOR

Junjiro Shintaku, the University of TokyoEDITORIAL BOARD

Makoto Abe, the University of Tokyo
Takahiro Fujimoto, the University of Tokyo
Makoto Kasuya, the University of Tokyo
Nobuo Takahashi, the University of Tokyo
Technical Editor: Maki Nishida, Global Business Research Center

ABAS: Annals of Business Administrative Science is published annually by Global
Business Research Center, Marunouchi, Chiyoda-ku, Tokyo, JAPAN. http://www.gbrc.jp