Activity: Refine the Architecture
This activity completes the architecture for an iteration.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Relationships
Parent Activities
Description

This activity:

  • Provides the natural transition from analysis activities to design activities, identifying:
    • appropriate design elements from analysis elements
    • appropriate design mechanisms from related analysis mechanisms
  • Describes the organization of the system's run-time and deployment architecture
  • Organizes the implementation model so as to make the transition between design and implementation seamless
  • Maintains the consistency and integrity of the architecture, ensuring that:
    • new design elements identified for the current iteration are integrated with pre-existing design elements.
    • maximal re-use of available components and design elements is achieved as early as possible in the design effort.
Properties
Event-Driven
Multiple Occurrences
Ongoing
Optional
Planned
Repeatable
Staffing

These activities are best carried out by a small team staffed by cross-functional team members. Issues that are typically architecturally significant include usability, performance, scaling, process and thread synchronization, and distribution. The team should also include members with domain experience who can identify key abstractions. The team should also have experience with model organization and layering. The team will need to be able to pull all these disparate threads into a cohesive, coherent (albeit preliminary) architecture.

Because the focus of the architecture effort is shifting toward implementation issues, greater attention needs to be paid to specific technology issues. This will force the architecture team to shift members or expand to include people with distribution and deployment expertise (if those issues are architecturally significant). In order to understand the potential impact of the structure on the implementation model on the ease of integration, expertise in the software build management process is useful to have.

At the same time, it is essential that the architecture team not be composed of a large extended team. A strategy for countering this trend is to retain a relatively small core team with a satellite group of extended team members that are brought in as "consultants" on key issues. This structure also works well for smaller projects where specific expertise may be borrowed or contracted from other organizations; they can be brought in as specific issues need to be addressed.