John Q. Dickmann
ESD Symposium
March 19, 2004
Leading Systems Architects:
Diverse Problems and Common Patterns
Abstract
The topic of system architecture is receiving increased attention as technical
complexity and social importance of our engineered systems increases. This work
proposes and tests a simple framework for study of system architects and their systems.
The framework focuses on identifying rule sets chosen by system architects that act as
drivers of socio-technical dynamics of their systems. The framework is built on the
premise that, in general, development, dynamics and evolution of complex systems are
the result of repeated application of relatively few and relatively simple rules that govern
interactions between components of the system and between the system and its
environment. For four systems –the Toyota Production System, the Marshall Plan,
Microsoft Corporation and the Nuclear Navy- this paper identifies rules, highlights
system boundary decisions and evolutionary contexts to gain first order understanding of
possible connections between rules and system evolution. These systems represent a
wide array of technical and social contexts: from government to private enterprise,
explicitly technical to technically related, high technology to ‘classic’ industrial. This
first order assessment shows that rules are identifiable, openly stated and have common
patterns across systems. These patterns are strong focus on both technical excellence of
personnel and the human element while emphasizing careful analysis of feedback and
attention to information flows, both inside and outside the system. It is argued that
system success is strongly dependent on developing an appropriate rule set.
Professor Chris Magee of MIT’s Engineering Systems Division provided invaluable
guidance and assistance in maintaining focus and clarity in this paper.
1
John Q. Dickmann
ESD Symposium
March 19, 2004
Introduction and Motivation
The topic of system architecture is receiving increased attention as technical
complexity and social importance of our engineered systems increases. There is an
emerging need to develop better understanding of various aspects of architecture and
architecting of large scale engineered systems. A recent review (Whitney 2004) notes the
early stages of work in this area. Many treatments of large scale systems and systems
architecture, focus on either technical aspects (Maier and Rechtin 2002, Pahl and Beitz
1996, Clark and Baldwin 2000), descriptive historical accounts of system evolution
(Thomas Hughes 1998, Knox and Murray 2001), industry level analysis of technology
dynamics and evolution (Utterback 1994, Christensen 1997) or case study research to
discover best practices (Miller and Lessard 2001). As an additional contribution, the
focus of this paper is on a framework for developing better understanding of system
architects, their systems and the architecture of forces that most directly influence system
evolution. It is designed as an initial investigation of the socio-technical aspects of
systems architecture and system architects and to explore whether generalized
characteristics might exist among diverse systems studied through one framework.
Complex Engineering Systems as viewed by Engineering Systems Division
require new mental frameworks and new methods of assessment through which to
evaluate their instantiation, performance and evolution. This framework is built on the
conception of complex engineering systems articulated by the Engineering Systems
Division, summarized below (ESD Symposium Committee 2001, Magee and deWeck
2002, Dodder and Sussman 2002):
-
Systems are a set of interacting components having well-defined (although
possibly poorly understood) behavior or purpose; the precise boundaries of a
system can be dependent upon the level of analysis or the specific aspect of the
system under consideration;
-
Complex systems have many components, interconnections, interactions and/or
interdependencies; this makes precise prediction and description of behavior
difficult in some important circumstances;
-
Humans design engineering systems; they have purpose, are large in scale,
complex and have complex management or social dimensions as well as
technical ones.
-
Additionally, this framework also considers that Complex Engineering Systems
are intimately tied to, influence and are influenced by the environment (context)
in which they exist and operate.
The conceptual foundation for the framework comes from contemporary complex
systems research and ESD conceptions. In general, the development, dynamics and
evolution of complex systems are the result of repeated application of a limited set of
relatively simple rules governing interactions (feedback and feed forward) between
system components and cause-effect relationships in these systems are difficult to
untangle. As a result, understanding complex systems prioritizes knowledge of (1)
interactions and processes within the system over detailed knowledge of internal
2
John Q. Dickmann
ESD Symposium
March 19, 2004
component characteristics and (2) long-term evolution of the system over static analysis
of it.
The system architects and systems chosen for study provide a diverse
representation of ‘systems’ as contemporary thinking and Engineering Systems Division
has come to term them. Spanning a range from government to private enterprise,
explicitly technical to only marginally technically related, high technology to classic
industrial, they are:
1. Taiichi Ohno (Toyota Production System);
2. Hyman G. Rickover (Naval Nuclear Power Program);
3. George C. Marshall (European Recovery Program (Marshall Plan));
4. Bill Gates (Microsoft Corporation).
Assessment Framework
Assessing the effectiveness of systems architects requires a look at the
architectural design decisions they made and how the system they designed, built and
operated performs against the problem for which it was created and how it interacts with
other aspects of its operating environment. The central aspects of this framework are:
(1) explicit recognition of the difficulty of precisely connecting every micro-scale
interaction to aggregated macro-level effects or behaviors and (2) a consideration of the
context in which the system was developed and operated and how context influenced
initial development and system evolution over time. Addressing context (external
constraints) explicitly creates a focus on decisions about system boundaries, a
fundamental issue when assessing system performance or behavior. Macro- versus
micro- aspects of systems are considered by highlighting rules used to guide system
decisions and evolution and then making inferences regarding connections between rule
execution and system evolution. The objective is to see whether a small set of rules,
either explicit or implicit, might be a commonly identifiable feature of complex sociotechnical systems and whether, across diverse complex engineering systems, there are
commonalities in rules and in the approach architects take in architecting their systems.
This line of investigation might lead to more formal methods of assessment, modeling,
and analysis of complex socio-technical systems.
For each architect and system, the general historical context will be set and then a
specific starting point for the assessment will be defined. This sets the stage for
definition of the architect’s problem. Because system boundaries set the scale at which
the system operates, attention will be focused on the architect’s definition of system
boundaries in terms of objectives and external constraints (context) that drove those
choices. We will describe generally how or whether system scale changed over time as
the system evolved. Where explicitly stated, the rule sets that the architect’s used in
architecting their system will be listed, in other cases, rules will be inferred from an
assessment of the architect’s actions and decisions. An overall assessment and
comparison of the major characteristics of each system will be made, with emphasis on
enduring strengths of the systems, especially as they evolved over time. This assessment
will be high level and qualitative, since the four examples are generally acknowledged
successes and detailed performance assessment is not the major thrust of this work.
3
John Q. Dickmann
ESD Symposium
March 19, 2004
The framework consists of five parts:
1. Establishing initial context: Setting general historical background,
defining a starting time for assessment of the architect and the
system;
2. Stating the goal or purpose of the system;
3. Identifying rules, protocols or principles that guide the growth and
evolution of the system;
4. Identifying system boundaries: Initially and as they evolved over
time;
5. A brief subjective assessment of overall effectiveness of the
created system.
Taiichi Ohno and the Toyota Production System
Context and Goal
Taiichi Ohno is widely known as a visionary leader at Toyota Motor Company
and the intellectual creator of the Toyota Production System (TPS). Origins of the TPS
can be traced to the particular circumstances of Japan and to the specific goal set for
Toyota by its President following World War II.1 Toyoda Kiichiro challenged the Toyota
Motor Company the day World War II ended: “Catch up with America in three years.
Otherwise, the automobile industry of Japan will not survive.” [Ohno 1988, p. 3] This
goal was straightforward and challenging and generated intense activity at all levels of
the company [Ohno, p. 9]. As Ohno set about making his contribution to the corporate
challenge, he centered his focus on waste elimination. At the time, by standard measures,
American productivity greatly exceeded Japanese productivity. The challenging goal and
this performance differential with America gave Ohno his initial inspiration for the
fundamental governing rule of the Toyota Production System:
It [the productivity differential] meant that a job then being done by 100
workers had to be done by 10 workers…But could an American really
exert ten times more physical effort? Surely, Japanese people were
wasting something. If we could eliminate the waste, productivity should
rise by a factor of ten. This idea marked the start of the present Toyota
production system. [Ohno, p. 3]
The context of post-war Japan is key to understanding the evolution of the Toyota
Production System (TPS) and Ohno’s decisions regarding it’s development. Post-war
Toyota faced many problems [Womak, Jones and Roos 1990, p. 49-50]:
-
A small domestic market that demanded a wide array of vehicle types;
-
A work force that was unwilling to be treated as a disposable part;
-
Labor laws established by the American occupation force that restricted
management’s options with respect to hiring and firing;
1
Ohno traces the intellectual roots of TPS much farther back, to Toyoda Sakichi and Toyoda Kiichiro in the
1920s and 1930s. For purposes of this analysis, the end of WW-II is an appropriate starting point.
4
John Q. Dickmann
ESD Symposium
March 19, 2004
- Lack of an immigrant population willing to accept lower pay or lower standard
working conditions;
-
A capital starved economy;
-
Mature and large overseas automobile manufacturers as competition.
These were significant constraints, almost all of them pointing to a ‘don’t waste
resources’ solution.
Recognizing he had to work under conditions that were essentially opposite to
those in America and the rest of the global automobile manufacturing industry, Ohno
developed an approach that fully considered the unique context of Japan. This approach,
Ohno’s basic rule, was: “eliminate waste.” Ohno continuously focused on the goal
(“Catch up to America”), always applying this rule. Over time, external context changed;
in 1950, there was a large strike, in 1973, there was the oil crisis, the Japanese economy
grew. Through all changes, internal and external, Ohno’s response was fundamentally
grounded in the basic rule: waste elimination.
Solution and Rules
Ohno’s solution was not a single technical system, but a set of rules and practices
that guided decisions about manufacturing processes and technology choices. These
rules did not immediately result in the “Toyota Production System” as we know it today
but built it, over time, as they proved valuable through repeated application. [Ohno, p.
33, 35]
Though he did not call it a ‘system’ at the beginning, to support the system and its
central operating rule of waste elimination, Ohno established two related rules2 that
governed subsequent choices over the next 50 years: Just in Time and Autonomation
(automation with human touch) [Ohno, p. 4-7]. These three rules became the foundation
for the set of practices, subsidiary rules and management tools applied to the Toyota
Motor Company’s goal, “Catch up to America”:
Rules: 1. Eliminate waste
2. Implement Rule 1 by using Just in Time flow and
3. By meshing human and machine capabilities (Autonomation).
System Boundaries and Evolution
It is worth noting that Ohno’s initial aim was not to revolutionize Toyota, but to
improve existing processes in order to achieve the goal. The System did not spring whole
and get implemented across the Toyota Corporation immediately and it does not appear
that he had an overarching vision that it would; Just-in-Time production flow were
simply his contribution to achieving Toyoda’s goal. Initially Ohno could implement
these principles only in the machine shop he managed. So, at first, the system boundaries
of what we recognize today as TPS were limited to a single shop in the Toyota enterprise
[Ohno, p. 31]. Over time, as effectiveness was proven, Ohno’s responsibilities grew and
2
He calls them principles (p. 4). Dictionary definitions for ‘principles’ and ‘rules’ are very closely related
and for the purposes of this framework are synonymous.
5
John Q. Dickmann
ESD Symposium
March 19, 2004
the ‘system’ with them, expanding and maturing over 35 years to include Toyota’s
outside suppliers.3 [Ohno, p. 11, 31-36] The net effect of these rules, applied
increasingly across the enterprise, was an asymmetric increase in productivity, product
quality and responsiveness to market demands compared to the rest of the automobile
industry, a competitive advantage recognized by the marketplace [Womak, Jones, Roos
1990, p.62; Womak and Jones 1994, p. 230-31].
Another important boundary feature of TPS is its unique conceptual orientation to
the market place. In describing his development of Just-in-Time production flow, Ohno
points out how the standard production process results in excess inventory. By focusing
on the need to eliminate waste, he decided to stop flowing forward, instead, pulling from
prior production steps (solving the problem of inventory pile ups). [Ohno, p. 13]
Logically extending this view across the entire manufacturing process results in Ohno’s
innovative concept of viewing the production system from the customer back through the
manufacturing process to the raw materials. This is one factor among many that
generates tight coupling across the boundary between the Toyota Production System and
its external environment. In contrast to what he describes as the traditional ‘push’
system, where goods are produced and pushed out the door to be (hopefully) purchased,
Ohno’s ‘pull’ system inherently eliminates waste, because nothing is produced “unless it
is needed.” [Ohno, p. 5, 33]
Since information is needed for people to effectively apply rules, a key to
successful evolution of TPS is its extensive reliance on information extraction and flow.
The information extraction tool supporting evolution of the system is a subordinate rule
set called the ‘5 Whys’. Discussed in Chapter 2 of Ohno’s text, this rule is designed to
ensure the multiple layers of causality are probed to discover root causes of any problem.
Kanban, a system of information tags linking parts of the process together, enables
information flow through the system. Kanban, sitting on top of Just-in-Time, creates a
networked ‘nervous system’ for the process, that transmiting signals from the external
environment to stimulate action inside the production system. [Ohno, p. xvii, 40-46]
Like the flow process, the scale of “5 Whys” and kanban grew as it and TPS
demonstrated their ability to improve performance.
The TPS boundaries grew over time as worth was proven. Once the system grew
to the point of connecting outside suppliers to the process, the system boundaries
expanded beyond the Toyota Motor Company. Today, TPS is considered a multienterprise networked system, “a group of roughly 200 companies integrated by their
common interest in supplying the Toyota Company.” [Watts 2003, p. 254-55]
Net Assessment
Ohno’s architecting of the Toyota Production System consisted of a set of basic
rules, centered on the elimination of waste, repeatedly and vigorously applied. There
were (and are) supporting rules and techniques used to address day-to-day operational
issues, but they only reinforce or implement the foundational rules of Waste Elimination,
3
Ohno credits management commitment to his early experiments with kanban and Just-in-Time flow for
much of the follow-on success, an indication of what many know as the necessity of top-down commitment
to anything ‘new’ in an enterprise.
6
John Q. Dickmann
ESD Symposium
March 19, 2004
Just-in-Time flow and Autonomation. The system started in a single shop of the Toyota
Motor Company, expanding as positive results were achieved and as success was
recognized by senior management in the form of Ohno’s promotion. System boundaries
evolved, expanding as success was proven, today encompassing multiple enterprises in
an extended (global) network of suppliers. At each stage, difficulties arose but were
overcome through diligent attention to the fundamental rules and rational assessment of
performance, with individuals, groups and the organization learning over time.
Overall, Ohno can be assessed as effective in building a system robust to external
shocks and highly focused on delivering value. His personal account of the genesis of the
system shows him to be a true systems thinker, highly focused on his goal, demanding
high standards of him and those who worked for him. [Ohno, p. 5, 17, 35-36, 45-46] His
rules generated a tightly coupled system, responsive to external stimulus and proven
scalable from shop floor to the multi-enterprise level. The beneficial features of the
system are not without hazards; waste elimination can create single point vulnerabilities
as the Aisin fire of 1996 demonstrated. [Nishiguchi and Beaudet 1997] As a
counterpoint to this vulnerability, the cooperative culture built up around the need to
eliminate waste across enterprises can be a key to survival when these ‘single point’
crises occur.
Hyman G. Rickover and the Naval Nuclear Power Program
Context and Goal
The genesis of the U.S. Navy’s nuclear propulsion program, like the origins of the
Toyota Production System, can be traced back some years before concentrated effort
began. In March of 1939, the Naval Research Laboratory initiated a $1,500 research
program on nuclear fission, chartered to investigate new submarine and torpedo power
plant technology. In 1944, the Director of the Manhattan Project established a committee
to study other uses of atomic energy, including two naval officers in the group. By 1946,
there was a formal report, briefed to senior submarine officers, describing the feasibility
of a nuclear submarine. [Polmar and Allen 1982, p. 118-123]
The relevant historical genesis of the Navy’s nuclear program dates from 1946,
when a group of naval officers was sent to Oak Ridge National Laboratory to investigate
the application of nuclear energy for naval propulsion, specifically for submarines.
Shortly after reporting to Oak Ridge, then Capt. Rickover became convinced that with
proper attention and management, a nuclear power plant could be engineered for
submarine application. An exceptionally strong personality, with strong views on the
proper approach to engineering, he made the goal of putting a nuclear powered submarine
to sea for the U.S. Navy a personal mission and convinced his fellow officers at Oak
Ridge to join him.
During this time, the services were adjusting to the post-war drawdown and the
Soviet Union was emerging as an adversarial competitor to the U. S. in world affairs.
These were two significant factors, along with the Atomic Energy Act of 1946, which
centralized all control of atomic activities in the country with the Atomic Energy
7
John Q. Dickmann
ESD Symposium
March 19, 2004
Commission (AEC), driving the context in which Rickover would architect his system.4
Initially, and for most of the duration of his tenure as the head of the program,
Rickover’s problem was bounded along the two axes of technical and organizational
constraints. Technical system constraints were: limited size of submarine hulls, close
proximity to crew, a dynamic ocean environment as well as requirements set by military
operations. These constraints set the context for engineering and technical development.
The Atomic Energy Act of 1946, coupled with the internal structure and processes of the
Navy’s Bureau of Ships (BuShips) were the major factors setting constraints for
organization design. BuShips contracted for and managed ship construction; the AEC
had total control over anything related to atomic energy.
Solution and Rules
This effort, in contrast to TPS, began as a “blank-sheet.” Neither organization nor
technology existed when Rickover began. In the early stages of development, there were
many uncertainties, technical and non-technical. Addressing them boiled down to two
significant architectural issues: building an organizational structure to manage effectively
a high technical risk program with unique legal constraints and safety requirements while
simultaneously inventing technology, engineering practice and physical system
architecture.
Rickover’s organizational and technical solution developed as he built the
program and as uncertainties became knowledge. It was grounded in fundamental rules
built on his personality and operational and engineering experience.5 These were:
1. Personal accountability;
2. Technical excellence focused on reactor safety;
3. Use real data from the technical system operating in the real world to
make decisions in pursuit of rule 2.
As noted by Robert Pool in Beyond Engineering [p.46-47]:
“…[he] demanded complete testing of everything that went into the
reactor and was ruthless about reworking things or even starting over, if
necessary, when problems appeared…He gave people freedom to do a job
the way they thought best, but in return he demanded complete
accountability. If something went wrong, there was always someone who
bore ultimate responsibility. Rickover’s management style had no room
for finger pointing.”
This rule of accountability is borne out in his testimony to Congress regarding an
accident at an Army research reactor in Idaho [Rockwell 1992]:
“You have yet to bring forth an individual in that program who will
answer to you “I am responsible.” They rotate people and delegate
responsibility in the usual military way. You do not have that problem
5
Duncan 2001 and Polmar and Allen 1982, provide detailed accounts of Rickover’s formative years prior
to Navy and of his early career.
8
John Q. Dickmann
ESD Symposium
March 19, 2004
with my program. I have many people carrying out tasks in the program
and I hold them accountable to me for those tasks. But if anything
important goes wrong in my program, is there any doubt in your minds
who is responsible? I will tell you right now, in case there is any
uncertainty about it, I am responsible.”
Over time, these principles were codified explicitly and implicitly through reports
to Congress, instructions to his organization, training curricula and other
communications. In 1982 testimony to Congress, he laid out “important tenets of
the program’s engineering philosophy:” [cited in Duncan, 1990, p. 295-96]:6
“Avoid committing ships and crews to highly developmental and untried
systems and concepts;
“Ensure adequate redundancy in design so that the plant can
accommodate, without damage to ship or crew, equipment or system
failures that inevitably will occur;
“Minimize the need for operator action to accommodate expected
transients. If the Plant is inherently stable, the operator is better able to
respond to unusual transients;
“Simplify system design so as to be able to rely primarily on direct
operator control rather than on automatic control;
“Select only materials proven by experience for the type of application
intended and insofar as practicable, those that provide the best margin for
error in procurement, fabrication, and maintenance;
“Require suppliers to conduct extensive accelerated life testing of critical
reactor systems components to ensure design adequacy prior to
operational use;
“Test new reactor designs by use of a land based prototype of the same
design as the shipboard plant. Prototype plants can be subjected to the
potential transients a shipboard plant will experience, so problems can be
identified and resolved prior to operation of the shipboard plant;
“Train operators on actual operating reactors at the prototypes. Simulators
are not an acceptable training device for naval operators;
“Confirm reactor and equipment design through extensive analyses, fullscale mockups and tests;
“Use specially trained inspectors and extensive inspections during
manufacture; accept only equipment that meets specification
requirements; concentrate on designing, building and operating the plants
to as to prevent accidents, not just cope with accidents that could occur.”
System Boundaries and Evolution
6
These tenets were most recently articulated by the current Director of Naval Reactors, Admiral F. L.
Bowman in testimony to the House Committee on Science [29 October 2003 testimony].
9
John Q. Dickmann
ESD Symposium
March 19, 2004
The two axes of technical and organizational issues are the bounds within which it
is most useful to view the impact of Rickover’s rules on system evolution over time.
Technical system constraints coupled with the preexisting tendency of submarine officers
to demand technical excellence for reasons of survival, were able to set the pattern of
technical excellence behavior early. This pattern, once established in the small
community of submarine operators and builders, was then more easily transferred when
the program expanded to include surface ships [Rockwell 1992, p. 119-120].
Organizational system boundaries did not exist when Rickover began his effort. He had
to create the organization and set boundaries with consideration of the constraints of the
Atomic Energy Act of 1946 and internal policies and bureaucratic organization of the
Navy.
Organizational and legal constraints were seemingly in direct conflict with his
rule that demanding centralized accountability for management and decision-making in
such a complex project. Rickover’s solution was to architect an organization and charter
for it that spanned the areas of control necessary to integrate atomic energy with a naval
ship. Theodore Rockwell, a long time engineer for Rickover notes, [Rockwell 1992, p.
44-45]:
“Rickover spent a lot of time thinking about how the program should be
organized, if and when he finally got some money and authority to move
on it. “ There is no precedent, or formula, or procedure for what we’re
trying to do. We’re on our own, there’s nobody to turn to for advice. We
have to think this thing out from basic principles. First, let’s look at the
legalities of the matter…We have to be able to do things in the name of
BuShips---to sign contracts, spend money and approve ship design
features…We need another base of power. And there’s a legal basis for
this. I’ve been studying the Atomic Energy Act of 1946. And it’s very
clear that responsibility and authority for anything atomic lies with the
U.S. Atomic Energy Commission, the AEC. If atomic fuel is to be
procured, if it is to be fabricated and reprocessed after use, if reactor safety
inspections and evaluations are to be made—all these matters require an
AEC base. Only AEC officials can sign contracts and make arrangements
to deal with atomic materials and atomic secrets. So I need an AEC hat
too…the question is, “How do you set up an organization that operates
within two wholly different government agencies?”
With this construct, he drafted a Memorandum of Understanding between both agencies
chartering the organization that would develop and manage the project. The concrete
organizational form evolved over time [Lewis 1980, p. 54-84], but was always working
under two different agencies of the government. This unique structure, built to retain
fidelity to the rule of central control of and accountability for the program, was
formalized by Executive Order in 1982.
Relative to traditional government and military organizations, these were very
broad “system boundaries.” Legal and institutional issues, combined with technical
constraints and Rickover’s “system architecture” rules to mandate this “dual-hatted”
approach. Organizationally very small in scale, a few engineers managing the start of a
10
John Q. Dickmann
ESD Symposium
March 19, 2004
new program, its scope grew over time, extending connections to every site, government
or civilian, with any technical or operational connection to the system.
Technically, the system boundaries and constraints on a nuclear power system for
shipboard use are clear-cut. Physical space is limited, it must “produce enough energy to
propel a ship at significant speeds … operate reliably for sustained periods of time, and
… be manned by highly skilled Navy enlisted men … the propulsion system had to
withstand the shock and motion that were part of the life of any combatant ship.”
[Duncan, 2001, p .100] In the early days of the program, there were many unknown
technical issues and no nuclear engineering expertise or manufacturing base. This was
another significant context factor that drove decisions about technical and organizational
system boundaries.
Because of these operational and technical constraints, Rickover’s solution, again,
was to draw system boundaries broadly. He concurrently explored competing technical
alternatives (liquid metal, pressurized water and gas-cooled designs) in parallel with
building the operational platform. Full-scale prototypes were used as a learning device to
inform design modifications in the shipboard installation. He built tight and carefully
controlled alliances with vendors, exerting technical oversight and control over technical
(and sometimes personnel) decisions that would have been “provided to the customer by
the vendor” in other contexts [Rockwell, 1992, p. 168-171].
Another aspect of system boundaries was the expansion of application of nuclear
propulsion plants to other platforms in the Navy. Nuclear surface ship construction
programs were started in the late 1950s, after the submarine system had become
established and had proven operational utility and safety. These programs grew over
time, with the Navy eventually building 9 nuclear powered Cruisers and today’s force of
11 nuclear powered Aircraft Carriers. However, due to the life cycle expense of
operating nuclear powered surface ships in comparison to the operational benefit gained
by nuclear propulsion, the Navy has decommissioned the Cruisers, maintaining only
nuclear powered Aircraft Carriers in its surface force.
Net Assessment
Through steady, continuous, application of his primary rules, Rickover crafted an
organization widely recognized as a standard for technical and operational excellence.
The external context changed over time as the military threat evolved, political and
service leadership changed and technology advanced but the fundamental rules governing
management and operation of the system remained constant. The program has compiled
a notable record of safe operations, steaming over 128,000,000 miles (more than 5,500
reactor years) with no nuclear accident or environmentally significant release of
radioactivity [CAIB 2003, Bowman, 2003]. Recognizing the effectiveness of this
system, the President formalized it in 1982 with Executive Order 12344. It was
subsequently codified in law (Public Laws 98-525 [1984] and 106-65 [1999].
There are also some things that can be assessed as negative about this system and
its rules. The long tenure of Admiral Rickover may have not been in the best overall
interests of the program. While continuity of leadership is a strong positive factor
(shared by the Toyota example), ‘forever’ may be too long. Rickover’s longevity and
11
John Q. Dickmann
ESD Symposium
March 19, 2004
effectiveness was also closely coupled with strong ties to Congressional leaders, ties
developed over time. There are also some possible longer term and larger scale negative
impacts on institutional innovation in the Navy and in the wider nuclear industry that may
have been negatively impacted by Rickover’s longevity and other legal and regulatory
structures; exploration of these issues requires more detailed analysis.
George C. Marshall and the Marshall Plan
Context and Problem
The Marshall Plan does not explicitly qualify as a socio-technical system but is an
example of an architected large-scale system intended to have socio-technical impact. As
with other large-scale systems considered here, its evolution pre-dates the explicit
architecting process. The Marshall Plan played a central part in the evolving role of the
United States in the post-War geopolitical world order. The most significant factor in
this evolution was the emerging competition with the Soviet Union, noted early in the
post-War period by many U.S. diplomats and strategists and the weakness of the
traditional Great Powers in the aftermath of the War. There were other issues at play
during the period that impacted Marshall’s overall approach to architecting a solution to
the emerging problem of European recovery [Pogue 1987, p. 213, 215, 196, 241-2 and
Acheson 1969, p. 223, 230, 235]:
-
Domestic political tension regarding over-involvement in the national
affairs of others;
-
Uncertainty regarding the precise amount of aid needed to address the
complex issue of world-wide economic and social recovery from the
war;
-
Difficulties surrounding other post- war aid (United Nations Relief and
Rehabilitation Administration (UNRRA) and aid to Greece and
Turkey);
-
An upcoming election year;
-
Added to these was a sense of urgency among the diplomatic
community to restore economic and social infrastructures in the face of
two especially difficult European winters.
Marshall and his immediate staff began laying the groundwork for the proposal of
economic aid to Europe months before his famous Harvard speech on June 5, 1947.
They continued to evolve the plan as formal legislation worked through the Congress.
The basic rules that Marshall laid out at Harvard became the architecture for the
evolution of formal legislation for and administration of the aid program.
The immediately pressing problem the Marshall Plan intended to address was
potential socio-economic collapse of Europe due to widespread physical destruction and
economic dislocation (caused by economic exploitation and destruction of capital and
capital assets during the War). Though there has been debate about the economic
necessity of the Plan, there is little doubt that it provided a stabilizing function during the
transition to post war social, political and economic systems in Europe and, with other
efforts, established the Transatlantic ties that endured through the Cold War [DeLong and
12
John Q. Dickmann
ESD Symposium
March 19, 2004
Eichengreen, 1991].
Solution and Rules
Marshall’s speech clearly articulated Europe’s problem and its implications for
the United States. He then proceeded to state the rules under which an economic aid
program should be run:
1. Assistance should be part of a long-term plan: “Such assistance…must
not be on a piecemeal basis as various crises develop.”
2. Recipients should be integral to building the plan: “The initiative … must
come from Europe. The role of this country should consist of friendly aid
in the drafting of a European program and of later support of such a
program so far as it may be practical for us to do so.”
3. The plan administrator should be independent, isolated from political
interference. This rule was not explicitly articulated in the speech, but
arose as Marshall and the Executive worked with Congress on the formal
legislation that became the Plan.
System Boundaries
For the socio-economic problem that Marshall addressed, system boundaries can
be characterized in terms of nations, political constituencies and characteristics of
candidate projects for Plan aid. The boundaries of the Marshall Plan were not
specifically known when it was articulated, but were defined, as legislation was
developed and as European nations joined. Marshall drew the “upper boundary” of the
plan explicitly by leaving it open to any nation choosing to cooperate under the
framework. Openness was explicitly part of Marshall’s decision calculus:
“Any government that is willing to assist in the task of recovery will find
full cooperation, I am sure, on the part of the United States Government.
Any government which maneuvers to block the recovery of other
countries cannot expect help from us. Furthermore, governments, political
parties, or groups which seek to perpetuate human misery in order to profit
therefrom politically or otherwise will encounter the opposition of the
United States.”
Though not specifically named, the increasingly adversarial Soviet Bloc was the intended
audience for this comment. Conceivably, the Plan could have included all of Eastern
Europe and the Soviet Union. [Pogue, p. 196, 204]
There were other significant boundaries drawn by Marshall. The first was the
‘lack of a boundary’ between the aid plan and its intended recipients. Marshall made the
Plan explicitly contingent upon participation by the countries receiving aid. This served
two functions, related to previously defined context: it appeared less like interference in
the affairs of others and forced stronger administrative ties between the governments of
Europe and the U.S [DeLong and Eichengreen]. The second boundary of importance was
temporal; he convinced Congress to commit to a four and a half year aid period, to ensure
that it could be effectively applied to the problem. [Pogue, p. 241] He also worked with
Congress to make sure that an appropriate administrative boundary was drawn between
13
John Q. Dickmann
ESD Symposium
March 19, 2004
the Plan administrator and undue political influence from the State Department, President
or Congress [Pogue, p. 241-2, 254-56]
Net Assessment:
The Marshall Plan was the concrete instantiation of a clear set of rules set up to
address a compelling national security problem. As architect, Marshall skillfully walked
the space between grand abstraction when articulating the problem and its importance
and practical execution when working with Congress to craft a concrete Plan. A case has
been made that the outcome of the Marshall Plan was not the economic recovery of
Europe but the instantiation and strengthening of U.S/European ties and redirection of
European governments toward democratic infrastructures [DeLong and Eichengreen]. In
many ways, the Economic Cooperation Administration set the stage for a strong U.S.European economic and political relationship during the Cold War. This set of
relationships facilitated effective opposition to totalitarian forces by encouraging
appropriate structural changes in European economies and governments toward open
markets and away from command economies.
Bill Gates and Microsoft Corporation
Background and Goal
The roots of Microsoft Corporation, like the other cases, predate the relevant time
frame of this analysis. The context of the development of Microsoft was the early period
of microprocessor and personal computer development the late 1970s and early 1980s.
During this time frame, there were many different computer operating systems, a wide
array of computers and a high rate of change in them. There was great debate among
software writers at the time over the future direction of their profession, namely whether
software should be free or should be sold for profit. Computer manufacturers were trying
to understand the impact the personal computer would have on their business. This was a
time of high uncertainty regarding future economic value for computer and software
firms.
From very early stages, Gates defined Microsoft’s problem very succinctly:
“Compete and win in the IT industry by focusing on writing and selling software”.
Because of the uncertainty surrounding the future direction of software at the time, Gates'
business model, concentrating only on software, was a risky one. Software is a product
highly dependent on individual human knowledge and skill; it is easily transported and
copied. It also has unique economic characteristics: once the first copy is produced,
subsequent copies are very inexpensive to manufacture, so profit margins can be very
large. In addition, the rapid rate of change in computer hardware capability drives similar
rates of change in the needs and desires of customers. As these capabilities became
available, market success was and remains intimately tied to deep connections with and
understanding of customer value equations and the aggregated dynamics of them.
Solution and Rules
Gates’ rules, similar to Rickover’s and Ohno’s are clear and unambiguous:
commit to technical excellence; hire intelligent, dedicated people; challenge and trust
them. In their 1995 work Microsoft Secrets, Michael Cusumano and Richard Selby listed
the rules that guide the management of Microsoft. It is remarkably consistent with lists
14
John Q. Dickmann
ESD Symposium
March 19, 2004
compiled by other authors who have studied Microsoft. The list, taken from Cusumano
and Selby:
1. Hire a CEO with deep understanding of the technology and the business
2. Organize flexibly around product markets and business functions
3. Hire smart people with a deep understanding of the industry and the
business.
In addition to these rules, there are several subsidiary ones, again, found in numerous
books and articles, but Cusumano and Selby’s [p.26-7] capture them well:
-
“Smart people and small teams;
-
A development process that allows large teams to work like small teams;
-
Product architectures that reduce interdependencies among teams;
-
Nearly all-new product development done on one site;
-
People working on the same machines the build products for;
-
A single main development language;
-
Large capital investments to support people;
-
Internal use of their own engineering tools;
-
More than one person who understands the product details;
-
Managers who both create the product and make the technical decisions;
-
Quick decision making on technical versus business tradeoffs;
-
An enormous feedback loop from customers;
-
Deliberate efforts to learn from past projects”
These rules are not earth shattering, as Cusumano and Selby point out. It is in execution
and in the leadership of the system architect (Gates) that the separation from companies
occurs and performance differentials arise.7
System Boundaries and Evolution
As in any entrepreneurial business, the scale of Microsoft began very small, both
in size and scope. Starting in an apartment, moving to small rented offices with only a
few people using purchased computer time at schools and governments, the physical size
of the enterprise has grown to encompass several sites and a dedicated campus in
Redmond Washington. Product-wise, scale began with BASIC, a software set that
allowed compiling of programs on various hardware systems, growing, as computer
hardware capability grew, to include an operating system (MS-DOS to Windows) then
application software (Office). More recently, growth has been in the direction of webbased services and applications.
7
None of the other system architects in this study have been formally designated or studied as architects.
Only Gates, in a recent corporate reorganization, carries a formal designation: Chief Software Architect.
15
John Q. Dickmann
ESD Symposium
March 19, 2004
This growth in system boundaries is in direct correlation to business success and a
result of the highly effective execution of the business rules noted above. As the external
market for software and related computer products has changed, the business (system)
rules have helped to steer Microsoft in response. The evolution of the product line of
Microsoft can be seen as the result of successful execution and successful execution can
be traced directly to the application of the rule set articulated by Gates. In terms of
organizational design, Cusumano and Selby document numerous organizational changes
over the years, changes that reflect the continual evaluation of current organizational state
versus other possible states, while using the rule sets fed information from inside and
outside Microsoft to make organizational decisions.
Net Assessment
The results of this rule set put into practice are similar to that of Rickover’s
program, though measures of success are different. Corporate performance is well
known, Microsoft is the most highly valued corporation in the world and its products are
highly successful. On non-monetary measures, performance is similarly different from
others in most of commercial industry: employee turnover at Microsoft is among the
lowest in its industry8
Negative perspectives about Microsoft abound, from anti-trust, quality of code,
philosophical perspectives of the IT marketplace. These issues are all debatable and the
eventual success of Microsoft over the long term is an open question. That said, few
people would argue that their ability to sense and respond to a market place driven by
technology with extremely high rates of change is not exceptional.
Summary and Overall Assessment
This study aims to test a conceptual framework that views repeated application of
a limited set of rules as the fundamental guide of system evolution over time, that these
rules can be identified and at first order linked to system performance. By reviewing
histories and other literature on four large-scale systems, this study has shown that
decision-making rules are used by system architects to guide evolution of their systems,
sometimes very clearly and forcefully, and that, at the highest scale, there are a very
limited number of them. Though factors leading to success of each of these systems are
numerous, the effectiveness of each system can be inferred to be at least partially
attributable to the rule sets put in place by the system architects.
Table 1 summarizes the results of this review. In considering these four systems
and architects, common themes emerge:
(1)
A well defined problem or goal for the enterprise or system to
measure progress against;
(2)
A core set of rules governing routine (day-to-day) decisions in
pursuit of the goal;
8
Based on data from Directions on Microsoft, provider of independent analysis of Microsoft at:
http://www.directionsmicrosoft.com/sample/DOMIS/update/2001/02feb/0201mamt_ch.htm , accessed 12
Feb 2004.
16
John Q. Dickmann
ESD Symposium
March 19, 2004
(3) Strong enforcement and reinforcement of rules through feedback and
leadership.
(4)
Goals, rule sets and system boundaries together might be central
factors in successfully understanding system evolution
Further work using this lens to focus on the evolution of large scale systems may be able
to yield more generalizable knowledge for understanding of growth and dynamics of
other complex engineering systems as well as the role that system architects and their rule
sets play in setting conditions and guiding that evolution.
System Architect/System
Clearly
articulated
goal
Ohno
Toyota Production
System
4: Catch up to America
in Automobile
Production
Explicit
recognition of
system
boundaries and
constraints
4: Japanese Market;
Labor relations; Limited
physical resources;
Large competitors;
import restrictions;
Rule
Evolution over
time
Rules
Rickover
Naval Nuclear
Propulsion
4: Harness nuclear
energy for naval
combatants
4: Compete and win in
computer software
industry
4: Domestic political
constraints; Soviets as
adversaries
4: Technical: physical
constraints of ships
and ocean
environment;
organizational:
AEC/Navy interface
4: Computer software
and software enabled
capabilities; technical
capability of
processors; intellectual
capability of people;
4: One shop, growing
over 35 years to
encompass enterprise
and partner suppliers
7: Limited time horizon
program; but integral to
50 year alliance
evolution
4: Technology
evolved inside strict
boundaries;
Organization
institutionalized by
E.O. 12344 and Pubic
Law
4: Computer operating
systems, growing to
encompass applications,
web services;
Organization evolves
continually to adapt to
changing market
4: Eliminate Waste;
Just-in-time;
Autonomation;
4: Long term
commitment;
Autonomous
Administrator; Strong
input from Europe
4: Technical
excellence focused on
safety; decentralized
control with personal
accountability and
review
4: Technical
excellence; Extremely
intelligent people;
decentralized control
with “detailed” review
Marshall
Marshall Plan
4: Provide economic aid
to Europe
Gates
Microsoft
Table 1.
It is also possible to look at these systems and see common patterns in the
character of the rule sets, in the evolution of the systems and the actions of the architects:
9
(1)
Strong emphasis on technical excellence9;
(2)
A strong, technically competent personality in the leadership position
for an extended period of time10;
Marshall Plan is an exception, because of the nature of the system.
17
John Q. Dickmann
ESD Symposium
March 19, 2004
(3)
Rational evaluation of data and information transmitted by feedback
loops with the goal of reducing uncertainty to the maximum extent
possible;
(4)
Strong emphasis on the human element, especially notable in the
technically oriented systems—both attention to their value and to the
critical need to continually refresh technical knowledge.
These patterns and other common characteristics among the systems are summarized in
Table 2.
Ohno
Marshall
Rickover
Gates
TPS
ECA
NNPP
Microsoft
Clear Goal
4
4
4
4
Strive for
technical
excellence
4
4
4
People are key
to success
4
4 11
4
4
Rationally
assess
feedback
4
4
4
4
Draw system
boundaries
4
4
4
4
Continuity of
Leadership
4
4
4
4
Intense focus
on goal and
rules12
4
4
4
4
Class of rule
Table 2
As noted in the discussion of each, these systems are all generally considered
successes. Nonetheless, the success record of each system and, in many cases, the
architects remains open to debate or still is unfolding—success is often ‘in the eye of the
beholder’ and is very dependent on the time period of evaluation.13 Although these
systems appear to be successful over the timeframe of decades, all may be further
questioned as evaluation time increases and more knowledge is gained:
-
For Toyota: the degree of adaptability and flexibility of TPS in the face of
unforeseen turbulence is not well known;
10
Again, Marshall Plan is an exception, though the head of the Economic Cooperation Administration was
specifically chosen for his competence as a businessman. [Pogue, p. 255]
11
For the Marshall Plan, the participation of Europeans in the Plan captures this aspect.
12
This can also be viewed as ‘reduction of noise’ to the system. The ability to focus only on what moved
the organization closer to its goal.
13
It can also be argued that traditional, technically oriented, success measures are becoming insufficient to
effectively judging ‘success’.
18
John Q. Dickmann
ESD Symposium
March 19, 2004
- The centralization of control in atomic matters with the AEC coupled with
the dominance of Rickover in that arena may have inhibited wider
industrial activity in nuclear technology;
-
In hind sight, the Marshall Plan may have been unnecessary for the
economic recovery of Europe, but may have served other important
purposes in the Post-War period;
-
Microsoft Corporation, its products and Bill Gates are the subject of often
contentious debate on the subjects of innovation, competition, and quality
in the computer software (and, more frequently, internet) industry.
Other questions about the effective architecting of complex sociotechnical systems are highlighted by this initial exploration:
-
Role of a strong leader compared to more diffuse decision-making
structures in generating exceptional performance (comparing, for example
nuclear submarines with other large system development programs);
-
What rules best match external contexts for long term system or enterprise
survival?;
-
Effectiveness is a ‘value judgment’, generally either a subjective
evaluation of qualitative data or a subjective choice of a quantitative
metric. Can a set of common success metrics be identified for large-scale
systems so that better generalizations regarding effective architecture rules
may be made, ex ante?
-
It is difficult (at present) to judge effectiveness of rules a-priori; can
models be built to help forecast or guide the evolution of complex largescale systems?
With increasing scale and complexity of our engineered systems, risks of
all types of failure (safety, financial, political, performance) grow and our ability
to microscopically control these systems for risk mitigation becomes untenable.
A closer look at foundational rules governing system behavior and evolution as
well as architecture of processes built on them might guide us toward generation
of tools that can better assess system performance potential, risk and possibly
provide better on-line diagnostic tools as well as better up front enterprise level
design information.
19
John Q. Dickmann
ESD Symposium
March 19, 2004
References:
Acheson, Dean (1969), Present and the Creation, W.W. Norton & Co., New York,
NY.
Baldwin, Carliss and Clark, Kim (2000), Design Rules: The Power of Modularity,
MIT Press, Cambridge, MA.
Bar-Yam, Yaneer (1997), Dynamics of Complex Systems, Perseus Books, Reading,
MA.
Bowman, Frank L., ADM, 2003, Statement before the House Committee on
Science, 29 October 2003.
Christensen, Clayton (1997), The Innovator’s Dilemma, Harvard Business School
Press, Boston, MA.
Columbia Accident Investigation Board (CAIB) Report, (2003) Chapter 7.
Cusumano, Michael and Selby, Richard (1995), Microsoft Secrets, The Free Press,
New York, NY.
DeLong, J. Bradford and Eichengreen, Barry (1993), "The Marshall Plan: History's
Most Successful Structural Adjustment Programme," in Dornbusch, Nölling, and
Layard, eds., Postwar Economic Reconstruction and Lessons for the East Today,
M.I.T. Press, Cambridge, MA, pp. 189-230.
Dodder, R. and Sussman, J (2002), “The Concept of a CLIOS Analysis Illustrated
by the Mexico City Case”, MIT Engineering Systems Division Working Paper
2003-01.07.
ESD Symposium Committee (2001), “ESD Terms and Definitions (version 12)”,
MIT Engineering Systems Division Working Paper 2002-01.
Duncan, Francis (2001), Rickover: The Struggle for Excellence, , Naval Institute
Press, Annapolis, MD.
Duncan, Francis (1990), Rickover and the Nuclear Navy: The Discipline of
Technology, Naval Institute Press, Annapolis, MD.
Hughes, Thomas (1998), Rescuing Prometheus, Vintage Books, New York, NY.
Lewis, Eugene (1980), Public Entrepreneurship, Indiana University Press,
Bloomington, IN.
Magee, C. L. and deWeck, O. L. (2002), “An Attempt at Complex System
Classification”, MIT Engineering Systems Division Working Paper 2003-01.02.
Maier, Mark and Rechtin, Eberhardt (2000), The Art of Systems Architecting, CRC
Press.
Marshall, George C. (1947), Speech given at Harvard University, June 5, 1947,
State Department version referenced at:
http://www.marshallfoundation.org/about_gcm/marshall_plan.htm.
Miller, Roger and Lessard, Donald, 2001, The Strategic Management of Large
20
John Q. Dickmann
ESD Symposium
March 19, 2004
Engineering Projects: Shaping Institutions, Risk and Governance, MIT Press,
Cambridge, MA.
Nishiguchi, Toshihiro and Beaudet, Alexandre (1997), “Self-Organization and
Clustered Control in the Toyota Group: Lessons from the Aisin Fire, MIT
International Motor Vehicle program Working Paper #W-0167a.
Ohno, Taiichi (1988), Toyota Production System: Beyond Large Scale Production,
, Productivity Press, Portland, OR.
Pahl, G.. and Bietz, W. (1996), Engineering Design: A Systematic Approach,
Springer, New York.
Pogue, Forrest C. (1987) George C. Marshall, , Viking, New York, NY.
Polmar, Norman and Allen, Thomas (1982), Rickover: Controversy and Genius, ,
Simon and Schuster, New York, NY.
Poole, Robert (1997), Beyond Engineering, Oxford University Press, New York,
NY.
Rockwell, Theodore (1992), The Rickover Effect: How One Man Made a
Difference, , Naval Institute Press, Annapolis, MD.
Stross, Randall (1996) The Microsoft Way, Addison-Wesley, Reading, MA.
Utterback, James (1994), Mastering the Dynamics of Innovation, Harvard Business
School Press, Boston, MA
Watts, Duncan J. (2003), Six Degrees, , W.W. Norton & Co. New York, NY.
Whitney, Daniel, 2004, “System Architecture and Complexity”, paper prepared for
ESD Symposium, 29-31 March 2004.
Wolfram, Stephen (2002), A New Kind of Science, Wolfram Press, Chicago, IL.
Womak, James, Jones, Daniel and Roos Daniel (1990), The Machine That Changed
the World, HarperCollins, New York, NY.
Womak, James and Jones, Daniel (1996), Lean Thinking, Simon and Schuster, New
York, NY.
21