Summary of “97 things every software architect should know”


The essay “97 things every software architect should know”  discuss what it means to be a software architecture. It is a good source for ideas on how to improve your skills as an architect or what skills you need to develop to become one.

In this post I summarize the chapters I found interesting. Currently, only some chapters from the range 71-95 are summarized.

73. The Business Vs. The Angry Architect – By Chad LaVigne

  1. you need to listen what other people say to you and not concentrate only on what you have to say. you already know what you are going to say – so you might learn something new from listen to others. This is especially true for architects that are experienced and might think they know what is the next step for any situation.
  2. The business is your employer – you need to serve it. The business domain experts are your major partners – listen to what they have to say. if you disagree with them that is fine. learn to leave with disagreements. if there are too many and you can’t contain that – look for another business to work for and contribute your experience to its success.

75. Before anything, an architect is a developer – By Mike Brown

An architect of a project should also write code of the project. This will have several benefits:

  1. Help the architect to estimate how much time coding tasks will take his developer to complete.
  2. Its fun
  3. Keep him in sync with latest technologies updates
  4. His developers will appreciate him more as they will see his high quality code and that he take part of the developing effort.

77. Stable problems get high quality solutions – By Sam Gardiner

  1. An architect should be able to look at a problem and separate it to chunk of problems that are cohesive and decoupled.
  2. The splitting to chunks should be driven to create chunks that are stable i.e., chunks the do not change even if other chunks are changed.
  3. When a problem is stable it cause its design to be stable, when the design is stable – the implementation can be made stable with high quality.
  4. An architect should develop internal sense for separation that is similar to a good sense of direction that some people have.

78. It Takes Diligence – By Brian Hart

An architect is expected to have ingenuity in his work but less common characteristic is of being diligent.

Effective architects are using daily and weekly check lists to remind them do the things that are necessary but harder for them to do like tracking project status.

They use commitments as for example:

  • keeping project’s schedule and budget
  • complete tasks that are not fun for them
  • commitment to process/methodology
  • accepting overall responsibility of the project

Getting better in what you do requires diligence.

79. Take responsibility for your decisions – By Yi Zhou

Here is how you can become a responsible architect:

  1. each major decision need to be well documented, traceable and communicated to engineers and other stockholders so they can review and have the chance to object it.
  2. review your past architectual decision. Identify decision that remain valid and those that do not – figure out how you could avoid bad decisions. learn from your mistakes.
  3. enforce your decisions
  4. delegate decisions to other who are expert in a domain that you are not proficient. you are not know-it-all-genius.

80. Don’t Be a Problem Solver – By Eben Hewitt

An architect has the reflex to try and solved a given problem instead of asking themselves if this problem is a real problem? can it be avoided?

He should not accept requirements as solid. If removing some of them can have a more sustain design then he should offer that.

81. Choose your weapons carefully, relinquish them reluctantly – Chad LaVigne

  1. Selecting the technologies we use to attack problems with is a large part of the software architect‘s job.
  2. architect have a toolbox of technologies they are experienced with, They know the technologies limitations. They know how to solve problems when arise. They are able to estimate project effort accurately.
  3. technologies improved over time – you need to replace old technologies when new ones proved to be significantly better from the one you know.
  4. update technologies in your product if there is an obvious improvements to the business

88. Don’t Be Clever – By Eben Hewitt

  1. Good qualities an architect should have:
    1. General intelligence
    2. resourcefulness
    3. thoughtfulness
    4. a breadth and depth of knowledge
    5. affinity for precision
  2. Write simple solutions not clever ones. The disadvantages of clever solutions:
    1. They are not simple
    2. Hard to fix
    3. Hard to replace, they stick for ever

90. Find and retain passionate problem solvers

    1. Putting together a team of outstanding developers is one of the most important things you can do to ensure the success of a software project.

    2. Building a team
      1. asking someone to explain their approach to diagnosing a performance problem gives you great insight into their methods for problem solving.

      2. ask what they would change given the chance to start their most recent project anew.

      3. Good developers are passionate about their work. Asking them about past experience will bring out that passion and tell you what correct answers to technical trivia questions cannot.

    3. keep the team together

      1. Finding great developers is difficult. Letting people know they are valued is not. Don‘t miss simple chances to build morale and boost productivity.

      2. Keep criticism constructive and don‘t require that every solution look like it came from you.

      3. go the extra mile to keep it together

92. Pay down your technical debt – By Burk Hufnagel

  1. A fix of bug in a production system might be needed ASAP. This means that it will probably be “quick and dirty” fix.
  2. such fixes have hidden cost:
    1. system instability
    2. increase maintenance cost
    3. lack of proper design
    4. lack of documentation
    5. lack of tests
  3. Once the fix is in production, have the developers go back and fix it properly so that it can be included in the next scheduled release.


95. The Importance of Consommé – By Eben Hewitt

  1. A consommé is an extremely clarified broth, usually made with beef or veal, served as a delicate soup. It is made by repeated, simple, fine-grained straining.

  2. Software architecture requires a continual refinement of thought, a repeated straining of ideas until we have determined the essence of each requirement in the system.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s