ConwaysLawRevisited

SOZIALE SYSTEME
MICROSERVICES
AGILITÄT
CONWAYS LAW REVISITEDJens Himmelreich - XPDays 2015

HOW DO
COMMITTEES
INVENT?by MELVIN E. CONWAY
That kind of intellectual activity which creates
a useful whole from its diverse parts may be
called the design of a system. Whether the
particular activity is the creation of specifica-
tions for a major weapon system, the formation of a rec-
ommendation to meet a social challenge, or the program-
ming of a computer, the general activity is largely the
same.
Typically, the objective of a design organization is the
creation and assembly of a document containing a coherent-
ly structured body of information. We may name this
information the system design. It is typically produced for
a sponsor who usually desires to carry out some activity
guided by the system design. For example, a public official
may wish to propose legislation to avert a recurrence of a
recent disaster, so he appoints a team to explain the catas-
trophe. Or a manufacturer needs a new product and desig-
nates a product planning activity to specify what should be
introduced.
The design organization may or may not be involved in
the construction of the system it designs. Frequently, in
public affairs, there are policies which discourage a group's
acting upon its own recommendations, whereas, in private
industry, quite the opposite situation often prevails.
It seems reasonable to suppose that the knowledge that
one will have to carry out one's own recommendations or
that this task will fall to others, probably affects some
design choices which the individual designer is cailed upon
to make. Most design activity requires continually making
choices. Many of these choices may be more than design
decisions; they may also be personal decisions the designer
makes about his own future. As we shall see later, the
incentives which exist in a conventional management en-
vironment can motivate choices which subvert the intent of
the sponsor.!
stages of design
The initial stages .of a design effort are concerned more
with structuring of the design activity than with the system
itsel£.2 The full-blown design activity cannot proceed until
certain preliminary milestones are passed. These include:
1. Understanding of the boun9aries, both on the design
activity and on the system to be designed, placed by
the sponsor and by the worltl's realities.
2. Achievement of a preliminary notion of the system's
organization so that design task groups can be mean-
ingfully assigned.
We shall see in detail later that the very act of organiz-
1 A related, but much more comprehensive discussion of the behavior of
system-designing organizations is found in John Kenneth Galbraith's,
The New Industrial State (Boston, Houghton Mifflin, 1967). See especially
Chapter VI, "The Technostructur<!."
2 For o discussion of the problems which may arise when the design
activity takes the form of o project in a functional environment, see C. J.
Middleton, "How to Set Up o Project Organization," Harvard Business
Review, March-April, 1967, p. 73.
28
design organization criteria
ing a design team means that certain design decisions have
already been made, explicitly or otherwise. Given any
design team organization, there is a class of design alterna-
tives which cannot be effectively pursued by such an
organization because the necessary communication paths
do not exist. Therefore, there is no such thing as a design
group which is both organized and unbiased.
Once the organization of the design team is chosen, it is
possible to delegate activities to the subgroups of the
organization. Every time a delegation is made and some-
body's scope of inquiry is narrowed, the class of design
alternatives which can be effectively pursued is also nar-
rowed.
Once scopes of activity are defined, a coordination prob-
lem is created. Coordination among task groups, although
it appears to lower the productivity of the individual in the
small group, provides the only possibility that the separate
task groups will be able to consolidate their efforts into a
unified system design.
Thus the life cycle of a system design effort proceeds
through the following general stages:
1. Drawing of boundaries according to the ground
rules.
2. Choice of a preliminary system concept.
3. Organization of the design activity and delegation of
tasks according to that concept.
4. Coordination among delegated tasks.
5. Consolidation of subdesigns into a single design.
It is possible that a given design activity will not pro-
ceed straight through this list. It might conceivably reorga-
nize upon discovery of a new, and obviously superior,
design concept; but such an appearance of uncertainty is
unflattering, and the very act of voluntarily abandoning a
creation is painful and expensive. Of course, from the
Dr. Conway is manager, pe-
ripheral systems research, at
Sperry Rand's Univac Div.,
where he is working on recog-
nition of continuous speech. He
has previously been a research
associate at Case Western Re-
serve Univ., and a software
consultant. .He has an MS in
physics from CaiTech and a
PhD in math from Case.
:C»ATAMATION

