Modularity is a key aspect of software and architectural design, setting explicit boundaries between different parts of the system. But we have been banging on about this since the 70s, and still we are creating big balls of mud -- now even the distributed kind. Either modularity as a concept is insufficient or maybe there are aspects here we seem to get wrong. We know that good fences make good neighbours, but only when the boundaries are placed correctly. How can we create robust and sustainable modular designs when identifying those boundaries are so challenging? In this talk, we are going to take a closer look at why modularity is needed, what it actually can do for us, and how we can increase our chances of getting it right by taking a systems thinking approach. The claim made is that a holistic view of the problem space is critical; one that consider all its parts, including the business and all the people affected. Software development today is a inherently a sociotechnical endeavour and any modularisation effort, be it information hiding, SOA, microservices, DDD, Team Topologies and more, must take this into account in order to be able to create solutions that are sustainable and have the necessary conceptual integrity. In summary, this talk will help you piece together all of the these good modularisation practices and understand the theory behind them, improving your holistic system design skills, and enabling you to create requisite coherence in your designs. Maybe this will guard you against the dreaded distributed big ball of mud, the killer of agility and productive collaboration.

1. Making IT your winning asset

2. Good Fences Make Good Neighbours

3. Photo: Steingard over Årdal, Jarle Lunde
@trondhjort

4. “You have to remember that any
boundary is a useful fiction.”
-Buckminster Fuller
@trondhjort

5. @trondhjort

6. @trondhjort

7. Source: “The Good, The Bad and The (Can Be) Ugly: The Three Parts of Cognitive Load”, mcdreeamiemusings.com
@trondhjort

8. @trondhjort

9. @trondhjort

10. “Sadly, architecture has been
undervalued for so long that many
engineers regard life with a BIG
BALL OF MUD as normal.”
-Foote & Yoder
@trondhjort
@trondhjort

11. A loosely coupled, well-
encapsulated architecture is the
biggest contributor to IT
performance, even larger than
test and deployment automation.
@trondhjort

12. @trondhjort

13. @trondhjort Source: Randall Munroe, What Makes Sand Soft?

14. “Architectural design is system
design. System design is
contextual design — it is inherently
about boundaries (what’s in, what’s
out, what spans, what moves
between), and about tradeoffs. It
reshapes what is outside, just as it
shapes what is inside.”
-Ruth Malan
@trondhjort

15. @trondhjort

16. @trondhjort
Parts Whole
Deterministic No purpose No purpose
Animated No purpose Purpose
Social Purpose Purpose
Ecological Purpose No purpose

17. @trondhjort

18. @trondhjort

19. @trondhjort
“A system is more than the sum of
its parts; it is an indivisible whole.
It loses its essential properties
when it is taken apart.”
-Russell L. Ackoff

20. @trondhjort

21. @trondhjort

22. Photo: Folded Carbonates flysch in Basque Country, France. Thibault Cavailhes
@trondhjort

23. @trondhjort Source: Clker-Free-Vector-Images from Pixabay

24. @trondhjort

25. Source: https://www.gamified.uk/gamification-framework/the-intrinsic-motivation-ramp/
@trondhjort

26. On the Criteria To Be Used in
Decomposing Systems into Modules
“This paper discusses modularization
as a mechanism for improving the
flexibility and comprehensibility of a
system while allowing the shortening
of its development time. The
effectiveness of a ‘modularization’ is
dependent upon the criteria used in
dividing the system into modules.”
“We propose instead that one
begins with a list of difficult design
decisions or design decisions
which are likely to change. Each
module is then designed to hide
such a decision from the others.”
-David Parnas, 1972
@trondhjort

27. Source: “How Buildings Learn: What Happens After They're Built”, Brand 1994
@trondhjort

28. @trondhjort

29. @trondhjort Source: “A Business-Oriented Foundation for Service Orientation,” Ulrich Homann 2006
“A business capability is a
particular ability or capacity
that a business may possess
or exchange to achieve a
specific purpose or outcome.”
-Ulrich Homann

30. @trondhjort
-Udi Dahan, 2010
“A service is the technical
authority for a specific
business capability.”
Photo: DDD Europe 2017
@trondhjort

31. The Enterprise
Source: Business Capability Management, Ulrich Kalex 2011
@trondhjort
Corporate Management
Market
Dev.
Oversight
Delivery
Product
Dev.
Market Development
Contact Man.
Revenue
Analysis
Regional
Market
Man.
Order
and
Contract
Man.
Market
Analysis
Support
&
Services
Direct Marketing
Channel Man. Sales Man.

32. Source: https://github.com/ddd-crew
@trondhjort

33. @trondhjort

34. Source: “Patterns, Principles and Practices of Domain-Driven Design”, Tune & Millett
@trondhjort
@trondhjort

35. Source: “Discovering Bounded Contexts with EventStorming,” Alberto Brandolini
@trondhjort

36. Source: “Strategic Domain Driven Design with Context Mapping,” Alberto Brandolini
@trondhjort

37. Source: Implementing Domain-Driven Design, Vaughn Vernon
@trondhjort

38. Source: domainstorytelling.org
@trondhjort

39. @trondhjort https://leanpub.com/visualcollaborationtools

40. @trondhjort

41. “Thus God knows the world,
because He conceived it in His
mind, as if from the outside,
before it was created, and we
do not know its rule, because
we live inside it, having found
it already made.”
-William of Baskerville
“The Name of the Rose” miniseries 2019
@trondhjort

42. Photo: Tori Hogan
@trondhjort
Analysis & Synthesis

43. Good Fences Make Good Neighbours

44. Making IT your winning asset
trondhjort