Rethinking enterprise software - Codemotion 2014

3,363 views
3,380 views

Published on

As a Software Architect and consultant I designed software with some artefacts in mind. As an entrepreneur I found myself on the other side of the fence. I'd improve distribute holistic knowledge through EventStorming and Domain-Driven Design rather than partition the system with User Stories.

Published in: Software, Business, Technology
0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,363
On SlideShare
0
From Embeds
0
Number of Embeds
1,237
Actions
Shares
0
Downloads
66
Comments
0
Likes
16
Embeds 0
No embeds

No notes for slide

Rethinking enterprise software - Codemotion 2014

  1. 1. Rethinking Enterprise Software @ziobrandoCodemotion 2014 - Roma
  2. 2. About me @ziobrando ! I do something else instead @ziobrandoAbout me DDD enthusiast Post-it addicted Visual thinker Chaos summoner Developer Idea thief …never satisfied Entrepreneur avanscoperta
  3. 3. Some news about software estimation Even broken models can teach us something
  4. 4. The real problem with estimations:
  5. 5. They may be right, sometimes
  6. 6. 11 x 2 = …
  7. 7. Easy homework
  8. 8. What if we have Legacy?
  9. 9. “It’s only a couple of mines somewhere…”
  10. 10. Some recap from one year ago
  11. 11. Ignorance is the single greatest impediment to throughput. Dan North http://dannorth.net/2010/08/30/introducing-deliberate-discovery/
  12. 12. Learning is the constraint Dan North http://dannorth.net/2010/08/30/introducing-deliberate-discovery/
  13. 13. Software development is a learning process Working code is a side effect
  14. 14. Learning
  15. 15. Memories
  16. 16. Learning School Boring Study Lesson Experiment Mistakes Fun Marks Exams Stress Life
  17. 17. Learning didn’t happen there
  18. 18. Learning is crucial for our job, and yet we don’t know much about it Look inside!
  19. 19. Learning is non linear (doesn’t fit into spreadsheets, burndown and Gantt charts)
  20. 20. Stress Psychological reaction ! To an adverse situation ! Situation is perceived as inevitable
  21. 21. Brain can’t learn under stress
  22. 22. Relax
  23. 23. Looks like…
  24. 24. Conformity kills creativity
  25. 25. Pressure hurts problem solving
  26. 26. Can you estimate learning?
  27. 27. I haven’t finished, yet
  28. 28. Value Stream Mapping http://agile.dzone.com/books/continuous-delivery-free
  29. 29. A quicker notation...
  30. 30. We need a different model! (again)
  31. 31. Coding 20cl, learning 20cl, deciding 20cl, waiting...
  32. 32. Mutual waiting Apparently, a process and organisation issue...
  33. 33. Learning is not the only constraint
  34. 34. Deciding?
  35. 35. We suck at it
  36. 36. How many DDD practitioners are needed to name a class?
  37. 37. We should really find a name for our daughter... Isn’t a GUID sufficient? No, I mean a proper name... What about Foo now, and refactor later?
  38. 38. Should I marry her? Yes No
  39. 39. We really should be getting married soon... Can we talk about this another time, honey? I’m facing a zerg assault right now...
  40. 40. The strategy?
  41. 41. Deadline!
  42. 42. Wedding ceremony is a Ponzi schema designed to stop the man procrastinating
  43. 43. ...but can we stop afterthoughts?
  44. 44. Wow, Kate looked really hot today, maybe… maybe I should have used MongoDB in that project
  45. 45. Finally, everybody leaves
  46. 46. Can you provide me an estimate? You can use *points if you want…
  47. 47. Problem
  48. 48. Yes… there’s no one size fits all
  49. 49. Summary Repeatable (boring) —> Pseudo-linear Legacy —> Too guilty to accept the real numbers Learning —> Non Linear Deciding —> Deadlines & acceptable results Waiting —> Remove coupling
  50. 50. Enterprise software
  51. 51. Enterprise software, also known as enterprise software application (ESA), is purposed-designed computer software used to satisfy the needs of an organization rather than individual users.
  52. 52. Enterprise software, also known as enterprise software application (ESA), is purposed-designed computer software used to satisfy the needs of an organisation rather than individual users.
  53. 53. Which are the needs of an organisation?
  54. 54. Kanban View of the system: Decision Making is the bottleneck
  55. 55. A business process is a series of connected business-relevant decisions
  56. 56. So what should we do?
  57. 57. Should we write use cases?
  58. 58. Developers loved templates
  59. 59. But forgot good readings
  60. 60. User Stories As a [role] I want to [action] in order to [goal]
  61. 61. Really?
  62. 62. A placeholder for future conversation
  63. 63. What are we supposed to say?
  64. 64. meaningful conversation with the domain expert
  65. 65. “...Eric?”
  66. 66. ...even better!
  67. 67. Hack! Warning: DDD doesn’t work on the Death Star
  68. 68. Event Storming!
  69. 69. Video If a picture is worth a thousand words…
  70. 70. ©  Alberto  Brandolini  2009 #CDays14 – Milano 25, 26 e 27 Febbraio 2014 Video!
  71. 71. Yes, I mean that much space...
  72. 72. My best friend
  73. 73. And… no table.
  74. 74. It’s no fun to just watch others play
  75. 75. Ubiquitous Language Reloaded
  76. 76. Model Affinity
  77. 77. Domain Events work better
  78. 78. Events are precise
  79. 79. Event are meaningful
  80. 80. here the user decides Command User issues influences External information influences Read Model
  81. 81. Quali informazioni
  82. 82. Fine-Grained Delegation Management 30.com
  83. 83. Steal and tweak
  84. 84. Process fine tuning
  85. 85. Conversation happens here!
  86. 86. “Which are the events needed in order to make this event happen?” “Which are the information needed for a user in order to take this decision?” (more or less wisely)
  87. 87. “Do you have a story to describe edge cases?”
  88. 88. Some great ideas here... BDD Specification by example Concrete scenarios
  89. 89. We provided a dedicated place for learning to happen
  90. 90. Divergence can be managed or enforced
  91. 91. There is value in enforcing divergence
  92. 92. Conflict resolution
  93. 93. The only thing they agree on is fooling us!
  94. 94. They’re both right! Context A Context B
  95. 95. whew!
  96. 96. Tool Affinity
  97. 97. Simple notation
  98. 98. How long is this cycle?
  99. 99. What about ...minutes?
  100. 100. Event Storming Provides a model of the shared level of understanding of a complex business process …I’ve never said it’s the right one!
  101. 101. Validate with multiple sources
  102. 102. ...Waiting
  103. 103. Remove dependencies…
  104. 104. Scrum Way: —> Cross Functional Teams
  105. 105. but…
  106. 106. Stand-up meetings You’re doing them wrong
  107. 107. Loosely coupled architecture reduces organisation load
  108. 108. Bounded Context CQRS Event Sourcing Reactive Apps
  109. 109. … not necessarily a process problem
  110. 110. Coding against an ecosystem How do we measure effect on an ecosystem?
  111. 111. Definition of Done - It works on my machine - Green tests - Deployed in production - Up and running - Users are using it - We’ve solved the business goal
  112. 112. Wrap up: There is a better model for enterprise apps ! There are better ways to discover this model and learn together around it ! There are better implementations that perfectly fit this model
  113. 113. I am not paying for that!
  114. 114. Grazie! Alberto.brandolini@avanscoperta.it @ziobrando

×