SOZIALE SYSTEME
MICROSERVICES
AGILITÄT
CONWAYS LAW REVISITEDJens Himmelreich - XPDays 2015
CONWAYS
LAW
HOW DO
COMMITTEES
INVENT?by MELVIN E. CONWAY
That kind of intellectual activity which creates
a useful whole from its dive...
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 ...
IF YOU HAVE FOUR GROUPS
WORKING ON A COMPILER,

YOU'LL GET 

A 4-PASS COMPILER.
HACKERDICTIONARY
A
B
C
A
B
C
A
B
C
?
A
B
C
A
B
C
A
B
C
A
B
C
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...
BECAUSE THE DESIGN WHICH
OCCURS FIRST IS ALMOST NEVER
THE BEST POSSIBLE … THEREFORE,
FLEXIBILITY OF ORGANIZATION IS
IMPORT...
DOMÄNE
ORGANISATION
SYSTEM
KOPPLUNG
Copyright © 2007, 2008, 2011 by Alan MacCormack, John Rusnak, and Carliss Baldwin
Working papers are in draft form. This w...
EXPLORING THE DUALITY BETWEEN

PRODUCT AND ORGANIZATIONAL ARCHITECTURES:

A TEST OF THE MIRRORING HYPOTHESISAlan McCormick...
MIRRORING HYPOTHESES
„Loosely-coupled organizations

will tend to develop products
with more modular architecture

than ti...
MIRRORING HYPOTHESES
„Loosely-coupled organizations

will tend to develop products
with more modular architecture

than ti...
MIRRORING HYPOTHESES
„Loosely-coupled organizations

will tend to develop products
with more modular architecture

than ti...
MIRRORING HYPOTHESES
„Loosely-coupled organizations

will tend to develop products
with more modular architecture

than ti...
MIRRORING HYPOTHESES
„Loosely-coupled organizations

will tend to develop products
with more modular architecture

than ti...
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...
IN ALL PAIRS WE EXAMINE, THE
LOOSELY-COUPLED ORGANIZATION
DEVELOPS A PRODUCT WITH A MORE
MODULAR DESIGN THAN THAT OF THE
T...
QUALITÄT
THE INFLUENCE OF ORGANIZATIONAL STRUCTURE ON
SOFTWARE QUALITY: AN EMPIRICAL CASE STUDY
Nachiappan Nagappan
Microsoft Resea...
THE INFLUENCE OF ORGANISATIONAL STRUCTURE
ON SOFTWARE QUALITY:

AN EMPIRICAL CASE STUDYNachiappan Nagappan, Brendon Murphy...
IN THIS PAPER WE PRESENT A METRIC
SCHEME TO QUANTIFY ORGANIZATIONAL
COMPLEXITY, IN RELATION TO THE
PRODUCT DEVELOPMENT PRO...
ORGANIZATIONAL STRUCTURE
CODE CHURN
CODE COMPLEXITY
DEPENDENCIES
CODE COVERAGE
PRE-RELEASE BUGS
86,2%
78,6%
79,3%
74,4%
83...
THE PRECISION AND RECALL MEASURES
FOR IDENTIFYING FAILURE-PRONE
BINARIES, USING THE ORGANIZATIONAL
METRICS, WAS SIGNIFICAN...
MUSTER
1
CD
WEBSHOP
CD
CD
WEBSHOP
PROD
WEBSHOP
PROD
WEBSHOP
MUSTERtemporal
MUSTER
MUSTERtechnisch-organisatorisch
AB
A
B
B
A
MUSTER
2
SHOP
SHOP
RECO TRACKING
SEARCH
NEWS-
LETTER
SHOP
RECO TRACKING
SEARCH
NEWS-
LETTER
SEO ATTRIBUTE
BILD
SHOP
RECO TRACKING
SEARCH
NEWS-
LETTER
SEO ATTRIBUTE
BILD
SHOP
RECO TRACKING
SEARCH
NEWS-
LETTER
SEO ATTRIBUTE
BILD
MUSTERfunktional
MUSTER
3
SHOP
SHOP
D
SHOP
DI
SHOP
DWAWII
SHOP
DWAWII
SHOP
DWAWII
FRONTEND
APPLIKATION
DWAWII
FRONT
APPLIKATION
DWAWII
T1
FRONT
T2
MUSTERsozial
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)
CONWAYkonstruktiv
DOMÄNEoperationalisiert in
ORGANISATIONmaterialisiert im
SYSTEM
TEST
FRONTEND
APPLIKATION
PRODUKTION
DATENBANK
BETRIEB
FEATURE
EFFIZIENZ
KUNDE PRODUKT BILD
SUCHE WARENKORB NAVIGATION EMPFEHLUNG DETAILSEITE MEINKONTO
REDUNDANZ
VERTIKALE
VERTIKALESelf Contained System
VERTIKALEMicroservice mit UI
AMAZONNETFLIX
OTTO
GALERIA
TALENTFORMATION
DEVOPS MICROSERVICES
Quellen
PHASENdes
KAUFPROZESSES
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
KUNDENORIENTIERUNG
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
TIME-TO-MARKET
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
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
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
DB DB DB DB DB
HTML HTML HTML HTML HTML
VARIANTE
PRODUKT

