7.3. Communication Responsibilities

One of the duties of a software architect is to serve as the spokesperson of the development team on technical matters. As such, the architect will frequently need to prepare and present briefings to upper management and other stakeholders. Furthermore, briefings are usually faster to create than white papers and are a good preparatory vehicle for outlining the key concepts for future papers. In order to be effective in creating and presenting briefings, the use of a few straightforward techniques can increase the odds of success.

As a technical person, there is always a tendency to convey too much information on a technical topic. Upper-level management frequently is interested only in conclusions—summary information. Also, other technical people can already figure out the details, once the basic idea has been successfully conveyed. First-time technical presenters nearly always cram much more detail and information onto charts than the briefing-chart medium can effectively handle.

In a military campaign, it is essential that information is appropriately updated as the situation changes. This includes the verification that targets were successfully incapacitated, the position and direction of mobile units, and the additional defensive capabilities acquired by the enemy since the last time they were directly observed. Every commander knows that viewed information is immediately obsolete, as several of the campaign elements are constantly in flux. Similarly, on any software project, the status of a development team is also changing. Initial assumptions about time lines, task complexity, and resources will need to take advantage of new information throughout a project's life cycle. While project management will be responsible for the replanning of the current project plan, the architect should wisely be utilizing feedback to alter his technical approach to the project. The issues of when to get feedback, how to get it, and what to do with it once you have it will be addressed in considerable detail.

In some respects, acquiring feedback should be a continual part of the architect's daily responsibilities. It has already been mentioned that in a walkthrough, the architect should be listening for details which reflect how the project is progressing and what obstacles are occupying the most resources. Furthermore, where time permits, cross-team reviews of deliverables should be a part of every development process. Still, there are a few milestones which provide special opportunities to extract useful feedback.