Successfully reported this slideshow.
Your SlideShare is downloading. ×

Good Fences Make Good Neighbours

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Thriving in Complexity
Thriving in Complexity
Loading in …3
×

Check these out next

1 of 44 Ad

Good Fences Make Good Neighbours

Download to read offline

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.

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.

Advertisement
Advertisement

More Related Content

Recently uploaded (20)

Advertisement

Good Fences Make Good Neighbours

  1. 1. Making IT your winning asset
  2. 2. Good Fences Make Good Neighbours
  3. 3. Photo: Steingard over Årdal, Jarle Lunde @trondhjort
  4. 4. “You have to remember that any boundary is a useful fiction.” -Buckminster Fuller @trondhjort
  5. 5. @trondhjort
  6. 6. @trondhjort
  7. 7. Source: “The Good, The Bad and The (Can Be) Ugly: The Three Parts of Cognitive Load”, mcdreeamiemusings.com @trondhjort
  8. 8. @trondhjort
  9. 9. @trondhjort
  10. 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. 11. A loosely coupled, well- encapsulated architecture is the biggest contributor to IT performance, even larger than test and deployment automation. @trondhjort
  12. 12. @trondhjort
  13. 13. @trondhjort Source: Randall Munroe, What Makes Sand Soft?
  14. 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. 15. @trondhjort
  16. 16. @trondhjort Parts Whole Deterministic No purpose No purpose Animated No purpose Purpose Social Purpose Purpose Ecological Purpose No purpose
  17. 17. @trondhjort
  18. 18. @trondhjort
  19. 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. 20. @trondhjort
  21. 21. @trondhjort
  22. 22. Photo: Folded Carbonates flysch in Basque Country, France. Thibault Cavailhes @trondhjort
  23. 23. @trondhjort Source: Clker-Free-Vector-Images from Pixabay
  24. 24. @trondhjort
  25. 25. Source: https://www.gamified.uk/gamification-framework/the-intrinsic-motivation-ramp/ @trondhjort
  26. 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. 27. Source: “How Buildings Learn: What Happens After They're Built”, Brand 1994 @trondhjort
  28. 28. @trondhjort
  29. 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. 30. @trondhjort -Udi Dahan, 2010 “A service is the technical authority for a specific business capability.” Photo: DDD Europe 2017 @trondhjort
  31. 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. 32. Source: https://github.com/ddd-crew @trondhjort
  33. 33. @trondhjort
  34. 34. Source: “Patterns, Principles and Practices of Domain-Driven Design”, Tune & Millett @trondhjort @trondhjort
  35. 35. Source: “Discovering Bounded Contexts with EventStorming,” Alberto Brandolini @trondhjort
  36. 36. Source: “Strategic Domain Driven Design with Context Mapping,” Alberto Brandolini @trondhjort
  37. 37. Source: Implementing Domain-Driven Design, Vaughn Vernon @trondhjort
  38. 38. Source: domainstorytelling.org @trondhjort
  39. 39. @trondhjort https://leanpub.com/visualcollaborationtools
  40. 40. @trondhjort
  41. 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. 42. Photo: Tori Hogan @trondhjort Analysis & Synthesis
  43. 43. Good Fences Make Good Neighbours
  44. 44. Making IT your winning asset trondhjort

×