- microservices - and the inverse Conway manoeuvre jalewis@thoughtworks.com @boicy 1
“…organizations which design systems … are constrained to produce designs which are copies of the communication structure of those organizations” Melvyn Conway, 1968 2
The mirroring phenomenon is consistent with two rival causal mechanisms. First, designs may evolve to re fl ect their development environments. In tightly-coupled organizations , dedicated teams employed by a single fi rm and located at a single site develop the design. Problems are solved by face-to-face interaction, and performance “tweaked” by taking advantage of the access that module developers have to information and solutions developed in other modules. Even if not an explicit managerial choice, the design naturally becomes more tightly-coupled . By contrast, in loosely-coupled organizations , a large, distributed team of volunteers develops the design. Face-to-face communications are rare given most developers never meet. Hence fewer connections between modules are established. The architecture that evolves is more modular as a result of the limitations on communication between developers. "Exploring the Duality between Product and Organizational Architectures : A Test of the “Mirroring” Hypothesis" 2007 http://www.hbs.edu/faculty/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf 4
The mirroring phenomenon is consistent with two rival causal mechanisms. First, designs may evolve to re fl ect their development environments. In tightly-coupled organizations , dedicated teams employed by a single fi rm and located at a single site develop the design. Problems are solved by face-to-face interaction, and performance “tweaked” by taking advantage of the access that module developers have to information and solutions developed in other modules. Even if not an explicit managerial choice, the design naturally becomes more tightly-coupled . By contrast, in loosely-coupled organizations , a large, distributed team of volunteers develops the design. Face-to-face communications are rare given most developers never meet. Hence fewer connections between modules are established. The architecture that evolves is more modular as a result of the limitations on communication between developers. "Exploring the Duality between Product and Organizational Architectures : A Test of the “Mirroring” Hypothesis" http://www.hbs.edu/faculty/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf 5
The mirroring phenomenon is consistent with two rival causal mechanisms. First, designs may evolve to re fl ect their development environments. In tightly-coupled organizations , dedicated teams employed by a single fi rm and located at a single site develop the design. Problems are solved by face-to-face interaction, and performance “tweaked” by taking advantage of the access that module developers have to information and solutions developed in other modules. Even if not an explicit managerial choice, the design naturally becomes more tightly-coupled . By contrast, in loosely-coupled organizations , a large, distributed team of volunteers develops the design. Face-to-face communications are rare given most developers never meet. Hence fewer connections between modules are established. The architecture that evolves is more modular as a result of the limitations on communication between developers. "Exploring the Duality between Product and Organizational Architectures : A Test of the “Mirroring” Hypothesis" http://www.hbs.edu/faculty/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf 6
tightly-coupled organizations ⇒ design becomes more tightly-coupled . loosely-coupled organizations ⇒ , design is more modular as a result of the limitations on communication between developers. "Exploring the Duality between Product and Organizational Architectures : A Test of the “Mirroring” Hypothesis" http://www.hbs.edu/faculty/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf 7
8
componentisation via services organised around business capabilities decentralised data management products not projects decentralised governance smart endpoints and dumb pipes evolutionary design infrastructure automation designed for failure
But fi rst… How big are they?
microservices should be: cheap to replace quick to scale withstand failure and should allow you to go as “fast as possible”? 14
THE 20 TH CENTURY ORGANISATION 15
testing ops develop- ment architects PMO sales fi nance marketing HR 16
Project(process( Idea Change Request Business Additional Project <thing> raised Approve d >10 Business User Business % Case Acceptance Requirement CAPE Testing Document X Project IT Brief Solutions Requirement <10 s reqs. % matrix clarification CAPE and X estimation Functional spec High level Estimation and decision PM 1010100010100101011010 to proceed Detailed docs Dev Deploymen Estimate Initiation Doc dev Kick off t Coding (Dev) TDD KEY Testing Test QA Script s Normal Flow Data Flow Support handover Dropped requirements Support become Alternate Enhancements Process 17 Flow
18
19
20
testing ops develop- ment architects PMO sales fi nance marketing HR 21
each of these chords represents a delay 22
“There is nothing so useless as doing e ffi ciently that which should not be done at all” Peter Drucker 23
INTRODUCING BUSINESS CAPABILITIES (nothing new to see here, move along now folks) 24
A capability is a combination of people, processes, systems that provides value to customers (internal or external) 25
26
Retail Customers 27
Customers Retail 28
Customers Retail 29
Customers Retail 30
Customers Retail 31
THE TROUBLE WITH PROJECTS 32
THE CAPABILITIES WERE BUILT BY LARGE TEAMS Customers Retail 33
USING PROJECT-THINKING, NOT SERVICE THINKING* Customers Retail * http://lmgtfy.com/?q=GDS+service+thinking 34
AND THE DECOUPLED CAPABILITIES END UP AS A TANGLED MESS OF “MICROSERVICES” 35
Feature Feature starts deployed dev regression testing iteration iteration iteration performance testing 1 2 3 deployment tests cycle time ANYONE SEEN 6 WEEK PERIODS OF “HARDENING”?
Service A Build Unit Tests Service Tests Service Tests Service B Unit Tests Build End-to-end Tests Service C Build Unit Tests Service Tests Service D Build Unit Tests Service Tests ANYONE SEEN “FAN-IN” TO END TO END TESTS? 37
write write test release spec code ? Without deploying into production, inventory is built up - inventory costs money and the more we have the more risky our deployments ANYONE HAD TO DEPLOY EVERYTHING ALL AT ONCE?
beware the distributed monolith! 40
this is not “as fast as possible” this is a recipe for a nervous breakdown 41
WHAT MIGHT GOOD LOOK LIKE? 42
43
Pauline Ca ff erkey, early 2015
Team at the Royal Free 45
Royal Free Hospital Capabilities lab domestic services services <other> <other> facilities physio infectious diseases estates fi nance pharmacy micro biology 46
lab domestic services services facilities infectious physio diseases fi nance pharmacy micro estates biology 47
“The approach favors agility over raw power <snip>” http://en.wikipedia.org/wiki/OODA_loop 48
Recommend
More recommend