HOW DO
COMMITTEES
INVENT?Melvin Conway - Datamation, April 1968

ORGANIZATIONS WHICH DESIGN
SYSTEMS ARE CONSTRAINED TO
PRODUCE DESIGNS WHICH ARE COPIES
OF THE COMMUNICATION STRUCTURES
OF THESE ORGANIZATIONS.
MELVIN CONWAY

IF YOU HAVE FOUR GROUPS
WORKING ON A COMPILER, 
YOU'LL GET  
A 4-PASS COMPILER.
HACKERDICTIONARY

ORGANISATIONspiegelt sich im
SYSTEM

ORGANISATIONmaterialisiert sich im
SYSTEM

ORGANISATIONzementiert im
SYSTEM

ORGANISATIONist eine Hypothese für die
DOMÄNE

ORGANISATIONoperationalisiert
DOMÄNE

DOMÄNEoperationalisiert in
ORGANISATIONmaterialisiert im
SYSTEM

GIVEN ANY DESIGN TEAM
ORGANIZATION, THERE IS A CLASS
OF DESIGN ALTERNATIVES WHICH
CANNOT BE EFFECTIVLEY PURSUED
BY SUCH AN ORGANIZATION …
MELVIN CONWAY

BECAUSE THE DESIGN WHICH
OCCURS FIRST IS ALMOST NEVER
THE BEST POSSIBLE … THEREFORE,
FLEXIBILITY OF ORGANIZATION IS
IMPORTANT TO EFFECTIVE DESIGN.
MELVIN CONWAY

Copyright © 2007, 2008, 2011 by Alan MacCormack, John Rusnak, and Carliss Baldwin
Working papers are in draft form. This working paper is distributed for purposes of comment and
discussion only. It may not be reproduced without permission of the copyright holder. Copies of working
papers are available from the author.
Exploring the Duality
between Product and
Organizational Architectures:
A Test of the “Mirroring”
Hypothesis
Alan MacCormack
John Rusnak
Carliss Baldwin
Working Paper
08-039

EXPLORING THE DUALITY BETWEEN 
PRODUCT AND ORGANIZATIONAL ARCHITECTURES: 
A TEST OF THE MIRRORING HYPOTHESISAlan McCormick, John Rusnak, Carliss Baldwin
Harvard Business School Working Paper, 27 Mar 2008

MIRRORING HYPOTHESES
„Loosely-coupled organizations 
will tend to develop products
with more modular architecture 
than tightly-coupled organizations.“

GNUCASH
MYBOOKS
ABIWORD
STARWRITER
GNUMERIC
STARCALC
LINUX 2.1.32
SOLARIS
LINUX 2.6.8
XNU
MYSQL
BERKELEY DB

GNUCASH
MYBOOKS
ABIWORD
STARWRITER
GNUMERIC
STARCALC
LINUX 2.1.32
SOLARIS
LINUX 2.6.8
XNU
MYSQL
BERKELEY DB
7,74%
47,14%
8,25%
41,77%
23,62%
54,31%
7,18%
22,59%
7,21%
24,83%
11,3%
43,23%

IN ALL PAIRS WE EXAMINE, THE
LOOSELY-COUPLED ORGANIZATION
DEVELOPS A PRODUCT WITH A MORE
MODULAR DESIGN THAN THAT OF THE
TIGHTLY-COUPLED ORGANIZATION.
MACCORMACK, RUSNACK, BALDWIN

