8.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. To be effective in creating and presenting briefings, using 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, after 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 be appropriately updated as the situation changes. This includes the verification that targets were successfully incapacitated, the position and direction of mobile units were clearly identified, and additional defensive capabilities were acquired by the enemy since the last time they were directly observed. Every commander knows that viewed information is immediately obsolete because 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 replanning the current project plan, the architect should wisely be utilizing feedback to alter the technical approach to the project. The issues of when to get feedback, how to get it, and what to do with 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 that 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, a few milestones provide special opportunities to extract useful feedback.