架構情況一切穩定。
可靠性的需求出自於建構階段的特性,在建構專案期間中,往往會擴編、增援開發人員,他們在產品生產過程中並行工作,密切地相互溝通。若架構不穩定,則無法達到建構所需的獨立性及並行化作業。
穩定架構的重要性不容誇大。不可抱著得過且過的心態,認為「差不多就算夠好了」,不穩定就是不穩定,應著手修正架構,即使會延後建構時間,也不應貿然進行。架構尚待修正,但開發人員卻急於據此架構進行建構時,協調一旦出問題,將導致原本可加速時程的明確效益
付諸流水。於建構期間變更架構,影響層面較廣,往往代價昂貴,且容易造成干擾並打擊士氣。
評量架構穩定性的最大困難在於「無從知道的事情便無從判斷」,只能根據預期變更結果來衡量穩定性。因此,穩定性基本上是一種主觀評量。
不過,我們仍應以主觀判斷為重,單純推測為輔。架構本身的開發乃依據架構重要性情境考量,亦即從使用案例中,採取部分最具技術面挑戰行為者,同時也是系統所必須支援者。評量架構穩定性牽涉到確保架構涵蓋面的廣度,乃至於確保架構於後續過程中不會出現突發狀況。
過去的架構規劃經驗也是值得借鏡的指標:假如架構的變更率低,且在納入新狀況後仍維持低水準,便可讓人相信該架構確實穩定。相對的,若每次遇到新狀況時都會造成架構變更,則表示架構仍在演進階段,基準線尚未確立。