11.1 Participants in the ATAM
The ATAM requires the participation and mutual cooperation of three groups:
The evaluation team.
This group is external to the project whose architecture is being evaluated. It usually consists of three to five people. Each member of the team is assigned a number of specific roles to play during the evaluation. (See Table 11.1 for a description of these roles, along with a set of desirable characteristics for each.) The evaluation team may be a standing unit in which architecture evaluations are regularly performed, or its members may be chosen from a pool of architecturally savvy individuals for the occasion. They may work for the same organization as the development team whose architecture is on the table, or they may be outside consultants. In any case, they need to be recognized as competent, unbiased outsiders with no hidden agendas or axes to grind. Project decision makers.
These people are empowered to speak for the development project or have the authority to mandate changes to it. They usually include the project manager, and, if there is an identifiable customer who is footing the bill for the development, he or she will be present (or represented) as well. The architect is always included-a cardinal rule of architecture evaluation is that the architect must willingly participate. Finally, the person commissioning the evaluation is usually empowered to speak for the development project; even if not, he or she should be included in the group. Architecture stakeholders.
Stakeholders have a vested interest in the architecture performing as advertised. They are the ones whose ability to do their jobs hinges on the architecture promoting modifiability, security, high reliability, or the like. Stakeholders include developers, testers, integrators, maintainers, performance engineers, users, builders of systems interacting with the one under consideration, and others. Their job during an evaluation is to articulate the specific quality attribute goals that the architecture should meet in order for the system to be considered a success. A rule of thumb-and that is all it is-is that you should expect to enlist the services of twelve to fifteen stakeholders for the evaluation.
Table 11.1. ATAM evaluation team roles
|
Team Leader
|
Sets up the evaluation; coordinates with client, making sure client's needs are met; establishes evaluation contract; forms evaluation team; sees that final report is produced and delivered (although the writing may be delegated)
|
Well-organized, with managerial skills; good at interacting with client; able to meet deadlines
|
|
Evaluation Leader
|
Runs evaluation; facilitates elicitation of scenarios; administers scenario selection/prioritization process; facilitates evaluation of scenarios against architecture; facilitates onsite analysis
|
Comfortable in front of audience; excellent facilitation skills; good understanding of architectural issues; practiced in architecture evaluations; able to tell when protracted discussion is leading to a valuable discovery or when it is pointless and should be re-directed
|
|
Scenario Scribe
|
Writes scenarios on flipchart or whiteboard during scenario elicitation; captures agreed-on wording of each scenario, halting discussion until exact wording is captured
|
Good handwriting; stickler about not moving on before an idea (scenario) is captured; can absorb and distill the essence of technical discussions
|
|
Proceedings Scribe
|
Captures proceedings in electronic form on laptop or workstation, raw scenarios, issue(s) that motivate each scenario (often lost in the wording of the scenario itself), and resolution of each scenario when applied to architecture(s); also generates a printed list of adopted scenarios for handout to all participants
|
Good, fast typist; well organized for rapid recall of information; good understanding of architectural issues; able to assimilate technical issues quickly; unafraid to interrupt the flow of discussion (at opportune times) to test understanding of an issue so that appropriate information is captured
|
|
Timekeeper
|
Helps evaluation leader stay on schedule; helps control amount of time devoted to each scenario during the evaluation phase
|
Willing to interrupt discussion to call time
|
|
Process Observer
|
Keeps notes on how evaluation process could be improved or deviated from; usually keeps silent but may make discreet process-based suggestions to the evaluation leader during the evaluation; after evaluation, reports on how the process went and lessons learned for future improvement; also responsible for reporting experience to architecture evaluation team at large
|
Thoughtful observer; knowledgeable in the evaluation process; should have previous experience in the architecture evaluation method
|
|
Process Enforcer
|
Helps evaluation leader remember and carry out the steps of the evaluation method
|
Fluent in the steps of the method, and willing and able to provide discreet guidance to the evaluation leader
|
|
Questioner
|
Raise issues of architectural interest that stakeholders may not have thought of
|
Good architectural insights; good insights into needs of stakeholders; experience with systems in similar domains; unafraid to bring up contentious issues and pursue them; familiar with attributes of concern
|
|
