Category: Softwares

97 Things Every Software Architect Should Know – 19/97

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

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. The project manager (co-pilot) performs the day-to-day management tasks leaving the architect free from the hassles of mundane tasks and people management. Ultimately the architect should have responsibility for the delivery and quality of the projects to the business, this is difficult to achieve without authority and this is critical the success of any project.

People learn best by watching others; it’s how we learn as children. 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 work-around or solution. It is perfectly respectable for an architect to ask for help from the team. The team should feel part of the solution but the architect should chair from discussion and identify the right solution(s).

Architects should be bought into the team at the earliest part of the project; they should not sit in an ivory tower dictating the way forward but should be on the ground working with the team. Questions about direction or choices of technology should not be spun off into separate investigations or new projects but be made pragmatically through hands-on investigation or using advice from architect peers, all good architects are well connected.

A good architect should be an expert in at least one tool of their trade, e.g. an IDE, remember they are hands-on. It stands to reason that a software architect should know the IDE, a database architect should know the ER tool and an information architect an XML modelling tool but a technical or enterprise architect should be at least effective with all levels of tooling from being able to monitor network traffic with Wireshark to modelling a complex financial message in XMLSpy – no level is too low or too high.

An architect usually comes with a good resume and impressive past, he can usually impress the business and technologists but unless he can demonstrate his ability to be hands-on it’s difficult gain the respect of the team, difficult for the team to learn and almost impossible to deliver what they were originally employed to do.

97 Things Every Software Architect Should Know – 18/97

A common problem in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems: the quest for unbounded generality rarely serves them well (if at all). The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork.

Favoring simplicity before generality acts as a tiebreaker between otherwise equally viable design alternatives. 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. Of course, it is entirely possible (and more than a little likely) that the simpler solution will turn out to be the more general one in practice. And if that doesn’t turn out to be the case, it will be easier to change the simpler solution to what you now know you need than to change the ‘general’ one that turns out not to be quite general enough in the right way.

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. 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, thereby adding to the accidental complexity developers and future architects must face.

Although many architects value generality, it should not be unconditional. People do not on the whole pay for (or need) generality: They tend to have a specific situation, and it is a solution to that specific situation that has value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.