5.4. Architect's Walkthrough
A number of development milestones occur that require the attention of the software architect. 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, an architect must give the impression that he/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 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 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 you get a lower-level understanding of the project details than you would 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, 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 your suggestions into the overall team direction. In addition, it will provide you with greater insight into team dynamics in future walkthroughs, when you can gauge to what extent your suggestions were accepted by the overall team. The architect should avoid making too many suggestions directly to team developers, as 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, you 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, there are a few heuristics which are effective for recognizing when you are succeeding as an architect. Unfortunately, the ultimate metric, repeatably 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 XYZ is the right thing to do. Later, if the architect is successful, there is an implicit agreement on what to do, and the developer battleground shifts to arguments about how to accomplish XYZ. 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 XYZ, new arguments will arise, again just as heated, on what an implementation of how to accomplish XYZ looks like. While the volume levels and passion may be constant and to an outside observer the internal problems appear unchanged, it is the shift of focus which indicates vision, architectural, and design consensus. Achieving this consensus is a monumental accomplishment and eliminates a slew of problems which would arise did such a consensus 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 is mainly motivated to ensure that its concerns are acknowledged and known to the team and is not actually demanding that all of its issues are addressed immediately. An 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 which satisfies the architectural vision and project objectives.
Heuristic 3: Other developers are willing to argue the merits of the architecture.
When this occurs, it indicates team buy-in for the system architecture. Note that if the software architect considers himself 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 to 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 less obvious.
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 to new stakeholders. Design and code reviews rarely turn up areas which 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, you know when you are not succeeding as a software architect 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 achieving a consensus on meaningful issues is increasingly more 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 which 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 may require educating the team on technologies and industry trends which they may not otherwise be aware of. 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/her role.
It is important to differentiate between architectural leadership and management. The most obvious difference is that the software architect is 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 which 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 twelve developers. Similarly, a manager has to ensure that a specific set of agreements are satisfied and often has to 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 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 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 which 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.