Abstract: There are a lot of concepts in software development, that look perfect on the whiteboard, and then completely suck in practice. Due to years of things like implementing ESB where it’s not needed, programming with EJB, where it brings only tears and blood, our industry has build a distrust for Ph.D., ex-cathedra, design by committee and generally any theory not tested in reality. We have learned to make small steps, proof-of-concepts, spikes, proper research. Yet, even with small steps, TDD and the like, the architecture we design backfires months later in unpredictable ways. That happens quite often because architects disregard the organization’s structure and culture completely.

1. Conway’s
revenge
How ignoring
org setup
backfires in
architecture,
and vice versa

2. How do you
keep quality
in 1-man
project?
Test Driven Development?
Following best practices?
Not being stupid?

3. How do you
keep quality
in 1-man
project?
Self-discipline

4. How do you
keep quality
in a 1 team
project?
Simple: hire only smart people!

5. How do you
keep quality
in a 1 team
project?
So smart engineers will come to
the same conclusions, right?

6. How do you
keep quality
in a 1 team
project?
So smart engineers will come to
the same conclusions, right?

7. But when we agree on unifying,
it will be alright.How do you
keep quality
in a 1 team
project?

8. USB: UNIVERSAL Service Bus
How do you
keep quality
in a 1 team
project?

9. USB: UNIVERSAL Service Bus
How do you
keep quality
in a 1 team
project?

10. How do you
keep quality
in a 1 team
project?
How was this problem being
solved before?
Siloses, jars, maven/gradle
modules

11. How do you
keep quality
in a 1 team
project?
Problems:
truck factor = 1
final solution looks like this

12. How do you
keep quality
in a 1 team
project?
Current solutions
Pull requests + code review
Pair programming
Sharing good practices
Mentoring

13. Self-discipline
Team-discipline
Last resort: EnforcementHow do you
keep quality
in a 1 team
project?

14. How do you
keep quality
in a 50
people
project?

15. How do you
keep quality
in a 50
people
project?
Discipline?

16. How do you
keep quality
in a 50
people
project?
Discipline?
In a creative, passionate crowd?
Have you ever seen a rock
concert?

17. How do you
keep quality
in a 50
people
project?
Engineers be like:
Static code analysis?
Pipeline + Sonar?
Inquisition!
Purge the
heretics!

18. How do you
keep quality
in a 50
people
project?
Managers be like:
Laws, rules, committees,
permission control. Control!
Moar control! MOAR!!1!

19. How do you
keep quality
in a 50
people
project?
Productivity and creativity
requires freedom
Fine balance
between chaos
and order

20. How do you
keep quality
in a 50
people
project?
Solutions so far:
Shared responsibility
Education & Mentoring
Corporate...

21. How do you
keep quality
in a 50
people
project?
Solutions so far:
Shared responsibility
Education & Mentoring
Corporate… Hacker...

22. How do you
keep quality
in a 50
people
project?
What they had in common was
mainly love of excellence and
programming. They wanted to
make their programs that they
used be as good as they could.
[Richard Stallman explains about hackers who
program]

23. How do you
keep quality
in a 50
people
project?
Culture is hard to make right
Hackers hate corporations
Hackers like freedom

24. How to solve
people’s
problem with
technology?

25. How to solve
people’s
problem with
technology?

26. How to solve
people’s
problem with
technology?

27. How to solve
people’s
problem with
technology?
Requires:
DevOps as in “developers
operating their systems in
production”
Distributed monitoring
Distributed security
Good knowledge of distributed
systems, CAP theorem, etc.
Lots of infrastructure setup,
code, libs...

28. How to solve
people’s
problem with
technology?
But it’s mostly a technical
problem
Developers are good at solving
technical problems

29. How to solve
people’s
problem with
technology?

30. Let’s see where
we can fail

31. 1
Too many
products

32. Orchestration
You have a distributed system
(eCommerce) that has to go
from single product for single
country, into 5 slightly different
products for 20 slightly different
countries
(5x20 matrix)
How do you do it?

33. Orchestration

34. Orchestration
Options:
1. Country/product specific
modules per microservice

35. Orchestration
Country/product specific
modules per microservice

36. Modules
If you have country/product
specific modules per
microservice
If this service grows (lots of
country/product specific
features) it will become the new
monolith.
Difficult to maintain.

37. Modules
Except not really, because you
can have self-discipline/quality
as long as you only have one
team for that service
But what if requirements grow
so much, that you need to add
more teams to it? Then it’s a
mess again

38. Orchestration
Options:
1. Country/product specific
modules per microservice
2. Proxy-microservice in front,
with country/product specific
logic

39. Proxy-microservice, with country/product specific
logic

40. Proxy
If you have proxy-microservice
in front, with country/product
specific logic
It may not always be possible
(proxy transforms input/output
data), and you may need to
write a new instance of a
microservice, just to change a
few things inside
And hundreds of services are
hard to maintain

41. Orchestration
Options:
1. Country/product specific
modules per microservice
2. Proxy-microservice in front,
with country/product specific
logic
3. One orchestration service to
rule country/product flow,
services sharing many entry
points

