原則2 部分最適と全体最適を両立
短期的要求を満たし将来への布石も打つ
ITシステムの構築には、さまざまな制約が付いて回る。例えば、既存システムと連携するための接続仕様や対象ハードウエア、使用するデータベースが既に決まっているなどだ。コストや時間の制約もある。そうした制約を受け入れつつ、変化の構えを盛り込む必要がある。これを実現するには、ITアーキテクトの二つめの行動原則である「部分最適と全体最適の両立」が不可欠となる。
一つめの原則（見えにくいところを可視化）に従うことで、全体最適となるアーキテクチャーの枠組みが浮かび上がってくる。その枠組みの中で、短期的には制約を受け入れるために部分最適を残す。そして、長期的には要素技術や要求仕様は変化するという前提に立ち、全体最適に近付くように段階的に改善（是正）を図るべく、その方針（計画）を打ち立てる。重要なのは、アーキテクチャーを今使える技術や当面の要件に最適化しないことだ。
将来の変化は誰も正確には予測できない。だから、すべての構成要素を入れ替え可能にしておく。つまり、全体アーキテクチャーをコントロールできようにする。具体的には、ベンダーや製品へのロックインを回避するために移植性（ポータビリティー）を確保し、“息の長い”システムをデザインする。
フレームワークで生産性を高める
移植性を確保するには、外から調達する部品が別の部品で代替できる必要が生じる。となると、その部品でなければ実現できない固有機能は極力使用を避ける必要がある。つまり、調達する個々の部品の役目を小さくし、逆に各部品を組み込むアプリケーション本体の役目を大きくすることになる。ただし、アプリケーション本体が余分に負う責務をアプリケーション開発者に転嫁したのでは、短期的なゴール（QCD）を達成できなくなってしまう。
そこで、全体アーキテクチャーをデザインする際に、アプリケーション開発の負荷が低くなる方策を講じておく。つまり、アプリケーション開発の視点から、生産性が高くなるように最適化したアプリケーションフレームワーク（共通の機能セットを実装したクラスやライブラリ）を設けることが、アーキテクトに求められる（図3）。
時代を貫いて役立つ技術を見分ける
昨今は、便利なオープンソースの部品が充実している。手軽なのでそうした部品を多用しがちだが、個別に設計された部品を組み合わせると設計思想の食い違い（アーキテクチャーミスマッチ）が生じて、整合性を取りにくくなる点に留意が必要だ。
各部品は特定領域の問題を解決するために用意されている手段であり、時の流れとともに人気の部品は変化する。アーキテクトは、一過性のブームに終わる技術と、時代を貫いて課題解消に役立つ技術を見分けなければならない。その上で、ITシステムが抱える複雑さに対処でき、かつ自らのデザインに合致する長命の部品を組み込んだアプリケーションフレームワークを整備する必要がある。
