The agile and software craftsmanship movements are helping to push up the quality of the software systems that we build, which is excellent. Together they are helping us to write better software that better meets the needs of the business while carefully managing time and budgetary constraints. But there's still more we can do because even a small amount of software architecture can help prevent many of the problems that projects face. Successful software projects aren't just about good code and sometimes you need to step away from the IDE for a few moments to see the bigger picture.

This book is about that bigger picture and its role in delivering better software. It's a collection of essays that together form a practical and pragmatic guide to software architecture, with the overall goal being to demystify what it means to be a software architect and provide guidance on how to do software architecture effectively.

The book is aimed at software developers that want to learn more about software architecture as well as those that are new to the role. It fills the gap between software development and high-level architecture that probably seems a little "enterprisey" for most developers.

You'll find this book useful if any of the following scenarios sound familiar!

• I'm not sure what software architecture is about and how it's any different from design.
• I don't understand why we need "software architecture".
• My manager has told me that I'm the software architect on our new project, but I'm not sure what that actually means.
• I want to get involved in designing software but I'm not sure what I should learn.
• I've been given some requirements and asked to design some software, but I'm not sure where to start.
• I need to make some major enhancements to my system, but I'm not sure where to start.
• I've been asked to write a software architecture document but I'm not sure what to include in it.
• I'm not sure who to talk to in my organisation about how best to integrate what we're building.
• I understand what software architecture is all about, but I'm not sure how to tackle it on my project.
• My project seems like a chaotic mess; everybody is doing their own thing and there's no shared vision. Help!

Don't forget, this is a work in progress but if you buy now all future updates are free.

1. Preface
2. About the author
3. Speaking
4. Writing
5. Want to get in touch?
6. Training
7. Part 0: The prelude
8. The frustrated architect
9. Software architecture has a bad reputation
10. Agile aspirations
11. So you think you’re an architect?
12. From frustration and beyond
13. Part 1: What is software architecture?
14. What is architecture?
15. As a noun
16. As a verb
17. Types of architecture
18. What do they all have in common?
19. What is software architecture?
20. Application architecture
21. System architecture
22. Software architecture
23. Architecture vs design
24. Making a distinction
25. Understanding significance
26. What is the big picture?
27. Strategy rather than code
28. Application architecture
29. System architecture
30. Software architecture
31. Enterprise architecture
32. Is enterprise architecture the next step for my career?
33. Is software architecture important?
34. A lack of software architecture causes problems
35. The benefits of software architecture
36. Does every software project need software architecture?
37. Questions
38. Part 2: The software architecture role
39. The software architecture role
40. 1. Architectural drivers
41. 2. Technology selection
42. 3. Architecting
43. 4. Architecture evaluation
44. 5. Coding
45. 6. Architecture evolution
46. 7. Quality assurance
47. 8. Coaching and mentoring
48. Collaborate or #fail
49. Technical leadership is a role, not a rank
50. Crossing the mythical line or bridging the gaping chasm?
51. Experience is a good gauge but you need to look deeper
52. The line is blurred
53. Crossing the line is our responsibility
54. Software development is not a relay sport
55. “Solution Architects”
56. Somebody needs to own the big picture
57. Software architecture introduces control?
58. Provide guidance, strive for consistency
59. How much control do you need?
60. Control varies with culture
61. A lever, not a button
62. Mind the gap
63. Developers focus on the low-level detail
64. Architects dictate from their ivory towers
65. Reducing the gap
66. A collaborative approach to software architecture
67. Where are the software architects of tomorrow?
68. We’re losing our technical mentors
69. Software teams need downtime
70. Everybody is an architect, except when they’re not
71. Everybody is an architect
72. Except when they’re not
73. Does agile need architecture?
74. Questions
75. Part 3: Designing software
76. You don’t need a UML tool
77. There are many types of UML tool
78. The simplest thing that could possibly work
79. There is no silver bullet
80. Start with the big picture
81. Wide angle view (the big picture)
82. Standard view (containers)
83. Telephoto view (major components/services and their interactions)
84. Macro view (classes and implementation details)
85. Analysis paralysis vs refactor distractor
86. Tell a consistent story
87. Questions
88. Part 4: Communicating software
89. Architectural constructs
90. C4: context, containers, components and classes
91. Summarising the static view of your software
92. The code doesn’t tell the whole story
93. The code doesn’t portray the intent of the design
94. Supplementary information
95. Software architecture is a platform for conversation
96. Software isn’t just about delivering features
97. Questions
98. Part 5: Software architecture in the development lifecycle
99. Collaborative design
100. Experience influences software design
101. Just enough up front design
102. It comes back to methodology
103. You need to do “just enough”
104. Architecture represents the significant decisions
105. How much is just enough?
106. Contextualising just enough up front design
107. Too little vs too much
108. How much is “just enough”?
109. Practice the architecture process
110. Quantifying risk
111. Probability vs impact
112. Prioritising risk
113. Risk-storming
114. 1. Draw some architecture diagrams
115. 2. Identify the risks individually
116. 3. Converge the risks on the diagrams
117. 4. Prioritise the risks
118. Mitigation strategies
119. When to use risk-storming
120. It’s easier to ask forgiveness than it is to get permission
121. How do you introduce software architecture?
122. Questions
123. Part 6: The retrospective
124. Appendix A
125. Financial Risk System
126. Background
127. Functional Requirements
128. Non-functional Requirements
129. Version history