Quotes from Richard Monson-Haefel

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.

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.

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.

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.

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.

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.

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.

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.

You don't drive the architecture, the requirements do. You do your best to serve their needs.

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.

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.

Learning to treat people with respect, and learning give them the benefit of the doubt, is one of the core skills that turn a smart architect into an effective one.

One thing most software architects fail to realize is that a software architect is also a leader.

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.

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

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

In the real world, the best architects don't solve hard problems they work around them.

Software architects have to take responsibility for their decisions as they have much more influential power in software projects than most people in organizations.

Design is a discovery process, as we implement we discover new information, often impossible to know up front. 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 too. Clinging onto your original designs and trying to force them through is only going to end up with one result so you need to learn to understand that it will never look like that.

We cannot love our customers so much, love we not their customers more.

If your customer willingly and knowingly doesn't care about certain important things that your customer's customer cares about—as happens from time to time—consider stepping away from the project.

As you work in requirements meetings to design software, pretend that your customer is not your customer. It turns out that this is a very easy thing to do, because it is true. Your customer is not your customer. Your customer's customer is your customer. If your customer's customer wins, your customer wins. Which means you win.

Many software projects get software architects involved only in the design phase, then they move to other projects or the consultation contract ends. How can they ensure that their deliberate architectural decisions have been implemented correctly? Their decisions will be at best good intentions unless they follow-through with them.

Software architects have to take responsibility for their decisions as they have much more influential power in software projects than most people in organizations. Studies of software projects show over two-thirds of them either are outright failures or deliver unsuccessfully (deadline slip, budget overruns, or low customer satisfaction). Many of the root causes point to improper decisions software architects made, or failures of follow-through on the right architectural decisions.