Architecture In the Small<br />Richard Banks<br />Principal Consultant, Readify<br />Sydney & Virtual ALT.NET Groups<br />...
What Does an Architect do?<br />
3 Fundamentals<br />
Communicate the Vision<br />
Explain how to “Get There”™<br />
Lead the Way Technically<br />
and Architecture Itself?<br />
The Design & Structure<br />
Underpins the Vision<br />
Architecture is...<br />
Simple, Right?<br />
NSW Transit T-Card<br />$370million<br />10 years<br />0 to show<br />
Westpac Rebuild (1988)<br />$156 million<br />3 years<br />0 to show<br />
Not just big projects<br />
Apps that can’t support 10 users<br />
Apps that lose/corrupt data<br />
Apps that are <br />
So where does it go wrong?<br />
Project Failure Reasons<br />Architect Involvement Has Yellow Background<br />
Unrealistic or unarticulated goals<br />
Inaccurate estimates<br />
Badly defined system requirements<br />
Poor reporting of the project&apos;s status<br />
Unmanaged risks<br />
Poor communication among customers, developers, and users<br />
Use of immature technology<br />
Inability to handle <br />the project&apos;s complexity<br />and Over Complexificationisationing<br />
Sloppydevelopment practices<br />
Poor project management<br />
Stakeholder politics<br />
Commercial pressures<br />
Another Issue...<br />
Software Is Designed Top Down<br />
Software is Built Bottom Up<br />
[Serializable][AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class, AllowMultiple = false, Inherited = false...
Design == What<br />Code == How<br />
There’s a Disconnect Here<br />
It’s the Architect’s Problem<br />
Solution:<br />
Design & Architect code<br />at the Lowest Levels to<br />Support High Level design goals<br />
Architecture in the Small<br />
Deals with (at least) <br />3 Failure Causes<br />
Complexity<br />Technical Risk<br />Sloppy Practices<br />
Where Architects Go Wrong<br />
Stopping Short on Design<br />
Believing Marketecture<br />
Following Guidance without Thinking<br />(P&P)<br />
Inattention To Detail<br />
N.I.H. Syndrome<br />
Not (properly) Explaining Howthings should be done<br />
Not Trying Out What They Expect Others To Do<br />
a.k.a.<br />One-Directional Architecture<br />Only doing Top Down Design<br />
Remember:<br />The only way to “Get There” is via code<br />
ArchitectsMUST write code<br />
If you code it you can explain it<br />
(Dis)Prove the Marketecture<br />
Ensure Guidance Makes Sense<br />
Provide Examples Others Can Follow<br />
Deal With Technical Risk<br />
Find Problems You Overlooked<br />
Example: AOP<br />
Choice of Methods<br />IL Weaving<br />Interceptors<br />Roll your own<br />
Choice of Tools<br />EntLib<br />IoC Container<br />PostSharp<br />...more<br />
Impact on compile times<br />
Impact on discoverability<br />
Impact on debugging<br />
Impact on runtime performance<br />
Impact on developers<br />
If you’ve never tried it...<br />How will you prove it works?<br />How will you show others?<br />
Another Thing to Consider<br />
Teams mimic their architect<br />
Write Clean, Maintainable Code<br />
Example Time<br />
Worst Method?<br />
CC: 81<br />LOC: 282<br />Coupling: 32<br />
Complexity FAIL!<br />
Lesson: Keep Code Simple<br />But don’t be simplistic<br />
Lesson: Small Methods Only<br />20 Lines or Less<br />
Lesson: Small Classes<br />
Lesson: Loose Coupling<br />
Lesson: Meaningful Names<br />
Lesson: Use Domain Language<br />
Lesson: Single Responsibility<br />
Lesson: Discoverable API<br />
Lesson: Single Level Of Abstraction<br />
Lesson: Avoid the “Duh!”<br />Experience: Captain Obvious comments indicate a poorly architected system<br />
A Note on Unit Testing<br />
Test Code == Production Code<br />
Lesson: Name Tests Well<br />
Lesson: Assert Something!<br />
Lesson: Test Behaviour Not State<br />
Lesson: Test Just One Behaviour<br />
What About the *ilities<br />
Usability: (Subjective)<br />
Maintainability:<br />Destroyed in the small<br />Includes agility, flexibility, testability, etc<br />
Scalability:<br />Hampered by the small<br />
Reliability:<br />Brought down by the small<br />
Extensibility:<br />Stymied by the small<br />
Securability:<br />Foiled via the small<br />
Performance:<br />Stalled by the small<br />
It all comes from what happens in the small<br />
Recap<br />
Architects Are Project Fail Points<br />
Architects Need to Code<br />
Prove The Design<br />
Lead By Example<br />
Follow Sound Practices<br />
Simple but Not Simplistic Code<br />
Communicate via Code<br />(not just Diagrams)<br />
And sweat the details!<br />
Thank You!<br />http://richardsbraindump.blogspot.com<br />http://twitter.com/rbanks54<br />richard.banks@readify.net<br />
Upcoming SlideShare
Loading in …5
×

Architecture In The Small

1,755 views

Published on

No matter how good your design or how well the big pieces of your architecture fit together it's the little things that really count. The little things are the things that can take your vision of beauty and either make it a reality or turn it into a thing of nightmares. This deck talks about what these little things are, the impact they have and, most importantly, what to do about them.

Published in: Technology, Business
  • Be the first to comment

Architecture In The Small

  1. 1. Architecture In the Small<br />Richard Banks<br />Principal Consultant, Readify<br />Sydney & Virtual ALT.NET Groups<br />http://richardsbraindump.blogspot.com<br />richard.banks@readify.net<br />http://twitter.com/rbanks54<br />
  2. 2. What Does an Architect do?<br />
  3. 3. 3 Fundamentals<br />
  4. 4. Communicate the Vision<br />
  5. 5. Explain how to “Get There”™<br />
  6. 6. Lead the Way Technically<br />
  7. 7. and Architecture Itself?<br />
  8. 8. The Design & Structure<br />
  9. 9. Underpins the Vision<br />
  10. 10. Architecture is...<br />
  11. 11.
  12. 12. Simple, Right?<br />
  13. 13. NSW Transit T-Card<br />$370million<br />10 years<br />0 to show<br />
  14. 14. Westpac Rebuild (1988)<br />$156 million<br />3 years<br />0 to show<br />
  15. 15. Not just big projects<br />
  16. 16. Apps that can’t support 10 users<br />
  17. 17. Apps that lose/corrupt data<br />
  18. 18. Apps that are <br />
  19. 19. So where does it go wrong?<br />
  20. 20. Project Failure Reasons<br />Architect Involvement Has Yellow Background<br />
  21. 21. Unrealistic or unarticulated goals<br />
  22. 22. Inaccurate estimates<br />
  23. 23. Badly defined system requirements<br />
  24. 24. Poor reporting of the project&apos;s status<br />
  25. 25. Unmanaged risks<br />
  26. 26. Poor communication among customers, developers, and users<br />
  27. 27. Use of immature technology<br />
  28. 28. Inability to handle <br />the project&apos;s complexity<br />and Over Complexificationisationing<br />
  29. 29. Sloppydevelopment practices<br />
  30. 30. Poor project management<br />
  31. 31. Stakeholder politics<br />
  32. 32. Commercial pressures<br />
  33. 33. Another Issue...<br />
  34. 34. Software Is Designed Top Down<br />
  35. 35.
  36. 36.
  37. 37.
  38. 38.
  39. 39.
  40. 40.
  41. 41. Software is Built Bottom Up<br />
  42. 42.
  43. 43.
  44. 44. [Serializable][AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class, AllowMultiple = false, Inherited = false)][MulticastAttributeUsage(MulticastTargets.Class, AllowMultiple = false)]publicclassNotifyPropertyChangedAttribute : CompoundAspect{publicintAspectPriority { get; set; }publicoverridevoidProvideAspects(object element, LaosReflectionAspectCollection collection){Typetype = (Type)element;collection.AddAspect(type, newPropertyChangedAspect { AspectPriority = AspectPriority });foreach (PropertyInfopropertyInfointype.GetProperties(BindingFlags.Public | BindingFlags.Instance) .Where(pi =&gt; pi.GetGetMethod() != null && pi.GetSetMethod() != null)) {collection.AddAspect(propertyInfo.GetSetMethod(),<br />newNotifyPropertyChangedAspect(propertyInfo.Name, <br />propertyInfo.PropertyType,<br />propertyInfo.DeclaringType) { AspectPriority = AspectPriority }<br />); } }}<br />
  45. 45. Design == What<br />Code == How<br />
  46. 46. There’s a Disconnect Here<br />
  47. 47. It’s the Architect’s Problem<br />
  48. 48. Solution:<br />
  49. 49. Design & Architect code<br />at the Lowest Levels to<br />Support High Level design goals<br />
  50. 50. Architecture in the Small<br />
  51. 51. Deals with (at least) <br />3 Failure Causes<br />
  52. 52. Complexity<br />Technical Risk<br />Sloppy Practices<br />
  53. 53. Where Architects Go Wrong<br />
  54. 54. Stopping Short on Design<br />
  55. 55.
  56. 56. Believing Marketecture<br />
  57. 57. Following Guidance without Thinking<br />(P&P)<br />
  58. 58. Inattention To Detail<br />
  59. 59. N.I.H. Syndrome<br />
  60. 60. Not (properly) Explaining Howthings should be done<br />
  61. 61. Not Trying Out What They Expect Others To Do<br />
  62. 62. a.k.a.<br />One-Directional Architecture<br />Only doing Top Down Design<br />
  63. 63. Remember:<br />The only way to “Get There” is via code<br />
  64. 64. ArchitectsMUST write code<br />
  65. 65. If you code it you can explain it<br />
  66. 66. (Dis)Prove the Marketecture<br />
  67. 67. Ensure Guidance Makes Sense<br />
  68. 68. Provide Examples Others Can Follow<br />
  69. 69. Deal With Technical Risk<br />
  70. 70. Find Problems You Overlooked<br />
  71. 71. Example: AOP<br />
  72. 72. Choice of Methods<br />IL Weaving<br />Interceptors<br />Roll your own<br />
  73. 73. Choice of Tools<br />EntLib<br />IoC Container<br />PostSharp<br />...more<br />
  74. 74. Impact on compile times<br />
  75. 75. Impact on discoverability<br />
  76. 76. Impact on debugging<br />
  77. 77. Impact on runtime performance<br />
  78. 78. Impact on developers<br />
  79. 79. If you’ve never tried it...<br />How will you prove it works?<br />How will you show others?<br />
  80. 80. Another Thing to Consider<br />
  81. 81. Teams mimic their architect<br />
  82. 82. Write Clean, Maintainable Code<br />
  83. 83. Example Time<br />
  84. 84.
  85. 85.
  86. 86.
  87. 87. Worst Method?<br />
  88. 88. CC: 81<br />LOC: 282<br />Coupling: 32<br />
  89. 89. Complexity FAIL!<br />
  90. 90. Lesson: Keep Code Simple<br />But don’t be simplistic<br />
  91. 91. Lesson: Small Methods Only<br />20 Lines or Less<br />
  92. 92. Lesson: Small Classes<br />
  93. 93. Lesson: Loose Coupling<br />
  94. 94.
  95. 95.
  96. 96. Lesson: Meaningful Names<br />
  97. 97. Lesson: Use Domain Language<br />
  98. 98.
  99. 99. Lesson: Single Responsibility<br />
  100. 100. Lesson: Discoverable API<br />
  101. 101.
  102. 102.
  103. 103. Lesson: Single Level Of Abstraction<br />
  104. 104.
  105. 105. Lesson: Avoid the “Duh!”<br />Experience: Captain Obvious comments indicate a poorly architected system<br />
  106. 106. A Note on Unit Testing<br />
  107. 107. Test Code == Production Code<br />
  108. 108.
  109. 109.
  110. 110. Lesson: Name Tests Well<br />
  111. 111. Lesson: Assert Something!<br />
  112. 112.
  113. 113.
  114. 114. Lesson: Test Behaviour Not State<br />
  115. 115. Lesson: Test Just One Behaviour<br />
  116. 116. What About the *ilities<br />
  117. 117. Usability: (Subjective)<br />
  118. 118. Maintainability:<br />Destroyed in the small<br />Includes agility, flexibility, testability, etc<br />
  119. 119. Scalability:<br />Hampered by the small<br />
  120. 120. Reliability:<br />Brought down by the small<br />
  121. 121. Extensibility:<br />Stymied by the small<br />
  122. 122. Securability:<br />Foiled via the small<br />
  123. 123. Performance:<br />Stalled by the small<br />
  124. 124. It all comes from what happens in the small<br />
  125. 125. Recap<br />
  126. 126. Architects Are Project Fail Points<br />
  127. 127. Architects Need to Code<br />
  128. 128. Prove The Design<br />
  129. 129. Lead By Example<br />
  130. 130. Follow Sound Practices<br />
  131. 131. Simple but Not Simplistic Code<br />
  132. 132. Communicate via Code<br />(not just Diagrams)<br />
  133. 133. And sweat the details!<br />
  134. 134. Thank You!<br />http://richardsbraindump.blogspot.com<br />http://twitter.com/rbanks54<br />richard.banks@readify.net<br />

×