“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.”

“97 things every software architect should know“ is a collection of (very) short essays by some of the most effective software architects of our times, and contains practical as well as philosophical guidance for aspiring and practising software architects. Each essay is extremely focussed on a specific them. Most of them talk about concrete scenarios and how to deal with them. They are also independent and can be read one-by-one – there is no progression from one essay to the next.

As someone who has been this role for some time now, it really resonated with me that a lot of the advice is not technical but rather focussed around team work and enablement. These are the parts that are most difficult to internalize for architects because we are trained to think like developers and measure ourselves in terms of “code shipped”. The role of an architect is more than, as the many voices on this book repeatedly tell us.

The moment I started reading “97 things every software architect should know”, I realized that a lot of highlighting was going to happen :). I have included here what I feel are the highlights from the book and cover most of the messages conveyed in it. They are put here is the order of appearance in the book, and like the book, they do not follow a thematic progression. Pulling out highlights like this deprives them of some of the context they are written under, but I feel that these are essential nuggets and stand on their own. This is good place to start if you want a flavour of what you will find inside the book.

I strongly recommend this book for anyone interested in playing the role of a software architect.

Support “It Depends” on Patreon

1. Architects are expected to know the technologies and software platforms on which their organizations run as well as the businesses that they serve.
2. Always put the customer’s long-term needs ahead of your own short-term needs and you won’t go wrong.
3. “Essential Complexity” represents the difficulty inherent in any problem.
4. “Accidental Complexity” grows from the things we feel we must build to mitigate essential complexity.
5. In large-scale software, though, removing accidental complexity while retaining the solution to the essential complexity is challenging.
6. Prefer frameworks derived from working code rather than ones cast down from ivory towers.
7. Projects are built by people, and those people are the foundation for success and failure.
8. Being clear and concise in the way you communicate your ideas is vital to the success of any software project.
9. Having the developer on your side creates a collaborative environment whereby decisions you make as an architect are validated. In turn, you get buy-in from developers by keeping them involved in the architecture process.
10. Experienced architects understand that they need to “sell” their ideas and need to communicate effectively in order to do that.
11. A better expression than ‘common sense’ is contextual sense — a knowledge of what is reasonable within a given context.
12. Sufficiently different nonfunctional properties of a subsystem create a boundary across which managing inconsistent representations is tractable.
13. To the extent that the business community fails to fulfil its responsibility to provide direction, answer questions, and make business decisions for the software development team, it is actually delegating the business decision making to software developers.The architect must provide the macro-context for this ongoing series of micro-decisions made by developers, by communicating and protecting the software architecture and business objectives, and must seek to ensure that developers do not make business decisions.
14. The long-term interests of the software development team are best served when business drives.
15. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development. They are based on assumptions that later turn out to be wrong, offer choices that later turn out not to be useful, and accumulate baggage that becomes difficult or impossible to remove.
16. A good architect should be able to spot a problem, call the team together, and without picking out a victim, explain what the problem is or might be and provide an elegant workaround or solution.
17. Build as a big bang event in project development is dead.
18. You’ll commonly see attempts to require overtime or sacrifice “less important scheduled tasks” (like unit testing) as a way to reduce delivery dates, or increase functionality while keeping the delivery dates as is.
19. Every software architect should know and understand that you can’t have it all.
20. Enough cannot be said about the importance of building a solid data model from Day One.
21. While business rules and user interfaces do evolve rapidly, the structures and relationships within the data you collect often do not.
22. Migrating data from one schema to another in situ is difficult at best, time consuming always, and error prone often.
23. The database is the final gatekeeper of your precious data. The application layer, which is by design ephemeral, cannot be its own watchdog.
24. The presence of two options is an indicator that you need to consider uncertainty in the design.
25. All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
26. Effective architecture is one that generally reduces the significance of design decisions.
27. Issues that seemed trivial early in the project become critical after it is too late to fix them.
28. Individuals often face resistance when the rest of the team does not share their experience or knowledge.
29. Defensiveness is easy. Learning to stop it is hard. Pride in our accomplishments is easy. Recognizing our limitations without conscious effort is hard.
30. Did you give everyone’s ideas the respect and acknowledgment they deserved?
31. If it looks good, it probably is good.
32. The architect should constantly be on the lookout for decisions that will have to be made soon.
33. Effective software architects understand not only technology but also the business domain of a problem space. Without business domain knowledge, it is difficult to understand the business problem, goals, and requirements, and therefore difficult to design an effective architecture to meet the requirements of the business.
34. Programming is an act of design, not an act of construction.
35. Over time, a good solution to the right challenge will probably outlast all others.
36. Was the solution an appropriate one for the problem? Did it solve the needs of the problem? Keep these as your measure — you will be a lot happier. Be happy with all that old stuff.
37. Expanding scope is the enemy of success because the probability of failure grows faster than expected.
38. Question any requirements not explained in terms of measurable value to the customer. If it has no effect on the company’s bottom line, why is it a requirement?
39. Important requirements usually remain important as the business changes, while others change or even evaporate.
40. Stewardship, taking responsibility and care of another’s property, is the appropriate role of an architect.
41. Value stewardship over showmanship; never forget that you are playing with other people’s money.
42. It’s not ethical to worsen the lives of others, even a small bit, just to make things easy for yourself.
43. We should plan to deploy one component at a time – it forces us to create well-defined interfaces between components.
44. When we deploy software, we are exposing ourselves to the accumulated technical risk embodied in the code. By deploying one component at a time, we spread technical risk out over a longer period of time.
45. It’s rare to find a technique that simultaneously provides higher commercial value and better architectural qualities, but early deployment of individual components offers both.
46. Performance of the people building the system is often called productivity, and it is important because it directly affects the cost and schedule of the project.
47. To be an effective software architect you must understand the basic architecture and design patterns, recognize when those patterns are being used, know when to apply the patterns, and be able to communicate to other architects and developers using them.
48. Enterprise architecture patterns define the framework for the high-level architecture. Some of the more common architecture patterns include event-driven architecture (EDA), service-oriented architecture (SOA), resource-oriented architecture (ROA), and pipeline architecture.
49. Application architecture patterns specify how applications or subsystems within the scope of a larger enterprise architecture should be designed.
50. Integration patterns are important for designing and communicating concepts surrounding the sharing of information and functionality between components, applications, and subsystems.
51. Anti-patterns, a term coined by Andrew Koenig, are repeatable processes that produce ineffective results.
52. Context is king, and simplicity its humble servant.
53. While newsgroups rage with the flames of technology debates of X versus Y, it is idle amusement. The reason these debates rage is often not because of huge disparities in their technical merits, but rather because there are more subtle differences between them, and what features individuals value more tha n others when there is no guiding context to act as a trump card.
54. In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight.
55. Duplication is evil. Repetitive work slows down development.
56. It’s not the domain logic that is copied; it’s the infrastructure code that just has to be there to make it work.
57. It’s crucial that you can envision the effects your examples have.
58. As an architect, you need to be highly sensitive to any kind of repetitive patterns, since anything you write will (ironically) be repeated.
59. Repetition in code is something that developers eventually learn to filter out and ignore when reading the code, once they figure out where the interesting variabilities are found, but even if the developers get used to it, it slows them down.
60. Repetition won’t go away unless someone does something about it. That someone is you.
61. Be ready to respond to events at any time in any order, regaining your context as needed. Make asynchronous requests concurrently instead of calling methods one by one. Avoid complete chaos by modelling your application using event-driven process chains or state models. Reconcile errors through compensation, retry, or tentative operations.
62. Building loosely coupled systems is a bit of a drag, so why do we bother? Because we want our systems to be flexible so they do not break apart at the slightest change.
63. Building a system that is flexible generally means the architecture is more complex and it’s more difficult to get the proverbial “big picture.”
64. An architect strives to merge realities with vision; past success with future direction; business and management expectations with development constraints. Creating these bridges is a major part of being an architect.
65. Like Janus, a software architect needs to be a keeper of doors and passageways, spanning the old and the new, incorporating creativity with sound engineering to fulfil today’s requirements while planning to meet tomorrow’s expectations.
66. From an architect’s point of view, the hard part is to find the natural places to locate boundaries and define the appropriate interfaces needed to build a working system. This is especially difficult in large enterprise systems, often characterized by few natural boundaries and intertangled domains.
67. A bounded context is an area where a model or concept is uniquely defined.
68. The role of an architect is usually to impose constraints, but you also have the opportunity to be an enabler.
69. Make sure developers have the tools they need.
70. The work life of a developer should be hands-on and practical, but also should be actively academic.
71. Let developers make their own decisions wherever it won’t contradict the overall goal of the software design. But put constraints where they count, not only to guarantee quality, but also to further empower developers. Create standards for the sake of consistency, but also to reduce the number of troublesome, insignificant decisions that aren’t part of the essential problem developers are solving.
72. One type of documentation that ages well, doesn’t require much effort, and almost always pays off is a record of the rationale behind decisions that are made regarding the software architecture.
73. The documentation should answer the basic questions “What was that decision we made?”, and “Why did we make that decision?”. A secondary question that is often asked and should be documented is “What other solutions were considered, and why were they rejected?”
74. Best practices in software architecture state that you should document the rationale behind each decision that is made, especially when that decision involves a tradeoff.
75. At an individual level, we are all trying to grow and come to understand how to build larger and larger systems. The course of our careers will take us toward ever-increasing challenges, for which we want our past experiences to help guide us.
76. Testing your knowledge against the real world is scary, particularly when you find out that something dear is myth, incorrect, or was never true; it’s hard to be wrong.
77. Given the state of so much of our software, it is clearly important for us to take every opportunity to share the things we know, what we think we know, and what we’ve seen.
78. Stamping patterns all over a project unnecessarily is over-engineering.
79. The support and maintenance of an application should never, ever be an afterthought.
80. Sometime accepting a constraint or giving up on a property can lead to a better architecture, one that is easier and less expensive to build and run.
81. When creating your architecture, you should explicitly use principles, axioms, and analogies to guide the creation. This gives the architecture a number of benefits that are not present if you simply create by implicitly leveraging your experience, opinions, and tastes.
82. An architecture with clear principles is an architecture that frees its architect from reviewing everything and being everywhere. It gives architects greater leverage.
83. Start with a walking skeleton, keep it running, and grow it incrementally.
84. Seeing the system entirely by the structure of its underlying information — can reduce even the most complicated system down to a tangible collection of details.
85. Data sits at the core of most problems.
86. What we don’t want to do is apply a complicated solution to an easy problem.
87. Keep the simple stuff simple.
88. Your code is your currency.
89. As an architect, your primary goal should be to create a solution that is feasible, maintainable, and of course addresses the issue at hand.
90. If you design it, you should be able to code it.
91. Not everything need directly translate in monetary gains, but our investments should result in added value.
92. The ROI of each option can be determined by examining its costs and projected profits, and can be used as a base for selection from available options.
93. Consider architectural decisions as investments and take into account the associated rate of return.
94. Even if your system is bleeding edge and developed in the latest technology, it will be legacy to the next guy. Deal with it!
95. Good design will document itself in many ways.
96. Legacy tends to be a bad word in software circles, but in reality, all software systems should endure the tag. It is not a bad thing.
97. If you can only think of one solution to a problem, you’re in trouble.
98. If you find yourself in the situation where you automatically know the solution, without having done any comparison to other approaches, stop, take a step back, and ask yourself if you can think of another way to do it.
99. A good architect reduces complexity to a minimum and can design a solution whose abstractions provide solid foundations to build upon, but are pragmatic enough to weather change.
100. The great architect understands the impact of change — not just in isolated software modules, but also between people and between systems.
101. The architect’s role is not necessarily to manage change, but rather to ensure that change is manageable.
102. Shortcuts taken during the initial development phase of a project can result in significant maintenance costs later.
103. Poorly designed features can become the foundation for future features, making corrective action later even more costly.
104. Don’t give in to the temptation to make your design, or your implementation, perfect! Aim for “good enough” and stop when you’ve achieved it.
105. Show the business domain experts the respect you expect to receive; this is the last group of people you want viewing you as unapproachable.
106. Don’t allow yourself to become a disgruntled genius who spends all of his time trying to impress others by making witty, condescendin g statements about how poorly the company is run. They won’t be impressed. They’ve met that guy before and they don’t really like him.
107. Find a way to establish a good relationship with the business and don’t let your ego damage it.
108. Before anything, an architect is a developer.
109. If you don’t know what a thing should be called, you cannot know what it is. If you don’t know what it is, you cannot sit down and write the code.
110. An architect should be able to look at a whole mess of concepts and data and process and separate them into smaller pieces or “chunks.” The important thing about those problem chunks is that they are stable, allowing them to be solved by a system chunk that is finite and stable in scope.
111. If the problem is stable, then when it is solved, it is solved permanently.
112. Diligence also requires an architect to succeed at the deceptively simple task of making and keeping commitments.
113. Better is possible. It does not take genius. It takes diligence. It takes moral clarity. It takes ingenuity. And above all, it takes a willingness to try.
114. Don’t be clever. Be as dumb as you possibly can and still create the appropriate design.
115. There’s usually no huge advantage to being the first to adopt new technology, but there can be several drawbacks.
116. Your customer is not your customer. Your customer’s customer is your customer.
117. During requirement gathering, allow your customer to express only the Platonic ideal, his concept and goals, rather than dictating a solution or even using technical terms.
118. No matter how in-depth, how well researched, and how well thought-out your design, it will never come out looking the same as in your head.
119. By accepting that design is an ongoing and empirical process in a forever-changing world, we learn that the design process must be flexible and ongoing.
120. If you can control how people perceive the architectural approach you propose, it’s virtually guaranteed that you can control how they will react to your proposal.
121. Make a strong business case for your architecture. People who have the budget authority to sponsor your ideas are almost always business-driven.
     • Establish the value proposition.
     • Build metrics to quantify.
     • Link back to traditional business measures.
     • Know where to stop.F
     • ind the right timing.
122. Make data and schema management a seamless part of your automated build and testing process early on and include an undo button.
123. Sometimes the best solution is no solution. Many software problems need not be solved at all. They only appear as problems because we look only at the symptoms.
124. Make sure it’s tough to crack the starting lineup, and once you’ve got a winning team, go the extra mile to keep it together.
125. It is simply not possible to future-proof an architecture.
126. Your goal as an architect is to be aware of and measure the threat of acceptance problems and work toward mitigating those threats.
127. Many missed requirements and bugs in software can be traced to ambiguous, general language.
128. The architect should also look at doing user interaction testing while the product is still in beta with actual end users, and incorporate their feedback into the final product.
129. It is the architect’s responsibility to make the most common interactions not only easy but also rewarding for the end user.
130. Resist trying to design a large complete system to “meet or exceed” the known requirements and desired properties, no matter how tempting that might be. Have a grand vision, but not a grand design.
131. Design the smallest system you can, help deliver it, and let it evolve toward the grand vision.

Next – More book reviews.