97 Things Every Software Architect Should Know

During my recent Borders’s-browsing, I came across Richard
Monson-Haefel’s book, 97
Things Every Software Architect Should Know
with the tag line, “Collective
Wisdom from the Experts”. The book is interesting and even though it falls
short in providing details, gives a good overview of architectural principles. Mind
you, this is not a book with case studies or principles of how to define an
effective interface with example but more of a 10K ft view of software
architectural “principles”. Recently I have seen few books which belong to this
genre of collective wisdom aka geek interviews such as “Secrets
of the Rock Star Programmers: Riding the IT Crest
” and “Coders
at work
”. I think 97 things is a good addition to this observe-and-report
tradition from people presumably working in the trenches of software

Following is the table of contents and I have highlighted
the chapters/metaphors I liked.

1. Don't Put Your Resume Ahead of
the Requirements

2. Simplify Essential
Complexity; Diminish Accidental Complexity

3. Chances Are, Your Biggest
Problem Isn't Technical

4. Communication Is King;
Clarity and Leadership, Its Humble Servants

5. Application Architecture
Determines Application Performance

6. Seek the Value in Requested

7. Stand Up!

8. Everything Will Ultimately

9. You're Negotiating More Often
Than You Think

10. Quantify

11. One Line of Working Code Is
Worth 500 of Specification

12. There Is No
One-Size-Fits-All Solution

13. It's Never Too Early to
Think About Performance

14. Architecting Is About

15. Commit-and-Run Is a Crime

16. There Can Be More Than One

17. Business Drives

18. Simplicity Before Generality,
Use Before Reuse

19. Architects Must Be Hands On

20. Continuously Integrate

21. Avoid Scheduling Failures

22. Architectural Tradeoffs

23. Database As a Fortress

24. Use Uncertainty As a Driver

25. Warning: Problems in Mirror
May Be Larger Than They Appear

26. Reuse Is About People and
Education, Not Just Architecture

27. There Is No 'I' in

28. Get the 1,000-Foot View

29. Try Before Choosing

30. Understand the Business Domain

31. Programming Is an Act of

32. Give Developers Autonomy

33. Time Changes Everything

34. "Software Architect"
Has Only Lowercase a's; Deal with It

35. Scope Is the Enemy of

36. Value Stewardship Over

37. Software Architecture Has
Ethical Consequences

38. Skyscrapers Aren't Scalable

39. Heterogeneity Wins

40. It's All About Performance

41. Engineer in the White Spaces

42. Talk the Talk

43. Context Is King

44. Dwarves, Elves, Wizards, and

45. Learn from Architects of

46. Fight Repetition

47. Welcome to the Real World

48. Don't Control, but Observe

49. Janus the Architect

50. Architects' Focus Is on the
Boundaries and Interfaces

51. Empower Developers

52. Record Your Rationale

53. Challenge
Assumptions—Especially Your Own

54. Share Your Knowledge and

55. Pattern Pathology

56. Don't Stretch the Architecture

57. Focus on Application
Support and Maintenance

58. Prepare to Pick Two

59. Prefer Principles, Axioms,
and Analogies to Opinion and Taste

60. Start with a Walking Skeleton

61. It Is All About The Data

62. Make Sure the Simple Stuff Is

63. Before Anything, an
Architect Is a Developer

64. The ROI Variable

65. Your System Is Legacy; Design
for It

66. If There Is Only One
Solution, Get a Second Opinion

67. Understand the Impact of

68. You Have to Understand
Hardware, Too

69. Shortcuts Now Are Paid Back
with Interest Later

70. "Perfect" Is the
Enemy of "Good Enough"

71. Avoid "Good Ideas"

72. Great Content Creates Great

73. The Business Versus the Angry

74. Stretch Key Dimensions to
See What Breaks

75. If You Design It, You
Should Be Able to Code It

76. A Rose by Any Other Name Will
End Up As a Cabbage

77. Stable Problems Get
High-Quality Solutions

78. It Takes Diligence

79. Take Responsibility for
Your Decisions

80. Don't Be Clever

81. Choose Your Weapons Carefully,
Relinquish Them Reluctantly

82. Your Customer Is Not Your

83. It Will Never Look Like That

84. Choose Frameworks That Play
Well with Others

85. Make a Strong Business Case

86. Control the Data, Not Just the

87. Pay Down Your Technical

88. Don't Be a Problem Solver

89. Build Systems to Be Zuhanden

90. Find and Retain Passionate
Problem Solvers

91. Software Doesn't Really Exist

92. Learn a New Language

93. You Can't Future-Proof

94. The User Acceptance Problem

95. The Importance of Consommé

96. For the End User, the
Interface Is the System

97. Great Software Is Not Built,
It Is Grown