This is the first part of 97 Things Ever Software Architect Should Know cheatsheet.

Instead of summarizing all the items in the one monolitic page, I decided to divide it into six blog pages to ease the read. The cheatsheet can make no sense if you didn’t read the book before, it is an easygoing book, please read it. 😄


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

  • Make happy customers.
  • Following the latest techs should not cost customers.
  • Loyalty first.
  • If you are not happy with the techs, find another one.
    • This leads to less stressfull life.
  • Favor customer’s long-term needs to your short term needs.

2. Simplify Essential Complexity; Diminish Accidental Complexity

  • Essential complexity is the difficulty level of the problem.
  • Accidental complexity grows from the things we feel we must build to mitigate essential complexity.
  • Check the percentage of the code directly address the business problem.
  • Architects duty is to find solutions for the essential complexity without accidental complexity.

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

  • Approach as conversations, not as confrontations.
  • Approach these conversations only after you have got the right attitude.
  • Use these as opportunities to set mutually agreed-upon goals.
  • Explain the introverted people not to dive in the conversations without waiting 5 sec.
  • Start with a shared purpose.

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

  • The key to effective communication is clarity and leadership.
  • Clarity describes how you communicate.
  • Keep things as simple as possible at the start of the project.
  • Another effective means of communication is informal whiteboard meetings.
    • Carry a camera or smartphone.
  • Software architect is also a leader.
  • Gain the respect of your co-workers to work healthy and effective environment.
  • Do not keep the developers in the dark about big picture or why decisions were made.
  • Work with developer, not against them.

5. Application Architecture Determines Application Performance

  • The application is the primary determinant of the application performance.
  • The quality attributes cannot be improved with silver-bullet switch of software brands, or infrastructure tuning.
  • The improvements in those areas require the hard work of carefully considered reachitecting.

6. Seek the Value in Requested Capabilities

  • The asked and required (needed) can be different.
  • To understand what is needed:
    • Collaboration over contract.
    • Arrange workshops and meetings focusing customer needs.
    • Ask why question.

7. Stand Up!

  • Sell your idea and communicate effectively.
  • If you are talking to more than one person, stand up! That gives you:
    • Authority & Self-confidence
    • Less interruptions
    • Body language enabled
    • Eye contact with everyone
    • Change your tone of your voice, volume, pitch and speed. That enables:
      • Projecting your voice to larger rooms
      • Slowing down to make more important points

8. Everything Will Ultimately Fail

  • Hardware is fallible, so we add redundancy.
  • Software is fallible.
  • Accept that, no matter what, your system will have a variety of failure modes.
  • If you do not design your failure modes, then you will get whatever unpredictable - and usually dangerous - one happens to emerge.

9. You’re Negotiating More Often Than You Think

  • A: Do we really need this?
  • B: Yes, we do.

10. Quantify

  • Requirements should be given with the measures.
  • Reject “lots” and “soon” as answers.
  • Uncertain quantative criteria must be given as range:
    • The least
    • The nominal
    • The most

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

  • The ultimate goal of a software project is a production system.
  • Value the team members who work on implementing your vision.
    • Listen to them.
  • Your vision of both macro and micro levels will be enchanced by the time.

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

  • Contextual Sense

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

14. Architecting Is About Balancing

  • Balance Stakeholders’ Interests (Business Requirements) with Technical Requirements

15. Commit-and-Run Is a Crime

  • Invest time in making the system fast to work with.

16. There Can Be More Than One

  • Consider the possibility that decomposition of your system by nonfunctional parameters may reveal oppurtunities to allow diverse solutions to your customers advantage.