THE INFLUENCE OF ORGANIZATIONAL STRUCTURE ON
SOFTWARE QUALITY: AN EMPIRICAL CASE STUDY
Nachiappan Nagappan
Microsoft Research
Redmond, WA, USA
nachin@microsoft.com
Brendan Murphy
Microsoft Research
Cambridge, UK
bmurphy@microsoft.com
Victor R. Basili
University of Maryland
College Park, MD, USA
basili@cs.umd.edu
ABSTRACT
Often software systems are developed by organizations consisting
of many teams of individuals working together. Brooks states in
the Mythical Man Month book that product quality is strongly
affected by organization structure. Unfortunately there has been
little empirical evidence to date to substantiate this assertion. In
this paper we present a metric scheme to quantify organizational
complexity, in relation to the product development process to
identify if the metrics impact failure-proneness. In our case study,
the organizational metrics when applied to data from Windows
Vista were statistically significant predictors of failure-proneness.
The precision and recall measures for identifying failure-prone
binaries, using the organizational metrics, was significantly higher
than using traditional metrics like churn, complexity, coverage,
dependencies, and pre-release bug measures that have been used
to date to predict failure-proneness. Our results provide empirical
evidence that the organizational metrics are related to, and are
effective predictors of failure-proneness.
Categories and Subject Descriptors
D.2.8 [Software Engineering]: Software Metrics – complexity
measures, performance measures, process metrics, product
metrics.
General Terms
Measurement, Reliability, Human Factors.
Keywords
Organizational structure, Failures, Code churn, People, Empirical
Studies.
1. INTRODUCTION
Software engineering is a complex engineering activity. It
involves interactions between people, processes, and tools to
develop a complete product. In practice, commercial software
development is performed by teams consisting of a number of
individuals ranging from the tens to the thousands. Often these
people work via an organizational structure reporting to a manager
or set of managers.
The intersection of people [9], processes [29] and organization
[33] and the area of identifying problem prone components early
in the development process using software metrics (e.g. [13, 24,
28, 30]) has been studied extensively in recent years. Early
indicators of software quality are beneficial for software engineers
and managers in determining the reliability of the system,
estimating and prioritizing work items, focusing on areas that
require more testing, inspections and in general identifying
“problem-spots” to manage for unanticipated situations. Often
such estimates are obtained from measures like code churn, code
complexity, code coverage, code dependencies, etc. But these
studies often ignore one of the most influential factors in software
development, specifically “people and organizational structure”.
This interesting fact serves as our main motivation to understand
the intersection between organizational structure and software
quality: How does organizational complexity influence quality?
Can we identify measures of the organizational structure? How
well do they do at predicting quality, e.g., do they do a better job
of identifying problem components than earlier used metrics?
Conway’s Law states that “organizations that design systems are
constrained to produce systems which are copies of the
communication structures of these organizations.” [8]. Similarly,
Fred Brooks argues in the Mythical Man Month [6] that the
product quality is strongly affected by org structure. With the
advent of global software development where teams are
distributed across the world the impact of organization structure
on Conway’s law [15] and its implications on quality is
significant. To the best of our knowledge there has been little or
no empirical evidence regarding the relationship/association
between organizational structure and direct measures of software
quality like failures.
In this paper we investigate this relationship between
organizational structure and software quality by proposing a set of
eight measures that quantify organizational complexity. These
eight measures provide a balanced view of organizational
complexity from the code viewpoint. For the organizational
metrics, we try to capture issues such as organizational distance of

THE INFLUENCE OF ORGANISATIONAL STRUCTURE
ON SOFTWARE QUALITY: 
AN EMPIRICAL CASE STUDYNachiappan Nagappan, Brendon Murphy, Victor R. Basili
Microsoft Research TechReport, January 2008

IN THIS PAPER WE PRESENT A METRIC
SCHEME TO QUANTIFY ORGANIZATIONAL
COMPLEXITY, IN RELATION TO THE
PRODUCT DEVELOPMENT PROCESS TO
IDENTIFY IF THE METRICS IMPACT
FAILURE-PRONENESS.
NAGAPPAN, MURPHY, BASILI

ORGANIZATIONAL STRUCTURE
CODE CHURN
CODE COMPLEXITY
DEPENDENCIES
CODE COVERAGE
PRE-RELEASE BUGS
86,2%
78,6%
79,3%
74,4%
83,3%
73,8%
84,0%
79,9%
66,0%
69,9%
54,4%
62,9%
PRECISION
RECALL

