Refine the key abstractions to decide on the important design elements (such as classes and subsystems) that make up the architecture, and provide at least a name and brief description for each. Add them to the Design. Gain consensus with the developers on architecturally significant design choices.

The Developer and the Architect work togehter to define each architectural mechanism into design elements by looking at the requirements in the context of the current iteration. Include each architecturally significant scenario in scope. Look for commonality across scenarios and propose common components and patterns for their solution. Work with the developers and analysts to gain consensus on the architecture mechanisms.

While the Developer creates the concrete design and implementation of a mechanism, the Architect is responsible for assuring it's fit for it's purpose. The Architect works with the Developer to define a pattern that achieves the architectural goals.

Use this opportunity to harvest new architectural mechanisms (patterns) thay may be used in other architecturally significant areas of the design.

This step is usually performed in Elaboration. It's only performed in Construction or Transition if the architecture needs to be modified during those phases. Modifying the architecture during Construction and Transition should be avoided. See Guideline: The Importance of Architecture in OpenUP/Basic.

Ensure that the development and test architectures are defined. Note any architecturally significant differences between these environments and work with the team to devise strategies to mitigate any risks these may introduce.

Update the architecture to reflect new insights and perspectives that are identified during development. Work with the Developer to document how the architecture should be changed as a result of what's been discovered during development.

Update the descriptions of how elements collaborate - the sequence of messages - to reflect new insights and discoveries if it would be useful. This idea here is not to describe the collaborations for every system function. Architecturally significant behavior is, by definition, critical to the system functioning as it should. So it's wise to describe those collaborations so they can be thouroughly thought-out now, and referenced by future Developers and Architects later.

Assure that any new technologies, techniques, risks, etc, that are being incorporated into the architecture will work as expected.

If they don't work, identify alternatives. If the alternatives are simple (e.g. using a well-known older technology) then it can be addressed in the current iteration. Otherwise it will need to be addressed in future Elaboration iterations.

Verify that the architecture decisions are appropriate for their purpose. 

Development work should be performed to produce a Build that shows that the software architecture is viable. This should provide the definitive basis for validating the suitability of the architecture. As the software should be developed iteratively, more than one increment of the build may be required to prove the architecture. During the early stages of the project (up to the end of Elaboration), it may be acceptable for the software to have a incomplete or prototypical feel, as it will be primarily concerned with baselining the architecture to provide a stable foundation for the Construction phase.

Ensure that those who need to act upon the architectural work understand it and are able to work with it. Make sure that the description of the architecture clearly conveys not only the solution but also the motivation and objectives related to the decisions that have been made in shaping the architecture. This will make it easier for others to understand the architecture and to adapt it over time.

TBD