KNOTEN
PRODUKT
WARENKOR...
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
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
HTML
DETAIL...
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
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
HTMLHTML HT...
ARCHITEKTUR-
PRINZIPIEN
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
FACHLICHE ISOLATION
Bounded Context
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
ORGANISATORISCHE ISOLATION
Separates Scrumteam
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
TECHNISCHE ISOLATION
Keine synchrone Kopplung
FRONTENDINTEGRATION
DETAILNAVIGATION
EMPFEHLUNG
MINIWARENKORBANREDE
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
REST-INTEGRATION
smart endpoints and dump pipes
BEWERTEN
PIM
MICROSERVICES
synchrone Kopplung erlaubt
DETAIL
SEITE BACKOFFICE
PRODUKT
VERGLEICH
SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
PAGER PAGER PAGER PAGER PAGER
BETRIEBLICHE ISOLATION
You Built it - you run it!
CONWAYkompakt
DOMÄNE
ORGANISATION
SYSTEM
DOMÄNEoperationalisiert in
ORGANISATIONmaterialisiert im
SYSTEM
ORGANISATION
SYSTEM
Wie spiegelt sich meine Organisation
im technischen System?
DOMÄNE
ORGANISATION
Welche Hypothese über die Domäne
stellt meine Organisation dar?
?ENDEFragen?
QUELLEN
HOW DO COMMITTEES INVENT?
http://www.melconway.com/Home/pdf/committees.pdf
EXPLORING THE DUALITY BETWEEN PRODUCT A...
ConwaysLawRevisited
Nächste SlideShare
Wird geladen in …5
×

ConwaysLawRevisited

767 Aufrufe

Veröffentlicht am

Conways Law says: the structure of a technical system ist a mirror of the structure of the underlying social system.

The first part of the slides will refer the thesis of Conway.

The second part discusses scientific papers about the Law an Coupling and about the Law and prediction of software quality.

The third part explains patterns of the co-evolution of systems.

The Last part tries to explain an approach, which is based on Conways Law. The approach ist a way to structure microservices in the world of e-commerce.

Veröffentlicht in: Software

