The need for stability is dictated by the nature of the Construction phase: in Construction the project typically expands, adding developers who will work in parallel, communicating loosely with other developers as they produce the product. The degree of independence and parallelism needed in Construction simply cannot be achieved if the architecture is not stable.
The importance of a stable architecture cannot be overstated. Do not be deceived into thinking that ‘pretty close is good enough’ – unstable is unstable, and it is better to get the architecture right and delay the onset of Construction rather than proceed. The coordination problems involved in trying to repair the architecture while developers are trying to build upon its foundation will easily erase any apparent benefits of accelerating the schedule. Changes to architecture during Construction have broad impact: they tend to be expensive, disruptive and demoralizing.
The real difficulty of assessing architectural stability is that “you don’t know what you don’t know”; stability is measured relative to expected change. As a result, stability is essentially a subjective measure. We can, however, base this subjectivity on more than just conjecture. The architecture itself is developed by considering ‘architecturally significant’ scenarios – sub-sets of use cases which represent the most technologically challenging behavior the system must support. Assessing the stability of the architecture involves ensuring that the architecture has broad coverage, to ensure that there will be no ‘surprises’ in the architecture going forward.
Past experience with the architecture can also be a good indicator: if the rate of change in the architecture is low, and remains low as new scenarios are covered, there is good reason to believe that the architecture is stabilizing. Conversely, if each new scenario causes changes in the architecture, it is still evolving and baselining is not yet warranted.