THE PRECISION AND RECALL MEASURES
FOR IDENTIFYING FAILURE-PRONE
BINARIES, USING THE ORGANIZATIONAL
METRICS, WAS SIGNIFICANTLY HIGHER
THAN USING TRADITIONAL METRICS.
NAGAPPAN, MURPHY, BASILI

MUSTERtechnisch-organisatorisch

SHOP
RECO TRACKING
SEARCH
NEWS-
LETTER

SHOP
RECO TRACKING
SEARCH
NEWS-
LETTER
SEO ATTRIBUTE
BILD

MUSTERtemporal - funktional - sozial

DWAWII
SH
FRONT
OP
RECO TR
SEA NEWS
SEO ATTR
BILD
PROD

DWAWII
SH
FRONT
OP
RECO TR
SEA NEWS
SEO ATTR
BILD
PROD
FEATURE (BILD)
FEATURE (PREIS)

TEST
FRONTEND
APPLIKATION
PRODUKTION
DATENBANK
BETRIEB
FEATURE
EFFIZIENZ

KUNDE PRODUKT BILD
SUCHE WARENKORB NAVIGATION EMPFEHLUNG DETAILSEITE MEINKONTO
REDUNDANZ

VERTIKALESelf Contained System

AMAZONNETFLIX
OTTO
GALERIA
TALENTFORMATION
DEVOPS MICROSERVICES
Quellen

SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
KUNDENORIENTIERUNG

TIME-TO-MARKET

DB DB DB DB DB
HTML HTML HTML HTML HTML
A B
C
A B
C
A B
C
A B
C
A B
C

DB DB DB DB DB
VARIANTE
PRODUKT 
KNOTEN
PRODUKT
WARENKORB 
POSTITION
ARTIKEL

DB DB DB DB DB
A B
C
A B
C
A B
C
A B
C
A B
C
HTML
DETAIL
HTML
NAVIGATION
HTML
EMPFEHLUNG
HTML
MINIWARENKORB
HTML
ANREDE
STYLEGUIDE

DB DB DB DB DB
A B
C
A B
C
A B
C
A B
C
A B
C
HTMLHTML HTML HTML HTML
RWD APP INSTORE

FACHLICHE ISOLATION
Bounded Context

ORGANISATORISCHE ISOLATION
Separates Scrumteam

TECHNISCHE ISOLATION
Keine synchrone Kopplung

FRONTENDINTEGRATION
DETAILNAVIGATION
EMPFEHLUNG
MINIWARENKORBANREDE

REST-INTEGRATION
smart endpoints and dump pipes

BEWERTEN
PIM
MICROSERVICES
synchrone Kopplung erlaubt
DETAIL
SEITE BACKOFFICE
PRODUKT
VERGLEICH

PAGER PAGER PAGER PAGER PAGER
BETRIEBLICHE ISOLATION
You Built it - you run it!

ORGANISATION
SYSTEM
Wie spiegelt sich meine Organisation
im technischen System?

DOMÄNE
ORGANISATION
Welche Hypothese über die Domäne
stellt meine Organisation dar?

QUELLEN
HOW DO COMMITTEES INVENT?
http://www.melconway.com/Home/pdf/committees.pdf
EXPLORING THE DUALITY BETWEEN PRODUCT AND ORGANIZATIONAL ARCHITECTURES: 
A TEST OF THE MIRRORING HYPOTHESIS
http://www.hbs.edu/research/pdf/08-039.pdf
THE INFLUENCE OF ORGANISATIONAL STRUCTURE ON SOFTWARE QUALITY: 
AN EMPIRICAL CASE STUDY
http://research.microsoft.com/pubs/70535/tr-2008-11.pdf
The colors and fonts are inspired by Phil Hawksworth
http://hawksworx.com/
THIS WORK IS LICENSED UNDER A CREATIVE COMMONS
ATTRIBUTION-NONCOMMERCIAL-NODERIVS 3.0 UNPORTED LICENSE

ConwaysLawRevisited

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie ConwaysLawRevisited

Ähnlich wie ConwaysLawRevisited (20)

Mehr von Jens Himmelreich

Mehr von Jens Himmelreich (15)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

ConwaysLawRevisited