アーキテクチャーは安定していると思われる。
作成フェーズの特性上、安定の必要性があるのは当然のことです。作成においては、プロジェクトは通常は拡大します。それは、共同で作業する開発者 (製品の作成にあたって他の開発者との多少のつながりをもつ) の数が増えるからです。
アーキテクチャーが安定していないと、作成において必要とされる程度の独立性と並列性を達成することはできません。
安定したアーキテクチャーの重要性は、過大評価されすぎることはありません。
「ほとんど最高に近ければ十分である」という考えに陥らないでください。不安定は不安定でしかなく、先を急ぐよりは、現在の作成フェーズが遅れてもアーキテクチャーを是正するほうがましです。
開発者がアーキテクチャーの基盤上での構築に取り組んでいる間に、アーキテクチャーの修理作業にからんで調整上の問題が発生すれば、スケジュールが早まれば確実に得られたはずの利益が簡単に消え去ってしまいます。
作成フェーズでのアーキテクチャーの変更は、多大な影響を及ぼします。多くの場合、コストがかかり、混乱を生じ、しかも意欲の喪失をまねきます。
アーキテクチャーの安定度の評価における本当の難題は、「分からないものは分からない」という点にあります。安定度は、見込まれる変更に対して相対的に評定されるからです。
すなわち、安定度は、本質的に主観的に評定されるということです。
しかし、そのような主観性を、単なる推測以上の土台の上に置くことができます。
アーキテクチャーそのものは、アーキテクチャーの面から見て重要なシナリオを考慮に入れたうえで開発されます。そのようなシナリオとは、システムが対応すべき技術的に最もやりがいのある作業を代表するユース・ケースの 1 つです。
アーキテクチャーの安定度の評価では、将来そのアーキテクチャーにおいて「想定外の事態」が起きないようにするため、アーキテクチャーの対象を広範囲に設定することも懸案事項の 1 つになります。
アーキテクチャーに関するこれまでの経緯も重要な指針になることがあります。アーキテクチャーの変更率が低い場合に、新しいシナリオを取り上げたときにも低いままであれば、そのアーキテクチャーは安定していると考えてもよい十分な根拠となります。
それとは逆に、新しいシナリオが原因でアーキテクチャーに変更が加えられた場合は、そのアーキテクチャーはまだ発展途中であって、基本的な点で未確定であるということです。