6.4 Architect's Walkthrough

A number of development milestones that require the attention of the software architect can occur. Unless the architect is available, the development team may be faced with either waiting for approval-the kiss of death for rapid development-or making assumptions that may not always be accurate. Correcting these incorrect assumptions at a later date is always substantially more expensive and difficult than getting them right initially. Therefore, the architect must give the impression that he or she is always available with the expectation that the internal demands of a development team will be greatest early in the development process through the design process, tapering off somewhat during implementation, testing, and deployment. The best way to be available is to walk around periodically and to talk to people about their progress. If any significant issue comes up, set up an appointment between the two or three people most involved and discuss it at some time separate from that devoted to the walkthrough. This approach limits the time spent during the walkthrough and gives the people involved a chance to work things out on their own before the meeting. If the meeting continues to be necessary, everyone will be prepared to focus on a specific problem, which, if properly facilitated, can lead to a short, highly productive meeting.

Another benefit of the walkthrough is that the architect can get a lower-level understanding of the project details than would be available from just meeting with the team leaders. Restraint is required to remember that the primary objective of the architect in a walkthrough is to listen and understand the problems rather than immediately to attempt to resolve every issue. In fact, the less direct guidance given in a walkthrough, the better. Rather, the software architect should think about the problem and make suggestions to the appropriate team leader. This will keep the team leader in the information loop, allowing him/her freedom in incorporating the architect's suggestions into the overall team direction. In addition, it will provide the architect with greater insight into team dynamics in future walkthroughs, when he or she can gauge to what extent the overall team incorporated his or her suggestions. The architect should avoid making too many suggestions directly to team developers because these suggestions are frequently taken as mandates, regardless of the direction set by the team leaders. Without fail, the political and organizational problems resulting from such actions will overshadow any short-term technical benefits. In general, the architect should always be willing to listen, but direct action, and even suggestions, must be performed with care, taking the needs of the entire development effort into consideration.

So after nine months or so with the same team, the software engineer may realize that there are still hotly debated topics, people who just don't like each other, and a project that is falling behind schedule. The issue most new architects face is evaluating whether their efforts have actually made a difference on a particular software project. Fortunately, a few heuristics are effective for recognizing success. Unfortunately, the ultimate metric, repeatedly delivering high-quality software on time within the estimated constraints, typically takes several years to establish.

Heuristic 1: Arguments within a team are over increasingly trivial subject areas.

With any group of software professionals of diverse backgrounds, there will always be disagreements of some kind or another. Early in a project new to software architecture, the typical disagreements focus on whether or not some task, such as developing a business model layer, is the right thing to do. Later, if the architect is successful, the team implicitly agrees on what to do, and the developer battleground shifts to arguments about how to accomplish the task, such as the specific design patterns that best map to the task. These arguments will be just as heated and impassioned as the previous wave of disagreements, but the debated issues are at a lower level. Later, if there is an implicit buy-in on how to accomplish the task, new arguments will arise, again just as heated, on what an implementation of how to accomplish the task looks like. While the volume levels and passion may be constant and to an outside observer the internal problems appear unchanged, the shift of focus indicates a consensus on vision, architecture, and design. Achieving this consensus is a monumental accomplishment and eliminates a slew of problems that would arise if such a consensus did not exist.

Heuristic 2: When it appears that there is no consensus initially, consensus is easy to achieve after listening to all sides.

Frequently, when establishing the overall vision and defining the architecture for a project, complete consensus is nearly impossible to achieve. For whatever reasons, there will always be a few people who will need concrete evidence of the benefits of the approach on their own personal level, before they will accept any vision save their own. Later, if a consensus is established, there will be roughly the same number of disagreements. However, most frequently, one side or the other will be mainly motivated to ensure that its concerns are acknowledged and known to the team without actually demanding that its issues be addressed immediately. The architect should recognize such concerns for what they are and allow them to be presented to the team. Typically, when the minority side has been convinced that it has been heard and understood, it will not object to a more popular alternative plan that satisfies the architectural vision and project objectives.

