97 Things Every Software Architect Should Know

97 Things Every Software Architect Should Know

by Richard Monson-Haefel
Released February 2009
Publisher(s): O'Reilly Media, Inc.
ISBN: 9780596555467

Read it now on the O’Reilly learning platform with a 10-day free trial.

O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Book description

In this truly unique technical book, today's leading software architects present valuable principles on key development issues that go way beyond technology. More than four dozen architects -- including Neal Ford, Michael Nygard, and Bill de hOra -- offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they've learned from years of experience. Among the 97 principles in this book, you'll find useful advice such as:

  • Don't Put Your Resume Ahead of the Requirements (Nitin Borwankar)
  • Chances Are, Your Biggest Problem Isn't Technical (Mark Ramm)
  • Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
  • Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
  • For the End User, the Interface Is the System (Vinayak Hegde)
  • It's Never Too Early to Think About Performance (Rebecca Parsons)

To be successful as a software architect, you need to master both business and technology. This book tells you what top software architects think is important and how they approach a project. If you want to enhance your career, 97 Things Every Software Architect Should Know is essential reading.

Publisher resources

View/Submit Errata

Table of contents

  1. 97 Things Every Software Architect Should Know
  2. Preface
    1. Permissions
    2. How to Contact Us
    3. Safari® Books Online
    4. Acknowledgments
  3. 1. Don't Put Your Resume Ahead of the Requirements
  4. 2. Simplify Essential Complexity; Diminish Accidental Complexity
  5. 3. Chances Are, Your Biggest Problem Isn't Technical
  6. 4. Communication Is King; Clarity and Leadership, Its Humble Servants
  7. 5. Application Architecture Determines Application Performance
  8. 6. Seek the Value in Requested Capabilities
  9. 7. Stand Up!
  10. 8. Everything Will Ultimately Fail
  11. 9. You're Negotiating More Often Than You Think
  12. 10. Quantify
  13. 11. One Line of Working Code Is Worth 500 of Specification
  14. 12. There Is No One-Size-Fits-All Solution
  15. 13. It's Never Too Early to Think About Performance
  16. 14. Architecting Is About Balancing
      1. Balance Stakeholders' Interests with Technical Requirements
  17. 15. Commit-and-Run Is a Crime
  18. 16. There Can Be More Than One
  19. 17. Business Drives
  20. 18. Simplicity Before Generality, Use Before Reuse
  21. 19. Architects Must Be Hands On
  22. 20. Continuously Integrate
  23. 21. Avoid Scheduling Failures
  24. 22. Architectural Tradeoffs
  25. 23. Database As a Fortress
  26. 24. Use Uncertainty As a Driver
  27. 25. Warning: Problems in Mirror May Be Larger Than They Appear
  28. 26. Reuse Is About People and Education, Not Just Architecture
      1. Know It's There
      2. Know How to Use It
      3. Are Convinced That It's Better Than Doing It Themselves
  29. 27. There Is No 'I' in Architecture
  30. 28. Get the 1,000-Foot View
  31. 29. Try Before Choosing
  32. 30. Understand the Business Domain
  33. 31. Programming Is an Act of Design
  34. 32. Give Developers Autonomy
  35. 33. Time Changes Everything
      1. Pick a Worthy Challenge
      2. Simple Rules
      3. Be Happy with That Old Stuff
  36. 34. "Software Architect" Has Only Lowercase a's; Deal with It
  37. 35. Scope Is the Enemy of Success
  38. 36. Value Stewardship Over Showmanship
  39. 37. Software Architecture Has Ethical Consequences
  40. 38. Skyscrapers Aren't Scalable
  41. 39. Heterogeneity Wins
  42. 40. It's All About Performance
  43. 41. Engineer in the White Spaces
  44. 42. Talk the Talk
  45. 43. Context Is King
  46. 44. Dwarves, Elves, Wizards, and Kings
  47. 45. Learn from Architects of Buildings
  48. 46. Fight Repetition
  49. 47. Welcome to the Real World
  50. 48. Don't Control, but Observe
  51. 49. Janus the Architect
  52. 50. Architects' Focus Is on the Boundaries and Interfaces
  53. 51. Empower Developers
  54. 52. Record Your Rationale
  55. 53. Challenge Assumptions—Especially Your Own
  56. 54. Share Your Knowledge and Experiences
  57. 55. Pattern Pathology
  58. 56. Don't Stretch the Architecture Metaphors
  59. 57. Focus on Application Support and Maintenance
  60. 58. Prepare to Pick Two
  61. 59. Prefer Principles, Axioms, and Analogies to Opinion and Taste
  62. 60. Start with a Walking Skeleton
  63. 61. It Is All About The Data
  64. 62. Make Sure the Simple Stuff Is Simple
  65. 63. Before Anything, an Architect Is a Developer
  66. 64. The ROI Variable
  67. 65. Your System Is Legacy; Design for It
  68. 66. If There Is Only One Solution, Get a Second Opinion
  69. 67. Understand the Impact of Change
  70. 68. You Have to Understand Hardware, Too
  71. 69. Shortcuts Now Are Paid Back with Interest Later
  72. 70. "Perfect" Is the Enemy of "Good Enough"
  73. 71. Avoid "Good Ideas"
  74. 72. Great Content Creates Great Systems
  75. 73. The Business Versus the Angry Architect
  76. 74. Stretch Key Dimensions to See What Breaks
  77. 75. If You Design It, You Should Be Able to Code It
  78. 76. A Rose by Any Other Name Will End Up As a Cabbage
  79. 77. Stable Problems Get High-Quality Solutions
  80. 78. It Takes Diligence
  81. 79. Take Responsibility for Your Decisions
  82. 80. Don't Be Clever
  83. 81. Choose Your Weapons Carefully, Relinquish Them Reluctantly
  84. 82. Your Customer Is Not Your Customer
  85. 83. It Will Never Look Like That
  86. 84. Choose Frameworks That Play Well with Others
  87. 85. Make a Strong Business Case
  88. 86. Control the Data, Not Just the Code
  89. 87. Pay Down Your Technical Debt
  90. 88. Don't Be a Problem Solver
  91. 89. Build Systems to Be Zuhanden
  92. 90. Find and Retain Passionate Problem Solvers
  93. 91. Software Doesn't Really Exist
  94. 92. Learn a New Language
  95. 93. You Can't Future-Proof Solutions
      1. Today's Solution Is Tomorrow's Problem
  96. 94. The User Acceptance Problem
  97. 95. The Importance of Consommé
  98. 96. For the End User, the Interface Is the System
  99. 97. Great Software Is Not Built, It Is Grown
  100. Index
  101. Colophon
  102. Copyright

Product information

  • Title: 97 Things Every Software Architect Should Know
  • Author(s): Richard Monson-Haefel
  • Release date: February 2009
  • Publisher(s): O'Reilly Media, Inc.
  • ISBN: 9780596555467