ConwaysLawRevisited

  1. 1. SOZIALE SYSTEME MICROSERVICES AGILITÄT CONWAYS LAW REVISITEDJens Himmelreich - XPDays 2015
  2. 2. CONWAYS LAW
  3. 3. 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
  4. 4. HOW DO COMMITTEES INVENT?Melvin Conway - Datamation, April 1968
  5. 5. ORGANIZATIONS WHICH DESIGN SYSTEMS ARE CONSTRAINED TO PRODUCE DESIGNS WHICH ARE COPIES OF THE COMMUNICATION STRUCTURES OF THESE ORGANIZATIONS. MELVIN CONWAY
  6. 6. IF YOU HAVE FOUR GROUPS WORKING ON A COMPILER,
 YOU'LL GET 
 A 4-PASS COMPILER. HACKERDICTIONARY
  7. 7. A B C
  8. 8. A B C A B C
  9. 9. ?
  10. 10. A B C
  11. 11. A B C
  12. 12. A B C A B C
  13. 13. ORGANISATIONspiegelt sich im SYSTEM
  14. 14. ORGANISATIONmaterialisiert sich im SYSTEM
  15. 15. ORGANISATIONzementiert im SYSTEM
  16. 16. ORGANISATIONist eine Hypothese für die DOMÄNE
  17. 17. ORGANISATIONoperationalisiert DOMÄNE
  18. 18. DOMÄNEoperationalisiert in ORGANISATIONmaterialisiert im SYSTEM
  19. 19. GIVEN ANY DESIGN TEAM ORGANIZATION, THERE IS A CLASS OF DESIGN ALTERNATIVES WHICH CANNOT BE EFFECTIVLEY PURSUED BY SUCH AN ORGANIZATION … MELVIN CONWAY
  20. 20. BECAUSE THE DESIGN WHICH OCCURS FIRST IS ALMOST NEVER THE BEST POSSIBLE … THEREFORE, FLEXIBILITY OF ORGANIZATION IS IMPORTANT TO EFFECTIVE DESIGN. MELVIN CONWAY
  21. 21. DOMÄNE ORGANISATION SYSTEM
  22. 22. KOPPLUNG
  23. 23. 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
  24. 24. 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
  25. 25. MIRRORING HYPOTHESES „Loosely-coupled organizations
 will tend to develop products with more modular architecture
 than tightly-coupled organizations.“
  26. 26. MIRRORING HYPOTHESES „Loosely-coupled organizations
 will tend to develop products with more modular architecture
 than tightly-coupled organizations.“
  27. 27. MIRRORING HYPOTHESES „Loosely-coupled organizations
 will tend to develop products with more modular architecture
 than tightly-coupled organizations.“
  28. 28. MIRRORING HYPOTHESES „Loosely-coupled organizations
 will tend to develop products with more modular architecture
 than tightly-coupled organizations.“
  29. 29. MIRRORING HYPOTHESES „Loosely-coupled organizations
 will tend to develop products with more modular architecture
 than tightly-coupled organizations.“
  30. 30. GNUCASH MYBOOKS ABIWORD STARWRITER GNUMERIC STARCALC LINUX 2.1.32 SOLARIS LINUX 2.6.8 XNU MYSQL BERKELEY DB
  31. 31. 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%
  32. 32. 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
  33. 33. QUALITÄT
  34. 34. 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
  35. 35. THE INFLUENCE OF ORGANISATIONAL STRUCTURE ON SOFTWARE QUALITY:
 AN EMPIRICAL CASE STUDYNachiappan Nagappan, Brendon Murphy, Victor R. Basili Microsoft Research TechReport, January 2008
  36. 36. 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
  37. 37. 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
  38. 38. THE PRECISION AND RECALL MEASURES FOR IDENTIFYING FAILURE-PRONE BINARIES, USING THE ORGANIZATIONAL METRICS, WAS SIGNIFICANTLY HIGHER THAN USING TRADITIONAL METRICS. NAGAPPAN, MURPHY, BASILI
  39. 39. MUSTER
  40. 40. 1
  41. 41. CD
  42. 42. WEBSHOP CD
  43. 43. CD WEBSHOP
  44. 44. PROD WEBSHOP
  45. 45. PROD WEBSHOP
  46. 46. MUSTERtemporal
  47. 47. MUSTER
  48. 48. MUSTERtechnisch-organisatorisch
  49. 49. AB A B B A
  50. 50. MUSTER
  51. 51. 2
  52. 52. SHOP
  53. 53. SHOP RECO TRACKING SEARCH NEWS- LETTER
  54. 54. SHOP RECO TRACKING SEARCH NEWS- LETTER SEO ATTRIBUTE BILD
  55. 55. SHOP RECO TRACKING SEARCH NEWS- LETTER SEO ATTRIBUTE BILD
  56. 56. SHOP RECO TRACKING SEARCH NEWS- LETTER SEO ATTRIBUTE BILD
  57. 57. MUSTERfunktional
  58. 58. MUSTER
  59. 59. 3
  60. 60. SHOP
  61. 61. SHOP
  62. 62. D SHOP
  63. 63. DI SHOP
  64. 64. DWAWII SHOP
  65. 65. DWAWII SHOP
  66. 66. DWAWII FRONTEND APPLIKATION
  67. 67. DWAWII FRONT APPLIKATION
  68. 68. DWAWII T1 FRONT T2
  69. 69. MUSTERsozial
  70. 70. MUSTERtemporal - funktional - sozial
  71. 71. DWAWII SH FRONT OP RECO TR SEA NEWS SEO ATTR BILD PROD
  72. 72. DWAWII SH FRONT OP RECO TR SEA NEWS SEO ATTR BILD PROD FEATURE (BILD) FEATURE (PREIS)
  73. 73. CONWAYkonstruktiv
  74. 74. DOMÄNEoperationalisiert in ORGANISATIONmaterialisiert im SYSTEM
  75. 75. TEST FRONTEND APPLIKATION PRODUKTION DATENBANK BETRIEB FEATURE EFFIZIENZ
  76. 76. KUNDE PRODUKT BILD SUCHE WARENKORB NAVIGATION EMPFEHLUNG DETAILSEITE MEINKONTO REDUNDANZ
  77. 77. VERTIKALE
  78. 78. VERTIKALESelf Contained System
  79. 79. VERTIKALEMicroservice mit UI
  80. 80. AMAZONNETFLIX OTTO GALERIA TALENTFORMATION DEVOPS MICROSERVICES Quellen
  81. 81. PHASENdes KAUFPROZESSES
  82. 82. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN KUNDENORIENTIERUNG
  83. 83. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN TIME-TO-MARKET
  84. 84. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
  85. 85. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN
  86. 86. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN 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
  87. 87. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN DB DB DB DB DB HTML HTML HTML HTML HTML VARIANTE PRODUKT
 KNOTEN PRODUKT WARENKORB
 POSTITION ARTIKEL
  88. 88. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN 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 HTML DETAIL HTML NAVIGATION HTML EMPFEHLUNG HTML MINIWARENKORB HTML ANREDE STYLEGUIDE
  89. 89. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN 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 HTMLHTML HTML HTML HTML RWD APP INSTORE
  90. 90. ARCHITEKTUR- PRINZIPIEN
  91. 91. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN FACHLICHE ISOLATION Bounded Context
  92. 92. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN ORGANISATORISCHE ISOLATION Separates Scrumteam
  93. 93. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN TECHNISCHE ISOLATION Keine synchrone Kopplung
  94. 94. FRONTENDINTEGRATION DETAILNAVIGATION EMPFEHLUNG MINIWARENKORBANREDE
  95. 95. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN REST-INTEGRATION smart endpoints and dump pipes
  96. 96. BEWERTEN PIM MICROSERVICES synchrone Kopplung erlaubt DETAIL SEITE BACKOFFICE PRODUKT VERGLEICH
  97. 97. SUCHEN ENTDECKEN BEWERTEN KAUFEN STEUERN PAGER PAGER PAGER PAGER PAGER BETRIEBLICHE ISOLATION You Built it - you run it!
  98. 98. CONWAYkompakt
  99. 99. DOMÄNE ORGANISATION SYSTEM
  100. 100. DOMÄNEoperationalisiert in ORGANISATIONmaterialisiert im SYSTEM
  101. 101. ORGANISATION SYSTEM Wie spiegelt sich meine Organisation im technischen System?
  102. 102. DOMÄNE ORGANISATION Welche Hypothese über die Domäne stellt meine Organisation dar?
  103. 103. ?ENDEFragen?
  104. 104. 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

×