This is the second 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. 😄


17. Business Drives

  • ROI (Return on Investment) should serve as a major piece of objective context:
    • In the give-and-take conversations with the business about the value of a feature versus the cost of delivering that feature
    • With the development team about technical design and implementation.
  • The long-term interests of the software development team are best served when business drives.

18. Simplicity Before Generality, Use Before Reuse

  • Favoring simplicity before generality acts as a tiebreaker between otherwise equally viable design alternatives.
  • Effective generality comes from understanding, and understanding leads to simplification.

19. Architects Must Be Hands On

  • A good architect should read by example.
  • He can usually impress the business and technologist, but unless he can demonstrate his ability to be hands on, it is difficult to gain the respect of the team, difficult for the team to learn and almost impossible for team members to deliver what they were originally employed to do.

20. Continuously Integrate

  • “Build early and often”, which was a risk-reduction technique to ensure there were no suprises at this point in development.
  • Continuous integration will provide a more stable and directed development effort.

21. Avoid Scheduling Failures

  • One of the most common sources of failure is altering the project schedule in mid-stream without a proper planning.
  • Problem starts:
    • When you are asked to do more in the same timeline.
    • When the schedule is shortened without reducing the workload.
  • Remind those requesting the changes of the following facts:
    • A rushed design schedule leads to poor design, bad documentation, and probable quality assurance or user acceptance problems.
    • A rushed coding or delivery schedule has a direct relationship to the number of bugs delivered to the users.
    • A rushed test schedule leads to poorly tested code and has a direct relationship to the number of testing issues encountered.
  • What to do?
    • Speak up early.
    • If shortened schedule is necessary, then try to move noncritical functionality to future release(s).

22. Architectural Tradeoffs

  • Two popular methods to determine the tradeoffs:
    • Architecture Tradeoff Analysis Method (ATAM)
    • Cost Benefit Analysis Method (CBAM)

23. Database As a Fortress

  • It is critical to have your data model defined from the start.
  • Migrating data from one schema to another in situ is:
    • Difficult at best
    • Time consuming always
    • Error prone often
  • While you can suffer bugs temporarily at the application layer, bugs in the database can be disasterous.
  • A solid data model is one that guarantees:
    • Security of today’s data
    • Extensible for tomorrow’s
  • The database is the final gatekeeper of your precious data.
  • The data model must be designed:
    • To reject data that does not belong
    • To prevent relationships that do not make sense.
  • Domain rules encoded in the data model are also physical and persistent:
    • A change to application logic does not wash them away.

24. Use Uncertainty As a Driver

  • The presence of two options is an indicator that you need to consider uncertainty in the design.
  • Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
  • Effective architecture is one that generally reduces the significance of design decisions.
  • When a design decision can reasonably go one of two ways, an architect needs to take a step back. Instead of trying to decide between options A and B, the question becomes “How do I design so that the choice is less significant?”
  • Respond by figuring out what separation or encapsulation would isolate that decision from the code that ultimately depends on it.
  • Defer the actual decision until a decision can be made more responsibly, based on actual knowledge, but not so late that is not possible to take advantage of that knowledge.

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

  • The forces at work include:
    • Issues that seemed trivial early in the project become critical after it is too late to fix them.
    • Individuals often face resistance when the rest of the team does not share their experience or knowledge. Overcoming this resistance requires unusual courage, confidence and persuasiveness.
    • Most developers are optimists. Without specific experience we tend toward optimism. Natural pessimists on development teams are often unpopular, even if they are constantly right.
    • Every team member has a different view of what is more or less important. Their concerns are often focused on their personal responsibilities, not the project goals.
    • We all have blindspots, shortcomings that are difficult for us to recognize or to accept.
  • Strategies:
    • Establish an organized approach to managing risks. One simple approach is to track risks the same way you track bugs. Anyone can identify a risk, and each risk is tracked until it is no longer a risk. Risk are prioritized and reviewed when their status changes or when there is new information.
    • Encourage any team you are on to recognize the value in dissenting opinions and look for a neutral way to discuss them.
    • “Bad smells” are worth recognizing. If the facts aren’t there yet, look for the simplest tests that would provide the facts.
    • Test your understanding against the team and the customer. Tools such as a prioritized list of user stories can help, but are no substitute for regular communication with the customer and an open mind.
    • Blind spots are, by definition, hard to recognize. People you trust to tell you the hard truth when you need it are a precious resource.

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

  • The most beautiful, elegant and reusable architecture, framework or system will only be reused by people who:
    • Know It’s There
    • Know How to Use It
    • Are Convinced That It’s Better Than Doing It Themselves

27. There Is No ‘I’ in Architecture

  • Our egos can be our own worst enemy. Who hasn’t experienced architects who:
    • think they understand the requirements better than the customer.
    • view developers as resource hired to implement their ideas.
    • get defensive when their ideas are challenged or ignore the ideas of others.
  • Why this happen?
    • We have had succces. There is a fine line between self-confidence and arrogance.
    • People respect us.
    • We are human.
      • Defensiveness is easy.
      • Learning to stop is hard.
      • Pride in our accomplishments is easy.
      • Recognizing our limitations without conscious efford is hard.
  • How to avoid it?
    • Requirements don’t lie.
    • Focus on the team.
    • Check your work.
    • Watch yourself.
  • Removing “I” from architecture doesn’t guarantee success. It just removes a common source of failure that is entirely your fault.

28. Get the 1,000-Foot View

  • The 1,000 foot view would provide information at the right level.
  • We need tools that create these views from the only true source, the source code.
    • InfoViz
    • GraphViz

29. Try Before Choosing

  • They argue that we should delay commitment until the last responsible moment; that is the moment which, if the team does not make a decision. It is made for them - when inaction results in an - outcome that is not (easily) reversible.
  • The architect should constantly be on the lookout for decisions that will have to be made soon.
  • As the last responsible moment approaches, the team meets to assess the benefits and drawbacks of the different solutions.

30. Understand the Business Domain

  • It is the role of the software architect to
    • Understand
      • The business problem
      • The business requirements
    • Translate these requirements into a technical architecture solution capable of meeting them.
  • Understanding such as industry trends enables you as a software architect to plan for these trends in the architecture, even if the company you are working with hasn’t planned for them yet as part of its business model.
  • Understanding the specific goals of the business also helps you design an effective architecture.
  • The most succcessful architects are who have broad hands-on technical knowledge coupled with a strong knowledge of a particular domain.
  • These software architects are able to communicate with C-level executies and business users using the domain language that these folks know and understand.
  • Knowing the business domain allows a software architect to better understand:
    • Problem
    • Issues
    • Goals
    • Data
    • Processes

31. Programming Is an Act of Design

  • Kristen Nygaard, father of Object-Oriented Programming and the Simula programming language, used to say programming is learning.
  • The first process is the creative design process, including establishing the required assembly lines.
  • The second process is the manufacturing of cars in line with customer specifications.
  • Programming is an act of design, not an act of constuction.

32. Give Developers Autonomy

  • While developers are building, you should be making sure that all those pieces work well together.
  • You really should not have enough time to interfere with developers.