Session:Architecting--Results

From WICSA Conference Wiki

Deliverables/Results

The Architecting session examined the development of software architectures. We discussed some of the current approaches to architecting, and what the most pressing needs and problems are. The results, summarized below, yield no particular surprises; they generally confirm views that are either well-accepted or becoming accepted.

Agile methods can affect the way the architecture is developed and used, but they present no special concerns or problems in architecting, nor do they improve our ability to architect. One minor caveat is in cases where application generators or product line frameworks are used: if the architecture is embodied in the tools, this will likely hinder the ability to modify the architecture as development progresses.

Patterns and styles are good solutions for architecting, but we need better ways to describe (teach) them. The higher-level, more abstract patterns are not as well-served by current descriptions as the lower-level, more concrete ones.

Documentation

• It is not sufficient to have the architecture embodied in the code. Many things that should be captured, such as rationale, are simply not present in the code. Thus architecture documentation is critical, although extent and representation varies widely.
• "Lightweight" documentation, such as digital photos and video tapes, are somewhat useful, but there are problems. It is still necessary to understand how the things in the photos (e.g. notecards, flipcharts) are related. Video tapes are not easily searchable for relevant information.
• Documentation (artifacts) can never yield as much or as good information as having discussions with the architects. However, over time the architects themselves forget what they've done and why, and need documentation to help remind them.
• UML is for documenting code, not architecture. We need good ways to represent the architecture. We expect representation to be domain-specific, but within a domain there needs to be widespread agreement on representations, in order to reduce the effort required to document architecture, to improve communication among architects and with stakeholders, and to improve the quality of architecture descriptions.

The architect needs to code. The most important reason for this is for team morale. An architect who tries to rule autocratically will not be successful, as there will be mutiny among the developers. Being "first among equals" and working alongside developers is the best way to achieve buy-in.