42. One orchestration
service to rule
country/product flow,
services sharing many
entry points

43. Orchestration
If you have an orchestration
service, either:
There is a team responsible for
it, therefore creating a huge
bottleneck (everybody waits for
them)
Nobody is responsible for it,
therefore it’s a total mess,
impossible to maintain

44. Conclusion
If for each of your services you
choose between modules and
proxies, you will
- stay within reasonable
number of services
- not copy&paste to change 2
lines of a service inside
- not use modules, when the
service has a chance of
growing to >1 teams

45. Conclusion
Orchestration, however, is the
worst solution for this company
Because of lack of
ownership/self-discipline

46. Conclusion
Unless every team has one guy
from this project
(2D team system)
But that complicates a lot and is
risky (may not work in the long
run). Is it worth it?

47. 2
Cool
technologies,
boring people

48. People on
the market
Scala + Akka
So you want a cool technology
Small country
~100 Scala developers
~30 Akka developers
Can get ~10% from the market
Business success, needs to hire
~30 devs

49. People on
the market
Scala + Akka
Options:
- accept slowing down, recruit
juniors, train them
- become a 100% remote
working company (big culture
change)
- remove Akka, drop Scala

50. People on
the market
Scala + Akka
Accept slowing down, recruit
juniors, train them
Management doesn’t want to
slow down
Become a 100% remote working
company (big culture change)
Management doesn’t trust
developers enough
Remove Akka, drop Scala
Management doesn’t give a fuck

51. People on
the market
Scala + Akka
Lesson:
Ignore management,
organization, structure, and your
architecture will perish

52. 3
Cool people,
boring
technologies

53. People on
the market
Delphi
Year 2003. Business analyzes
local University. They still teach
Turbo Pascal
Enterprise architects +
management decide to build
new platform with Delphi
(Object Pascal) because it’s close
to what is at the University

54. People on
the market
Delphi
They chose Kylix (Linux version)
Good business
- Linux: free
- Students: almost free, educated
- Borland Kylix: cheap

55. People on
the market
Delphi
Students were learning Turbo
Pascal, because the University
had old teachers, that couldn’t
teach anything else.
In 2003 not a single developer
would like to work in Kylix
Students treated this job as a
start to go somewhere else

56. Enterprise
Service
Bus
An architect wanted to introduce
ESB in 2014, for internal
distributed system
3 months later, his team
rebelled

57. People on
the market
Delphi
Lessons:
Ignore fashion, needs of
developers, and you will end up
without developers

58. 4
How much
abuse can your
architecture
take?

59. Resistant
architecture
DDD + CQRS, for clean design
Company hires lots of new devs
Big ball of mud (all entities have
relation to each other, no
boundaries)

60. Resistant
architecture
Does your architecture fit the
people who are going to use it?
How do you communicate
constraints?
How do you verify you
architecture?

61. Resistant
architecture
Integration Tests for architecture
Veripacks
Separate modules
Separate DBs for bounded
contexts
Make it hard to break
architecture
Wiki, documentation

62. 5
Two styles of
management

63. Two style of
management
How do sell your microservice
architecture to management?

64. Two style of
management
“I’ve also noticed that different
countries and cultures place
different values on control.
Some (e.g. the UK) value control
and the restraint that it brings
whereas others (e.g.
Scandinavia)
value empowerment and
motivation.”
[Software Architecture for Developers; Simon Brown;
Leanpub 2014]

65. Two style of
management
For Scandinavia:
- emphasise productivity
- invest in tools to get people
up to speed
- get to production fast
- show how much devs like this
architecture

66. Two style of
management
For UK:
- create a service visualization
tool (who talks with whom)
- emphasise control, and
visibility
- create a reporting service
- get metrics working first
- use magic word: SOA
(English people love three letter acronyms)

67. 6
Why big
systems go
bad
Conway’s Rationale

68. 1
Managers realize the system will
be large, so they throw too
many people at the design

69. 2
many people = too many
communication paths = zero
productivity
so organizations limit
communication by creating
design subgroups

70. 3
large organization can
understand only tree structure
with single superior + 7
subordinates.
so design subgroups are
organized this way
this limits communication
channels to this structure, hence:
miscommunication

71. 4
relationship between the graph
structure of a design
organization and the graph
structure of the system it
designs is 1:1

72. 5
so the final design also has the
wrong structure, and is build on
miscommunication

73. Conclusion

74. Conclusion
Look at your architecture from
communication perspective
Will communication be
efficient?
Can your organization handle
this architecture?

75. Conclusion
Even big systems should be
designed only in a small group
What a small group cannot
handle, a big one will fuck up
even more

76. Conclusion
Design architecture AND
organization
World has no boundaries
Boundaries are in our minds
All systems are connected
All systems interact
And read Conway’s paper:
http://www.melconway.com/Home/Committees_Paper.html

77. Thanks!
Questions?
jakubn@gmail.com
@jnabrdalik
solidcraft.eu