97 Things Every Software Architect Should Know

In this post, I have tried to compress the wisdom of multiple software architects into one/two-liner chapter summaries.

Note: Some of the inputs may appear to be redundant/overlapping. That’s because a different architect has provided each input.

1. Don’t map a technology stack to a problem, only because the former would shine on your resume.
2. Only live with the complexity you cannot ignore. Simplify everything else.
3. Tech isn’t your biggest problem, it’s people.
4. (Clear) Communication is king.
5. Application architecture determines application performance, not ‘tuning’ the infra.
6. Not every business requirement adds value to the customer. Map requirements to value.
7. Stand up (literally) and talk. It gives you the confidence to sell your ideas.
8. Everything will ultimately fail. Have fallbacks.
9. “Do we need X?”. The right answer is “Yes, we do.” Period. Negotiations are not the same as engineering discussions. Negotiate to win.
10. Quantity. If not exactly, then range-based (min, avg, max).
11. Look at both macro (design) and micro (code).
12. There is no one-size-fits-all solution. Exercise contextual sense to avoid over/under-engineering.
13. Begin performance testing as early as possible.
14. Software Architecting is about balancing technical interests with the business interests of stakeholders.
15. Make the system easy/fast to work with. Developer bandwidth is crucial.
16. It’s fine to have overlaps across systems. One system is not equipped enough to handle all the messiness as the business evolves.
17. You are the bridge between the business and the technical communities of the organisation. The business objectives should be the light in which technology-oriented decisions are made.
18. Prefer Simplicity over Generality, Use before Reuse.
19. Your title is not an excuse to sit in an ivory tower, dictating the way forward. An architect must be Hands On, able to fulfil any positions within the team.
20. Continuously Integrate (CI). It makes the team more efficient.
21. Avoid altering project scope/schedule at the cost of software quality.
22. Tradeoffs. You can’t have it all.
23. While business rules and user interfaces do evolve rapidly, the data model does not. Define a solid data model right from the start.
24. The presence of two or more options indicates uncertainty in the system design. An effective architecture should reduce the significance of design decisions.
25. Problems in the mirror may be larger than they appear. Don’t overlook risks/bugs until it’s too late.
26. For an architectural element to be reused, it needs to be sold to developers. Developers especially the “young guns”, have a bias to build everything by themselves.
27. There is no (capital) I in Architecture. Keep your ego in check.
28. Software quality can be better assessed at a 1000-foot view, not at 30,000 (HLD) or at 0 (source code).
29. Spend enough time trying multiple approaches before choosing one.
30. Understand the business domain.
31. Progamming is an act of design, not construction.
32. If you’re doing a great job as an architect, you really shouldn’t have enough time to interfere with developers. Give developers autonomy to exercise their creativity.
33. Your best work now will become outdated in the future. Time changes everything and makes us look silly when we look at our code/design a year later. Pick a worthy challenge, keep the rules simple and be happy with the work you did the in past (as long as the solution was appropriate enough to solve the problem at hand).
34. Software Architecture and Development is still too young to be compared with classical professions like Law, Medicine etc. The amount of study, academia, and training that these fields undergo dwarf our own. We have much cause to be content for enjoying considerable compensation for being creative/exploratory.
35. Expanding the scope of the project increases the probability of failure by magnitudes. Reducing it to what is needed often results in a simpler architecture.
36. Value stewardship over showmanship.
37. Successful software affects millions of people positively/negatively. It has ethical consequences. You should be willing to bear large burdens to ease the lives of your users.
38. Deploy one component at a time.
39. Embrace and leverage technical diversity (programming languages, tools, paradigms etc). Heterogeneity wins.
40. The performance of a system has a broader scope than just its responsiveness. It includes aspects such as: the performance of the developers building the system aka productivity, time taken by users to complete a task flows on the interface, and performance of the non-interactive components (batch runs, disaster recovery etc).
41. There is a lot of engineering involved in the white spaces, between the rectangle boxes connected by arrows (consider routers, switches, network interface cards and other hardware). These are important considerations in architectural design as well.
42. Be aware of architectural design patterns to be able to effectively communicate with fellow architects and developers.
43. Context is King. It impacts the architectural decisions we make.
44. Ensure the architecture has roles for all characters in the team to perform, learn and grow.
45. No architecture can truly be noble which is not imperfect.
46. Avoid repetition/duplication.
47. The real world is not binary. It’s difficult to predict the user behaviour in white/black.
48. Build flexible systems, to tackle requests and events in any order.
49. Fulfill today’s requirements while planning for tomorrow’s expectations.
50. Focus on boundaries and interfaces in systems. What belongs together vs should be kept apart.
51. Empower developers in every way possible.
52. Record your rationale regarding the architectural decisions taken (the what’s and the why’s, with tradeoffs)
53. Challenge assumptions — especially your own.
54. Share your knowledge and experience with others. The debates make our blind spots visible and help us grow.
55. Avoid pattern pathology (stamping your favourite design pattern over a project, where it does not apply)
56. Don’t overstretch using architectural metaphors. The development team starts to think more in terms of metaphor than actual business problem.
57. 80% of the application lifecycle will be spent in maintenance/support. Don’t overlook it while designing systems.
58. Constraints are good for the architecture. It forces you to be creative/inventive.
59. An architecture designed with clear principles frees its architect from reviewing everything and being everywhere.
60. Start with a walking skeleton, keep it running, and grow it incrementally.
61. Functionality is what we see first. But, it’s data that is at the core of every system. Have a data-oriented perspective.
62. Don’t apply complicated solutions to simple problems. You would get enough opportunities to showcase your talent when difficult problems arise, and they will.
63. Before anything, an architect is a developer. If you design it, you should be able to code it.
64. Consider architecture decisions as investments and take into account ROI (Return on investment). It is a useful approach to find out how pragmatic every option on the table is.
65. If your system is tagged as a legacy system in the future, it means it was successful in meeting the business expectations of the day. Legacy is not a negative word in that sense. Design systems for legacy.
66. If there is only one solution, get a second opinion.
67. Change has many forms: functional, scale, cost, people etc. Understand the impact of change, and ensure it is manageable.
68. You have to understand hardware, too.
69. Shortcuts now are paid back with interest later.
70. ‘Perfect’ is the enemy of ‘Good enough’. In most cases, striving for the perfect solution leads to an over-engineered system, which is harder to maintain.
71. “Bad ideas” are rejected upfront. Keep watching for “good ideas” that can kill your project (in terms of scope, timeline, business need, complexity etc)
72. Designing an effective data/object/domain model is sometimes not enough. Great content creates great systems.
73. ‘Listen’ first.
74. Stretch key dimensions to observe the unseen design limits.
75. In design, don’t use patterns/frameworks that your team hasn’t worked with before. You will be creating risks in the implementation.
76. Names convey intentions. If you don’t know what something should be called, you cannot know what it is – you cannot write the code that reflects the intention.
77. If the problem is neat, the design and code can be neat.
78. It takes diligence (more than genius) to be an architect.
79. Take responsibility for your architectural decisions: write, communicate, enforce, periodically review them.
80. It takes a smart architect to be dumb. Clever software is expensive, hard to maintain and brittle. Don’t be clever.
81. Choose your tech stack carefully. Don’t jeopardise your project for a new technology in the market. Wait for the hype to die down, and then evaluate.
82. You need to care for what the customer really needs, not just what they say they need.
83. Software Design is an ongoing and empirical process in a forever-changing world. It has to be flexible and adapt. Clinging to your original design and trying to force it, is only going to cause misery.
84. Choose frameworks that play well with other frameworks.
85. People with budget authority are business-driven. You have to make a strong business case for your architecture, to be able to secure funding.
86. Make data/schema management a seamless part of your automated build and testing, not just code.
87. Pay down your technical debt, ASAP.
88. Avoid problems before solving them.
89. Build systems/products that are handy, and the user can adapt to naturally.
90. Find and retain passionate problem solvers.
91. Software does not exist. It is virtual and continues to change with requirements, unlike its physical counterparts. (e.g.: civil engineering pursuits of building a bridge)
92. People are most comfortable with those who are similar to them. Learn the language of business and testing. It helps avoid miscommunications.
93. Today’s solution is tomorrow’s problem. You cannot future-proof solutions.
94. People aren’t always happy about new systems and major upgrades (loss of influence, fear of unproven tech, cost issues or that they simply do not like change etc). Measure the threat of acceptance problems and mitigate them.
95. Reduce and reduce again, until you are left with only a list of simple/true statements that describe the essential nature of the system.
96. For the end user, the user interface is the system. An advanced architecture behind a poor interface is futile. Make user interface design an equally important part of your architecture. Nothing supersedes customer happiness.
97. Great software is not built, it is grown.