一般的に認められた定義によれば、ソフトウェア設計者の役割は「利害関係者からの入力に基づいたシステムのマクロ面」を定義することである。これは、技術的問題点だけでは設計者を動かすことができないことを示す。設計者は、技術やアーキテクチャ設計の選択にしばしば制約を受ける、異なる利害関係者の要件を念頭に置く必要がある。
Phillip Calçado氏は自身のブログで、デベロッパはアーキテクチャ決定によって直接影響を受けるので、システムユーザやプロジェクトスポンサーとともに、ソフトウェア開発チームが重要な利害関係者になると強調する。従って、設計者は、選択範囲が制限されたり、客観的に見てプロジェクトに最適である技術を廃棄する結果になっても、開発環境を考慮に入れる必要がある(source)。
たとえば、Calçado氏はチームのスキルを考慮に入れることが重要であると強調する。
新しいWebサイトを開発するため、長期間にわたりVB6プログラマーチームに参加したと考えます。Ruby on Railsでの経験がジョブにとってまさに最適なツールであることはわかっていますが、誰も経験がありません。Webサイトは短期間で配信する必要があり、研修する時間はありません。最適な技術選択に進みますか？
物理的であってもなくても、別の制約がチームの配置から発生することがある。Claçadoの例では、トレーダーの証券取引システムには、共同で作業する他のチームとのデータ収集、ユーザとの対話、および取引の3つの部分がある。システムを単一のモジュールとして技術的に設計することが最適な選択だとしても、設計者は「チームが公正で独立して従事できるよう」、むしろブラックボックスである3つのモジュールを設計しなければならない。
より一般的に言えば、Calçado氏は「フィードバックを集め、あなたの決定によって最も影響を受けるであろうグループの意見を尊重する」ことが重要であると主張する。コメンテーターの1人であるAlberto Brandolini氏は、「アーキテクチャ設計がチームのメンバーによってコミットメントを達成できること」を設計者が保証する必要がある「持続可能なアーキテクチャ」という表記を使用して同じ方針で進めていく。
この種の制約を考慮することは、プロジェクトを成功させるのに重要である。ただし、これは、時間やスキルのアベイラビリティの制約またはチームからの抵抗によって、プロジェクトに付加価値を付ける技術を最終的に廃棄することを意味するものではない。設計者の役割は、変化を実際に持ち込むための戦略を練り上げ、これを設計に統合することである。
[…]設計者はシステムのロードマップへの移行を含める必要があります。[…] スクリプトまたは小さなプログラムが必要な場合、たとえば、新しいWeb開発プラットフォームを徐々に導入する場合、Ruby（または最適な技術）を使用することで開始できます。最重要なのは、今後どのようなシステムを目指し、またこれをどのように実現するかをはっきりさせることです。
原文はこちらです：http://www.infoq.com/news/2008/02/architecture-is-about-people