Heuristic 3: Other developers are willing to argue the merits of the architecture.

When developers want to argue the merits of the architecture, it indicates team buy-in for the system architecture. Note that if the software architect considers him/herself the sole defender of the architecture and is always the first to rise to its defense, the architect will never realize that this architectural buy-in has occurred. Therefore, the architect should be patient and give others the opportunity to comment when architectural issues are challenged. If the architect is exceptionally successful, several meetings will pass where consensus is reached in accordance with the architectural principles of the project without the architect's saying anything. Of course, when this occurs in several consecutive meetings, the architect is obligated to bring donuts to subsequent similar meetings.

Heuristic 4: There is an implicit willingness to delegate development issues to teams.

As the subjects of many meetings degrade in quality, fewer of the team members will care about how many of the development issues (configuration management trees, coding conventions, utility modules, etc.) are resolved. In such cases, it is beneficial to everyone to delegate an issue to a group of two or three people. This group can meet independently, come to an agreement on the issue, and present the agreed-upon solution to the development team at a later date. In fairness, it is important that everyone agree to accept whatever solution is agreed upon by the smaller group. Otherwise, interested parties will not join the group in hopes of overriding the group's decision later, thereby wasting the efforts expended by the developers who possessed the initiative to join the smaller group.

Heuristic 5: The software architecture becomes assumed rather than decided.

There is an implicit acceptance that adhering to the architectural principles has some value so that there is no longer any need to debate it or even talk about it except when mentoring new developers or presenting it to new stakeholders. Design and code reviews rarely turn up areas that reflect a lack of understanding regarding the software architecture. They may take just as long but now focus on lower-level issues, such as variable naming or lack of reuse.

Conversely, software architects know they are not succeeding when the opposite of these heuristics are true-for example, if various fundamental aspects of the architectural vision are questioned throughout the development life cycle, or if achieving a consensus on meaningful issues is increasingly difficult to obtain. If a consensus is developing against the architectural vision, then it is necessary to understand the opposing arguments and discover why they are so compelling to the developers on the team. Sometimes, gaining insight into the compelling nature of the opposing arguments may result in modifying the architectural vision to one that can achieve buy-in from the development team. At other times, the software architect needs to present a better case as to why the proposed architecture is better than the available alternatives. Frequently, this explanation may require educating the team on technologies and industry trends of which they may not be aware. This education process, along with everything else that is required to achieve vision and architectural buy-in, is a prerequisite for a successful development project and for a software architect to be successful in his or her role.

It is important to differentiate between architectural leadership and management. The most obvious difference is that software architects are responsible for creating and articulating the technical vision of the development effort. Frequently, the architectural vision is not limited to a single effort but provides a blueprint of what the organization can accomplish in the long run. The success of the current project validates the architectural vision and provides greater confidence that the long-term architectural vision is achievable through similar methods. Management, on the other hand, is focused on the success of a short-term project with limited, well-defined objectives. For example, an architectural vision could be a component-based enterprise framework that may be used to produce scalable applications in several domains. A manager's goal is to produce a workflow management system for logistics in nine months with a team of 12 developers. Similarly, a manager must ensure that a specific set of agreements are satisfied and often must interact with external stakeholders to verify that what is being produced matches their expectations. Any changes in direction, such as new requirements or procedures, are communicated from external stakeholders to project management, whose responsibility it is to communicate the changes to the team. The architect, however, is focused more internally and communicates why the work is meaningful and the purpose of doing things in the prescribed manner. It is not uncommon to have the software architect advocate taking more risk and adopting radical changes if he or she is expected to produce a technically superior product without involving too many additional resources. Management, on the other hand, tends to be more cautious and more willing to repeat technical approaches that have been successful in the past rather than gamble on state-of-the-art techniques. All but the most routine of software development efforts require both a software architect and a project manager.