33.9. Process: Iterative Architecture in the UP
The UP is an architecture-centric iterative and evolutionary method. This does not mean a waterfall attempt to fully identify all architectural requirements before development, nor an attempt to fully design the "correct" architecture before program and test. Rather, it means that early iterations focus on programming and testing architecturally significant concerns (such as security) and using, proving, developing and stabilizing the key architectural elements (subsystems, interfaces, frameworks, and so on).In the UP, the architecture evolves and stabilizes through early development and test with an architecture-focus, not through speculation on paper, or "PowerPoint Architecture."In the UP, the architectural factorsor requirementsare recorded in the Supplementary Specification, and the architectural decisions that resolve them are recorded in the Software Architecture Document (SAD). Because the UP is not the waterfall, the SAD is not fully created before programming, but rather, after programmingonce the code has stabilized. Then, the SAD documents the actual system as a learning aid for others.documenting architecture and the SAD p. 655 Architectural analysis starts early, during the inception phase, and is a focus of the elaboration phase; it is a high-priority and very influential activity in software development.
Architectural Information in the UP Artifacts
- The architectural factors (for example, in a factor table) are recorded in the Supplementary Specification.
- The architectural decisions are recorded in the SAD. This includes the technical memos and descriptions of the architectural views.
Phases
Inception
If it is unclear whether it is technically possible to satisfy the architecturally significant requirements, the team may implement an architectural proof-of-concept (POC) to determine feasibility. In the UP, its creation and assessment is called Architectural Synthesis . This is distinct from plain old small POC programming experiments for isolated technical questions. An architectural POC lightly covers many of the architecturally significant requirements to assess their combined feasibility.Elaboration
A major goal of this phase is to implement the core risky architectural elements, thus most architectural analysis is completed during elaboration. It is normally expected that the majority of factor table, technical memo, and SAD content can be completed by the end of elaboration.Transition
Although ideally the architecturally significant factors and decisions were resolved long before transition, the SAD will need a review and possible revision at the end of this phase to ensure it accurately describes the final deployed system.Subsequent evolution cycles
Before the design of new versions, it is common to revisit architectural factors and decisions. For example, the decision in version 1.0 to create a single remote tax calculator service, rather than one duplicated on each POS node, could have been motivated by cost (to avoid multiple licenses). But perhaps in the future the cost of tax calculators is reduced, and thus, for fault tolerance or performance reasons, the architecture is changed to use multiple local tax calculators.