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.

1. Architecture In the Small Richard Banks Principal Consultant, Readify Sydney & Virtual ALT.NET Groups http://richardsbraindump.blogspot.com richard.banks@readify.net http://twitter.com/rbanks54

2. What Does an Architect do?

3. 3 Fundamentals

4. Communicate the Vision

5. Explain how to “Get There”™

6. Lead the Way Technically

7. and Architecture Itself?

8. The Design & Structure

9. Underpins the Vision

10. Architecture is...

12. Simple, Right?

13. NSW Transit T-Card $370million 10 years 0 to show

14. Westpac Rebuild (1988) $156 million 3 years 0 to show

15. Not just big projects

16. Apps that can’t support 10 users

17. Apps that lose/corrupt data

18. Apps that are

19. So where does it go wrong?

20. Project Failure Reasons Architect Involvement Has Yellow Background

21. Unrealistic or unarticulated goals

22. Inaccurate estimates

23. Badly defined system requirements

24. Poor reporting of the project's status

25. Unmanaged risks

26. Poor communication among customers, developers, and users

27. Use of immature technology

28. Inability to handle the project's complexity and Over Complexificationisationing

29. Sloppydevelopment practices

30. Poor project management

31. Stakeholder politics

32. Commercial pressures

33. Another Issue...

34. Software Is Designed Top Down

41. Software is Built Bottom Up

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 => pi.GetGetMethod() != null && pi.GetSetMethod() != null)) {collection.AddAspect(propertyInfo.GetSetMethod(), newNotifyPropertyChangedAspect(propertyInfo.Name, propertyInfo.PropertyType, propertyInfo.DeclaringType) { AspectPriority = AspectPriority } ); } }}

45. Design == What Code == How

46. There’s a Disconnect Here

47. It’s the Architect’s Problem

48. Solution:

49. Design & Architect code at the Lowest Levels to Support High Level design goals

50. Architecture in the Small

51. Deals with (at least) 3 Failure Causes

52. Complexity Technical Risk Sloppy Practices

53. Where Architects Go Wrong

54. Stopping Short on Design

56. Believing Marketecture

57. Following Guidance without Thinking (P&P)

58. Inattention To Detail

59. N.I.H. Syndrome

60. Not (properly) Explaining Howthings should be done

61. Not Trying Out What They Expect Others To Do

62. a.k.a. One-Directional Architecture Only doing Top Down Design

63. Remember: The only way to “Get There” is via code

64. ArchitectsMUST write code

65. If you code it you can explain it

66. (Dis)Prove the Marketecture

67. Ensure Guidance Makes Sense

68. Provide Examples Others Can Follow

69. Deal With Technical Risk

70. Find Problems You Overlooked

71. Example: AOP

72. Choice of Methods IL Weaving Interceptors Roll your own

73. Choice of Tools EntLib IoC Container PostSharp ...more

74. Impact on compile times

75. Impact on discoverability

76. Impact on debugging

77. Impact on runtime performance

78. Impact on developers

79. If you’ve never tried it... How will you prove it works? How will you show others?

80. Another Thing to Consider

81. Teams mimic their architect

82. Write Clean, Maintainable Code

83. Example Time

87. Worst Method?

88. CC: 81 LOC: 282 Coupling: 32

89. Complexity FAIL!

90. Lesson: Keep Code Simple But don’t be simplistic

91. Lesson: Small Methods Only 20 Lines or Less

92. Lesson: Small Classes

93. Lesson: Loose Coupling

96. Lesson: Meaningful Names

97. Lesson: Use Domain Language

99. Lesson: Single Responsibility

100. Lesson: Discoverable API

103. Lesson: Single Level Of Abstraction

105. Lesson: Avoid the “Duh!” Experience: Captain Obvious comments indicate a poorly architected system

106. A Note on Unit Testing

107. Test Code == Production Code

110. Lesson: Name Tests Well

111. Lesson: Assert Something!

114. Lesson: Test Behaviour Not State

115. Lesson: Test Just One Behaviour

116. What About the *ilities

117. Usability: (Subjective)

118. Maintainability: Destroyed in the small Includes agility, flexibility, testability, etc

119. Scalability: Hampered by the small

120. Reliability: Brought down by the small

121. Extensibility: Stymied by the small

122. Securability: Foiled via the small

123. Performance: Stalled by the small

124. It all comes from what happens in the small

125. Recap

126. Architects Are Project Fail Points

127. Architects Need to Code

128. Prove The Design

129. Lead By Example

130. Follow Sound Practices

131. Simple but Not Simplistic Code

132. Communicate via Code (not just Diagrams)

133. And sweat the details!

134. Thank You! http://richardsbraindump.blogspot.com http://twitter.com/rbanks54 richard.banks@readify.net