97 Things Every Software Architect Should Know Quotes

“Defer the actual decision until a decision can be made more responsibly, based on actual knowledge, but not so late that it is not possible to take advantage of the knowledge.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“Consider thinking of architectural decisions as investments and take into account the associated rate of return, it is a useful approach for finding out how pragmatic or fit for purpose every option on the table is.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“Good ideas kill projects. Sometimes it's a quick death, but often it's a slow, lingering death caused by missed milestones and a spiraling bug count.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“In the end, all vendor products and application architectures are constrained by the same fundamental principles of distributed computing and underlying physics: applications, and the products they use, run as processes on computers of limited capacity, communicating with one another via protocol stacks and links of nonzero latency. Therefore people need to appreciate that application architecture is the primary determinant of application performance and scalability.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know: Collective Wisdom from the Experts

“Software architects have to take responsibility for their decisions as they have much more influential power in software projects than most people in organizations.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“In the real world, the best architects don‘t solve hard problems they work around them.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“over 80% of an application's life-cycle is spent in maintenance, you should pay a lot of attention to the problems of support and maintenance when you're designing”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“...changing code or behavior is not a big issue, it just needs to be released, but revising data structures can involve a huge effort in transforming the old version into a newer one”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“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 fulfill todays requirements while planning to meet tomorrow's expectations.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“Once you accept that failures will happen, you have the ability to design your system's reaction to specific failures. Just as auto engineers create crumple zones---areas designed to protect passengers by failing first---you can create safe failure modes that contain the damage and protect the rest of the system.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“Much like an investment broker, the architect is being allowed to play with their client's money, based on the premise that their activity will yield an acceptable return on investment.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“As a developer you rarely get the time to sit back and really look at how the whole system fits together. As an architect, this is your main focus. While developers are furiously building classes, methods, tests, user interfaces and databases, you should be making sure that all those pieces work well together.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“The truth is that even the most beautiful, elegant and re-usable architecture, framework or system will only be re-used by people who:
a) know it is there
b) know how to use it
c) are convinced that it is better than doing it themselves”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“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. (Grady Booch)”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“An architect is like an airline pilot, he might not look busy all of the time but he uses decades of experience to constantly monitor the situation, taking immediate action if he sees or hears something out of the ordinary.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“We cannot easily add lanes to roads, but we've learned how to easily add features to software. This isn't a defect of our software processes, but a virtue of the medium in which we work.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“One thing most software architects fail to realize is that a software architect is also a leader.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know: Collective Wisdom from the Experts

“Every decision we make for our projects, be it technology, process or people related, can be a viewed as a form of investment. Investments come associated with a cost, which may or may not be monetary, and carry trust that they will eventually pay off. Our employers choose to offer us salaries in the hope that this investment will positively affect the outcome of their venture. We decide to follow a specific development methodology in the hope that it will make the team more productive. We choose to spend a month redesigning the physical architecture of an application in the belief that it will be beneficial in the long run.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“Usually, now with the benefit of hindsight, the best solution to the problem is apparent to everybody. The architect does not have to make the decision, he or she merely orchestrates the decision making process.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“You don‘t drive the architecture, the requirements do. You do your best to serve their needs.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“I know, there really is an ‗i‘ in architecture. But it‘s not a capital ‗I‘, calling attention to itself, dominating discussion. The lower-case character fits neatly within the word. Its there only because it fulfills requirements for proper spelling and pronunciation.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“The young guns on your team will always want to write things themselves because it appeases their ego, whereas your more experienced people are more likely to accept that someone else has given thought to the problem domain and has something to offer in terms of a solution.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“The idea that schedules can be shortened in order to reduce cost or speed up delivery is a very common misconception. 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. Avoid this scenario at all costs. 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.
- All of the above lead to Production issues which are much more expensive to fix.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“As has been said elsewhere the architect is the interface between the business and the technology team, the architect must understand every aspect of the technology to be able to represent the team to the business without having to constantly refer others. Similarly the architect must understand the business in order to drive the team toward their goal of serving the business.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“A good architect should lead by example, he (or she) should be able to fulfill any of the positions within his team from wiring the network, and configuring the build process to writing the unit tests and running benchmarks. Without a good understanding of the full range of technology an architect is little more than a project manager. It is perfectly acceptable for team members to have more in-depth knowledge in their specific areas but it's difficult to imagine how team members can have confidence in their architect if the architect doesn't understand the technology.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“Generalization can allow us to reduce a problem to something more essential, resulting in an approach that embodies regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“Although well meant, many things that are designed just to be general purpose often end up satisfying no purpose. Software components should, first and foremost, be designed for use and to fulfill that use well. Effective generality comes from understanding, and understanding leads to simplification.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“The long-term interests of the software development team are best served when business drives.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“Software development is fundamentally a design activity, in that it involves an ongoing process of decision making until the developed system goes into production.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know